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
Wowie hit the point I was thinking of, the rare times a surface is stupid simple, or only uses a single 'block', vs the Shader that has millions of parts that probably are not all used and still eating up CPU power just being there (even if only threw that encrypted IO bit). lol. Tho in general, yah, Shader mixer dose appear to be slower then scripted shaders for more complicated things then just diffuse, lol.
Oh, it is done. I think I got it all in the zip.
http://www.sharecg.com/v/82613/view/21/DAZ-Studio/Staff-Of-Render-Hell
Two reasons, why even on a single brick network, SM will always be slower...
1. The bricks need to be found, organized and then compiled before being passed to the temp folder as compiled sdl file. And they code passed to the compiler is not organized/optimized in any way.
2. They are compiled at minimal optimization level O=0 or O = 1 (can't remember which), so that automatically makes them run slower.
Thank you for sharing, Zarcon. I don't know when I am going to have a render to brag, but this model of yours looks so cool from the purely design and colours PoV =)
Y'know, Mike, this might be it. I remember him saying PRMan "pwns" 3Delight on these very forums. And if there is a PRMan-style gather() there somewhere... Join in the chorus!
This almost made me literally cry.
Damn. *sighs*
*nods*
Me too.
I think it should be possible to make DAZ Script generate procedural noise maps according to mesh UV, save them out and apply automagically as a texture map. In a renderer-agnostic way. Won't work with IPR-like stuff, and I don't know how to make a preview window for those procedural patterns, but it's because I am a beginner in terms of what DAZ Script really can do.
UE2 is doing something different...possibly it is using the older occlusion()/indirectdiffuse() pairing that was required in the pre-3DL 7 era. The original UE came out in 2008, 3DL was at version 8, then but If I recall, wasn't DS at least 1 FULL version back? (that would have put it at 7 or probably 6.5) and UE would have HAD to use that construct). If that code was recycled in UE2, without updating/accounting for the post 3DL 7 changes....
I'm fairly sure that UE2 is likely to be using older code/methods...probably won't be able to take advantage of the improvements.
Depending just how bad the compile optimization is set for the beta (akin to that shader 0 or 1), it may not even be using the CPU's FPU and Multiplayer, doing division and multiplication longhand with just the adder (that's a dreadful thought). I would like to think we have moved beyond the days of th 8088 with the optional external 'Math Unit', however I have some doubts given the results posted.
You know, now that I think about that, it may be compiled with that Pentium math patch. One of the math units was bad, so the fix was to do that operation longhand using the remaining good units. Hence the 100MHz 486 still outperformed the Pentium in those days, lol.
Without having access to the source code, this is all speculation. Worse, there's really nothing that could be done to change it. The onlly people that can change that are DAZ and omnifreaker. If anyone have a way of contacting him, you're welcome to try.
As I said before, the best tools going forward are Kettu's shaders and lights.
Thank you, Wowie. And yeah it's all speculation, but we're speculating for the sake of the scientific method =)
----
Could be as well. Indirectdiffuse() is listed as obsolete/deprecated on the 3DL wiki, so I doubt the DNA folks care about its performance anymore. Maybe further optimisation of trace() could break those older shadeops. If I have time, I will try to test these assumptions - I have an old indirectdiffuse()-based custom light, and there is envlight2 that uses gather() - though in a 3DL-specific way, of course.
envlight2 doesn't suffer a hit...
I'm guessing it's either a prman type gather() or indirectdiffuse ().
Very true. I still think it is just a 'debugging' thing in the beta, possibly with all optimizing off at that, for debugging reasons.
lol. and Kettu now has an evil tool to bring his light shaders to it's knees, eek. It need not be the 'unruly creation' it's self, as much as what it tests. I actually wanted to try a negative index of refraction (les then 1 in other shaders I think. like 0.75 index), tho the DazDefault shader didn't allow that, lol. Perhaps one of the other 3DL shaders can, possibly. Iray lacked the ability to do a Perfect reflection without some kind of 'noise' and I thought that was odd. The instant the 'Glossy Roughness' goes below 0.0001, the reflection simply turned off, There are telescope mirrors that do a better reflection then that, hmmm. Iray didn't give me anything close to what I wanted, I think I was asking for to many deferent extreme surface types for Iray when it was in beta, lol. AoA and Omni appeared to be more promising, tho I haven't had enough time with them yet.
The bands. well I was shooting for red in shadow, blue in direct light (or the other way around), and shades of purple in between them. red, pink, purple, magenta, blue, in a way or something like that. I almost got it close with the Daz default, you can tell that is "not normal", good enough for my needs.
The staff blinking out of this spacetime as the gravity wells form. Pure perfect reflection with pure perfect transparency, bands about the same, deferent color. The Daz default couldn't do that without other artifacts, and I've yet to try it with other shaders. The render times as noted earlier, are beyond painful.
Well, renders in about 1 minute for me. Exactly 59.75 seconds for rendering the entire staff and about 1. min 44 sec for the close up. I just applied a metal Chrome preset, enabled Opacity and Refraction, plus adjusted the Ambient channel. Didn't get the same deep purple on the non-metallic parts. It does have variations due to a mix of ambient and opacity color.
As I suspected, the massive render times you see is due to the DAZ default shader. You're better off with even plain UberSurface.
I definitely recommend not coloring/tinting some of the maps (ambient). If you had used clean mask, you can change the ambient color to whatever you like. Model wise, the geometry is quite dense. You can probably just use SubD on that and shrink the polygon count by quite a bit.
Even in the test chamber, as it loads with the staff as it loads, in Studio, it renders in under an hour for me. Changing things up and what not, I can get the staff to render in 2 minutes...on my 4 core machine.
I ended up going with colored maps, as the color selection on specular tends to tint the reflection. I would not be surprised if the reflection on the daz default is not the best for that. without the ray-traced reflection the staff dose render really quickly. I went with the mesh density, as I've had issues with 'smoothing on' causing odd shading on the ends of things when I d-form them into a shape (like the ends of the cylinder on that staff).
The past few days, I was checking out ships (space ships) from other sites. Some work well in studio, others are useless without completely remaking them from scratch to work. The past hour or so, I've been installing Trek sets that I just purchased.
http://www.daz3d.com/forums/discussion/comment/941485/#Comment_941485
I guess I should look to see if I can convince the Omni Shader to give me that nice ray-trace reflection and the bands that react to light. I remember something about the color of one channel tinting the others, tho that was a long time ago.
(EDIT)
Yea, there is a B/W mask in there for that ambient color thing. "sorh256x2001.png", I should have just used that on the ambient and diffuse.
Those renders look really good by the way wowie.
Well, that map is best used for the ambient strength (not color). The only problem i see is the specular. Since it's a mixed surface, what you want to do is a make specular strength map that's weaker on the chrome (reflective surfaces has less specular) and a reflection strength map that's greater on the chrome (just invert the values of the previous map). You still need to raise the overall specular/reflection strength to account for that (so you ended up with what you're aiming for).
lol. before 4.8, I would have said that was impossible (I think I made that staff in 4.6). before 4.8, reflection strength (or most of the dials) would not go beyond 100% intensity/strength, lol. The shaders will now go beyond breaking point if I ask them to, so it is a new ballgame. I am starting to get a laundry list of stuff I want to do to that staff. I'm still not going to touch the 'Original' as that's the one that was breaking things, that's the baseline of sorts, lol.
And no, I don't know why I had green in that one channel on the original, that was just to long ago for me to remember what was up with that.
Specular strength vs glossiness. Didn't I essentially do that by setting the glossiness with that map. no gloss where the white is (infinitely small gloss spot), and more spread out gloss where that map is darker (on the bands)? That way, I can have the specular color pure white for an unnatural perfect reflection (on the chrome part). Also Any color other then 255 white or any map in the reflection Chanel just turns off ray-trace reflections and makes it a mapped reflection (not what I wanted), so using that to off-set any color in the specular slot on the chrome just isn't going to work. A significant limitation of how each slot interacts with the others inside the shader. It would very much be better if I had the ability to redo the UV mapping to make them separate zones entirely (it's just so far beyond my knowledge at this time. what tools and how to use them).
I think the AoA and Omni may be better for that anyway, as I think the reflection is isolated from the other slots, in that specular color dose not tint the color of the reflection, I think? I need to try a few deferent combinations and see what happens with them. I remember something somewhere with some difficulty with silver inlay in a patron vs color somewhere, and the solution was to map out the silver in the other channel with colored maps instead of masks with backing colors for the cloth (That was a long time ago, my brain hurts, lol). Found it, attached screen-cap using the omUberSurface shader. I honestly can't remember if that was effecting velvet or gloss, I don't Think it was reflection.
There is something most definitely FUBAR with UberEnv2 and 3DL 12...
This render, consistently for the 15 times before the one I'm posting, without a UE2 light in it took around 180 seconds low of 167/hi of 185), in the standalone 3DL 12 to render. Adding a UE2 on bounce to the scene upped that to a whopping 87769.65 seconds (that's right, 24 hrs 23 mins). That is officially the LONGEST 3DL render I have ever done! Yes, I expected some increase..;.but not anything like that.
After it was still running when I woke up this morning I thought I'd let it finish, to see just how long it would take and now I know.
After looking over the RIB...
1. The new raytrace hider was enabled, raycacheing was NOT enabled!
2. Editing the RIB to enable raycacheing...still longer than I'd expect, but not 24+ hrs (3273 seconds).
3. Found that max depth was at 8...and without the UE2 light, it was still rendering around 3 mins!
4. Dropping max depth back to 2 and disabling the UE2 light...180 secs. With the UE2 light...323.15 seconds
Ah, yep, that's a long render. That ranks up there with a few others that were Not experimental renders, and I take it that was not at Max-Quality render settings (Shading rate, filter X Y, etc), lol.
I'm not sure I like the sounds of this new 3delight, 'Feature'.
That's confirmation of my results, I think. So even when we use kettu's script, raycaching parameters are just ignored? Wow. That's just stupid.
Not quite...
The 'easy' way for me, because using the collect and localize doesn't work right, probably with the way I have things set up, I create a RIB with Kettu's script and then a 'vanilla' RIB, with 'regular' 3DL...which does correctly collect and localize. Then I copy and paste the header/set up options from the scripted RIB to the 'vanilla' RIB, overwriting them. I forgot to do that for the first render...the longest one. But when I went back and pulled out the UE2 light, with the 'vanilla' RIB, it still took a long time, the almost an hour, but not the totally outrageous time.
Basically, it's the UE2 code itself, that is behaving poorly under 3DL 12...it's as simple as that. It's performance has suffered a huge drop. If I get a chance, I'll drop back to an 11 version and run the 'original' RIB and see what kind of performance it has.
And one other thing...recompiling the shaders did nothing to improve the performance...
Ah I see.
That's inline with my tests. 11.0.105 is the version used in DS 4.7. As for the standalone, I only have 11.0.5 to test.
Either way, DAZ should've enabled raycache. Even if UE2 is screwed, that's 24 hrs 23 mins compared to 54 min 33 seconds. I think that's about 20x improvement.
Exactly....
Without raycaching, it is totally intolerable. With it and UE2, it is barely tolerable...
Silly question regarding 'raycaching', as I try to think of a reason some would not use it. Is it's render quality akin to Lossy compression (JPG, MP3, etc) vs No compression at all (BMP, WAV, etc)?
Or is it just a ray-bundle method, that doesn't change the quality of the render at all?
Second one. Ray caching, sorting, batching just helps squeeze uot more performance. It's not a rendering method like point cloud or photon mapping.
It pretty much is the second.
The problem is when it was first introduced, it was not always the best route or quickest (it didn't help much and may have slowed down some simple operations), Plus it would cause the render to hang/crash in certain cases. So it was made to have an on/off switch. But, those cases (crashes) were quickly patched, more optimization was done so it's almost universally faster and there's not much, if any difference now on the bottom end (it doesn't slow down the very simple stuff). But the default is still 'off'. And even if it was 'on' the way some of the stuff in DS is written, it would actually turn it off, because it puts an explicit '0' (off) in the RIB...if it didn't, then when the default is 'on' (1) it wouldn't matter.
Ah, so there is possibly opposition, because of some very bitter experiences in the past. I know I've had my share, and some things I'm just not willing to give another try because it burnt me so badly (Non-daz related stuff).
So perhaps it may take some demonstrating to prove that the issues that once were, are no more. And in some cases, we may have to except that there are some that just will never be convinced.
THe best option would be to expose the parameter and let you decide to use it or not. If it doesn't work or add value to your workflow (ambient occlusion only), then you can opt to turn it off. But if you do photon mapping, indirect light and bounce rays/light, you have the option to turn it on.
But like everything else, DS with 3delight is stuck in the 90s.
Zarcon, I wouldn't say diffuse ray caching burnt anyone much in the DS world. It's one of those options that original DNA plugins (for Maya or Max) enable 'behind the scenes', but it's not explicitly mentioned in the published documentation - only on the 3DL forums. It's never been made a thing in DS - before I found it on the 3DL forums and put it in a script, haha.
I think we should just accept it that working upon perfecting the 3Delight/DS integration is not a priority for DS developers. We have been given the tools (however clunky and documented in a rather limited way) to try and do it ourselves, and I think I am simply grateful they aren't taking them away now that Iray is the new default.
I don't even know how many people are there in our community (outside of the regulars on this thread and a couple of non-forumites I know) who are genuinely interested in using 3Delight efficiently and effectively. If only we could run polls here, LOL
I'm going into a sort of 3D hibernation for the next several weeks anyway. November and December in my case mean too much extra stuff at work, and an overall 'malaise' because of all the weather changes (and draughts).
I think the Draft thing is stuck, lol. I may simple need to reboot the computer, I forgot how long ago was the last time, lol.
I like the idea of that raycaching being an 'Option' switch in the render tab, tho I'm not sure how easy it will be to sell the idea to daz. It is after all, essentially a free version of 3delight, that sometimes is newer then the free standalone you can get from DNA. So they may have some agreements that prevent them from including the "Really juicy features" that are in high demand.
I'm also not sure just how bad my standing is for bringing something like this up. I think I fumbled onto the biggest issues, that are nearly impossible to address. There is the dog house, then there is "Outcast", then there is me, lol.
(When I signed up for this Technomage thing, I had no idea this implant technology was Puer-evil in origin)
I do hope you have a good 'Busy season' kettu. I do tend to like to stay off the roads in December mostly because of all the other non-experienced in snow drivers out there, compounded by there hectic got to be there for the holiday rush, lol.
SORH geometry. This is another reason I went with such a high poly count. I keep stumbling onto surface settings that just break on shading around curves and revile the underlying geometry.
Yes "Smoothing" is on, it's still there, lol. The normal map is on the left vase, Displacement on the right vase. I was (and still am) experimenting with using "Fabric Basics Iray" shader's maps in 3delight. So I'm going to get back to experimenting with this, and see IF I can figure out what setting is doing that striping. Because it was not so pronounced in a few of my fumbling-s with surface settings.
http://www.daz3d.com/forums/discussion/comment/944973/#Comment_944973
P.S. The test vase is one of the trinkets in this set.
http://www.sharecg.com/v/81718/gallery/21/DAZ-Studio/ZdgStone-Shader-set-01-for-3delight