I re-rendered some angles in 4.0 without checking (preview differs anyway for other reasons), and suddenly my solid geometry windows came out completely black - couldn’t see into the neighboring room. I’ve been using a random color → normal map in object space with a tiny strength to indicate glass panes not always being completely accurate (inaccurate lay effect for tiles). Using the Normal Map node this way now completely breaks the refraction component; in manual setup, in glass shader, and in Principled.
Using Tangent Space Normals does work, but I have to multiply with yellow and add blue. However I prefer to use Object Space Normals because I may not have a UV channel active or whatever is there may contain garbage data for this purpose.
I cannot find any difference between 3.6 and 4.0 in respect to Object Space Normals.
I tested a few normal maps that I have, in Object Space and in Tangent Space, and they look correct, both in Cycles and in Eevee.
What are you trying to do when plugging a White Noise into a Normal Map node?
Note that Object space normals are just the object normals scaled from [-1, 1] to [0, 1]. They differ from the Tangent Space because they encode the final vector unrelated to the mesh normals, while in Tangent space, the Normal map is relative to the normal of each triangle.
Refraction only, where it works in 3.6 (top) and completely fails in 4.0 (bottom).
See attached project, does this really work in both versions for you? File is saved in 3.6. Normals.blend (805.3 KB)
I’m just using black → white brick color (could be voronoi I guess) to drive 1D White Noise to get random colors. Object based normals have worked for me better in the past for this purpose, as all bets are off if UV channel somehow gets corrupted, although it works in this case. I think the corruption could happen (but not always, it was a weird one) when UV channel input was exposed to a node group but no data fed to it.
Updated to 4.0.2 release candidate, but still no luck. Tried supported and experimental feature set, GPU and CPU, and tried resetting to factory defaults.
Ok…I compiled Blender again, this time without any of my patches, and I can confirm the bug.
I have to debug it a bit further to find where the culprit is… because none of my changes touch the normal_map node, or any of the functions used by the node…
In fact, I’m quite surprise with the current closure results from the vanilla 4.1… they don’t match at all with 3.6, even if I manually convert the texture into the Normal vector.
Thanks. Unable to report bug at the moment even if main site is back up. Didn’t test, but I wonder if this backfacing thing also affect translucency? Or maybe this is a step to support thin walled refraction down the line?
Yeah I did notice other components (i.e. glossy) worked with - or at least appeared to, didn’t look that much into it - object space normal map, but refraction apparently worked okay with tangent space normal maps (feeding in random colors).
Yeah, using reflect did the trick. Can any of you log this? The site seem to be back up, but now I’ve lost my access apparently and it doesn’t send me a password reset mail.
But at least I have something I can update my linked library with that fixes projects.
Downloaded the latest 4.0.2 RC which had this bug fixed. Although my old way don’t work, your negation of the normal map output on backfacing normals appears to work fine now. No weird reflect math needed anymore.
I just downloaded the 4.1 beta, and this one seems to behave like it used to do; random colors as object space normals don’t break refraction for the backside. I’m not seeing any updates to the tracker, nor have I paid attention to update details (still on that 4.0.3 RC update that was pulled), so I’m curious if anyone knows why this was reverted?
4.0.3 RC behavior, without the fix to make it work:
4.1 is right around the corner, so I’d like to know what I need my math library to have included and how I should treat any upcoming projects that may require this type of material.
)
