Incorrect shader normal calculation in godot 4 compared to godot 3

[FireCatMagic]

Godot version

Godot v4.1.1.rc1 and 3.5.2.stable

System information

Godot v4.1.1.rc1 - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 750 Ti (NVIDIA; 31.0.15.3179) - 12th Gen Intel(R) Core(TM) i5-12400F (12 Threads) - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 750 Ti (NVIDIA; 31.0.15.3179) - 12th Gen Intel(R) Core(TM) i5-12400F (12 Threads)

Issue description

Godot 3

Godot 4

If you did not notice, the positive Z facing direction is broken on the Godot 4 version.

It's correctly calculated in the godot 3 version

These are both the exact same scene using the exact same shader.

The z facing normal is controlled by these two lines, which (obviously) breaks it when removed:

The shader in godot 4:

The exact same shader in godot 3:

The expected behavior is that this shader will function the same in godot 3 and 4.

Steps to reproduce

Open the projects, and observe the shaders and how they are the same in both

Minimal reproduction project

I've included both projects below.
NormalsGD4.zip
NormalsGD3.zip

[bitsawer]

Instead of using floating point equality comparison, use an epsilon, like this:

if (abs(NORMAL.y) < 0.0001) {

seems to fix the issue.

You should generally avoid comparing floating points using == / != operators. It can be safe in some situations, but in practice it's often not. Especially depending on how you import or generate the mesh, the mesh import pipeline might add some inaccuracies if it recalculates normals or other data.

[AThousandShips]

Once #77239 is merged you'll be able to use is_equal_approx/is_zero_approx as well

[Calinou]

This is not a bug (but caused by floating-point precision errors), as described above. It might happen to work in Godot 3, but it's not guaranteed that it will keep working there correctly forever. This is why you want to use approximate comparisons instead of exact comparisons.