Normals/Lighting error with SurfaceTool generated mesh

[IndigoBeetle]

Godot version

v4.2.beta.custom_build [f8818f8]

System information

macOS Ventura 13.6 M1 Forward+

Issue description

When generating a mesh with SurfaceTool in the latest beta/master build, on macOS M1, the lighting seems to fail when the light direction passes a certain point. The images below demonstrate this. Image 1 shows the lighting/shadowing working with the directional light x angle being between -90 and -180. The second shows that the lighting seems to flip the normals when the light angle goes beyond -90, i.e. between -90 and 0. The third image shows that the lighting/normals are flipped, as the lighting and shadows are applied on the opposite side of the surface, the surface has a material with culling turned off to show both sides.

Note: changing the winding order of the two triangles in the mesh flips the behaviour, it works correctly between -90 and 0, and flips between -90 and -180, suggesting it might be something to do with face normals and vertex normals getting mixed up.

Steps to reproduce

Load the provided sample project and spin the directional light on the X-axis to change the direction it is facing in Z.

Note: I've found that making changes to the script and then regenerating the mesh (it's a @tool script) doesn't usually work, it requires reloading the project for some reason.

Minimal reproduction project

ShadingBug.zip

[clayjohn]

I think there is a good chance that this is a regression from #81138. Can you confirm that this issue is not present in dev6 for you?

I've tested the MRP on Windows 10 and I can't reproduce the issue, which doesn't necessarily mean anything as there have been a few reported issues that I can't reproduce (see #83240)

[IndigoBeetle]

Not sure what you mean by "dev6" I can't find a tag or branch with that name.

[AThousandShips]

This

[IndigoBeetle]

Confirmed, the problem is not evident in dev6.

[clayjohn]

I made a PR that might fix this, can you test it out? #83704

[IndigoBeetle]

I've applied your PR and rebuilt, unfortunately, it has no effect on the bug, it is still showing here on my mac in the sample project attached.

[akien-mga]

Sounds related to #83236 ?

[clayjohn]

@IndigoBeetle Could you test again with Beta4? https://godotengine.org/article/dev-snapshot-godot-4-2-beta-4/ There have been a number of fixes that might help here.

Sounds related to #83236 ?

I don't think so. In this case the project isn't relying on tangents (or normal maps or anything like that)

[IndigoBeetle]

Unfortunately, still not working, I sure hope it's not something I'm doing wrong. Has anyone else been able to reproduce it from the attached test project? I'm using an M1 mac mini if that matters.

…

On Wed, 1 Nov 2023 at 15:06, Clay John ***@***.***> wrote: @IndigoBeetle <https://github.com/IndigoBeetle> Could you test again with Beta4? https://godotengine.org/article/dev-snapshot-godot-4-2-beta-4/ There have been a number of fixes that might help here. Sounds related to #83236 <#83236> ? I don't think so. In this case the project isn't relying on tangents (or normal maps or anything like that) — Reply to this email directly, view it on GitHub <#83667 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALMDZEKZJGSMIMQCEDN42ELYCJQPXAVCNFSM6AAAAAA6I2V2ZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBZGEZDANZQG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[adjourn]

I feel like this issue could share the same cause with my project. Only tried on 4.2-beta4.

All imported meshes are fine but meshes generated by code have very odd shading.
These are basic planes, and the shading comes from directional light. (screenshot taken from top, these are flat on ground)

Ignore the difference in shading color, it's not another bug - lighter planes have material color #fff, darker ones #bbb.

Since normals are as simple as they can be and it works perfectly in 4.1.1, I can only blame 4.2.

Vector3[] normals = new Vector3[] {
  Vector3.Up, Vector3.Up, Vector3.Up, Vector3.Up
};

For completeness sake, here's the rendering logic as well:

// basically default standard material
StandardMaterial3D material = new StandardMaterial3D();
material.AlbedoColor = color;

// using rendering server directly!
Rid mesh = RenderingServer.MeshCreate();
GArray meshArrays = Meshes.GetPlaneArrays(size); // generates mesh array for plane
RenderingServer.MeshAddSurfaceFromArrays(mesh, RenderingServer.PrimitiveType.Triangles, meshArrays);
RenderingServer.MeshSurfaceSetMaterial(mesh, 0, material.GetRid());

Rid instance = RenderingServer.InstanceCreate();
// commenting out shadow casting line doesn't make a difference
RenderingServer.InstanceGeometrySetCastShadowsSetting(instance, RenderingServer.ShadowCastingSetting.Off);
RenderingServer.InstanceSetScenario(instance, Global.World3D.Scenario);
RenderingServer.InstanceSetBase(instance, mesh);
RenderingServer.InstanceSetTransform(instance, transform);

My apologies if it's a different issue, please let me know and I'll submit a new issue with reproduction (C#).

[testman42]

is this post of mine relevant to this issue?
#68200 (comment)

[Zireael07]

Highly likely that it is

[stoofin]

Unfortunately, still not working, I sure hope it's not something I'm doing wrong. Has anyone else been able to reproduce it from the attached test project? I'm using an M1 mac mini if that matters.

@IndigoBeetle I tried the example, but it looks fine for me in 4.2.beta4 on kubuntu 23.10.

Note: I've found that making changes to the script and then regenerating the mesh (it's a @tool script) doesn't usually work, it requires reloading the project for some reason.

I think the script has a typo, it looks like this

func _set_regen(value : bool) -> void:
	_gen

when surely it should be

func _set_regen(value : bool) -> void:
	_gen()

[IndigoBeetle]

I've fixed those issues in the script, I don't believe they contributed to the problem at all, here is a video of it on my M1 mac Mini, this is with generate_normals commented out and the winding as in the original project. Changing the winding just changes which side the shadow works and doesn't, i.e. flipping the winding just makes the shadow show on the negative Z side of the cube, and not on the positive Z side in the video.

error_small.mov

[clayjohn]

I think I have identified the cause of this issue (#84277 (comment)) and unfortunately it comes from Metal (Apple's rendering API) not supporting a basic Vulkan feature that we rely on. I am going to have to add some sort of fallback for Apple devices.

[clayjohn]

I've been able to emulate the problem with Apple devices on my device, I should have a fix coming in shortly