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
These have just come out:
http://www.daz3d.com/tattoo-parlor-genesis-2-male-s-geometry-shells-vol-1
Can they be made to work with RT Kit?
CHEERS!
The middle one looks like GI cache preview only; this pops up first, then the render progresses to 50% and cooks on from there.
To get indirect lighting, you need the DelightGI light - there's no surface-based IDL in the Radium shaders. If you put an HDRI map into it, it will handle both IDL and IBL. Or you can do without a map and use any other light for direct illum - either dzDefaults, or my SimplePhys delta ones,or UberArea. Just make them use correct falloff. AoA's Distant gives wrong colour bleed because of the non-standard shadow tracing direction, but that's the only real issue I have encountered.
Slow, like how slow? When I am using my scripts and DelightGI, render times for a whole dressed figure with hair even and RT SSS on skin + props background are under hour on an i7 laptop. Unless your computer is much older, your render times should be comparable.
Maybe simplest scenes like the Cornell box are slower than with other methods, but that's to be expected, according to the DNA guys. The raytracer is apparently optimised for complex scenes.
What is your OS, BTW? There are all sorts of weird things going on under WINE, as Mjc will testify.
I was doing test on my notebook and I did use the DelightGI . It's three years old but I think it's still good enough against today's standard http://www.cnet.com/au/products/hp-elitebook-8560w/ . See the specs on page 2
I don't know why but it was slow with the notebook compared with UE2 or envlight2 which cleaned up way quicker. Tried again with my Desktop. (AMD phenom black 955) and it was better for rendertime. However you still don't get the bleeding that you could get with UE
I couldn't get the caustics with the sphere but I didn't read the manual yet.
I uploaded the scene on my dropbox if anybody wants to try. I'm not sure it will work as i've seen references to the data directory in it, but it seems it's only for the UE sphere. https://www.dropbox.com/s/mo45qomu5d6lmto/DScornell.zip?dl=0
Now a few remarks about the SSS surface shader
- You should keep the DS diffuse in the diffuse and not put it in the Diffuse SSS. That is what got me wrong colors the first time. Furthermore the diffuse is used for openGL preview as well as some others. Keep DS' Standard
- You need to add a few ON/OFF switch so that one can quickly disable unwanted effects. And use DzBoolproperty instead of DzIntProperty for that
- Standard diffuse strength at 100% and effect ON. (sorry but you don't always want SSS)
- Reorder and arrange the different shading order to follow DS standard implementation (it's a pain to seek for the diffuse which is at the end)
- One script to transfer all the maps where they should (on big scenes with a lot of surface, going through many transfer map scripts is also a pain)
-Where is opacity? Would have been usefull for hairs
-The two specular may have too much control sliders. I'm not sure you need as much Simplify
-All in all the shader has a lot of parameters. I don't know if a lot of people could use that
Your G2F base preset starts with 0% diffuse and 100% SSS. That won't work very well in interior scene
Now there are a few implementations that I found usefull :
- The SSS color replacement
- Hue, saturation, lightness offset
Nice . I also prefer the idisplay LUT corrected look
Here's a quick beefcake shot of Nevio, I need more camera settings, any suggestions? The lights are the DelightGHDRI with KH Park and the SimplePhys Distant.
The wall is from DM's Instances with the Beach Cyclorama behind it.
CHEERS!
Wait, you mean an automated go-through-all-scene-items one? The scripts should work with everything selected in the scene and its selected surfaces. Maybe there are materials where the user doesn't want to copy anything.
Yes it's one of my concerns, but ultimately, simplifying controls will mean taking a lot of customisation away. I know I can't do without all the specular sliders. What would you suggest?
It's one of the reasons there are presets and the docs which are taking so long to finish.
Hmmm, I'm sorry I don't understand, what is the difference? It's still ultimately washed by the same GI light.
Do you find the render time increase to be acceptable when using colour correction?
Nice! You could add more bump/displacement to the wall, though.
Have you managed to finish my PhysicalSun tutorial? I much prefer it for real-world lights than anything else, the colours are so much more lifelike than just guesswork in the light colour field.
Or you could always use HDR IBL and a spec-only light. Take a look at the "Directional Light Sets" folder, there is a premade one for KHPark.
And I use this script for DOF (it's the best one!): http://www.daz3d.com/forums/discussion/43636/
http://www.daz3d.com/tattoo-parlor-genesis-2-male-s-geometry-shells-vol-1
Can they be made to work with RT Kit?
Yup, sure. You just have to make sure the geometry shells use UberSurface with the "Occlusion" parameter off, so that they won't slow down GI with unnecessary computations.
But I would personally add the tattoos to the diffuse maps that go into the SSS slot of the general figure. That gives them a much more convincing "under-the-skin-surface" look. I prefer overlays (shells or shader-based, doesn't matter) for stuff that is really on top of the skin, like paint or dirt.
---UPD: disregard the speculation, the real culprit is identified in the next post---
I have studied the scene finally... I hid the sphere because it's apparently using a custom shader of yours that I don't have. I also upped the Oren-Nayar roughness on the surfaces to make them a tad more realistic (kept the "coder colours", though, for colourbleed consistency) and added a high-roughness specular (0.6 "skin" which is Cook-Torrance), just for kicks to show its rolloff =)
I understand the difference now. First of all, the UE2 uses a white colour for its "skymap". Yup this is important for it. If you take a look at the UE2 presets Omnifreaker supplied, you will find there is a separate one for "Bounce". The light colour is set to black in it, so as to avoid the "skydome" effect.
This "skydome" kicks in wherever the trace distance is exceeded and the ray does not meet geometry. So the surfaces in your brighter scene that were farther from their neighbours than 500 cm were all extra-lit with coming-out-of-nowhere white light.
This is why it is so much brighter.
DelightGI will only use the skymap if it's deliberately plugged in. Then it will tint it with light colour, but otherwise it ignores that colour swatch and believes the scene is sitting in a vast vacuum of black interstellar Renderman space =)
And then, the area light was "non-physical": it wasn't using the quadratic falloff. For the final render, I enabled falloff and set intensity to 20000%.
Render times are for my office computer (Intel Core2Quad Q9300 2.5 GHz); the render script used was RaytraceFastDOF with Catmull-Rom 2x2.
UE2_Black: 1 minutes 43.25 seconds
DelightGI_NoDome: 57.9 seconds
DelightGI_AreaLightFalloff: 58.2 seconds
A lot to comment on...
One possibility to overcome the complexity of the shaders...two versions. A simple version with a number of the common controls set to a sane value then locked and hidden. And then the 'unlocked' version. (Or directions on how to unlock them, in the manual.) The 'make art button' types will never go for anything that requires 'setup' so a bunch of presets with either a full unlocked or a simple version would satisfy them. (Or the presets can be locked/hidden...but that would have to be done manually for each one...)
The RadiumFabric is one of the most fun shaders I've seen in a long time.
Yes, UberArea are odd ducks (actually the whole Uber line, while very useful, has some 'oddness' to it). And with the new headlamp controls are even odder. Yes, they load that headlamp blocker, still, and it can be a source of frustration if the light in the scene includes a specular area light and another light that isn't recognized as a light. There are some shader lights that the script does not recognize as being lights (I think any ambient ones fall under that category...distant, spot and point are recognized). But the blocker doesn't always seem to work right, that is it doesn't seem to always block the headlamp...deleting it and turning off the headlamp, under camera controls gives different results (better/more control). I say this because the headlamp seems to a) not do 'bleeding' (its a very simple light...probably just an illuminate, no indirectdiffuse component, no shadows, etc) and b) wash out/mask subtle effects...bleeding being one (no intensity control, for one). I really like the new, actual On/Off button for it...although I wish it would be moved/added to the options on the 'create camera' dialog (should probably put in an official feature request for that).
Hmmm...as a side and thinking about it, maybe some of the oddness with the Uber line comes from Rman vs 3DL differences...in the normalize and directional stuff (-1 instead of 1 in some cases will still work but cause not quite expected results...). Also there are some 'odd' things with ShaderBuilder...and it's probably more due to 'locked' settings/config than anything else. I've played around a little with RSL editor...very limited editing, but it's compile script seems to be a direct call to shaderdl. As a result it will actually compile things that SB won't...but it doesn't generate the needed DS scripts to make them useful. ShaderBuilder, on the other hand doesn't just compile the code it's given, it adds/rewrites/rearranges the source code, too. And I'm not sure that it uses any optimization when it does compile the code (-O2 is the 3DL default, but I'm not sure it uses the default)...I've used shaderdl to recompile the SB generated SDLs with -O3 switch and end up with much faster shaders (and much different file sizes).
Opacity maps do 'strange things' with RT SSS...to say the least. Maybe true alpha masks would work better...but not something I want to play with, as it isn't the DS way and would take too much trouble to make useful (for more than experimental work). Besides, it would probably be even more difficult to get everyone else to understand than linear workflow...
Thank you =)
Oh BTW, have you put in the feature request for that? I remember we were talking about it, but not sure if anything happened.
I don't think that this is adding that much
I uploaded the scene on my dropbox if anybody wants to try. I'm not sure it will work as i've seen references to the data directory in it, but it seems it's only for the UE sphere. https://www.dropbox.com/s/mo45qomu5d6lmto/DScornell.zip?dl=0
I have studied the scene finally... I hid the sphere because it's apparently using a custom shader of yours that I don't have. I also upped the Oren-Nayar roughness on the surfaces to make them a tad more realistic (kept the "coder colours", though, for colourbleed consistency) and added a high-roughness specular (0.6 "skin" which is Cook-Torrance), just for kicks to show its rolloff =)
I understand the difference now. First of all, the UE2 uses a white colour for its "skymap". Yup this is important for it. If you take a look at the UE2 presets Omnifreaker supplied, you will find there is a separate one for "Bounce". The light colour is set to black in it, so as to avoid the "skydome" effect.
This "skydome" kicks in wherever the trace distance is exceeded and the ray does not meet geometry. So the surfaces in your brighter scene that were farther from their neighbours than 500 cm were all extra-lit with coming-out-of-nowhere white light.
This is why it is so much brighter.
DelightGI will only use the skymap if it's deliberately plugged in. Then it will tint it with light colour, but otherwise it ignores that colour swatch and believes the scene is sitting in a vast vacuum of black interstellar Renderman space =)
And then, the area light was "non-physical": it wasn't using the quadratic falloff. For the final render, I enabled falloff and set intensity to 20000%.
Render times are for my office computer (Intel Core2Quad Q9300 2.5 GHz); the render script used was RaytraceFastDOF with Catmull-Rom 2x2.
UE2_Black: 1 minutes 43.25 seconds
DelightGI_NoDome: 57.9 seconds
DelightGI_AreaLightFalloff: 58.2 seconds
The sphere has your glass absorption shader. Don't know what is happening
I don't think you really understand the goal of a cornell box and why it is a standard test.
It's not about brightness it's about color bleeding and bounce light. Omnifreaker's light does work as expected in this area
Look at the ceiling. It gets illuminated by bounced light inside the box and that is the goal. If you get it to work, you know your GI is good
The cornell Box is a valid test for Global illumination. Do a google for any renderer and you'll get approximatively the same results.
It's not the IBL map which is there or not
I did the same test with UE just in bounce light mode and put DS new default IBL map
Tested your light with that map too and reduced your trace distance to 500 like UE
Then I activated the quadratic falloff to show it's not that either
Rendered again with your DELIGHTGI, then with UE in bounceGI mode
Quadratic or not the conclusion is the same. No light bounced off the walls
Last note : I also have a GI light with trace () and I do have bounce light like with UE. Deprecated shadeop don't mean that they are badly done or that you should throw them away. For what I've seen, UE is in the same line as what you can find in Pixar's site in their old documentation for PrMan
And about Uberarealight not casting specular with UE, that is a wrong conclusion. It's still casting specular. The problem is only with ubersurface
Last render (crappy) left sphere with AOA SSS; Ubersurface with the middle and DS default on the right
An on/off switch is nice. I second Takeo's request. It also can act as a separator between parts (diffuse, specular1, specular2, etc). Don't know if its possible to have the old DS3 behavior (hide when not active).
Locking values isn't needed. Hiding would do just fine.
The traditional ordering for shaders seems to be diffuse, specular, ambient, opacity, bump/displacement, reflrection/refraction, velvet, SSS.
As noted before, you could simplify the texture slots. Since you meant for diffuse and SSS to share the same texture, just reuse the same texture slot for those. The same can also be applied to specular control maps. This also makes the shader retain those maps when applied.
---
Another boring test render. :)
Nice! You could add more bump/displacement to the wall, though.
Have you managed to finish my PhysicalSun tutorial? I much prefer it for real-world lights than anything else, the colours are so much more lifelike than just guesswork in the light colour field.
Or you could always use HDR IBL and a spec-only light. Take a look at the "Directional Light Sets" folder, there is a premade one for KHPark.
And I use this script for DOF (it's the best one!): http://www.daz3d.com/forums/discussion/43636/
That dropbox link in that thread just takes you to a page full of text, how do you download it as a .dsa!? Could you maybe PM that file to me?
I just haven't been able to get round to that PhysicalSun tutorial, I do plan to though.
CHEERS!
I'd had this idea for a render ever since I got the freebie bundle that contains West Park. I was going to use Rob for it till I got Darius and RTKit. I wanted to keep the lighting as natural as I could and I think I got there with a mix of Simple Phys Distant, Delight GHDRI and Diffuse and Spec with Moonglow. Hopefully you'll be able to see it on all of your monitors.
Enjoy!
CHEERS!
Not quite...they have to have the same internal names...the variable names, not the same labels for the maps to be retained/automatically applied when switching. Which may or may not be an easy thing to do. I know AoA and the default share many of the same names, but I think some of the oF internal names are different (can't remember, which they are, but I'm constantly reapplying something when switching to US...and no, it's more than just turning on a couple of things that end up 'off').
And yes, standardizing the names does have another benefit than just making it so maps won't need to be reapplied. It makes it easier for non-tinkers to understand what's going on, if it is very similar to what they are familiar with.
I wonder if placing an if test in the SSS map would work, then hiding it. That way, if you want to use a different map in there, unhiding and putting one in would allow for that.
If SSS map = uniquemap use it
else use the diffuse map.
Which, at least to me, gives the most possible flexibility.
Again: if you actually paid attention to the renders in my previous post, you'd have seen I am not getting any light on the ceiling with UE2 in bounce mode and the light colour set to black.
Correct me if I'm wrong, but even a solid colour in UE2 light colour swatch will kick in as environment color when the max trace is reached.
Is that not so?
You can see that DelightGI handles the bounce onto the primitives inside the box well.
The only issue is the ceiling. Which is strange. It's as if the normals are reversed, but wouldn't UE2 complain then in any case as well?
If you truly want to help me, then could you please compare the source code for your trace()-based light with that of DelightGI and tell me what I might be doing wrong? It shouldn't take much time, the shader is tiny.
Alright. I wonder if there is a way to control the size of those pesky buttons from within shader builder...
That's for the "intro" variety, the one-map-ro-rule-them-all thing; the real deal should still have the separate maps. Right?
And yeah, retaining, as Mjc says, is only because of matching channel names (not labels, internal names). I guess an "upgrade" script of the kind that comes with US2 should be possible, but what should it really retain and what move where? And what's the point? Right now we retain diffuse as SSS, bump and displacement. For the updated and renamed one I am building now, I am thinking of killing the link between "specular strength" and "shine" strength slider values because it doesn't make sense. I don't recall if it inherits the map. Is it useful, inherting a spec map?
I think a copy-maps-between-speculars (shine to skin and the other way around) script might be useful. Full, strength only, roughness only.
Also copy roughness to reflection roughness.
What do you say?
You mean, putting the test in the shader code or in the DS param definition one? The idea is nice, but not that straightforward in either case.
As for non-tinkers, you sure it's okay with them to have a thousand shaders that all say "specular", but all these 'speculars' have wildly different parameters?
Doesn't it help if you just hit Ctrl-S and specify the DSA extension in the save dialogue?
The render is good as far as I can make out =) But the guy's coat becomes one with the shadows, is that intentional?
Doesn't it help if you just hit Ctrl-S and specify the DSA extension in the save dialogue?
The render is good as far as I can make out =) But the guy's coat becomes one with the shadows, is that intentional?
At least for me, it opens a text page...no file to download. It may be a Firefox thing or something. But it's being recognized as a text-mime type and not a file, so that's why it's opening as a page. Just copying text from the page into a new text file or the script editor in DS and saving it as a DAZ script works quite nicely.
You mean, putting the test in the shader code or in the DS param definition one? The idea is nice, but not that straightforward in either case.
As for non-tinkers, you sure it's okay with them to have a thousand shaders that all say "specular", but all these 'speculars' have wildly different parameters?
I haven't tried in the DS param code...but it wasn't that hard to do in the one I tried, in the shader code...but then it was a lot simpler shader.
And, unfortunately, there isn't an easy answer when expanding on already familiar parameters. I was thinking more along the lines of what they are already familiar with...the new/expanded ones..they'll just have to learn what they do. (Yeah, right...forget I said that...)
I was thinking having the same texture referenced by both the Diffuse and SSS Diffuse. One example I can think of is like doing it in shader mixer where the same image block gets referenced by both Diffuse and SSS. The same thing for specular maps - referenced by both specular.
So in the end, you only have texture slots for diffuse, specular maps, bump, displacement.
Doesn't it help if you just hit Ctrl-S and specify the DSA extension in the save dialogue?
The render is good as far as I can make out =) But the guy's coat becomes one with the shadows, is that intentional?
I got help with the script in the script thread. You can paste it into Notepad++ and save with All Files and use the .dsa extension.
Some of that render was intentional but most of it was load and hope, LOL! I'm happy with how it came out.
CHEERS!
Yes, but I meant this map sharing should be in the "intro"/simple version. And the 'full' version should have more helper scripts. Would that be okay?
There seems to be something funky going on with your box scene, Takeo...
Is it one you built or a downloaded one? If built, how?
The main 'box' has normals pointing 'out'.
This first image is showing it rendering as it loads directly from the scene file. The second is showing as it renders after flipping the normals with Geometry Editor. I'm rendering without caustics, because I'm having a crashing problem when trying to render any refractive caustics (don't ask, it's driving me nuts, because I can't figure out any possible causes...reflective caustics work with no problems). There are no other changes between the two.
Remember that problem I had with Rob? I tried baking the spec maps to the M4 UV but it made no difference. There has to something up with the way the backlight reacts to M4 textures. I turned it off and he looks fine.
CHEERS!
Sounds right.But the other stuff (on/off button, features reordering) can be done for the advanced version too. Makes sense to have the same layout and arrangements. The difference should just be the advanced one exposes features generally hidden in the base version.
Yes, the buttons will be there and the reorder too (but you may have noticed that DS will often shuffle order of certain channels around for no apparent reasons when you load a scene, and this is something I have no control over... it does it to any shader in my case, Uber, default, whatever).
There will be a small unavoidable difference in the shader code because the "intro" one should be taking fewer maps.
And what would happen if you put the backlight back, but killed the Edge strength on all the skin surfaces?
Don't know, but, I don't really plan on returning to that render now anyway. As I said before, the backlighting was to bring out the backscatter in Bjorn's ears and I just changed the figures and background colour and not the lights for subsequent renders.
CHEERS!