Glass Shader Problem

Hi everyone!

I’m having some trouble with a glass shader for a glass door.
Thing is, when rendering the glass seems to deform anything behind it.
Here is my node setup and an image of the problem.


If your glass is single-sided, it will refract, causing what you see here. Either add a solidify modifier so it refracts correctly, or use some other shader, like a transparent/glossy mix.

P.S. Instead of using the light path node to switch to a totally transparent shader, turn off the relevant ray visibility switches in the object tab. It will render faster. (it lets Cycles skip calculations entirely instead of solving them and getting “transparent”)

For “architectural glass” I would skip the glass or refraction shaders entirely: You can’t use flat window planes with those and the refractive effect of window glass is negligable anyway. Go with a glossy/transparent mix, which will also render much cleaner much faster.

Whenever I go glossy/transparent, I have to use layer weight @ facing mode. Any kind of fresnel seem to be broken with transparency shader (refraction shader works as expected though).

I’m still wondering if that isn’t the expected behaviour? From my understanding the Fresnel equations describe the behaviour of light when moving between media of differing refractive indices (thanks, Wikipedia…). Since a transparent medium has exactly the same refractive index as the “air”, any Fresnel calculation must end in a wrong result - I guess.

And by the way: What’s wrong with Layer Weight > Facing? I find that much more predictable than Fresnel anyway…:wink:
However, to not further confuse the OP with technicalities, I could imagine a glass setup like this:

Which will look rendered like this:

I don’t know how it does it internally, but for such materials you end up with a transparent/refractive part with a corresponding (inverse?, 1-fresnel anyway) reflective part. At least that’s what I was told ages ago :slight_smile: Keep in mind when we normally try to control something with fresnel/facing value, we plug our “controllant” into the second slot (edge reflections and so on), which is the 1-result. The actual result goes into the first slot, which could be transparency/refraction/diffuse/whatever.

I would not expect the main part of a fresnel mixer go crazy if I plug in a transparency shader there. It’s only a factor mixing two shading results, and it shouldn’t be aware of what’s going on inside each one of them (if I understand this correctly).
Fresnel -> Diffuse/Glossy = ok.
Fresnel -> Refraction/Glossy = ok (same result as glass shader, but allows toning down reflections if desired).
Fresnel -> Transparency/Glossy = fail.
Facing -> Transparency/Glossy = ok.

No, there is nothing wrong with using facing as long as you get the results you’re after. But sometimes you start out with simple glass, then expand for some fairly whacky stuff that I needed at the time. And then suddenly all hell breaks loose and you try everything to find a bug in the setup, and it turned out to be the driving factor that doesn’t work anymore, for reasons at least I don’t understand. This was window glass panes from perp to glancing angles. Refraction IOR doesn’t matter much (thin glass), but reflection levels had to look identical to more normal glass material. I wanted transparency for the speed increase compared to refraction, but I wasn’t able to. Could probably have used transparency with facing, but there were too many conditions to test for.

In your setup, I notice you clamp the add. Is that required into a mix shader fac? Can that input be overdriven?

That’s what I learned once in a tutorial: Apparently fac values > 1 can cause render/evaluation errors. Quite frankly, I never put that to the test… I’m not as adventurous as you are when it comes to Cycles shading and tend to do what I’m told…:wink: