Adding to Cart…
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2026 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
Cool tests, thank you!
I agree that ambient objects are more for "flavour" at this point. What were the area lights in your tests, Ubers or one of mine?
I've noticed that there seems to be a big difference between the samples needed for your area lights, Kettu, and the Uber...
This is with DelightGIHDRI and the 'default' map for Iray...
(yeah, I converted the CutiePie outfit for Dawn/Diva to G3F...)
wow I did not know Houdini had a free trial download http://www.sidefx.com/get/download-houdini/
I have seen tons of stuff created with Houdini But I always thought you have to pay some godly amount just to try it.. I'm gonna have to experiment with it now to see how much its worth investing in Annual Upgrade Plan
Thanks for the information Wowie.
I'm using UberArea lights.I'll probably test your Area lights later on. Oh yeah, I also noticed this with the tooltip for some items on your kit. I think I might still be using the older kit though. I noticed the Area lights are still UberArea lights.
Yes. But it's not that I did anything special for it. Which probably proves that simplicity is king. =D
Looks cute, but of course my default sampling settings are a compromise.
The "perfect" sampling setting for DelightGI is 256. It will acceptably smoothly resolve almost any HDR map (even those tricky small but very high-range ones). It doesn't make render time skyrocket either.
With the current 3DL releases (both the DS one and the standalone), 256 is also the "optimum" sample count for SSS. You can increase it for even better fidelity with those tricky maps, but in most scenarios, it's enough, especially with some diffuse (around 20%).
256 is also "the" setting for GGX refraction (like in my glass). Basically I'm thinking about upping the default reflect/refract samples to this number because the documentation says these are "maximum" samples, so the renderer does intelligent culling and won't shoot unnecessary rays.
I've also added specular-to-diffuse culling to RadiumFabric because it really helps with fireflies.
Oh yeah, and per-vertex displacement is a thing now, too. I'll show some examples this weekend if anyone's interested.
I'm adding features because I can't force myself to write documentation LOL I currently have too much to write at work.
Would be cool if you tested "oldschool" ones (ShadowArea) vs path-traced ones (AreaPT). I just haven't been able to bring myself to try and measure which approach is more efficient for our type of models. The issue with comparing them, though, is that their intensities don't match. I'll try to backtrack through the code and figure out why, but not today.
And thanks for reminding me I need a more descriptive tooltip for DelightGI than the default DS text about Ci and Oi =)
If you have the "Mesh Lights" folder under "Lights - Mustakettu85" in your content library, then you have the current alpha. I decided to distribute areas with custom (non-shader builder) scripts, so they install pre-compiled along with the render scripts in the DS exe file folder, and the duf loaders go into the content library (every shader builder piece will have a duf loader eventually, too). The source code is also there in the "shaders" folder alongside the compiled sdl files.
Hmm, I couldn't find any reference to Radium Area lights in my content folder. I have the Mesh Lights, but those just load as UberArea lights. Double checked the downloaded package to make sure and I didn't see any Radium Area lights in there either.
My bad, the folder is "RadiumArea" (never rely on your memory with an allergy active, haha). It's from the update. I'll PM you the link once again just in case.Just got it. Looking at the files, I think this one is newer. I noticed more shaders than the one in the older package. And Houdini have associated all .sdl files to it. :) Damn, I still have a big smile on my face from seeing all the neat updates in 15.5.
Got this error when I try to compile the fabric shader. That's the one that won't work in <4.8?
Did some test with the Shadow Area lights. Still had to push samples to 128 to get a clear image, but they render faster than UberAreas. 32 samples was 12 minutes, 128 samples was 13 minutes. Give or take a few seconds. The UberArea only render above was around 15 minutes, with the same surface settings. The big plus is changing the sample value settings works in IPR. Falloffs are different, but that's a given. Another is that speculars from your area lights doesn't get turned off with UE2. That alone makes it better than UberArea for me.
Interesting paper.
https://www.disneyresearch.com/project/modular-radiance-transfer/
Yup, RadiumFabric in the "Plus" and beyond editions is 3DL12 only. If you use the 4.9 beta trick, you can install it into the beta app folder, which is right there next to the "normal" one.
Two things about AreaPT before you try them:
1) They need surface shader support, so only mine will work: look for the latest versions of Solid, Fabric, Glass etc which have the "PT samples" settings in their diffuse and specular channels. These control how that particular surface channel samples the light.
2) For these area lights, 3DL MIS only supports polys, not sub-d surfaces. So it's best to use single poly planes for emitters to minimize noise and render time.
Thanks. The documentation was pretty clear on those points. Won't be using 4.8 or higher though. It should work with exported RIB (to the >3DL12 standalone). At least, I think it should.
One other thing I like about the Radium Shadow Area lights - they pass through the SSS precompute phase very quickly. Way much faster than UberArea light and maybe even the default delta lights.
I haven't specifically ever tried bypassing DS built-in version like that, but in theory it should work, if you compile the shader manually and put the resulting .sdl in the RIB folder.
I tried to follow the tutorial on converting EnvLight2 to Daz3D and I can't get it to render properly - it just renders black. I've tried inside enclosed spaces, in a scene with only a figure, .hdr files, .tiff files (omnifreaker's stuff), double checked the settings, deleted it and started over (even giving it a different name) and it's no good.
Is the tutorial compatible with the current DAZ / 3DL build? I could just be making a mistake somewhere, but I figured I should ask since I can't figure out what it is.
But Kettu's GICache / Diffuse Bounce Clamper Render Script, SSS tutorial, and light sets have all been both effective and educational.
Well, the EnvLight2 that I did in an earlier version runs just fine in 4.9, so it should still build.
Were there any compile errors?
Is Shadow Type set to anything other than None?
Thank you for your kind words, SmokingSun!
Apart from what Mjc suggests, may I ask if you´re on Windows or something else?
There was a thread here - http://www.daz3d.com/forums/discussion/53330/mustakettu85-s-envlight2-help-needed - where the light didn't work because there was a caching problem on a non-Windows machine (the environment map file got lost due to DS non-Windows bugs).
4.9.2.70 and as expected no 'fixes' to the problems reported.
And I find this bit really funny:
Added Glossiness Squared property to NVIDIA Iray Uber material; set to true on newest version Iray but set to false on old loaded files
Not really GGX or GTR, and certainly not in 3delight.
I don't even understand what that's supposed to mean, "glossiness squared".
Pity there is no 3Delight update. Somehow the release notes are written that way that it seemed to me at first there was a newer build.
The mirror morph function sounds intriguing (I want to test if it's better than Tofusan's scripts), but other than that, the "product-centric workflow" gimmick really put me off. I guess I'll update the beta first and see just how intrusive those "connect" features have become.
So i guess it's not yet worth updating from 4.8? Some part of me wants to get to 4.9 for the newer 3delight version and the other part says no because of messed up files and other unsolved problems.
If I remember correctly, that was the way Sebastian Lagarde's, or rather, DICE/EA's approach to getting something GGX-like. It's in his 'Moving Frostbite to PBR' paper. Roughness squared. So you get longer tail and higher peaks (longer curve). John Hable has a different take on 'optimizing' GGX for realtime usage: http://www.filmicworlds.com/2014/04/21/optimizing-ggx-shaders-with-dotlh/ and
http://www.filmicworlds.com/2014/04/29/optimizing-ggx-update/
They did update to a new 3delight build, but I don't know which. It was just a really vague reference to updated 3delight and refer to the DNA's research changelog.
Interesting, but it's (still) tied to MorphLoader. I still prefer Tofusan's script, since it is just a script. Some additional features I think was the ability to isolate affected regions, but I saw somebody made a similar script.
Depends on your needs. I certainly have decided not to upgrade, but others may like the new features.
The newer 3delight builds don't really improve render times to be noticeable with the current available shaders. But if you have modern shaders and lights like Kettu's, it'll probably be faster to render. But don't hold me to that.
I don't have Kettu's shaders yet, but I'm taking another plunge into shaderology so maybe then I'll feel adequate to them
Via the Shader Mixer? Then I probably think there will be very little noticeable difference between 4.7/4.8 and 4.9 onwards. I don't think any of the shader mixer bricks underlying code takes advantage of the new features and capabilities of 3delight. Not certain about Shader Builder though. Mjc probably knows more.
FYI, for those who are confused with falloffs, here's a practical graph:
Generally, what you want to get is the red line, but the black line is also usable. Particularly since the rest can just be simulated with an ambient light (or bounce light). Taken from http://mvpny.com/LightFalloff.html
For the bricks...not that I know of. Nothing seems schanged. But in Shader Builder importing 'new' code works (to a point...RSL2 code is still problematic).
I'm still a long way from coding my shaders myself, so that won't be of great use to me
Lots of good code available for importing, though...
It's funny. When I want good godrays in Iray, I STILL find it way easier to use AoA atmospheric camera to generate a mask/layer to put on the iray render.
Sheesh. ;)
It's not that I don't want to but I'd like to have a basic understanding of what I do and why and then there is always this render or that I'd first like to finish before getting into the shaderology...procrastination is my second name...