The Lux rules are clear: One geometry, one material. So the materials have to be converted/prepared before we can work with the geometry. The "scene-exporter" has to manage what must happen to make sure the geometry-exporter can work correctly. So, the name is prepared allready if the geometry-exporter starts working. Calling the material-exporter from within the geometry-exporter requires the material exporter object is still "on stage" (but not needed, just to provide a name).

Let the scene-exporter create and destroy objects as needed (collecting materialnames and such to hand this over to the next object). So we will have fast and clear processing at the end with as low as possible use of memory.

But if you want it your way, do it. 

Attached is what I did as "scene-exporter" so far. Not complete, needs further work on details. But puts out a scene-geometry (doesn't work yet with Lux).

The "write" methode of each of my classes receives a file-object to write to (if none is given, the class writes to sys.stdout, e.g. to the console). The given object can be a file or any object with basic-filemethodes (write). Even a network-stream - or an object calling the Lux-API. 

 Have to go to the hospital now seeing my mother. Will be back in a couple of hours.

I don't want to complicate things for you, but you might also need to consider how alternate (switching) geometry will be handled.

For instance, in Daz Studio, when the user switches to an alt geom body part, the list of materials is automatically updated to include any new/different materials in the alt geom. However, this isn't the case in Poser. Poser includes ALL materials in the list - from both normal and switching geometry.

This could mean that any figure with alt geom will have materials listed which only appear when the geometry is switched.

I'm not sure if this is an issue or not, but I thought I'd mention it at this stage in case it becomes a hassle later on.

mac

i'd be fine if this case was ignored entirely for the first version.  geometry switching isn't used by a lot of products, and it seems like one of those issues that can wait until after version 1.0.

i hope you and your mother are doing well.

"i'd be fine if this case was ignored entirely for the first version"

Sure. I would too.

I only mentioned it because it might be one of those things that's easy to include at the very start, rather than realising later that you've forgotten it.

mac

Quote - Poser includes ALL materials in the list - from both normal and switching geometry.

This could mean that any figure with alt geom will have materials listed which only appear when the geometry is switched.

I think that will be no problem to include extra materials that Lux doesn't use.

Quote - i'd be fine if this case was ignored entirely for the first version.  geometry switching isn't used by a lot of products, and it seems like one of those issues that can wait until after version 1.0.

Geometry switching is something that happens to an actor. So, at least for the geometry-export part it doesn't matter if the original or another geometry is used. Which material a geometry is bound to can be requested via **actor.Geometry().Polygons()[0].MaterialName() **(assuming an actor is using one material only). If more than one material is bound to a geometry, this geometry must be splitted. 

Preparing materials must be done before the geometry is touched. There is no other way to find out which parts of the geometry have actually the same (Lux) material attached or needs splitting. Same name is no guarantee we have the same material - see what LaurieA wrote about her actual project. And different names may even point to the same (Lux) material after preparation, so splitting may be not required.

Quote -  
i hope you and your mother are doing well.

Thanks. Surgery isdn't easy for an 88 year old woman. But she is fine now and in a good condition.

that's good to hear!

Feels free to give hints/corrections or publish replacements for whole classes/methods.
At least this part is owned by and dedicated to all poser users - so give your best - we have to beat Blender ;)

I'm not getting email about posts, so I'm a little behind.

ADP - Is the output of LuxPoserGeom supposed to work in Lux or no? I have one spotlight and the poser box and I'm getting errors. I don't understand the Lux format yet, so I'm probably making some gross mistake. The contents look sensible but I don't understand how to use it.

I'm guessing I have to have a wrapper with a camera in it or something that includes the resulting test.lxs. Sorry if I'm being dense, but I haven't been able to study things - too busy with my job. But I'm very interested to make a simple box and one light work, so I can mess with materials and not worry about geometry, while I wait for work stuff to compile and so on.

I'm getting this from Lux:

[2010-08-02 17:33:25 Error: 24] Scene description must be inside world block; 'AttributeBegin' not allowed. Ignoring.

[2010-08-02 17:33:25 Error: 24] Scene description must be inside world block; 'LightSource' not allowed. Ignoring.

[2010-08-02 17:33:25 Severe error: 47] Parsing error in file 'test.lxs' at line 7: syntax error

The test.lxs I have begins like this (then follows a lot of numbers).

 start poser scene

start lights

start light "Light 1"

AttributeBegin
LightSource "spot"
color L [1.000 1.000 1.000 ]
float gain [1000.000]
point from [-0.96851054 1.36041787 -0.05046293 ]
point to [0.00000000 0.00000000 0.00000000 ]
float coneangle [70.000]
float conedeltaangle [70.000]
AttributeEnd

end light "Light 1"

end lights

start figures

end figures

start props

start prop "GROUND"

invisible actor "GROUND" skiped.

end prop "GROUND"

start prop "FocusDistanceControl"

invisible actor "FocusDistanceControl" skiped.

end prop "FocusDistanceControl"

start prop "box_1"

start of prop 'box_1'

AttributeBegin
NamedMaterial "default"
Transform [2.62100000 0.00000000 0.00000000 0.00000000 0.00000000 2.62100000 0.00000000 0.00000000 0.00000000 0.00000000 2.62100000 0.00000000 0.00000000 0.00000000 0.00000000 2.62100000 ]
Shape "mesh"
 "integer triindices" [
0 1 2

Quote -
ADP - Is the output of LuxPoserGeom supposed to work in Lux or no? I have one spotlight and the poser box and I'm getting errors. I don't understand the Lux format yet, so I'm probably making some gross mistake. The contents look sensible but I don't understand how to use it.

Sorry, not yet working. It's just a "shell" for further code. There are lots of things not correct at the moment. So output a Poser scene is not possible.

Quote -
 I'm guessing I have to have a wrapper with a camera in it or something that includes the resulting test.lxs. Sorry if I'm being dense, but I haven't been able to study things - too busy with my job. But I'm very interested to make a simple box and one light work, so I can mess with materials and not worry about geometry, while I wait for work stuff to compile and so on.

I've created a simple scene with C4D and exported to Lux and Poser. To have a reference. Maybe you can use this too: www.poserprofis.de/LUXtest.zip

Thanks - I'm rendering something - Yay.

Your light writer forgets to put quotes around the parameters.

Thanks bagginsbill. I saw this already and corrected it (source lines 280 ff). 
I'll post a new version tomorrow. I'm fighting with the coordinate transformation from Poser to Lux at the moment.

How come you don't just set up a world transform at the beginning, and then forget about it?

I noticed that Preta talked about the coordinate system being a problem, with +Z as up. I don't see that at all. I told it my camera up is +Y.

Then all you need to do is figure out if it's a right hand or left hand coordinate. If it's the opposite as Poser, you just set the Z transform to negative 1 meter and you're done. With everything. Cameras, lights, everything.

Quote - I noticed that Preta talked about the coordinate system being a problem, with +Z as up. I don't see that at all. I told it my camera up is +Y.

That's ony true for the camera.

Quote -
Then all you need to do is figure out if it's a right hand or left hand coordinate. If it's the opposite as Poser, you just set the Z transform to negative 1 meter and you're done. With everything. Cameras, lights, everything.

Each geometry has it's own tranformation, as far as I can see from the file that is written from my C4D-Exporter ("xxx.lxo" from my zip).

Beside of this, vertices aren't restricted to -1.0 to 1.0 as you can see in the "floor" object (a simple rectangle in C4D, splitted into 2 triangles from the exporter).

The vertices are:

 "point P" [

-9.236659 -13.405624 0

9.236659 -13.405624 0

-9.236659 13.405624 0

9.236659 13.405624 0

]

I'm shocked :)

Perhaps someone can help out with this problem (Transformation entries). I have to go to bed now and have work to do tomorrow.

I don't understand how values outside -1 to 1 affect anything. The scaling to meters is just a multiplier in the transform.

ADP your sample scene file has what I'm talking about.

Before anything is defined there is this transform:

Transform [0.63742435 0.22012594 0.73840016 0  -0.77051294 0.18210419 0.61085832 0  0 0.95832282 -0.28568754 0  0.66067201 -2.046339 12.380427 1]

Are you thinking that is only applied to the camera?

I'll investigate. I'm almost sure the whole scene can be rotated, scaled, skewed, flipped, anything at all with the global Transform.

ADP: Glad to hear your mother is doing okay. My best wishes!

Great job with the skeleton script. I hope I can get some flesh on the geometry exporter tonight after work.

There is absolutely no need to do any coordinate transformations at all. I removed all that stuff completely. All you need is to set the camera "up" vector to 0 1 0 and it's done.

I am able to export simple props and Andy. This is enough for me to work on materials.

However, I'm getting some ugliness. These white spots (fireflies?) show up and the suggestions to not use pure white [1 1 1] isn't going to help - I already know not to do something like that and am using [.8 .8 .8]. And there are some strange artifacts in Andy's shadow on the back wall. Perhaps Luxrender isn't ready for prime time.

Anyway - this was 12 minutes rendered in Lux.

I did something.

• I used quads instead of triangles and it work without problems.
• The test is only a cube with six faces and a plane with one face, each face has its own texture mapping.
  The problem with seams is serious, I have split the cube in six faces to preserve each face uv and then included in the geometry the normals of a welded cube. The 8 welded normals transformed in 24 normals.
  The cube renders in Lux as it was a welded cube. Some strange thing happens at some vertices, probably has something wrong with the normals (I did the normals by hand).
  The worst thing is that Lux is very slow, the scene has only 7 polygons and I lost the patience to wait the render finish.
  I think that is not worth for me to continue, unless LuxRender improve a lot the speed.

Remove the txt extension of the file, it is a zip file

you guyss are doing great work.

but i have some important questions. are poser lights really important in LUXrender? you are aware that in luxrender you can use props for physical correct lighting right?

i downloaded again luxrender. i will try to export it to blender and then redner M4 in luxrender with the translucence material. i need to learn it.

The somewhat butchered version of ADP's script I've come up with is attached. Like bagginsbill, I've ripped out all the world transformations. I've also done a lot of fiddling with the code that transforms the lights, some of which may be useful, but most of which is probably rubbish. And I've added some boilerplate code to make Lux accept the whole thing as a scene file.

PS: Currently, I can write out the file from Poser noticeably faster than Lux reads and parses it. All the geometry splitting and such that we'll have to do will cost some extra time, but so far we're not doing badly.

Wow. That's awesome :o).

Laurie

just a quick comment to say that i don't care how long Lux takes to render now, i'd still be interested.  for me, it's not about how it can do the same thing as Poser, it's about how it can do what Poser can't.   also, it's only in version 0.7, but seems to have pretty active development. 

and if this lays the ground work for exporters to other renderers, i'll be even happier. 

Quote - just a quick comment to say that i don't care how long Lux takes to render now, i'd still be interested.  for me, it's not about how it can do the same thing as Poser, it's about how it can do what Poser can't.   also, it's only in version 0.7, but seems to have pretty active development. 

and if this lays the ground work for exporters to other renderers, i'll be even happier. 

Not to mention that they are going to be adding support for GPU assisted rendering as well fairly soon IIRC.

Yeah and the GPU rendering isn't just a little faster - it's crazy fast. A few seconds instead of 2 hours.

odf - I don't get white spots either, as long as I use only the matte material.

I have been attempting to produce a basic "glossy" material. With that material, I get the white spots. I believe that I have to decrease the Kd and Ks to well below what we use in Poser and then correspondingly increase the light gain. We'll see.

I've wasted hours also trying to just get a simple red diffuse color. There is always some blue. I do not have an environment or sky light, just a spot light, so it's not sky color bleeding. At least I think it isn't.

Even when my light source is pure red and my material is pure red, there is blue in it. It's driving me crazy.

Notice the red is not pure red. No idea why. Making me nuts. I've checked the material over and over.

Some of the images on the Luxrender site took 20-90 hours to render. CPU unbiased rendering is not a fast rendering solution if someone should think that. But as Bill said a GPU can be 10 - 50 times faster but is still limited to the ram on the gfx board.
Fireflies are a side effect of unbiased rendering. Im guessing that Luxrender have a MLT filter or some other options to prevent that from happening. Octane also have those fireflies now and then, but will soon have a filter for that.

It's not a "few" fireflies. It's a total mess.

oh!  now i get the weird fireflies and the long time.  you were making glossy materials,   which reflect and probably have ideally sharp highlights by default.

i'm thinking this type of testing doesn't work well for Luxrender.  empty world renders, that is.    since the red is getting some blue (according to my eyedropper extension) and the glossy seems to be picking up random highlights, it makes me think it might calculate based on the notion of some sort of sky surrounding the scene if there's nothing in the way.  just a thought.

edited to add: maybe Cornell box renders would make more sense?

Same thing happens in Octane with glossy materiels. It also goes nuts when a lot of transparence textures are used.

It may have something to do with the fact that my geometry isn't exporting UV coordinates. The highlight size in LuxRender is specified as uroughness and vroughness. This indicates it can do anisotropic specular effects, but may require that the object is UV mapped.

mmmm.  i could see that being an issue, too.

I have to go to work, so I have to stop experimenting for a while.

In case anybody cares to help figure this out, here is the Lux material I generated for Andy.

Material "glossy"
"color Kd" [0.20000000298 0.0 0.0]
"color Ks" [0.00500000007451 0.00500000007451 0.00500000007451]
"float uroughness" [0.0999999988824]
"float vroughness" [0.0999999988824]

And here's the material on the little boxes and the floor.

Material "glossy"
"color Kd" [0.198431399441 0.198431399441 0.198431399441]
"color Ks" [0.05 0.05 0.05]
"float uroughness" [0.0447213606121]
"float vroughness" [0.0447213606121]

Obviously it's not even close to where it needs to be. But for the moment, you can mess with diffuse and specular in the PoserSurface root node. It pays zero attention to anything else.

(Remove the .txt extension when downloading.)

Going back to my LuxRender window, what do I see?

Quote - I did something.

• I used quads instead of triangles and it work without problems.
• The test is only a cube with six faces and a plane with one face, each face has its own texture mapping.
  The problem with seams is serious, I have split the cube in six faces to preserve each face uv and then included in the geometry the normals of a welded cube. The 8 welded normals transformed in 24 normals.
  The cube renders in Lux as it was a welded cube. Some strange thing happens at some vertices, probably has something wrong with the normals (I did the normals by hand).
  The worst thing is that Lux is very slow, the scene has only 7 polygons and I lost the patience to wait the render finish.
  I think that is not worth for me to continue, unless LuxRender improve a lot the speed.

Remove the txt extension of the file, it is a zip file

Good news! Seems to be new with 0.7, isn't it?

Renderspeed is probably mutch better if we finished all features possible with our Poser/Lux combination. The Lux-devolpers are very active.  

If we (mostly bagginsbill :) ) are able to build something that renders with firefly close to what Lux does the Lux render engine can be seen as something like a photo-finishing-engine. Used at the very end of the process. Just to make something sensational out of a standard poser-setup.

If we have Lux-API directly connected with Poser, we are able to adjust lights, camera and textures right on the fly. So you better don't stop supporting this project ;)

Hey! You guys are very fast and motivated :thumbupboth:

I was a bit to deep into the C4D-Exporter sourcecode. Obviously I missed the point with this translation thing : blushing:

Now I have to look through the cool sourcecode and new info available here.

We need to standardize on light intensity conversion. ADP you had it multiplied by 1000. I changed it to 1. But I think that forced me to boost the material reflectivities and caused interreflections to go berserk. Somewhere in-between would probably be good - perhaps 300.

Of course LuxRender makes it trivial to adjust exposure on the fly, and also light intensity on the fly, but I would like to see a light intensity that produces nearly identical luminance between Poser and Lux when using the Linear tone mapper, with some reasonable "camera" defaults in the Tone Mapping section:

Sensitivity (ISO): 400
Exposure: 1/30 second
FStop: 2.8

The strange thing I never really thought about is that GI (bounced light) has to be in line with DI (direct illumination) in a ratio that makes sense. If you have a 1 square meter white matte prop, directly illuminated such that it appears to be RGB [.8 .8 .8], then you can get there many ways. You can have the light gain = 1 and the kD=[.8 .8 .8]. Or you can have the light gain = 100 and the kD=[.008 .008 .008]. For the DI effect, either works. But the reflected .8 .8 .8 is picked up by other nearby objects as part of the GI calculation. So what should the ratio of GI to DI be?

I considered this a few weeks ago in Poser as well. I experimented with light intensity of 1000% and changed my Diffuse_Value to .08 in all shaders. When rendered with IDL, the result was very very different. I believe this may be at the heart of why even with IDL, Poser lighting still looks somehow wrong. The ratio of direct versus indirect light levels has to be realistic. However, I did not pursue it further, as it is obvious to me that the Poser community as a whole will reject the idea of having to go into every single Poser material and change all the diffuse and specular values to be 1/10th of what they are now. Look how many people won't even bother to set it to .8, just to get IDL to work right at all.

But for automated conversion to Lux, this is not a problem. We just set up the correct ratios in the exporter. Users will never have to care.

Quote - We need to standardize on light intensity conversion. ADP you had it multiplied by 1000. I changed it to 1. But I think that forced me to boost the material reflectivities and caused interreflections to go berserk. Somewhere in-between would probably be good - perhaps 300.

I inserted just something I found (and guessed) while study what C4D did export. My job was to get a skeleton easy to work with. The details can be modified and corrected later - like odf has done allready :)

I'm ready soon with a basic camera and "film" exporter. If the values for this are corrected it should be possible to export a Poser scene - except materials.

Quote -
But for automated conversion to Lux, this is not a problem. We just set up the correct ratios in the exporter. Users will never have to care.

Yes! We can probably have a very smooth transition between Poser and Lux at the end (I hope). At least as smooth as possible. Understandig the differences between Lux and Firefly and why happens what is very important. So you are the best man to come close to what we want to have :)

Quote - We need to standardize on light intensity conversion. ADP you had it multiplied by 1000. I changed it to 1. But I think that forced me to boost the material reflectivities and caused interreflections to go berserk. Somewhere in-between would probably be good - perhaps 300.

Of course LuxRender makes it trivial to adjust exposure on the fly, and also light intensity on the fly, but I would like to see a light intensity that produces nearly identical luminance between Poser and Lux when using the Linear tone mapper, with some reasonable "camera" defaults in the Tone Mapping section:

Sensitivity (ISO): 400
Exposure: 1/30 second
FStop: 2.8

The strange thing I never really thought about is that GI (bounced light) has to be in line with DI (direct illumination) in a ratio that makes sense. If you have a 1 square meter white matte prop, directly illuminated such that it appears to be RGB [.8 .8 .8], then you can get there many ways. You can have the light gain = 1 and the kD=[.8 .8 .8]. Or you can have the light gain = 100 and the kD=[.008 .008 .008]. For the DI effect, either works. But the reflected .8 .8 .8 is picked up by other nearby objects as part of the GI calculation. So what should the ratio of GI to DI be?

I considered this a few weeks ago in Poser as well. I experimented with light intensity of 1000% and changed my Diffuse_Value to .08 in all shaders. When rendered with IDL, the result was very very different. I believe this may be at the heart of why even with IDL, Poser lighting still looks somehow wrong. The ratio of direct versus indirect light levels has to be realistic. However, I did not pursue it further, as it is obvious to me that the Poser community as a whole will reject the idea of having to go into every single Poser material and change all the diffuse and specular values to be 1/10th of what they are now. Look how many people won't even bother to set it to .8, just to get IDL to work right at all.

But for automated conversion to Lux, this is not a problem. We just set up the correct ratios in the exporter. Users will never have to care.

PLEASE let me borrow your brain for just a few hours....LOL.

Laurie

My gawd, I think I love all of ya...lmao.

Laurie

 We still need someone able to create a user-interface based on wxPxthon (P7 and up) or TkInter (Poser5/6).

The userinterface should collect parameters to a Python dictionary. Things like a "project name", path to write to, image-resolution, tone-mapping, gamma (for poser-versions without gamma feature), some parameters Lux has but Poser not, and so on. Also important: Seperate export possibilities (geometry only, material only, special light and special camera-settings). So the user-interface are actually at least 4: Global parameters, camera parameters, light parameters and material-parameters. 

And a big "Automatic" button.
And of course a start-button :)