I'm not particularly fond of introducing "magical" names into Poser content, but some mechanism for storing per-material, per-object and per-scene settings is definitely needed. The database approach that ADP suggested has its merits, but it's not the most practical for sharing those settings with other users. Content creators in particular would need some way to package that information into the usual zip files. So as far as I can see, there are two options: find some sneaky way to add them to the standard Poser files or keep them in separate configuration files that are then distributed with the content. I won't go into the pros and cons of each approach, as that is not exactly a new topic. But we will have to implement at least one of them in the long run.

This is completely separate from the question of how end users should specify settings when running the exporter. We're talking user interface versus persistence layer here - two very different things. Of course there has to be some way of picking objects or materials from a list and changing particular settings for them. And it has to be a damn fine way, too, or the complaints we're already hearing preemptively from people who render complex scenes will never stop.

With Sketchup the standard way of dealing with this is simply to provide the lights for each render engine as a prop you insert into the scene.

that would'nt be to much to do for poser. and lets face it. whatever method is chosen, someone's gonna complain.

Quote - and lets face it. whatever method is chosen, someone's gonna complain.

It's the tag line for my upcoming independent film "Open Source Development" (working title): There will be complaints.
Edit: Either that or "No one ever takes the refund."
 

Quote - LOL.  I was just going to ask how to determine target of a Poser spot.  I couldn't figure it out.  Now i know why.

Rotation seems not to work. Lux says: Parameter 'rotation' not used.

What about a "LUX_target" prop (parented to the light pointing to it)? :)

Quote - > Quote - LOL.  I was just going to ask how to determine target of a Poser spot.  I couldn't figure it out.  Now i know why.

Rotation seems not to work. Lux says: Parameter 'rotation' not used

What about a "LUX_target" prop (parented to the light pointing to it)? :)

There's a "to" parameter for spotlights and infinite lights. I suspect the necessary computation would not be all too different from what BB's implemented for the camera. I think he's already done the same  - and much more - for lights, which is why I've been twiddling my thumbs waiting for him to release his code. But all this fiddling with ad-hoc workarounds is getting a bit ridiculous, so I might just whip up something quick tonight for the interim.

It's been a while since i had to use any math skills, but I would think you could mathmatically determine the target if you know the origin and the rotation; at least within reason anyway.  ie, if the spot is pointing to the wall, does distance really matter except for falloff?

I'm getting a headache just thinking about math :p  but it should be easy to put a target 1 meter from a light, apply the rotation and determine the coordinates.

Quote - > Quote - this is how it looks in luxblend.

you pick the object that you want ot use as a ligh. and then in luxblend you make it a light.

Yes, I know. But things are a bit different with LuxPose. We decided to have an independent GUI. Simply because there are lots of P5/P6 users and so mutch differences between the versions.

I think the best method is the LuxBlend one, for there are many features in Lux which doesn't exist in Poser, period, and if users use Lux, it's to take full advantage of them.
Like, sun-lights, sky-lights, area-lights, and generally different types of lights (black body, spectral, RGB).

For lights, the exporter GUI really needs a "how do you want to translate this" feature, allowing people to change their infinite light into a sun, their point light into an area one, or just to make disappear a light not needed. Imagine wanting to import a Poser scene and have it use inside Lux a sun, a directional and an area (geometry) light. It has to be possible.

Quote - Err... Poser 8 does just that with IDL turned on and an ambient setting (former versions just had the object glow without emmiting light)... So the question is: why reinvent the wheel (and add corners)?

Because it's not a wheel.
Lux area lights are real lights, not just faked ones. You can have different types of area lights in Lux, like black body, spectral, RGB ones. They have the same attributes a "light" light has.

That been said, and since it is faked with Ambient inside Poser, the best solution would be to tie this to a given material. You just have to make sure the user can edit this material to make it a real area light in Lux.

Quote - Just a quick request.  A few pages back rty posted a sunsky for Lux.  It works great.  Would there be a way to incorporate that without having to edit the file everytime?

That's what we're discussing here - how to add features which don't exist in Poser, and thus can't be auto-magically translated.
It requires some (more) GUI, I'd say.

Quote - Seems that any render engine has some special things. No other engine I know of has a light that acts like a "skyglob" including a light for example.

Vue?...

Quote - Ok, we could assume any IBL should be replaced by a sunsky.

Could work, although no matter how you do it, you need to have a GUI part where you can set the settings for the sun.
I'd rather sugest to let the user transform his Poser lights as he wants, since there is little correspondence between Poser and Lux. With a special mention for area lights, since here we have a material which becomes a light, jumping categories.

Quote - But what if somebody is using a real skyglobe and addtionally IBL?

Too bad for him, I'd say.
People need to understand that Poser scenes will need a minimum of adaptation to be imported into Lux. Scenes using the tweaks and cheats we're used to use inside Poser will need to get rid of them before export.

Quote - So if it is possible to translate pure Poser materials to something like "Meta-Materials" (beside of the conversion to Lux matarials), the hardest work is done for any other render engine.

I sure would like to have the last word on materials (LuxBlend-like), meaning that, if I think that the whole gas refinery of nodes I used in Poser could be simply replaced by Lux "glass" (for instance), I should be able to do it, notwithstanding whatever clever translation the material translator might find for it.
It's a simple question of optimization.

Quote - LOL.  I was just going to ask how to determine target of a Poser spot.  I couldn't figure it out.  Now i know why.

I have this code already. What are you guys talking about?

I didn't publish it yet. I'm busy putting it all together.

I haven't yet had time to re-factor all this stuff. So if you're anxious to fit the spotlight code what you have, here it is.

I plan to completely rewrite this so don't spend too much time evolving it.

I'm sorry, but this program is just too wordy - too many lines of code that don't do anything. Scrolling past 200 lines of stuff that emits only a few lines in the Lux scene is making me nutty.

I'm writing new add-ons to BBML that are making the generation of Lux scene properties really trivial.

I'm hoping they stay trivial as I also implement the same for Kerkythea or whatever else we want.

Quote - > Quote - Seems that any render engine has some special things. No other engine I know of has a light that acts like a "skyglob" including a light for example.

Vue?...

Didn't say I know any render engine ;)

Quote -
I sure would like to have the last word on materials (LuxBlend-like), meaning that, if I think that the whole gas refinery of nodes I used in Poser could be simply replaced by Lux "glass" (for instance), I should be able to do it, notwithstanding whatever clever translation the material translator might find for it.
It's a simple question of optimization.

Yes, exactly this is what I mean. 

We have to do with several "know-how levels", especial with Poser. So a "full automatic" is a really good thing. But,  as you mentioned, we need something to override the automatic.

This is why I say anything with a prefix in his name should be left alone or handled in a special way. At the end it would hurt nobody. 

I'm going to be building the material GUI where you review what it does and one-click override to whatever you want. Don't worry about it.

Thanks again guys. Great work :o)

Laurie

YAY got a Dalek to render... Alpha .9a on poser pro (not 2010)

first attempt :)

Bagginsbills code added to the package. Download: See footer

Quote - Didn't say I know any render engine ;)

You didn't, but then Vue is probably the most used app here after Poser and DAZ Studio...
My point being that many (most) users know what to expect when they hear "sun"-light.

Quote - We have to do with several "know-how levels", especial with Poser. So a "full automatic" is a really good thing.

"Automatic" looks good on paper, but it usually is too sophisticated for the base users, and too limited for the advanced ones. Meaning you get flak from both sides.
I'm a partisan of making a somewhat advanced GUI, which might cause some comprehension problems to newbies at the start, but since being a newbie isn't a career, but just a temporary status, they will eventually be happy the exporter doesn't limit them to their original noob-ness.

Or, to be less consensual, if somebody wants to use an external renderer, he has to prove he is capable of taking 30 minutes to read through the Lux documentation. If he doesn't, well...

Quote - This is why I say anything with a prefix in his name should be left alone or handled in a special way. At the end it would hurt nobody.

No, I don't agree with this way of doing things. You shouldn't need to create fake named materials (complicated!) or lights; It's only once inside the exporter you should be asked to decide what to keep, what to reject, and what to transform into whatever Lux-ish.

Ideally, I load a 2-years-old scene, I hit "export" and it's at this point that the exporter allows me to manage the export to Lux, including material translation ("that's what I suggest, do you want to tweak it/use something else?"), light creation("Those lights found, what do I change them to? Any materials I need to lightify?"), and of course the classic setting already covered by the experimental GUI BagginsBill released last week.

Quote - I'm going to be building the material GUI where you review what it does and one-click override to whatever you want. Don't worry about it.

Great. That's the spirit!
Code is clever, but humans are even cleverer, and if at some point somebody decides not to use some specific Lux feature because it is bugged, he should be able to bypass it.

Fantastic work guys! Simply fantastic!

I gave it a try and came up with this image:

Miki2 with Kozaburo's Short Bob hair.
Rebel for Miki2 by MindVision-GDS
Stonemason's Urban Sprawl 2 The Big City
The only light is sunsky using code from rty's post up-thread.

This rendered for about 4hrs.

Looking forward to new updates.

Thank you for all your hard work on this project!

Unrelated - almost.

Ideally, we would also need a feature for editing the exported .lxm/.lxo/.lxs files, to change settings.

Imagine all of a sudden I want to change bidirectional to path; It would be nicer if, instead of redoing the whole export (including translation of materials and lights), I could just reload the exported files and change the Integrator parameter. It's a line in the file, so it's not complicated, but it always looks better (and more professional) when it's done through a GUI than when you need to fire up Notepad.

I know it is trivial to code, but it should better be planned from the beginning than added afterwards.

Quote - The only light is sunsky using code from rty's post up-thread.

LOL. My point: "Sun" light will be the most used feature in the exporter, you'd better get it right... :-D

Cool picture, BTW

Quote -
Fantastic work guys! Simply fantastic!

I gave it a try and came up with this image:

Really good!

Did somebody say something like "impossible to render usable skin without SSS"?

Quote - Unrelated - almost.

Ideally, we would also need a feature for editing the exported .lxm/.lxo/.lxs files, to change settings.

Imagine all of a sudden I want to change bidirectional to path; It would be nicer if, instead of redoing the whole export (including translation of materials and lights), I could just reload the exported files and change the Integrator parameter. It's a line in the file, so it's not complicated, but it always looks better (and more professional) when it's done through a GUI than when you need to fire up Notepad.

I know it is trivial to code, but it should better be planned from the beginning than added afterwards.

Actually the "framework" is planed to do so. All is in seperate, independent parts. A GUI is able to call this parts (exportFilm, exportLight, exportGeom). Even further splitting into more than 3 files is easy (a file only for lights for example).

Those parts you mentioned like changing from bidirectional to path should be done via the Lux-API (direct communication between GUI and Lux whithout the need of a file).

ok something not right with Alpha .10

Compiling D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseluxmaticnodes.pyc
Compiling D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseluxmaticnodes.pyc
Compiling D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseluxmaticnodes.pyc
Compiling D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseluxmaticnodes.pyc
Version alpha 1.0.3 (exporter: alpha 1.0.8), exporting Lux files to
D:Program Files (x86)Smith MicroPoser Pro
Traceback (most recent call last):
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosePoserLuxExporter.py", line 163, in ?
    ExportScene(scene, globalParameters).write(f)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseworkersPoserLuxExporter_workers.py", line 330, in write
    ExportLight(light, self.globalParameters).write(file)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseworkersPoserLuxExporter_workers.py", line 221, in write
    self.convert2Lux()
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseworkersPoserLuxExporter_workers.py", line 196, in convert2Lux
    from camexport import lookAt
ImportError: cannot import name lookAt

Quote - Actually the "framework" is planed to do so.

I know, just a reminder.

Quote - Those parts you mentioned like changing from bidirectional to path should be done via the Lux-API (direct communication between GUI and Lux whithout the need of a file).

?
Nochmal, bin nicht sicher ich hab alles verstanden.

Quote - ok something not right with Alpha .10*

I should do something how I manage my versions/files :(
Wrong file added to zip. Fixed.

we have Dalek!
that fixed it :)

Just to have it said:

The "mutch lines of code to put out some textlines" isn't required.

The Framework is there to make it easy to include source-parts. If someone writes sourcecode with a function or class to convert on Light, the framework is there to feed this function/class.  That's all.

Code to write-out things is in the framework just to have something written until it's done better. How the autor writes his function/class is up to him.

To see what I mean, here is the part to write out camera data after I got the file with the code to include:

class ExportCamera(object):
    def __init__(self, camera, globalParameters=exdict()):
        self.globalParameters = globalParameters

        if not camera.IsCamera() :
            raise Exception, "%s: given parameter is not a Poser camera" % self.__class__
        
        self.camera = camera


    def write(self, file=sys.stdout):
        import camexport # written by BB
        reload(camexport)
        from camexport import ExportCamera as excam
        if __reportcomments__ :
            print >> file, '# start Poser camera "%s"' % self.camera.Name()
            
        excam(self.camera, file, self.globalParameters)
        
        if __reportcomments__ :
            print >> file, '# end Poser camera "%s"' % self.camera.Name()

okies trying to render Obiwans Spacewolf Space Marine and I get this

*Converting figure ULTRA to a single mesh:
  21003 vertices in welded vs 21491 in unwelded figure
  42 listed materials

Traceback (most recent call last):
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosePoserLuxExporter.py", line 163, in ?
    ExportScene(scene, globalParameters).write(f)
  File "*D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseworkersPoserLuxExporter_workers.py", line 331, in write
    ExportFigure(fig, self.globalParameters).write(file)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPoseworkersPoserLuxExporter_workers.py", line 107, in write
    params).write(file)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosepydoughgeometry_export.py", line 351, in write
    Subgeometry(self, indices).write(file)
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosepydoughgeometry_export.py", line 103, in write
    self.fix_texture_seams()
  File "D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosepydoughgeometry_export.py", line 48, in fix_texture_seams
    tverts = [tpolygons[i][j] for i,j in corners_for_v]
IndexError: list index out of range

Quote - *
  File "*D:PoserSmith MicroPoser ProRuntimePythonposerScriptsScriptsMenuLuxPosepydoughgeometry_export.py", line 48, in fix_texture_seams
    tverts = [tpolygons[i][j] for i,j in corners_for_v]
IndexError: list index out of range

That's apparently a problem in my code, so I'll have to look into it tonight. Could become a bit tricky with commercial figures, unfortunately, so unless I spot the problem right away, I might have to give you a patched Python file with lots of debugging output.

In the meantime, can you tell me if there's any part of that figure that isn't UV-mapped?

no idea.. it's an ancient figure...

Forget that, anyway. If anything, the UV mapping would have to be broken, not missing. But it's equally likely that I simply made a mistake.

Just to be sure: is it a commercial figure or a freebie? Because if it's the latter, I could simply download it myself and see what I get.

Freebie.. but I think the site's down atm... working on getting you a link

edit
here we go http://storeandserve.com/download/758230/Obiwan40K.rar.html

Same error here with one of my self-made geometries.
Can be downloaded from freebies here, name is "HiTec Trike"

[ http://www.renderosity.com/mod/freestuff/index.php?user_id=133972

](http://www.renderosity.com/mod/freestuff/index.php?user_id=133972)

Added an errorcatcher if a material node could not be converted insteed of interrupting the script.
Any not known node is replaced with a Lux "default" material entry and the nodename is displayed with a warning.

Should help while exporting complicated materials until BB is ready with the new version.

Download: See below ...

IndexError: list index out of range

Got the error with "V4BikiniPanties". 

 ADP, your latest exporter pkg works wonderful, it now skips over most errors.

One small warning I noticed when importing, there's a [ ] pair missing here:
workers/camexport.py:    print >> file, ' "bool autofocus" "%s"' % gp.get("autofocus", "false")
it should be ["%s"].

Quote -  ADP, your latest exporter pkg works wonderful, it now skips over most errors.

One small warning I noticed when importing, there's a [ ] pair missing here:
workers/camexport.py:    print >> file, ' "bool autofocus" "%s"' % gp.get("autofocus", "false")
it should be ["%s"].

Yes, it's already fixed. I'm testing something before I update again. Fixing this warning makes no difference, because "autofocus=false" is default.

Quote - > Quote - imho, that doesn't make sense to do.  i mean, if you're going to automate loading, why not allow selection of materials and props rather than relying on developers to add some specific naming convention?  that's not a very extensible answer.  what happens when there's a Yafaray exporter, or some new free renderer comes along that's better and needs completely different treatment? 

Seems that any render engine has some special things. No other engine I know of has a light that acts like a "skyglob" including a light for example.

Ok, we could assume any IBL should be replaced by a sunsky. But what if somebody is using a real skyglobe and addtionally IBL?

I don't talk about what can be examined from a Poser scene to standards used by any other engine. But I think material conversion for render-engine xyz is also not possible without doing something. Except render-engines do use the same material handling (rib, for example). This is the reason why bagginsbill thought of adding a standard-material handling for Lux as a Lux-extension (probably this has to be done for other renders, too).

The reason you talked about (a programer has to add something for other render engines) is why I mean it's best to write the code as abstract and "easy to read" as possible to make sure somebody is able to extend the code later (or to use it as a framework).

As far as I can see, to address the standard Poser user the material export is the most important part (some specialists may not need a complete conversion). Moreover, guessing what a nodeset inside a material may be good for is the hard part (skin or not for example, or x-nodes just to get a "realistic" reflection/glaseffect). Most of the tricks done to get a nice material in Poser aren't useful for other render engines. Discarding such nodes may not only speed up rendering but also may come out better.

I'm sure this part is true for any other render-engine but Firefly (the common part). So if it is possible to translate pure Poser materials to something like "Meta-Materials" (beside of the conversion to Lux matarials), the hardest work is done for any other render engine.

But all this has nothing to do with all the nice features a new render-engine may have and could be used by the user - if he had a "handle" (simply a special prop to fill the gap; with a name prefix to not disturb what is defined for another render-engine and not accidently rendered). 

This leads me to the need of having an editable list of "Prefixes to ignore" :)
Or to call a function with each name in question ...

My conclusion: If props/actors/ligths with a prefix are ignored, the material-exporter isn't involved anyway. All this objects could be disabled before the exporter touchs them (with automatic re-activation later). Materialnames are still untouched.

At the end: What I'm talking about is nothing you HAVE to use. But you CAN if you want. If it is properly ignored by parts who don't know to handle objects with the prefix in question.

Huston this is not an option. he he ;)

teh sunsky is very slow. very slow. adding a siimple sphere that is very low on poly and making it a light with a texture renders faster and gets a fantastic result.

sunsky is very slow.

Quote - Lux and SSS 

From the FAQ:

Implementation of subsurface scattering is planned for LuxRender version 0.8. In the meantime, however, you can simulate it quite effectively, if not 100% physically correctly.

...

Third, the mattetranslucent material is best used in a "mix" material along with a glossy material. The combination of mattetranslucent and glossy materials, along with some tweaking and adjustment, does a very good job approximating subsurface scattering in LuxRender.

maybe there are some option hiden under the code where we dont see it. but in LuxBlend you have only the color for the mattetranslucent.

i tryed the mattetranslucent with the glossy and it looked in no wy like skin. i didnt even get any tranlucence.

Quote - > Quote -

Fantastic work guys! Simply fantastic!

Did somebody say something like "impossible to render usable skin without SSS"?

i dont want ot make trouble in this thread. but i can not ignroe this.

this looks like physical correct diffuse bouncing. this is all. the skin looks dry. and dry is wrong for skin.

yes fantastic scrip about exporting to Lux. BB and all here who are working are gods. you hear me? you are god's.

Quote -
i dont want ot make trouble in this thread. but i can not ignroe this.

this looks like physical correct diffuse bouncing. this is all. the skin looks dry. and dry is wrong for skin.

This image is only a simple export with relative simple material conversion. Not optimized to look like skin. 

Add a simple texture to a figure in Poser and render this. I bed you'll see the difference.

By the way: Very often if I look on real photos (I have too), I see "dry skin". It's not only "wet skin" that makes an image look real.

To have a good skin you need a good highlight/bumpmap combi. And a texture made for realistic renders (no Poser stuff). If you haven't, SSS can't do mutch for you. And yes, SSS is complicated to set up. Translucence also needs a bit know-how (for Lux you can find some hints in the faq and from the Lux forum).

i f.... love the realtime light groups. i can change colors in real time and nail the look that i want in 5 seconds.

this is a 10 minute render. it still renders. but in the time i was able to change the colors. both lights were in the beginning white. i changed them to blue and orange to make the cliche color contrast that is used everyday.

look at the light behind him. you see the shape of the light? you see how the shape looks physical correct on the wall? amazing.

does anyoen know if using transmapped hair works in luxrender? and does anyone know if it is very slow like in poser with GI?

Tried to make it look like bright daylight. Oh well...

About a 6 hour render - I let it run overnight. BRC Cloisters model from Daz, some trees I made in Baum3D and some ivy from the Ivy Generator with some of my textures on it :o). In total, export from Poser took about 47 seconds.

Laurie

nice

Quote - does anyoen know if using transmapped hair works in luxrender? and does anyone know if it is very slow like in poser with GI?

transmapped hair works fine in luxrender, with no apparent slowdown.  Bonus!