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
Thanks!
Ah, N for normal. I had noticed that brick but wasn't sure what it was for.
In 3DL, how can one add user input without disrupting existing inputs?
If I add 'user parameters' brick, it overrides all the standard inputs, which... isn't what I want.
Edit: Nevermind, figured it out. heh. Any set value will appear in the inputs! Yay!
Stupid question.
So in Iray, the more textures involved, the slower things run (and, potentially, falling out of GPU rendering)
How much of an impact do additional textures make in 3Delight, generally?
3Delight used MIPMapping - essentially it produced versions of each image at different resolutions (this it the Optimising Images stage) and used only the sizes needed for the size of the item. That allowed it to cope much more gracefully with texture-heavy scenes, though the numgber still matters as far as I can tell.
Never had a problem so far, even with just 8 GB of RAM. I did a render once with 14 characters, each with a unique set and your typical indoor scene. The viewport was sluggish as hell so i had to switch to shaded view (no textures), but the renders and IPR session runs very smoothly. The whole scene was probably something like 2M polys or more.
So I have a list of elements that I think about when deciding to use 3DL or Iray... and one of them is the number of textures, particularly since it appears 3DL is FAR more tolerant of texture-rich scenes.
Good to know!
It isn't that Iray can't handle a lot of heavy textures...it's just that you won't be able to use GPU acceleration if they don't all fit in the video card's memory.
I'm not sure why you didn't think I didn't know that, but yes.
It's more for the benefit of those looking at the thread for info...
But one of the other advantages...texture related, is the fact that 3DL creates the mipmaps and at render time uses the 'best' set, depending on distance from the camera. Usually they are stored in a temp file on a hard drive, until called...freeing up more memory.
Ah, sorry for any bristling. Too much politics on FB making me jumpy. ;)
Poly-ticks...multiple, blood sucking, little vermin...
Not just textures, I think but polygons too. Both has to fit in local memory. Textures can be compressed, but polygons can't. You can set instances and optimize polycount to get around that.
Just got around to testing the latest 3delight build. I think raytraced SSS is faster now. Even with 256 samples (area light samples at 128), a head/torso render is only about 3,5 minutes.
Yeah, but generally, textures are the bulk of the memory used.
I haven't tried the latest yet.
And I thank you for that, I don't say much here but this is the thread with the highest information ratio here (still don't understand half of it but that is moer than it once was
)
Hmm,
Left to right: DAZ default material, UberSurface, UberSurface2, RadiumSolidECS (Kettu's shader)
UE2 IDL and Bounce GI. No other lights.
And?
What, exactly are we looking at/for? Other than the noise and odd reflections.
With IDL, there's hardly any gloss reflections from the US2 sphere. No such problems with bounce mode.
Yeah...part of the 'odd reflections' thing.
I wonder if it's because of the two layers in US2?
Mike!! You're back! =) The 113 build does seem to be faster by a few percent in more than just RT SSS.Soooo is the underlying plane reflective in both cases?
PS I am not responsible if my surface shaders start a revolution and defect to Qo'noS when paired up with UE2 =DLooks tasty!
Better add that as part of the 'official' documentation...
As long as you don't divide by zero ...
Both the ground plane and the red plane is diffuse only. So in that respect, you can 'workaround' bounce lighting with very blurry reflections with IDL and surfaces with other than US2 shaders.
Not really intended but there is a possibility (see attached pics). However the absorption is only based off volume distance penetration so you don't control anything.
About the overlaping volume trick that is not something that convinve me. I think it's better to go with non overlaping volume and to think in term of enter/exit media IOR
For that you would have to create a separate surface for the top of the liquid.
The liquid in contact with the glass is the only one to care about and the other surfaces have the classic calculations with respective IOR
I didn't reopen a physic book but I I'm almost sure that it would give correct refraction and that doesn't need a lot of work
Got closer to what I get with 3dfm and Indigo.
Been doing it all wrong in setup. I should've start with what you get with GI, tune the reflection and diffuse there and then work your way down to AO, lights and spec.
It's been discussed here as well (I have lost count of the time I've linked to this thing all over the web LOL): http://adaptivesamples.com/2013/10/19/fluid-in-a-glass/
Doable, but more hassle. Potential shading artefacts.
And I'm not sure if it's easy in any software to handle the separate air/liquid interface dynamically when running a sim. But you can create the overlap if you use a collision volume a bit larger than your glass.
Everyone has their own lofty goals, and mine is working with simulations.
Wow, you even made the "tear" surface seem not redundant but meaningful!