Luxus discussion

KickAir 8P · April 2013

SphericLabs said:
Luxus 1.0.0.5 is available in your accounts . . .

Thanks! :coolsmile:

Michael G · April 2013

SphericLabs said:
Luxus 1.0.0.5 is available in your accounts.
Changes:
-> Projection Lights now work.
-> Render Settings now save and load with the file according to the preferences set in DAZ Studio
-> Added option to override the Light Group name
-> Strength texture maps no longer get gamma corrected. This fixes the hair too transparent problem.
-> Collect textures now allows the user to choose the format. In windows, LuxRender is having problems with some tiffs. The default is now png.
-> LuxRender Material Extra Settings now has an editor called "Luxus Extra Script Edit" that by default will show up in the Surfaces Option Pane.
-> The Extra Settings Fields now allows javascript scripting in a eval { } block. A Lux object exists in that context.See s few examples below.

Get started with:
eval { Lux.addEvalLine("I wrote to the lxs file"); }

Other Functions include:
Lux.getValue("Diffuse Color");
Lux.getMap("Diffuse Color");
Lux.addEvalLines(lines);
Lux.writeValue(var);

Javascript read function are available such as include, so the following can be done to use a lbm2 file
eval{
var v = include("/data/CJ/AlienEgg.lbm2");
Lux.writeValue( v );
}

Great stuff Spheric, keep up the good work. Will you be including portals at some point?

SphericLabs · April 2013

I have researched portals, but they did not seem to speed anything up. So I figured I must be doing them wrong. I will give it another go soon.

Michael G · April 2013

SphericLabs said:
I have researched portals, but they did not seem to speed anything up. So I figured I must be doing them wrong. I will give it another go soon.

Ok no worries.

FusionLA · April 2013

SphericLabs said:
fusionla said:
SphericLabs said:
Szark said:
fusionla said:
@ SphericLabs,
Is it possible for you to add an Invert direction option for the Area/Mesh Light settings?

Why can't you just turn it around 180 degrees...simple enough to do.

Probably for something like a cylinder?

Yes that would be correct, it's an option that Reality has.

I can add it as an option, for now you can simple paste the following line into your Extra Settings on the Material
ReverseOrientation

@SphericLabs, did you get a chance to add this option with the new release?

SphericLabs · April 2013

fusionla said:
SphericLabs said:
fusionla said:
SphericLabs said:
Szark said:
fusionla said:
@ SphericLabs,
Is it possible for you to add an Invert direction option for the Area/Mesh Light settings?

Why can't you just turn it around 180 degrees...simple enough to do.

Probably for something like a cylinder?

Yes that would be correct, it's an option that Reality has.

I can add it as an option, for now you can simple paste the following line into your Extra Settings on the Material
ReverseOrientation

@SphericLabs, did you get a chance to add this option with the new release?

Doh! I knew I forget something.

Soto · April 2013

Thank you very much for the update! :D

Kerya · April 2013

Thank you for the update! :)

cwichura · April 2013

SphericLabs said:
I have researched portals, but they did not seem to speed anything up. So I figured I must be doing them wrong. I will give it another go soon.

A couple things to keep in mind about Portals:

1) They only influence Sun, Sky and Infinite light sources. All other light sources ignore them.
2) They have to be attached to ALL relevant light sources. So define the geometry for the portal as an instance and then use the PortalInstance command to reference it after each relevant light source statement.
3) Portals don't necessarily change the sampling statistics reported by Lux, which can lead folks to believe it isn't doing anything. But the rays being traced are "more meaningful" when it is present, resulting in the image converging in less overall total samples than it would have required without the portals.

Michael G · April 2013

cwichura said:
SphericLabs said:
I have researched portals, but they did not seem to speed anything up. So I figured I must be doing them wrong. I will give it another go soon.

A couple things to keep in mind about Portals:

1) They only influence Sun, Sky and Infinite light sources. All other light sources ignore them.
2) They have to be attached to ALL relevant light sources. So define the geometry for the portal as an instance and then use the PortalInstance command to reference it after each relevant light source statement.
3) Portals don't necessarily change the sampling statistics reported by Lux, which can lead folks to believe it isn't doing anything. But the rays being traced are "more meaningful" when it is present, resulting in the image converging in less overall total samples than it would have required without the portals.

point 3, same as rendering inside a closed box, render efficiency shoots through the roof with a much higher rendering time but there's less wasted light rays and it converges much quicker.

Michael G · April 2013

Any tips for decent genesis eyes? I cant get them to look wet and glossy. :(

SphericLabs · April 2013

Michael_G said:
Any tips for decent genesis eyes? I cant get them to look wet and glossy. :(

I wonder if the geometry shell trick would work on this? You might need to setup most of the eye stuff on Genesis (Irus, etc) to be a simple glossy and then do a geometry shell, but turn off everything on the shell but the scelera and the cornea(I think). Then do the Glass2 with clear volume on the shell.

So effectively your eyes should have a layer of water on them.

Michael G · April 2013

SphericLabs said:
Michael_G said:
Any tips for decent genesis eyes? I cant get them to look wet and glossy. :(

I wonder if the geometry shell trick would work on this? You might need to setup most of the eye stuff on Genesis (Irus, etc) to be a simple glossy and then do a geometry shell, but turn off everything on the shell but the scelera and the cornea(I think). Then do the Glass2 with clear volume on the shell.

So effectively your eyes should have a layer of water on them.

oooooh thanks!

Michael G · April 2013

Bit better, thanks Spheric.

SphericLabs · April 2013

Michael_G said:
Bit better, thanks Spheric.

Awesome.

I am blown away at the realism y'all are achieving. I figured once you artists had a chance to work your magic, we would see some great looking skin settings.
-> http://www.daz3d.com/forums/discussion/20918/

Michael G · April 2013

SphericLabs said:
Michael_G said:
Bit better, thanks Spheric.

Awesome.

I am blown away at the realism y'all are achieving. I figured once you artists had a chance to work your magic, we would see some great looking skin settings.
-> http://www.daz3d.com/forums/discussion/20918/

Dude its all your fault :D

SphericLabs · April 2013

Michael_G said:
SphericLabs said:
Michael_G said:
Bit better, thanks Spheric.

Awesome.

I am blown away at the realism y'all are achieving. I figured once you artists had a chance to work your magic, we would see some great looking skin settings.
-> http://www.daz3d.com/forums/discussion/20918/

Dude its all your fault :D

100 pages of posts. Wow.

I give the credit to the LuxRender devs, but I am glad I can play a small part.

Rayman29 · April 2013

I rarely get highlights on the cornea, without adding an area light next to the camera. I keep its output low, just enough to reflect in the cornea.

Michael G · April 2013

@Spheric is there any chance of adding the Accelerators to the next build?

SphericLabs · April 2013

Michael_G said:
@Spheric is there any chance of adding the Accelerators to the next build?

Hmm, nothing in the spec about accelerators
-> http://www.luxrender.net/wiki/Scene_file_format_1.0

I will look into it.

Michael G · April 2013

SphericLabs said:
Michael_G said:
@Spheric is there any chance of adding the Accelerators to the next build?

Hmm, nothing in the spec about accelerators
-> http://www.luxrender.net/wiki/Scene_file_format_1.0

I will look into it.

http://www.luxrender.net/wiki/LuxRender_Render_settings

SphericLabs · April 2013

SphericLabs said:
Michael_G said:
@Spheric is there any chance of adding the Accelerators to the next build?

Hmm, nothing in the spec about accelerators
-> http://www.luxrender.net/wiki/Scene_file_format_1.0

I will look into it.

Ah there it is
mesh::acceltype

SphericLabs · April 2013

SphericLabs said:
SphericLabs said:
Michael_G said:
@Spheric is there any chance of adding the Accelerators to the next build?
Hmm, nothing in the spec about accelerators
-> http://www.luxrender.net/wiki/Scene_file_format_1.0
I will look into it.

Ah there it is
mesh::acceltype

If you can't wait you can experiment with pasting one of the following into the Extra Mesh Settings(choose more mesh parameters option)


"string acceltype" ["kdtree"] 
"string acceltype" ["grid"]
"string acceltype" ["qbvh"]
"string acceltype" ["none"]
"string acceltype" ["bruteforce"]

I am not seeing sqbvh, it must be a 1.3 LuxRender feature.

cwichura · April 2013

sqbvh has been there for a while, more likely just not documented in the wiki. It is still technically considered experimental. (Going by the Wiki alone, there are a lot of things missing. The source code is the real documentation...)

That said, qbvh is really the only accelerator type you should be worrying about. I honestly wouldn't even make the acceltype a render parameter; just set it to qbvh always and if someone REALLY wants to change it, they can use the extra settings. You can see performance gains using sqbvh with some scenes, but it's not massive in my experience, and I have found is often slower than qbvh. It also requires a lot more memory. qbvh is faster than kdtree and also much more memory efficient. I believe grid and bruteforce should be considered deprecated.

SphericLabs · April 2013

cwichura said:
sqbvh has been there for a while, more likely just not documented in the wiki. It is still technically considered experimental. (Going by the Wiki alone, there are a lot of things missing. The source code is the real documentation...)
That said, qbvh is really the only accelerator type you should be worrying about. I honestly wouldn't even make the acceltype a render parameter; just set it to qbvh always and if someone REALLY wants to change it, they can use the extra settings. You can see performance gains using sqbvh with some scenes, but it's not massive in my experience, and I have found is often slower than qbvh. It also requires a lot more memory. qbvh is faster than kdtree and also much more memory efficient. I believe grid and bruteforce should be considered deprecated.

Perhaps they removed it then, no sqbvh in the 1.2 LuxRender code:


 Mesh::MeshAccelType accelType;
 if (accelTypeStr == "kdtree")
  accelType = Mesh::ACCEL_KDTREE;
 else if (accelTypeStr == "qbvh")
  accelType = Mesh::ACCEL_QBVH;
 else if (accelTypeStr == "bruteforce")
  accelType = Mesh::ACCEL_BRUTEFORCE;
 else if (accelTypeStr == "grid")
  accelType = Mesh::ACCEL_GRID;
 else if (accelTypeStr == "none")
  accelType = Mesh::ACCEL_NONE;
 else if (accelTypeStr == "auto")
  accelType = Mesh::ACCEL_AUTO;
 else {
  SHAPE_LOG(name, LUX_WARNING,LUX_BADTOKEN) << "Acceleration structure type  '" << accelTypeStr << "' unknown. Using \"auto\".";
  accelType = Mesh::ACCEL_AUTO;
 }

Slosh · April 2013

Rayman29 said:
I rarely get highlights on the cornea, without adding an area light next to the camera. I keep its output low, just enough to reflect in the cornea.

I've been experimenting with trying to create a "catchlights" object just behind the camera to add to the highlights, but so far haven't had any luck. What makes it difficult is not being able to see what the character is looking at, like a camera through their eyes (which I have also tried to make).

Here is a render I did last night for Michael_G's eyes question. These are the settings I have been using recently, but not sure if they are quite right yet.

cwichura · April 2013

SphericLabs said:
Perhaps they removed it then, no sqbvh in the 1.2 LuxRender code

It's still there. It's dynamically registered in accelerators/sqbvhaccel.cpp.

Keep in mind that the accelerator specified by the Accelerator statement in the scene file only applies to shapes with accel type none when the primitive is reduced during scene prep. I'm not sure about in-line mesh declarations, but the default for plymesh is auto, which sets the acceltype based on the total number of primitives in the shape. Small meshes (<250k) get assigned none by auto. So scene is loaded, some meshes get set explicitly to kdtree or qbvh if they are large enough and reduced. Then after everything is loaded, all shapes with acceltype still set to none get glommed together in the accelerator type declared by the Accelerator scene file stanza.</p>

cwichura · April 2013

Looking at the source, inline mesh declarations also appear to use auto as the default accel type for each shape.

But the confusion here is over specifying the accel type at the mesh level or the scene level. I would argue that specifying it at the mesh level is something that should not be exposed, as most users are more likely to make things worse than help themselves by overriding the auto selection on a per-mesh basis. Bad meshes sometimes give QBVH problems, but those are so rare, it's really not worth worrying about. And the real solution is to fix the mesh, since while kdtree may load it, it's still gonna make the render suffer.

If you expose a parameter, it should only be for the scene-level accelerator used to collect all the none/global meshes at the end of scene prep. And again, I think for 99% of the cases, just setting it to qbvh is what you want, and doesn't really need to be exposed to the user.

Rayman29 · April 2013

I usually set cornea specular colour to 20,20,20 and remove any maps. I also some times use eye>point at, to position the reflection on the cornea.

---------------------------------------------------

Further discussions here

Notifications

Luxus discussion

Comments

Adding to Cart…