Luxus discussion

1444546474850»

Comments

  • KickAir 8PKickAir 8P Posts: 1,865
    edited December 1969

    Luxus 1.0.0.5 is available in your accounts . . .

    Thanks! :coolsmile:
  • Michael GMichael G Posts: 0
    edited December 1969

    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?

  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    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 GMichael G Posts: 0
    edited December 1969

    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.

  • FusionLAFusionLA Posts: 246
    edited December 1969

    fusionla 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?

  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    fusionla said:
    fusionla 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.

  • HellboyHellboy Posts: 1,151
    edited December 1969

    Thank you very much for the update! :D

  • KeryaKerya Posts: 9,435
    edited December 1969

    Thank you for the update! :)

  • cwichuracwichura Posts: 1,041
    edited December 1969

    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 GMichael G Posts: 0
    edited December 1969

    cwichura 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 GMichael G Posts: 0
    edited December 1969

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

  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    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 GMichael G Posts: 0
    edited December 1969

    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 GMichael G Posts: 0
    edited December 1969

    Bit better, thanks Spheric.

    barbarian.jpg
    1415 x 2000 - 394K
  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    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 GMichael G Posts: 0
    edited December 1969

    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

  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    Michael_G 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.

  • Rayman29Rayman29 Posts: 0
    edited December 1969

    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 GMichael G Posts: 0
    edited December 1969

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

  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    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 GMichael G Posts: 0
    edited December 1969

    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

  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    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

  • SphericLabsSphericLabs Posts: 598
    edited 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.

    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.

    Post edited by SphericLabs on
  • cwichuracwichura Posts: 1,041
    edited 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.

    Post edited by cwichura on
  • SphericLabsSphericLabs Posts: 598
    edited December 1969

    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;
     }
    
  • SloshSlosh Posts: 2,317
    edited December 1969

    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.

    FreakEyes.png
    500 x 700 - 498K
  • cwichuracwichura Posts: 1,041
    edited April 2013

    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>

    Post edited by cwichura on
  • cwichuracwichura Posts: 1,041
    edited 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.

    Post edited by cwichura on
  • Rayman29Rayman29 Posts: 0
    edited May 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

    Post edited by Richard Haseltine on
This discussion has been closed.