Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
This is a mostly reflection blur sample test. I've intentionally used lower pixel samples count (3x3) in the renderer options, so that explains the aliasing artifacts on the zipper and other geometry edges. Specular levels aren't correct yet - it still needs toning down on the rough dieletric preset. Bump mapping is also disabled, since I want to isolate the test to pure reflection.
What I've found is that reflection blur samples will vary depending on how much blur you use. More reflective, less blurry so less samples needed and vice versa. 8 samples is quite adequate for up to 10 samples. Higher blur levels like 25, 50 or 100 needs 16,32 and 64, respectively.
True, but I guess for many people it's a good starting point because it's simple and well-documented.
And thanks for the links!
Here's another one, from Image Engine - Breathing Life Into Chappie
http://image-engine.com/press/siggraph-production-session-2015-full-presentation/
Damn, the Scout robot is clot to 4 Million polys and 152 GB of textures (for all the models variations).
Video 2 is probably the most interesting since it delves into the technical details of the look dev.
I have been trying to replace textures using Lumina Materials Library and make them look good.
However, I have been having some trouble... I think I don't quite understand all the details I need. On the pillar, I have some glowing creases where there should be shadows - see the lowest part of the pillar just above the base.
Have you checked the properties of the pillar yet? Parameters tab. It almost looks like it's set not to cast any shadows. What light are you using in the scene (point,spot, ambient, UE2 or AoA's Advanced Ambient)?
Thanks, wowie. Cast shadows is set to On for the pillar - which is part of the wall section. That whole section has shadows on.
I am using AoA's Advanced Ambient, Spotlight and Distance Lights in the scene.
I haven't used them in awhile but here goes.
If you can, it's much easier to troubleshoot during an IPR session. Start with all scene lights disabled and toggle them individually (one by one) to see which light is the culprit. For spot and distant light, try using the DS default light with similar settings (with shadows enabled). Generally, just copy and paste the properties of each spot lights and distant light that you have from the AoA's light to the defaul light.
If that doesn't work, create a cylinder, apply the same preset you used on the pillar, copy the pillar's material and paste it to the cylinder's material. Just to rule out the possibility there's something odd in the pillar. If the cylinder exhibits the same behaviour, save the lights and the cylinder as a scene subset and send it to me via Dropbox, Google drive or something similar.
Thanks, wowie. I'm running those tests right now.
I think I found it. There was a light auto-loaded which included a headlamp blocker. I had turned it off and used the AoA lights.
It's strange, but I have found that having a headlamp blocker, even turned off in the scene tab, will still influence the lighting. When I deleted it an added the ambient and the fireplace linear point lights, then the shadows fell properly.
Thanks for telling me where to look!
Hmm, yea, the headlamp blocker is a through back to a version of studio that did not haf an on/off switch for the headlamp. I think there is a switch for the headlamp now somewhere in the render tab(?), so the headlamp blocker being in the scene may be doing odd stuff with the lights.
Also, when swapping surfaces over to other shaders, I've noticed maps get lost or settings go wild on some stuff (like reflection strength going to 100% from off on teeth). Nice render by the way.
headlamp blocker comes in the camera tab to switch between on off and auto in DS 4.9. works fine with auto most of the time but then I still don't own the AOA lights..
There's also DS loading some sort of an extra headlamp blocker with area lights. Generally it's okay when you load the area light "fresh", but if it comes from an older preset saved out in a previous version of DS, it may misbehave.
And then there is a camera setting in which it's possible to accidentally have the headlamp "always on".
Thanks Kettu, that's what I was thinking of being in the render tab, oops.
There are TWO locations and each controls it in different ways.
The Camera one, controls that specific camera...so if you have more than one camera, then each camera needs to have it turned off.
The other one (render) is Iray specific (I think...maybe not, but I'm in the middle of render and can't check) and will turn off all of them...and any new ones.
Thanks, It's OK, it was the camera one I was thinking of (and I mistakenly typed 'tab' instead of 'room'). I often set up cameras in the render room, just so I don't accidently mess up the camera location in the other rooms when I go to adjust something, hence the "Not sure where it was" moment. Good note on the multiple camera thing, I was not aware of that.
Looks like there is a headlamp setting in the render tab if there is nothing in a scene, hmmm. Iray is a different kind of thing with a sky-dome/sun kind of built in with many options.
http://www.creativebloq.com/3d/how-paint-realistic-creature-skin-textures-101413116
It's not exactly 3Delight-related, but I figure most of us "tinkerers" do wind up painting or otherwise editing texture maps for best results. These are very structured tips.
Mjc's render time comparison post for a hi-res model (REYES, raytracer, raytracer + GI caching, and CPU Iray):
http://www.daz3d.com/forums/discussion/comment/1810666/#Comment_1810666
I picked the most neutral/boring shader I had to run it, since the 'autoconvert' of the Default skews the times by the time spent converting, though for no textures, it isn't that much. I did several runs, including leaving the previous Iray render open and got less than 1 second variance among the 4 runs. The time I posted was the 4th run.
I knew that there would be a difference between REYES and raytracer, but I really didn't expect that big of one. And the difference is maintained when adding more to the surface. I didn't try any of the big time hits..like SSS, but everything else kept that huge gap. And this is the version of 3DL in 4.9. I know dumping to RIB gets an automatic boost in speed by dumping the Studio overhead. The gap between 3DL and Iray closed somewhat with more surface shading (but that was without pulling out shaders most folks don't have access too...sorry, Kettu
), it's rather obvious that hi-poly being a 3DL time killer is not true (or as true as it may have been in the past).
I think that most folks just have accepted what used to be without even considering the possibility that things have changed...I know modern/raytracer optimized shaders will show even better/hold up better to increasing effects/'photorealism', but since most are either impossible to port into Studio without hand crafting the support scripts or not accessible to the general user base, I didn't bother with them.
I may do a 'godray' test some time...
Yeah, I always go progressive if I can, although there are a few shaders that seem to fall apart or fail to work properly in progressive mode (Stonemason's dirt shaders, for example).
That's odd...unless they are using something that is very old. I thought they were a ShaderMixer build not a compiled shader...and I can't think of anything in ShaderMixer that should be incompatible.
There procedural, like ones for grass and rocks that I looked at a very long time ago that broke in progressive mode.
it produces geometry that is not really there in Studio, tho renders as if it was there. I'm Drawing a blank on the name of the shader product.
(EDIT)
Found it.
http://www.daz3d.com/forums/discussion/comment/982082/#Comment_982082
It was the AoA rocks.
http://www.daz3d.com/rock-grass-bundle
The lack of instances rendering in progressive mode (that's what that has to be) is not something I've run into. Other problems with instances, yeah...but not that.
OOh I know this one! In my expirience Displacement, particulary tiled displacement looks quite different, and progressive mode looks less displace-y (also, with all other settings remaining the same, progressive is signifigantly slower)
In the 2 images below the only difference was switching progressive on
I'll set up some tests later, but I think I know whats going on in those two examples...
Which lights and which shaders?
As to the speed...that's something that shouldn't make a difference, but there are cases where Studio is doing something odd with how it passes SubD to 3DL. There's some discussion on those oddities way up thread...
Ubershader basic and default lights with raytraced shadows, I think (it had happened with shader mixer shaders too) I always assumed It had to do with when the displacement was calculated relative to the the shadows
Displacements are done differently between REYES and the raytracer - because REYES does the micropoly thing without tracing for the camera, and the raytracer, well, only raytraces, even the visibility =)
So in certain cases, especially when the surface and/or light shaders are complex enough, displacement tracing may become noticeably more costly in the raytracer than in REYES.
And sometimes, the mesh will "tear" like in Zarcon's render if the topology isn't optimal (and in the case of AoA Rocks, it certainly wasn't optimised for the purely raytraced displacement because nobody really knew anything about it back then).
But when nothing "tears", it will be shaded in a more "correct" way (no shading rate involved in the raytracer), and so can appear "less displace-y".
It all was one of the reasons the 3Delight devs introduced a new displacement mode, vertex displacement, that is similar to what Carrara (and probably Iray??) has: it only moves actual model vertices. It obviously can't do the classic 3Delight superbly detailed displacement, but if the displacement map creates large features and the mesh is dense enough, it's quite nice, and fast.
...did I mention you can't do it in vanilla DS? =)
Uh, don't remember what lights, that was way more then "Many cups of coffee ago". I think it may have been the test chamber lights, possibly, Don't quote me on that. Simple Daz menu spots, OmUber soft-box thing (area light shader on a plane), and surfer guy UE2 (all stuff included free with Daz Studio).
The test chamber is here ShareCG, or DA If you don't have it already (The only thing not CC0, is the Surfer guy UE2 light map. Everything else is either free with Studio or from me and CC0).
I know the newest renderman has no REYES (I think because it has issues with with some of the more modern methods of light transport, I think thats what I read anyway)
Also I think I am obligated to mention that blender has really glorious micropolygon displacement in cycles now. Everything gets raytraced just as it should, the memory hit isnt bad, its super pretty... sorry, carry on
Haven't looked at the documentation for Renderman 21 yet, so I can't confirm this but given the apparent new direction they are going with it, I wouldn't be surprised to find out it's true.
And probably SuperFly (Poser 11 Cycles based rendering engine) as well.
The other slowdown with omUber is that it poorly optimizes the displacement bounds...so much so, that even with large 'movements', it will only use a fraction of what has been set aside for it to use. Calculating against the boundary and then caclulating the real amount is time wasted. That's basically what the 'this surface used x% of its bounds' warning is all about.
A reason testing needs to be done on more complex scenes...there's a certain amount of overhead that each rendering mode has and on small scenes, the REYES mode has the least internal overhead, but once past a certain complexity, it starts lagging behind in the actual render process. While the raytrace modes have more overhead in the short term, over the long/more complex scenes, they will catch up/pass the REYES in speed. In other words, the raytracer starts slower but finishes faster and if the scene isn't complex enough to account for that, it's not going to show up as 'faster'.