what ever works for you.as sayed,if you want a correct fresnel equation for example,you need the dot product,for a precise result.

if kesonmis is right,then layer weight is the dotproduct from normal and incoming too

what ever works for you.as sayed,if you want a correct fresnel equation for example,you need the dot product,for a precise result.

if kesonmis is right,then layer weight is the dotproduct from normal and incoming too

CarlG, That is absolutely fine. The reason I am using some math after dot product of incoming and normal is just to get the values in degrees going linearly from 0° to 90° only because it makes more sense to me to imagine what values I am looking at in reality when I observe a sample of material I am trying to make. If you divided a color ramp to 9 equal parts(that should represent 0° to 90°) and fed Layer Weight Facing output through it you would see why the distribution of values might be hard to visualize in angles in my head:

I think ‘correct’ and ‘precise’ are words that might be better to avoid at all. Is it not a simplified Schlick’s approximation that is used in CG? That cannot be described as correct or precise. It is a simplified approximation. The words should always be something more like ‘good enough’ the way I see it.

it doesent matter,if its a approximation… you need a cos theta (dot product incoming normal) in allmost all fresnel calculations.

look this page and its equations.you can replace all cos 0 i in the formulas with the dot product.cos 0 i is used for cos theta.( i )stands for incidence.cos t for example the (t) is for transmission

same goes for the thinfilm shader with its calculations and btw the schlick approximation uses cos theta too.its on the page as well.

Ok, so it’s for linearizing the angle, got it. Using 1-facing I get the exact same result as when using dot, with or without linearizing it. Question now is, is any method preferred, compile wise or rendertime wise?

There are node groups out there with dozens or even hundreds of math and vector operations in them.

Given the simplicity of this node group - is it like to make much real world difference?

It might, I don’t know. I have node setups that doesn’t work in Eevee. Typically expensive enough that I tend to only them on a single object - if not I guess baking the result would suffice.

Others are very simple in theory (fLerp - float mixer basically, fStepFunctions - simple color ramp with numeric driveable inputs), but become problematic on assets; linking breaks if I take the project to a different location, and appending gives me tons and tons of dupes of these things.

Given how I can easily break Eevee shader compile (nested groups, but not **that** complex), I like to stay safe when I can.

Searching for ways to fine-tune Cycles realism, I’m revisiting this approach, and bumping up this interesting thread.

Are the above node setup and default input values still correct for the Principled shader?

Thanks.

5 Likes

You could also take a look at the VShade addon which has micro-roughness in its shaders. I use it and am quite pleased with the results. It contains a few more options to enhance realism.

1 Like

Yes, the shader group just controls the roughness falloff, not the actual roughness value (which is fed into the group by the user) - so it works with Principled just fine.

1 Like

Thanks for the tip. I’ll definitely look into that.

1 Like

Is it possible to see the material nodes?

Isn’t it 1 post above?

Nop, @pixelgrip make changes to @moony original material that I’ve not understand, his result is really impressive!

Hi,this was the setup.Notice that in the original render another HDRI, that i could not found anymore,was used.

Like in almost all renders the lighting, in this case the right HDRI, makes or brakes the result.

wait,i have found it,here can you download the hdri.its called “walk of fame”

1 Like

Thank u so much

That’s awesome!!

Is there a final node group that came out of this thread? I’ve been trying to read through everything and between all of the back and forth I have no idea what the most up to date and realistic implementation of micro roughness is. Is this file from blendswap up to date?

Yes, I believe that is the final version.