3Delight Laboratory Thread: tips, questions, experiments

Rogerbee

mjc1016 said:

Here's a better one...more appropriate background and a shadow catcher. Render time jumped to a whopping 1 min 23 seconds...

Pretty cool! Though the windows don't look very glass-like. Is that the Foberghini? I think I've got that somewhere.

CHEERS!

wowie

Rogerbee said:

They look great, what were they all done in US2 or yours? I'm guessing your shader will have this Oren Nayar diffuse then?

Those are still US2. That was the point. Even with it's quirks, it's flexible enough to be used for just about anything.

mjc1016 said:

Well, hopefully I've got the temperature spikes under control...now I'm out of thermal paste...used the last of it tonight.

I find it actually beneficial to clean both surfaces first, dry them out in the sun (or a filtered hair dryer - lycra works pretty well as the filter) and then patiently sand them with very fine sand paper until you get a very nice mirror finish. Best to do that on both surfaces, but if you want to honor your CPU warranty, just do it on the base of the heatsink.

But when I said the physical sun was fast, I was just doing tiny renders...here's one at 800x800 scripted. All reflections are environmental. PhysicalSun is the only light.

1 min 6 seconds.

Does that include a physical sky as well?

Cars. We've got cars. :) Shadows are all wrong because the shadow catcher is quirky. I think each took about 5 minutes. mainly because I set ray trace depth to 8.

Rogerbee

Looking good, but, you need a Daz environment as they still suffer from the uncanny valley.

CHEERS!

wowie

Rogerbee said:

Looking good, but, you need a Daz environment as they still suffer from the uncanny valley.

As I have said before, it's the shadow catcher shader (PWCatch) that isn't catching shadows and occlusion correctly.

Your brain expects visual cues such as much darker shadows in the area under the car, progressing darker as it gets further into the shadows, but couldn't find it. To you, they look 'unreal' because they seem to be out of place with the background.

Here's a render with just a plane, where I matched the colors of the plane and the background. Notice how in this render, the shadows are much, much darker. Compare that to the one taken with PWCatch applied to it. The shadows are way too 'bright' on those areas. Even when I toggle the strength of the ambient light to get some of the darkness back, it doesn't match the first render.

Material wise, most of the problems comes from US2 just having a diffuse Clay model, rather than the more proper Oren Nayar. The specular are also just the glossy brick modified to have fresnel. But right now, it's the only shader worth using.

Mustakettu85

wowie said:

As I have said before, it's the shadow catcher shader (PWCatch) that isn't catching shadows and occlusion correctly.

You could try making one in shader mixer, then you could adjust the strength, I believe (for example, by multiplying the result over itself)

http://www.youtube.com/watch?v=qo2OVy9tf8E

Other than that, amazing renders!

Mustakettu85

Rogerbee said:

I know which lines to take out and add in the lightphysicalsun( bit, but, what do you mean by 'edit the body' what command do I want here!?

The body of the shader. My bad, I shouldn't have used the lingo. It's just a name for part of the code. Basically, in p.2 we are editing the header of the shader, and starting with p.3 we are editing the body. Just follow the steps in turn, and everything should be okay.

Rogerbee said:

Can it be adapted to become a moon?

Good question. Artistically speaking, it probably can - if you turn the saturation down and the red-blue shift to give more blue.

But physically... Probably yes, too, but we would need to change stuff in the colour function according to some moon-specific measured data. I'm no meteorologist, so I don't know the proper name for that =)

Here's a paper on simulating the night sky the physically based way - it is not of much help here, but still interesting:
http://graphics.stanford.edu/~henrik/papers/nightsky/nightsky.pdf

Rogerbee said:

As for AO do we still need it!?

As Mjc said, not when rendering with full GI done the proper way.

------------

mjc1016 said:

My son did find some thermal paste, so I'll be doing that tonight instead of testing this out...then I've got another shader to play with...thanks Kettu.

Physical Sun is a great little addition to the lighting toolbox...thanks Kettu. That one had been plaguing me for a while, I couldn't figure out where I was going wrong...it's the damn convoluted coordinates that DS is using that was throwing me. That little insight may help with some other light shaders I've been looking at, too.

You're welcome, and hoorray to your son! Enjoy! And yes, the fact that "up" in DS is the Y axis, it's just so annoying but we will have to live with that.

While I'm writing the docs, have my coordinate system from the render scripts for stuff where you just can't change the vector:

// Kettu: so you find the RiWorldBegin part of the script...


// Begin describing the scene
Renderer.riWorldBegin();

// Kettu: ...and now here we stick some new code because...
// Kettu: We need a new coordinate system!


Renderer.riTransformBegin();
Renderer.riRotate (-90, 1, 0, 0);
Renderer.riRotate (90, 0, 0, 1);
Renderer.riCoordinateSystem("kettuworld");
Renderer.riTransformEnd();  
Renderer.riIdentity();

As you can see, it ends with RiIdentity so everything after that stays the same. But it creates "kettuworld", a new coordsys you can pass to shadeops like trace() instead of "world", when rendering with this script. Then the directions will match to what a DS sphere primitive would give.

------------

Does that include a physical sky as well?

Nope. The ready-made PhysicalSky.sl is an imager shader, so it's very limited; moreover, Shader Builder does not allow making meaningful user parameters for imagers so you can't even pass the sun angle to it from the DS interface.

So right now, we have to use HDRI skies.

Maybe I will handle a proper physical sky envlight one day... but it won't be soon.

------------

so what it 'N', 'I', 'P', 'L', 'Ci', and 'Cl'

P: the shading point (the surface point being shaded right now)

N: surface normal the way it comes (may well be non-unit-length, so yes we need to normalise it, otherwise the dot product gives us weird results)

I: non-normalised "incident" vector, aka the viewing direction (from the "eye" point to the shading point)

L: non-normalised light vector (from the surface to the light in surface shaders, from the light to the surface in light shaders)

Ci: final surface colour

Cl: light colour

Take a look at page 120 to see the RiWorld from the surface's point of view:
http://renderman.pixar.com/products/rispec/rispec_pdf/RISpec3_2.pdf

Rogerbee

Mustakettu85 said:

Rogerbee said:

I know which lines to take out and add in the lightphysicalsun( bit, but, what do you mean by 'edit the body' what command do I want here!?

The body of the shader. My bad, I shouldn't have used the lingo. It's just a name for part of the code. Basically, in p.2 we are editing the header of the shader, and starting with p.3 we are editing the body. Just follow the steps in turn, and everything should be okay.

Still don't get it, you take out those lines, then what? Are there other references to that line which can be taken out with Find? I don't want to get lost, but I am.

CHEERS!

evilded777

Ok, lets talk about US2 for a minute, particularly how its used in the Photo Studio Kits.

I understand how it works, but I gotta say I don't understand WHY it works. Specifically the colors in the subsurface scattering. I understand the other color choices .and they are very similar to what I normally do for diffuse, etc. But the SSS colors... well, I really don't get the blue.

I've seen blue used in Lux, and never really cared for the result that way.

Nowhere else have I see blue. Is it okay to call it blue? I'm not near my render computer and can't look at the colors right now.

I really want to understand why it works so I can adapt it with other textures better than I am able to at the moment

I could also really use a better understanding of the specular layers and the how Fresnel works. I have never even remotely understood how Omni's Fresnel was supposed to work. Let me re-phrase that. I understand the Fresnel Effect, I don't understand US2's Fresnel controls.

And as a side note, Iray used Oren-Nayar for diffuse in the base layer. That's a good thing I take it? And skin really ought to have a little roughness to it, not leave it at 0? I don't want to side track this discussion with Iray, but since there's a confluence here, I thought it would be safe to bring it up.

wowie

Mustakettu85 said:

You could try making one in shader mixer, then you could adjust the strength, I believe (for example, by multiplying the result over itself)
http://www.youtube.com/watch?v=qo2OVy9tf8E

Yeah. I know but I'm lazy. :)

I'm cobbling up a shader in Shader Mixer with as much parameter simplification as possible. For instance, there's only one roughness dial that works for both diffuse and specular/blurry reflections. So as you raise the glossiness, the diffuse becomes more Lambert, the specular highlights smaller (and sharper) and reflections becomes clearer. Roughness also controls fresnel strength, but the shape is controlled by IOR and maybe specular sharpness (sharper specular equates sharper fresnel).

Other than that, amazing renders!

Don't have NUKE like the Image Engine guys, but I'm pushing as far as I can to not having do things in post work or post process..

Those are just test renders to make sure everything is good and how much further it can be tweaked. I imagine a readme wouldn't cover this one. Have to be a proper manual.

Ah, too bad about the physical sky. Well, if you ever tinker with EnvLight again, I always wondered if it is possible to cobble up a solution like the UberSoft Light kit. It has some controls for sky/horizon, plus there's also light nodes you can place around the scene. I'm thinking since you know have a point and vector with those nodes, is it even possible to use those nodes as base to compute specular light?

One other note: in that scene, I found the occlusion behaves more in line to expectations with max trace distance set at 150 cm. I could lower the intensity to get very dark shadows with trace distance 20 cm, but then most of the objects with diffuse get less light.

wowie

evilded777 said:

Specifically the colors in the subsurface scattering. I understand the other color choices .and they are very similar to what I normally do for diffuse, etc. But the SSS colors... well, I really don't get the blue.

I'm assuming you mean scatter color? I believe there are two main colors to use with US2 SSS - scatter color and absorption color. The easiest way I can explain it is that scatter color is the inverse of what you're trying to get. So if you want more red, you use very low value for red (vice versa for the others).

It probably would've been better if Omni invert the colors controls. But at least it wasn't a mess of six dials to fiddle with.

evilded777 said:

I could also really use a better understanding of the specular layers and the how Fresnel works. I have never even remotely understood how Omni's Fresnel was supposed to work. Let me re-phrase that. I understand the Fresnel Effect, I don't understand US2's Fresnel controls.

Well, it's not IOR based. As expected, when you raise fresnel strength, highlights will be dimmer when viewed directly (and stronger at grazing angles). The falloff controls the rate, so it's pretty much like your IOR dial, while the sharpness multiplies that effect. Think of it as a cutoff control.

What I figured out and now used extensively is that to have really strong highlights at grazing angles, you need to dial down glossiness to very low levels (think between 2 to 5%) and then use fresnel controls (falloff, sharpness) to set the shape of the specular highlights.

The 1st fresnel also does things to refraction when you enable refraction, fresnel and specular. Makes figuring out glass quite tricky since you need to eyeball the results to match the IOR used .

This probably stems from the limitation of the Glossy brick code used, but if I'm not mistaken, it is quite possibly the most advanced specular brick at the time Omni started writing shaders for DS.

Now we have more bsdf to choose from (Blinn, Ward, Cook-Torrance, Ashikhmin-Shirley). The trouble is that Oren Nayar is included, but hardcoded as a specular bsdf.

And as a side note, Iray used Oren-Nayar for diffuse in the base layer. That's a good thing I take it? And skin really ought to have a little roughness to it, not leave it at 0? I don't want to side track this discussion with Iray, but since there's a confluence here, I thought it would be safe to bring it up.

Oren Nayar is the go to model for diffuse, though I think someone made a better model that's actually better in terms of energy conservation. But it's probably simpler and cheaper to use Oren Nayar (there's actually a simplified alternative model, so there's two Oren Nayar model, not counting modifications).

Skin is best described as a rough material, coated in oil, with a varying levels of thickness. Breaking it down, what you need to simulate it are diffuse with roughness, rough specular with high fresnel strength, smooth specular with low fresnel strength and of course, subsurface scattering.

One other trick is that SSS (and translucency) in US and US2 is tied to diffuse, but more importantly, tied to diffuse roughness. So you can actually use the diffuse roughness to control the 'spread' of SSS across the whole surface. When used with backscatter, you can really push up SSS strength on extremities (nose, ears, fingers) but keep SSS strength low on thicker parts (but still visible).

The one gotcha is that the diffuse is not Oren Nayar. I believe it's the clay diffuse brick. So shadows gets noticeably sharper with very low roughness and can cause artifacts with low poly models. Oren Nayar doesn't have that problem (or maybe it does, but at the same polygon count, it's not noticeable). It's best not to go past 0.75.

With layered diffuse, you can have believable SSS, then add back the diffuse details in the second diffuse layer.

The problem with the SSS brick is that it's an old approach. It's a two step process and you need to correctly pass only the surface calculated - hence the need for SSS Group ID.

JonnyRay

mjc1016 said:

Johnny, I was wondering if you'd show up...feel free to join in the active discourse.

Thanks, MJ. :) I'll keep track and see where I can add any value. ;) As one can see in my tutorial link, I went pretty far down the rabbit hole chasing after a better hair shader. Then, just as I was starting to understand things, I got caught in some math I couldn't follow and I lost my way. :(

The surface stuff here in the thread is very good, though. Also really liking the physical sun. :) Lights and surfaces have always been a keen interest of mine.

I used to say that even in the DAZ default shaders, knowing what the dial is tweaking in the shader will help you understand when you need more or less of something.

On the skin stuff, I go into quite a bit of detail on how SSS works in my Light and SSS, SSS - Why should I care? and Additional points about SSS posts.

evilded777

Thanks, Wowie.

Inverse, huh? Now I understand. Seems kinda silly... Omni himself put red in that color in all his presets! But at least I understand it now.

Fresnel... well, I get the drift. Might take me a while to really figure out how to use it better in practice.

That information of Oren Nayar is quite helpful, perhaps.

mjc1016

evilded777 said:

Ok, lets talk about US2 for a minute, particularly how its used in the Photo Studio Kits.

I understand how it works, but I gotta say I don't understand WHY it works. Specifically the colors in the subsurface scattering. I understand the other color choices .and they are very similar to what I normally do for diffuse, etc. But the SSS colors... well, I really don't get the blue.

I've seen blue used in Lux, and never really cared for the result that way.

Nowhere else have I see blue. Is it okay to call it blue? I'm not near my render computer and can't look at the colors right now.

I really want to understand why it works so I can adapt it with other textures better than I am able to at the moment

I could also really use a better understanding of the specular layers and the how Fresnel works. I have never even remotely understood how Omni's Fresnel was supposed to work. Let me re-phrase that. I understand the Fresnel Effect, I don't understand US2's Fresnel controls.

And as a side note, Iray used Oren-Nayar for diffuse in the base layer. That's a good thing I take it? And skin really ought to have a little roughness to it, not leave it at 0? I don't want to side track this discussion with Iray, but since there's a confluence here, I thought it would be safe to bring it up.

Basically, the shading models should be the same. They are rather well defined and described in numerous scholarly papers, so the math is pretty much standard. The choice of which to use is partially governed by the author of the shader and partially by the age of the shader. The fact that US/US2 uses what it does, shows how old it really is. Back when US/US2 was written, the 'better' ones hadn't made into DS, yet. Some of them were barely in 3DL and DS was a couple of builds behind the 'real' 3DL, then.

The fact that Iray uses O-N as a default just shows that it is much more recent.

As to the OmniF family of shaders and Fresnel controls...is there anyone who really understands them? Wowie, excepted.

mjc1016

There's a DS 4.x shadow catcher ShaderMixer up on ShareCG.

http://www.sharecg.com/v/78521/browse/21/DAZ-Studio/ShadowCatcher-for-DAZ-4.X

That's the one I used, as I didn't feel like rolling my own, last night.

Another one...

http://www.sharecg.com/v/56594/browse/7/Material-and-Shader/Shadow-Catcher-with-adjustable-opacity

A couple of oddities I noted...

1. With the PhysicalSun, I had to turn Shadow Softness all the way off (0%) or there was a 'halo' around the shadow.

2. Turning up the Shadow Opacity (moving toward 100%) in the shadowcatcher makes the shadow weaker.

This image is for the first one I linked...Catweazle's.

wowie

mjc1016 said:

There's a DS 4.x shadow catcher ShaderMixer up on ShareCG.
http://www.sharecg.com/v/78521/browse/21/DAZ-Studio/ShadowCatcher-for-DAZ-4.X
http://www.sharecg.com/v/56594/browse/7/Material-and-Shader/Shadow-Catcher-with-adjustable-opacity\

Thanks. I'll check them out.

Yeah. US2 is 'old' but it almost matches the Ashikmin-Shirley bsdf brick perfectly.
Ashikmin-Shirley Without Fresnel
Ashikmin-Shirley Roughness 2 = Glossiness 10% Fresnel 88%, Falloff 4, Sharpness 0
Ashikmin-Shirley Roughness 0.1 = Glossiness 75%, Sharpness 50%, Fresnel 0%, Falloff 4, Sharpness 0

Ashikmin-Shirley With Fresnel
Ashikmin-Shirley Roughness 2 IOR 5 = Glossiness 1.2% Fresnel 94%, Falloff 4.5, Sharpness 1
Ashikmin-Shirley Roughness 2 IOR 1.3 = Glossiness 1.2% Fresnel 100%, Falloff 4.5, Sharpness 50
Ashikmin-Shirley Roughness 0.1 IOR 1.3 = Glossiness 100%, Sharpness 50%, Fresnel 0%, Falloff 4, Sharpness 0

US2 fails on the last test - the highlight is slightly bigger but about as sharp. Color and strength are the same for both shaders.

mjc1016

The second one is interesting in that you can get colored shadows from it...

The controls are practically non-existent...there's a Diffuse color and a Value color. Plug a grey into Value and get a variation of shadow strength. Plug a color in...get a shadow in the complement of the color you plugged in. Higher (closer to 255,255,255) grey equals darker shadows.

With a value for shadow softness with PhysicalSun it has a gradient, instead of a halo.

Richard Haseltine

The uberSurfaces don't literally use any bricks - they are real, compiled shaders not Shader Mixer networks. [strike]However, I think omniFreaker did get a credit for at least some of the Shader Mixer brick code so resemblances would not be surprising.[/strike]

wowie

Richard Haseltine said:

The uberSurfaces don't literally use any bricks - they are real, compiled shaders not Shader Mixer networks. However, I think omniFreaker did get a credit for at least some of the Shader Mixer brick code so resemblances would not be surprising.

Thanks for the clarification. Guess I was wrong then.

With 4.8 getting an update to Shader Mixer, will there also be updates to the bricks as well?

Richard Haseltine

wowie said:

Richard Haseltine said:

The uberSurfaces don't literally use any bricks - they are real, compiled shaders not Shader Mixer networks. However, I think omniFreaker did get a credit for at least some of the Shader Mixer brick code so resemblances would not be surprising.

Thanks for the clarification. Guess I was wrong then.

With 4.8 getting an update to Shader Mixer, will there also be updates to the bricks as well?

I don't know - may be a good time to make any reports or feature requests you've been hovering over.

wowie

Richard Haseltine said:

I don't know - may be a good time to make any reports or feature requests you've been hovering over.

Thanks.

Kettu, didn't you file a report for that? Oren Nayar being a treated as specular brick? Might be worth a shot bumping it up, if you have a link for it.

Rogerbee

Mmm, I don't have anything to add just now, but, the email bots seem to have gone to sleep since I changed my email address. I log in with it so it is on the system. Hope you don't mind, but, I just want to see if they're awake as I don't want to miss anything in this thread.

CHEERS!

EDIT: Oops, I didn't realise I had to change my email on here as well as the store! Should get something now.

atticanne

Just testing the email bot for you, Rogerbee.

Rogerbee

LOL! Got it, thanks!

Normal service resumed!

CHEERS!

Richard Haseltine

I've updated my post above as I was wrong in thinking omnifreaker wrote some of the shader code for Shader Mixer.

Takeo.Kensei

wowie said:

Richard Haseltine said:

I don't know - may be a good time to make any reports or feature requests you've been hovering over.

Thanks.

Kettu, didn't you file a report for that? Oren Nayar being a treated as specular brick? Might be worth a shot bumping it up, if you have a link for it.

Anyone could write one if fact. There is an example of how to integrate a Shader mixer brick in the SDK

ZarconDeeGrissom

wowie, nice rides :coolsmile:

Kettu, Despite not knowing at all, I was kind of also joking around. Thanks for the definitions.

Takeo.Kensei, that would be cool, from a 'wizard' perspective, for single purpose specific things, like a 'Perfect mirror' (not one that has a loss of reflection strength like real ones).

My distractions, working with 'Displacement' maps again, just to have fun, and try to achieve something I've wanted for some time. (Yes, Carbon-fiber-cloth, with real interactive with the scene gloss).
http://www.daz3d.com/forums/viewreply/805872/

one aspect I've noticed with stone, spandex, and CarbonFiber, is that Gaussian like speckle to it. It's here in this partial test-render, yet as the Progressive mode fills everything in, it kind of goes away.

So that's my progress report of sorts, I must get ready to set up a sound system for a GBFSC show.
Much to be doings, not much time. Chat later y'all, and keep rendering.

mjc1016

Kettu can probably guess where I found the code for this...

And wowie, this one defaults to O-N for diffuse.

Ignore the eyes and hair...I haven't done any settings for them.

wowie

Takeo.Kensei said:

Anyone could write one if fact. There is an example of how to integrate a Shader mixer brick in the SDK

Thanks. I know that, I just think it will be better if DAZ actually did it. If they did it, maybe, just maybe all those shaders that uses Shader Mixer can be updated to use that. Or at least the authors/vendors can be 'persuaded' to use them.

Can't believe that most of the shaders written at this day still uses Lambert diffuse and Blinn specular. But life is stranger than fiction. :)

And wowie, this one defaults to O-N for diffuse.

Great. That's one important piece of the puzzle.Can you make it really rough and show the shadow terminator area (transitional area between lit and unlit).

mjc1016

Went and hacked in separate controls for a couple of things, made a new control for IOR, so it is now a variable, instead of hard coded...and generally played around with it a bit more...need to hack in bump/displacement/normalmaps and make Specular Strength able to take a control map.

And over all, it's 2 to 3x quicker than either AoA or US, stuff that takes about an hour to render with AoA/US, renders in about 20-30 mins...the longest render I've had, so far has been just under 1 hr, this one. I know that with AoA or US, this would have taken at least 2 to 3 hrs...I didn't use anything on the hair to turn off occlusion. With this shader, it probably would have been a lot less than an hour if I did. It was lit with envlight2 and some additional specular. I did tweak the eyes a little, but still not happy with them (I'm experimenting with custom shaders on them, too) and the hair pretty much sucks, but I'm not testing the hair and I don't want her bald...

mjc1016

And damn...that was somewhat disappointing.

It took longer to render than it did to hack in displacement. The displacement macro is already there, it was just a matter of 'connect the dots'.

Anyway, now I've got displacement...need to make SpecStrength contralable by a map and almost forgot Opacity.

I just updated the instance on the lips for this render (yeah, it's 'over done' on the displacement, but it was only a test).