Lighting issue on last face of ArrayMesh

[issork]

Godot version

3.4.beta4.official

System information

Linux Mint 20.1 Cinnamon, GLES3, GLES2, NVIDIA GeForce GTX1060 6GB (470.63.01-0ubuntu0.20.04.1)

Issue description

In the attached project, I generated a mesh along a Curve3D. On the last surface (as seen on the screenshot below) the lighting seems to be slightly glitched. Removing the affected inner wall section will result in the glitch being present on the top surface instead, which is why I believe that this affects the last surface of the mesh.

Same Project in Godot 3.3.stable.official:

Steps to reproduce

Run the project, it has a controllable camera with controls as seen in Blender. (Middle Mouse Button to rotate around the camera origin, Shift + Middle Mouse Button to move the cameras origin)

On the last surface, as seen on the screenshots, the lighting issue should be visible.

Minimal reproduction project

issue.zip

Edit: The project below contains just the ArrayMesh exported from the generated one above with a camera facing the affected face directly.
LightIssue.zip

[Calinou]

This is likely a regression from octahedral compression or the vertex attribute split.

[akien-mga]

CC @The-O-King, @clayjohn, @lawnjelly

[clayjohn]

I can't reproduce using 3.4-beta4 and running on Windows 10 (Intel(R) Core(TM) i5-8265U CPU, integrated graphics)

[issork]

Tested it on Windows myself now - same issue there. So this might be driver or graphics card related, which is weird because it does work in 3.3. Let's see if others get the same issue.

[Zireael07]

I seem to be seeing the same, but in 4.0:

[akien-mga]

I can reproduce the issue on Linux with both Intel HD 630 and AMD Radeon RX Vega M, both using Mesa 21.2.2.

The bug is a bit weird when checking different versions though:

• In 3.4 beta 4 and 3.4 beta 5, I have the same as @MennoMax:
  

• In 3.4 beta 3, I have errors and no mesh:
  

• In 3.4 beta 2 and earlier (down to 3.3-stable), I have no errors but a different lighting from @MennoMax:
  

[issork]

@akien-mga The first minimal project I posted should be more accurate, as the other might contain differences in the way array meshes are imported/exported. I experienced the same issues with the other minimal project as you.

[akien-mga]

@akien-mga The first minimal project I posted should be more accurate, as the other might contain differences in the way array meshes are imported/exported. I experienced the same issues with the other minimal project as you.

Thanks, I can indeed reproduce the issue too with this project. Note: It's easiest to see by making the generation script tool so that you can fly around the geometry in the editor.

I confirm that the bug is caused by octahedral compression added in #46800, CC @The-O-King @clayjohn.

I worked it around with those flags:

	var path := MeshInstance.new()
	path.mesh = st.commit(null, Mesh.ARRAY_COMPRESS_DEFAULT & ~Mesh.ARRAY_FLAG_USE_OCTAHEDRAL_COMPRESSION)
	add_child(path)

[clayjohn]

I'm afraid I won't be of much help, I can't reproduce on any of my devices.

For interested contributors, the first step will be to run this scene through a frame debugging program like RenderDoc. Then you should inspect the drawcall that draws the mesh and then navigate to "Pipeline State" and finally "Vertex Input" from here you can inspect the values that are sent for each vertex and get an idea if the issue is related to the value going in to the draw call or if the issue is in the shader itself.

[The-O-King]

I will try to investigate this on the devices that I have and see if I can reproduce it and find out what exactly is causing this from the octahedral compression side

In the meantime I have updated #48625 which provides the option to enable/disable octahedral compression (among other compression options) at import time, which should allow you to get around this issue as @akien-mga has noted

[The-O-King]

Ok so I was able to reproduce this on one of my computers and was able to get a fix in! I tested it locally and things seem to work, if others want to give it a go to confirm that would be great :) #54768

The issue stemmed from the way I was binding vertex attributes from the buffer to the shader - I was always specifying the vertex attribute as a vec4 and using offsets to specify where in the vertex buffer the data would come from, regardless of whether we actually had 4 components of data (this is specific to octahedral normal/tangents)

But now we specify 2 or 4 components depending on what data is present in the buffer

[akien-mga]

Fixed by #54768.