Adding to Cart…

Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.You currently have no notifications.
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Thanks for checking!
So the glass shader loaded fine for you? Weird, because it didn't recognise itself on this office machine of mine.
I also noticed Takeo set "FixNormals" to "on" on every surface.
A word of caution to everyone (this will be in the docs): this is not a "magical fix for all bad geometry". It's a last resort fix, only meant to be used for one-sided polys you can't avoid seeing from the wrong side or for surfaces that can't be fixed in your modeling app or when it is unfeasible to invert normals manually in Geometry Editor: generally, for dynamic cloth that will often partially intersect itself when draped, or for clothing with heavy smoothing modifier when normals can get twisted on some details.
Normally, you don't need this. It's only there for a few specific cases, and even then, it's not likely to give 120% perfect results because, well, bad geometry is bad geometry.
PS We are used to all the shaders doing a general and generous faceforward() flip in DAZ Studio, but it's not good practice actually. Moritz Moeller warned against using it a long time ago already.
And the difference between UE2 "Indirect Light" and "Bounce Light" modes:
I got them mixed a bit in my mind in my latest posts (stupid headache!).
The Bounce Light mode will need its colour set to white to actually work.
The indirect Light mode will need to have its colour set to black to act as a pure GI light without extra light being poured from outside the max trace distance.
Any colour in the IDL mode is the "environment" colour, even if there is no map. It's like using a solid colour map.
I think this is important to remember.
I personally find backlighting to be artistically very important. Even in outdoor scenes, a subtle backlight can really help.
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.
As you mentionned a faceforward. would have worked.Don't know what Moritz Moeller said and in which context but you don't always have a good geometry and not everybody has the know how to correct them (I'm thinking about old DS or Poser stuff). Your choice
Now going on with reorganisation.
About the diffuse map. Why not a switch ON/OFF "Use diffuse as diffuse SSS map" instead?
And also put the two SSS effect one after the other?
I suppose that's fine if you want it to be artistic, but we don't have people walking behind us with backlights in real life.
CHEERS!
I decided to try one of Mec4D's textures with RSV and Byson came to hand. What I found interesting about morphing this one was that, in his default state, Darius is 100% him and 100% M6, you'd think Darius would just be him and not a variant of M6.
CHEERS!
That may be easier said than done...although with ShaderBuilder it is easier to do. DS does have a habit of rearranging things like that...
Although I've found with SB, you can pretty much end up with predictable results if you pay attention to groups AND rearrange the parameters manually in them. Makes for some nasty looking spaghetti on the connections, but they tend to stay put (hopefully).
That may be easier said than done...although with ShaderBuilder it is easier to do. DS does have a habit of rearranging things like that...
Although I've found with SB, you can pretty much end up with predictable results if you pay attention to groups AND rearrange the parameters manually in them. Makes for some nasty looking spaghetti on the connections, but they tend to stay put (hopefully).
A text editor works pretty well for that. No headache
I experienced something very weird tonight...
I've been trying to do a render that just was not co-operating. After suffering through some extremely long render times (2+ hrs), I looked at the geometry...it had some odd normals and other weirdness. After I fixed the geometry and reapplied the shaders, I got this from the standalone in about 5 minutes...and the same thing in the Studio included took about 15 minutes. I've never had geometry so affect the render time (one render, earlier and smaller sized, was only at 50% in that 2 hrs...so it was cancelled).
One of the other problems with the model is crappy UV mapping...so no decent tires. It would probably be easier to remodel them instead of trying to get decent UV maps out of what's there.
Is that a Daz Mustang? If it is then they are ages old and you really can't expect much from them by today's standards. DS1 was probably what it was built for.
CHEERS!
A text editor works pretty well for that. No headache
I do rearrange manually, Mjc, it is not a 100% save against shuffling either.
Takeo, I'd prefer to keep installation via shader builder files only, no custom param def scripts. Even then, again, DS can shuffle channels.
Now, why backscatter so deep down: because it's a cheat, really. A more-physically-based-than-most one, but a very specialised trick nonetheless. Only for those artists who really need it in very specific scenes. It has a long list of non-intuitive params.
You clamour for pulling diffuse up, and then you want this to get in the way? One of the two least generally useful features?
As for the switch: I'll need to think about and weigh the usability concerns with my less-tech-oriented focus group.
Unless it's a professional photoshoot, where you will have folks setting up reflection cards and even some extra artificial lights around the model, even outside. It's one of the reasons the city street 'magazine photos' look different from your generic 'fashion blogger' backyard selfies.
I guess the way the renderer code is optimised today can get thrown off by bad ( = 'anti-physical') normals.
It seems logical to me to pack related parameters together. It's my opinion. At the end it's you to choose. You know I can do all these (mostly done already in fact).
I guess the way the renderer code is optimised today can get thrown off by bad ( = 'anti-physical') normals.
It was coming out translucent in parts, black in others and all sorts of weirdness. Also, every surface shader behaved differently, but none of them were completely 'correct'...the results were always 'off' somehow. And this was a case where the GeoEditor didn't help. It just flips their current direction. I had to use Blender and repeated 'recalculate' runs to get them all in same direction, and even after that I had one door that was backwards from everything else. I'm thinking that it was constructed as half a model and the other half was 'mirrored'...and in the original application, that was fine, but the conversion to obj didn't 'make real' the mirrored parts correctly. I still haven't figured out why the tremendous time difference...
No, Roger, that's from Turbosquid...which even makes it more surprising that it was such messed up normals. But I think it was automatically converted from max file, through 'squid's converter, instead of saved out from Max as an obj. Overall, it's got nice clean geometry and is rather high poly.
If I was thinking I probably should have exported without writing the normals and then tried it.
Also, I discovered a very nice trick. If you are doing glass...like window glass and it is giving odd results, especially with a 'real' glass shader...like the Kettu's, make sure the glass has actual thickness. It's especially true for PBRs and plausible shaders, but is applicable to just about any shader/renderer that isn't using transparency to mimic glass.
No cheating, on the contrary - mimicking the planet Earth. Unless there is a sphere around your box, it's opening into the void. Light energy is lost in the void, it does not return. The distant delta only comes from one infinite plane, the remaining directions of the shading hemisphere aren't covered.
If you don't like the idea of a map, put a sphere around the scene, just make sure to include it into trace distance. Although the map should be faster.
From the surface shader POV, the light trace() gives to it is all the same, map or bounce. Remember, no distinction between light paths.
Hear, hear!
PS Here's a diffuse-only version with a better Oren-Nayar roughness: 0.58, taken from here:
http://www.yafaray.org/documentation/userguide/material
Under the heading "diffuse reflection" there is an archive of the measured Oren-Nayar roughness values for various real-world stuff.
As you can see, by increasing roughness the Oren-Nayar diffuse becomes more "even" - subtly darker in the better lit areas, but with more retroreflection along the edges.
When very rough, an Oren-Nayar sphere will look like the Moon.
All well and good if that's the type of thing you're into. I'm more interested in it looking good to my eyes and not looking good through a camera.
I tried out a V4 map and that glowing nostril effect still persists, even when you turn off that edge setting completely. Something else is awry and I'm not sure what. The texture is Farissa by Virtual World, it's one I really like as it comes with textures for different brow colours which makes it a bit more versatile. Once we have all the lighting and shaders worked out I can move onto what I know I'm good at which is creating characters. I got bogged down in testing lights and shaders and haven't done any for ages.
CHEERS!
I never encountered anything that bad in Poser/DS content. Random flipped normals in a few spots, in freebies mostly, that's that. Wasn't Poser very sensitive to wrong normals very early on?
Yeah, I think it was.
This was a Turbosquid model that was originally a Max or LWO one that was run through TS's autoconverter, by the guy that uploaded it. My guess is it was just a bad conversion. It really did look like it was 'half' there...like one fender was perfect, but the one on the other side was translucent, black or some of both. To get GeoEditor to work I probably would have had to do a poly by poly flip...and at almost 400K I was NOT about to do that. But it's all fixed now and in DS native...
I like it because it has a pretty nice interior...no engine, though, so if I wanted I could make it so the doors open. I have a lot of other cars to convert/set up...I just hope there aren't many more that are that troublesome (I know that most of the Sketchup ones will be troublesome).
All well and good if that's the type of thing you're into. I'm more interested in it looking good to my eyes and not looking good through a camera.
I tried out a V4 map and that glowing nostril effect still persists, even when you turn off that edge setting completely. Something else is awry and I'm not sure what. The texture is Farissa by Virtual World, it's one I really like as it comes with textures for different brow colours which makes it a bit more versatile. Once we have all the lighting and shaders worked out I can move onto what I know I'm good at which is creating characters. I got bogged down in testing lights and shaders and haven't done any for ages.
CHEERS!
Glowing nostrils on Gen4 has always been a problem. And I'm not sure it was all down to the mesh...
It did it on V6 as well, there's something up with Kettu's shader, she might have said where but I can't remember.
CHEERS!
I'm going to paste those Oren-Nayar values here...there's more of you want to dig through the data from the O-N database...
I spot the problem
In fact that is not the 100% SSS which causes the problem. It seems you have something wrong in the ambient
Put a delta light and something that will make some shadows between Genesis and the light
Rendered three pics
First with a sphere that is making shadows on G2F. No GI. The part in shadow gets some specular somehow (top of the head for ex)
Second render. Put a delta spot on the left of G2F. Nothing between genesis and the light.What is in shadow from the spot is completely black (not rendered but trust me). I then added a DELIGHTGI with no map. I get some IDL from the wall. That works. I played with shadow softness and shader hitmode and shadow sample. I kept the softness low because I want very sharp shadows. If you make them soft you may not see the problem
Third render. I saw that G2F Top and short get colored in shadow and no specular. And I thought that must be the ambient channel. So I put 0% ambient on the top and bingo. It gets black.
I didn't have a look at your code. There is no control of the ambient channel on your shader so there is no way to control that but there is something
* Edit : added a screencap of the scene
** Second edit :
Imagine, it's the night or you are in a cave with just a lamp torch. What is the environment color? Black. If you put a black map into your GI light it's the same effect as not putting any map. Try it
*** Last edit : added an Iray render for reference. You see that you get some IDL from the wall and the floor that tint a bit G2F in the part in shadows.
Other problem : the default glass transmission hitmode parameter and shadow color being inverted or something like that
Create a scene with a plane as ground. Create a cube that will get the glass absorption shader and resize it to be thin enough to simulate a window glass. Add a PhysSpotlight and a camera to see what happens with shadows
First pic : transmission hitmode = primitive and shadow color = black
Second pic : transmission hitmode = shader and shadow color = white
* Added a screencap of the scene
Interesting, so where on Kettu's shader would we input those?
CHEERS!
What are those values taken with? Is that with energy conservation? Clamped or normalized? Both generally looks very different with the same roughness.
Thought I'd try RTK out with an HD subject, in this case Boris by Smay. Normally HD slows down renders, which is why I tend not to use it much, however, with RTK there is no noticeable difference in render time and the detail is all there. Once we really get going with this shader kit, I might invest in a few more HD things if it doesn't slow up renders like it used to.
CHEERS!
I got to thinking 'What would I get if I crossed Boris with Darius!?'. The answer is this guy!
CHEERS!
It's not specific to the shader.
DS have improved HD morphs support for quite some time now. Although it's slightly slower when rendering (depending on what subD level the morphs were built in), there's no more long load times with HD morphs.