Making LuxRender v0.8 better

[jeanphi]

Hi,

I'd like to ask all exporter writers to post in this thread to tell us what should be improved to make their lives easier. I know documentation will probably come quite high on the list, but you might also have some technical requests that would make writing your exporter easier. Please tell us, I don't promise everything will make it into v0.8, but we'll make our best to help you.

Jeanphi

[m1j]

Ability to read OBJ files directly. Unless this is already possible then like mentioned before documentation of how this works.

[hedphelym]

documentation on all features (include max values for the different settings in scene wiki page would help too).

But there's one thing I would like to see, which to me seems to have gotten worse in the latest release, and that's when you close luxrender,
it closes UI but the process is still alive for a long while, and renderslaves keeps on rendering for a long time too before quitting.

This is very annoying when you launch luxrender with slaves 100 times a day when you code exporters.

A quicker way to kill\reset the render process on master computer and slaves would be nice.

And also maybe a "autoconnect" feature, so that you can add slaves to a list, then make it remember these slave ip's and try
to connect to them automatically at the next launch.
(I know you can do this by specifying a command on a shortcut, but would be easier to have in GUI).

Other then that I cannot think of anything right now.

Thank you for asking us exporter coders!

[SATtva]

documentation on all features (include max values for the different settings in scene wiki page would help too).

Min, max, default (if parameter is omitted).

But there's one thing I would like to see, which to me seems to have gotten worse in the latest release, and that's when you close luxrender,
it closes UI but the process is still alive for a long while, and renderslaves keeps on rendering for a long time too before quitting.

Because a master polls slaves for their last-minute work. I absolutely love this feature as I can use long update intervals, but still can stop rendering at any moment without losing any work done by both master and slaves. But do agree -- maybe some sort of a kill switch (KILL EM ALL AT INSTANT!!1) could be useful with large renderfarms.

[pciccone]

Based on my experience with Reality, the exporter that I wrote for Daz studio, I would say that most of my request are centered around the human figure rendering. Lux is spectacular for objects, architecture etc. But it could have a couple of additional features for humanoid figure rendering. So here is my list:

- Skin material. We have debated the use/faking of SSS but I'm actually thinking of skin material like the other basic materials, glossy, glass etc. The reason is simple, faking it is a lot of work and it's not always working out of the box. The human skin is partially glossy but with a shine that is unique. A skin shader would make life a lot easier and lead to more realistic results.

- Improvement to UV mapping. The way Lux requires the UV creates a lot of problems for subdivision. Because the UVs require the repetition of the vertices at the edges, when exporting to Lux the objects are actually unwelded at the uv seams. This causes some visible lines in certain times but it completely prevents the use of subdivision on those object since the seams will become completely visible. If there would be a way of weld the seams it would be great.

- Morphs. Humanoids use the same geometry but with a wide variety of morphs applied. This is common practice. Create a good unimesh and you can have male and female figures sharing the same rigging. Place the same geometry with two morphs in the scene and you save a lot of memory in using a combination of instancing and morphs. We have instancing in Lux but we don't have support for morphs. Right now, if I want to export a scene with 10 figures I have to duplicate the geometry 10 times. Each figure has 70,000 polygons, naked, so it gets big in a short time. Having a morph system, similar to the Transform command, would make the creation of complex scenes economical and possible of normal hardware. I'm quite sure that it would have other applications as well.

That's it for now

Thanks.

[tomb]

Skin material. We have debated the use/faking of SSS but I'm actually thinking of skin material like the other basic materials, glossy, glass etc. The reason is simple, faking it is a lot of work and it's not always working out of the box. The human skin is partially glossy but with a shine that is unique. A skin shader would make life a lot easier and lead to more realistic results.

A "true" skin material would require a multilayer BSSRDF (bidirectional surface scattering reflectance distribution) which it a bit involved to introduce. I've seen a couple of approaches in pbrt which typically ends up being implemented as a special case integrator with various preprocess steps. I doubt your users are interested in making the various layers of *dermis maps etc that is needed "Ordinary" SSS doesn't work very well for skin either, it usually just makes the models seem like wax or plastic. So perhaps a variant of your "hack" (matte translucent + glossy) combined with a asperity scattering BRDF would be a better approach for this (asperity: see for example http://bit.ly/c0axBU)

I would like to add that your users' use of the "simple hack" brings pretty amazing results already!

EDIT: I'm implementing the "The Secret of Velvety Skin" BRDF (paper linked above) in lux just to see how it looks and if its worth having

[SATtva]

- Improvement to UV mapping. The way Lux requires the UV creates a lot of problems for subdivision. Because the UVs require the repetition of the vertices at the edges, when exporting to Lux the objects are actually unwelded at the uv seams. This causes some visible lines in certain times but it completely prevents the use of subdivision on those object since the seams will become completely visible. If there would be a way of weld the seams it would be great.

Already in Mantis: http://www.luxrender.net/mantis/view.php?id=820

[pciccone]

Thank you SATva, to me that is of the highest priority. If there are any experimental fixes you can count on me for testing.

[tomb]

Just a quick test of the Asperity BRDF - it seems to work pretty well, http://dl.dropbox.com/u/9842264/default.png - the effect is overdone just to show the principle. It makes the skin more softly reflective at grazing angles of view/light. It looks somewhat like the fresnel effect but it's not quite the same. I was thinking about perhaps adding a multi-bsdf "skin" material based on the Reality plugin "hack" but with the added asperity factor.

[jeanphi]

Hi,

One of the main material features I'd like to work on is a proper layering infrastructure that would replace current glossy materials, color filters, and allow more kind of effects like better modeling of skin. Coupled with fresnel texture operators (scale, mix, ...) it should open some very interesting possibilities.
I'm also considering reinstating a sort of uber material to allow arbitrary reflection/transmission models.

Jeanphi