Quote - As there seems to be absolutely no point to post anything here, I'll leave this thread now...

Wut?

...did I kill the thread?   :sad: 

Don't know if you folks have seen this, but pretty cool

http://www.youtube.com/watch?v=GsnkLQIn7YY&hd=1

Done with Blender 2.5 and SmallLuxGPU at 25 seconds per frame on a single home PC!

Kevin

this is a 2 hour render because i have a very slow computer

Quote - the funny thing is that you dont need anymore to model details into geometry. LUX makes everything so real that even simple walls loo fantastic.

this is a 2 hour render because i have a very slow computer

I disagree, if anything, Lux brings out any and all flaws, so detailed geometry just looks better.

Quote - > Quote - the funny thing is that you dont need anymore to model details into geometry. LUX makes everything so real that even simple walls loo fantastic.

this is a 2 hour render because i have a very slow computer

I disagree, if anything, Lux brings out any and all flaws, so detailed geometry just looks better.

If there aren't any flaws in the details I would agree. I imagine flaws would be more prevalent in a detailed wall as opposed to a simple wall though.

Quote - As there seems to be absolutely no point to post anything here, I'll leave this thread now...

There's a point. I was listening.

Hooray!  I looked at lux a while back, but there wasn't much for it then, so I didn't pay much attention to it then. Thanks to all for putting this together.  One of the best Poser tools I have seen.

I read through the threads for LuxPose and downloaded 1.15 to try out.  The Python works great, and fast for me.  And I think I just got the AIR app figured out.

I am still a little iffy on the materials.  It seems to not work with VSS.  I figure I'll get smacked on the nose with a rolled up newspaper for saying that this late in the game, but I spent hours last night reading through all the LuxPose threads and I seem to remember BB saying something to that effect early on, except I can't find a definitive post with the info.  Or maybe not, it's all kind of a blur at the moment.  For now I am just testing what shader nodes will work and building a VSS prop to reflect the research.  It's easier for me than going through the code, since I am a novice at best in regards to programming.

Also, how are people getting decent renders?  I have a grasp on LuxRender, their documentation is very helpful.  And my system is capable,  Athlon II x4 running at 3360 Mhz with 4gb of ram.  It benchmarks a little faster than a stock Phenom IIx4 in Cinebench.  I let a simple test render with one point light, one figure, and walls go for six hours this morning and it was still a grainy mess.  Nothing like Raven's killer five-minute rat up there.

AFAIK, VSS, or any other shader node construct, will not work in Luxrender just yet.  Until such a time, simple shader arrangements are the requirements.

Quote - AFAIK, VSS, or any other shader node construct, will not work in Luxrender just yet.  Until such a time, simple shader arrangements are the requirements.

And it has to be said again: A whole lot of nodes in a Poser nodeset are only their to fake/support light- and/or reflection-effects etc. Because FireFly needs this support. Those nodes are not only not required with LuxRender. They even may have a negative effect, because Lux is a real physic based render engine.

The great trick with material conversion is to compute or guess what a nodeset is good for. Just to decide wether this set is required or better ignored.

If someone is willing to setup a special nodeset to be used with Lux, the result may be even better than an automatic convertion (if one knows how Lux materials work). But the hopefully soon coming Mat-Converter will not only try to convert what is already in a scene, but also help us setting up an advanced nodeset. But, I'm afraid, this will last a bit.

Thanks guys.  I wasn't sure if it was just me, or if there really was something going on with the shaders.

just wondering.. I know that "reality" doesn't handle point lights, however, I know that lux does.. so my question is..  does the luxPose?

Luxpose converts pointlights to a meshlight, the size dependant on the scale of the pointlight in Poser.

nice.. funny, that was the suggestion that I made to the reality forum :P

I saw that and I thought maybe you had read it here earlier.  I would have commented there, but didn't want to agitate anybody by mentioning Luxpose.

understandable :)   and no, I actually made the suggestion without knowing how they were handled in LuxPose (I missed about 4 days worth of posts because of being out of town (and too lazy to go back and read them to catch up))

After more experimenting with hair, I found something else that may be useful to know... the Poser file (.pz3, .hr2, whatever) only stores the guide hairs in the file, whether it was populated when you saved it, or not.  It's only when you populate it, export the obj, with "As Morph Target" unchecked, that it writes the fully populated geometry to the .obj.  So looking at the Poser file itself, pre-export, won't help with the populated hair, unless you want to look into seeing how Poser interpolates the guide hairs.  (There's a HairGrowthGroup later on in the Poser file, that has the parameters from the hair room.  I just don't know how each one mathematically affects each vertex.)

Quote - Luxpose converts pointlights to a meshlight, the size dependant on the scale of the pointlight in Poser.

Sorry that I have to correct you. It's not wrong what you say. But it is called "arealight". Meshlight suggests it wouldn't matter to convert any mesh to a light. This s possible, indeed. But you have to pay a high price for that: Rendertime. 

Lux has some built-in primitives. BB found out that using such an internal geometry is much faster than using something highres. Because each polygon of a mesh will become an individual lightsource. 

Using a scaled up Poser pointlight can give a nice soft light. Depends on the size of the resulting lightsource. You should note that a pointlight visible through the camera is visible in your render.

Lux handles light sources as mutch as real world does. Set a pointlight into an open geometry (like a lightbulb in a flootlight) and watch what happens. I bet you end up playing a whole day with it :)

Lets do a contest!

Create nice effects using a pointlight!
Build photolamps, for example. Try adding a partly transparent plane (Poser primitive) in front of the light. Try to attach a textures to the plane!

Years ago I tried to do something similar for Poser 5. Maybe this (free) prop can be used to have a startpoint.  http://www.renderosity.com/mod/freestuff/index.php?user_id=133972 (page 2)

Feel free to even modify the geometry. If used with Lux, this prop is completly open source :)

create it in poser? or lux?

Quote - create it in poser? or lux?

In Poser, of corse! Pointlights are automatically converted into arealights from the converter.

Click For Full Size

This was done a few years ago.. the only lights in the scene are point lights

A good sample. Because here indirect lighting is completly ignored by Poser. This is not a blame against Poser. It's just the difference to unbiased render engines or GI. 

Rendertime: 60 minutes with 4 cores (cheap AMD-Phenom), round about 200000 samples per second.

Model:
4 simple glasses (double-sided model) with standard Lux glass material, no special setups.
Table is a simple quad with a soft glossy.

Lux:
Tonemapping linear. I used Lens Effects and Noise Reduction from the Lux-GUI to get soft caustics and to smooth the glasses to the same level as the background image. Color-Space with Lux-GUI until all colors matched in a believable way. 

Can you share how you got the background IBL image to look so decent? I've been experimenting and I can't get mine to look like that ;o).

I've been using just a regular IBL light and plugging a high-res .hdr image into it. Even so, it comes into Luxrender looking crappy and pixelated ;o).

Oh, and how did you get the glass material? I can't seem to get that in Luxrender with any setting I use in Poser.

Laurie

one word.... "Perdy" :P

Quote - Can you share how you got the background IBL image to look so decent? I've been experimenting and I can't get mine to look like that ;o).

I've been using just a regular IBL light and plugging a high-res .hdr image into it. Even so, it comes into Luxrender looking crappy and pixelated ;o).

Oh, and how did you get the glass material? I can't seem to get that in Luxrender with any setting I use in Poser.

Laurie

he cheats.. and hacks the .lx* files :P

Quote -
 he cheats.. and hacks the .lx* files :P

Yes I did. To find out how "complicated" it is to get good glass :)

Indeed, it isn't. 

Probably I have to hack BB's material converter to make it simpler. Problem is, this part is heavy complicated programed. Will see what I can do today.

For the moment, find any occurence of Poser converted glas material.

After the line:
MakeNamedMaterial ""

insert:
 "string type" ["glass"]

 "float index" [1.52]

If you have a single-sided glass model, insert a third line:
 "bool architectural" ["true"]

For best results use double-sided glas. Or you have to use "glass2" and to play with "volumes". But this is another complicated Lux-story ;)

Originally, I've set another light (a spot) in the scene and used lightgroups to seperate lightsources.

For the first image I have set the spot to 0. This image here is the same, but the spot-light set to it's original value.

Note: I did not render this image anymore! I just raised his gain and let Lux do a new tonemapping. That's all and I got the image above a few seconds later.

I wonder how one would get rid of those moire effects on the glasses. Between this render and the snow globe that someone posted the other day, I feel as if we're missing something when exporting geometries.

one thing about architectural glass though.. is if you don't need it to be 100% perfect.. use it.. glass as a whole very resource intensive, so enabling architectural glass would speed up the render process.. i.e. it will still "look" like glass, but the refractions and stuff will be less, it doesn't have to be single sided.. just a matter of how "real" you want it to be

if you want to do a comparison.. I can take the fishbowl from the toon fish and export it in both luxPose and reality, and you can compare the differences to see what's going on..

Quote - Can you share how you got the background IBL image to look so decent? I've been experimenting and I can't get mine to look like that ;o).

I've been using just a regular IBL light and plugging a high-res .hdr image into it. Even so, it comes into Luxrender looking crappy and pixelated ;o).

Oh, and how did you get the glass material? I can't seem to get that in Luxrender with any setting I use in Poser.

Laurie

If you use the stock hdr-images from poser, make sure you are using the hires one (you can see it on file-size). 

Because Poser and Lux handles IBL different, you have to attach the hires version of a hdr to the light. Because Lux uses this image not only for IBL, but also for an "automatic skyglobe". This needs a hires image. Poser is using a lowres HDRI because Poser does only IBL (illumination based on an image). Sort of: Filling a fictive skydome with lightsources. For this a hires image is not required.
(Sorry, can't declare it better in english).

Quote - if you want to do a comparison.. I can take the fishbowl from the toon fish and export it in both luxPose and reality, and you can compare the differences to see what's going on..

Honestly, I feel a bit reluctant at doing anything that could be interpreted as 'reverse engineering' of Reality. I'd rather face the embarrassment of asking in the Lux forums. Then if I get told how to get smooth glass with LuxBlend, I have no problem trying that and peeking into the lxo file to see what the data looks like.

no, I'm not saying attempt to  reverse engineer it or anything.. I'm saying compare what the lux file looks like between the 2, which would help point out if there is something that is being missed

Quote - > Quote - if you want to do a comparison.. I can take the fishbowl from the toon fish and export it in both luxPose and reality, and you can compare the differences to see what's going on..

Honestly, I feel a bit reluctant at doing anything that could be interpreted as 'reverse engineering' of Reality. I'd rather face the embarrassment of asking in the Lux forums. Then if I get told how to get smooth glass with LuxBlend, I have no problem trying that and peeking into the lxo file to see what the data looks like.

At first, there are many other exporters in source code available. My C4D-Exporter is one of the simplest, but written in C++. 

Second, they are working on the problem. With 0.8 this normal problem should be gone.

Third: (Didn't look in your source) maybe some meshes are better "left untouched" and just exported as quads? What about a flag?

Forgotten - There are some flags (for Lux) you can set for the mesh. 

mesh::N         normal[n]       Per vertex normals over the mesh        none - optional
mesh::P         point[n]        An unordered list of vertex positions in the mesh.      none - must be specified
mesh::acceltype         string  Accelerator structure to use (auto, bruteforce, grid, kdtree, none, qbvh)       "auto"
...

C4D-Exporter is using "acceltype". Don't know what it exactly does, but it seams to work :)

Quote - no, I'm not saying attempt to  reverse engineer it or anything.. I'm saying compare what the lux file looks like between the 2, which would help point out if there is something that is being missed

Fair enough! That's worth a try.

@ADP: so what's the advantage of quads over triangles? I don't mind adding that flag, but users need to be aware that (in Lux 0.7, anyway) it will kill the UV mapping, and if those quads aren't perfectly flat, the only effect will be heaps of error messages.

Quote - Forgotten - There are some flags (for Lux) you can set for the mesh. 

mesh::N         normal[n]       Per vertex normals over the mesh        none - optional
mesh::P         point[n]        An unordered list of vertex positions in the mesh.      none - must be specified
mesh::acceltype         string  Accelerator structure to use (auto, bruteforce, grid, kdtree, none, qbvh)       "auto"
...

C4D-Exporter is using "acceltype". Don't know what it exactly does, but it seams to work :)

C4D-Exporter is using which acceltype? If I remember right, the default is kdtree. We could try some others and see if that changes the outcome. I'm pretty sure that that would constitute a bug, though, so one should be able to find info on that on Mantis.

Forget about acceltype. Makes only sense with another sampler.

With a second export, my C4D-Exporter isn't use it anymore. 

The real difference is:

C4D exports the model as one whole object. Your codes splits the object into several parts.

And C4D does no complicated normal handling.

Want to have the output from C4D? 

Quote - Want to have the output from C4D? 

No! You keep giving me little confusing bits of useless information. This thread is full of people making wild guesses, and it's not helping.

I'll figure it out myself or ask in the Lux forums.

If you want to compare anyway:

http://www.poserprofis.de/glas.zip

Contains obj-file, C4D export and LuxPose export.
 

ADP, I have a suggestion (I'll post this on the peanut gallery, as well, so it doesn't get lost):

If you look at my GeometryExporter class, you'll see that it doesn't do anything too complicated. It's essentially just a bit of glue between different components. It calls a function that extracts geometry information from Poser, sticks that in a Geometry object, calls a few methods on it, grabs the data and writes it to the Lux output file. You can take that code and change it any way you like. If you don't want per-vertex normals, don't compute them (Lux will then compute and use its own per-face normals). If you don't want triangles, loop over geom.polys instead of geom.triangles. If you want to output a trianglemesh instead of a mesh, or change some of the options, you can do just that.

I think that's really how it should work. I provide the basic operations for preparing the data, such as computing normals, subdividing and triangulating, and you, bagginsbill or whoever uses the pydough library is responsible for calling the right methods in the right order and producing the output. Then you can experiment with all the different options that Lux provides at your heart's content and figure out what works best in which situation. If there's need for additional functionality (such as converting hair data into actual geometric objects, which I'm about to start on), give me a holler.

For now I'll add another argument to GeometryExporter.init(), namely a function that will be called whenever a mesh object gets written to the output file, right after the opening 'Shape "mesh"' command. That method can then write additional parameters for that mesh directly onto the output. It will get passed all the relevant parameters plus a pointer to the Geometry object that's being exported.

Quote - ADP, I have a suggestion (I'll post this on the peanut gallery, as well, so it doesn't get lost):

If you look at my GeometryExporter class, you'll see that it doesn't do anything too complicated.

Grrr (to me). This was not meant as it sounds.

I did a last, simple test. I removed the normals from the C4D-Exporter output and let it render.  And I got the same result as with LuxPose.

If I look at LuxPose normals, I couldn't find some for the glass??? (don't beat me). 

About the "complicated things".

Because of how Poser meshes are constructed and uv-mapped, you had to split the meshes according to the uv-maps and had to re-compute the normals to make them as smooth as possible again. You did it perfectly at the end. 

C4D doesn't care about such things.

This is what I meant with "complicated things".

Quote -
For now I'll add another argument to GeometryExporter.init(), namely a function that will be called whenever a mesh object gets written to the output file, right after the opening 'Shape "mesh"' command. That method can then write additional parameters for that mesh directly onto the output. It will get passed all the relevant parameters plus a pointer to the Geometry object that's being exported.

This is a pretty good idea!

I didn't think you were criticizing me. You were just confusing me. I still don't know what works and what doesn't, and why.

The thing is, with the code I have in pydough, it should be possible to do anything the C4D exporter does (or more to the point, switch off anything that LuxPose does in addition), and it should not be hard to experiment and see which bit it is that makes Lux stumble. You can do it, or I can do it, each on our own time, and we shouldn't have to wait for each other to implement something. That's just unproductive. So if the code is organized in a way that unnecessarily makes us rely on each other to make changes, then that's a bug (or, as the refactoring crowd would say, a smell) in the code, and it needs to be reorganized.

This is a Poser export. Just modified the material to "glass" by hand.

In a few minutes anybody interested may request the PZ3 from here: http://www.poserprofis.de/posertest.zip

That absolutely looks incredible!

That looks much, much better than the other version. What's the trick?