Environment lighting not rendering properly on GLES3 on M1 Mac

[TuxTheAstronaut]

Godot version

3.4.stable.official [206ba70f4]

System information

macOS 12.0.1 21A559 arm64 , GLES3, GPU: Apple M1

Issue description

when i play my project on my mac there is like a 80% chance that the shadows in my scene will be completely black while in the editor they have a blueish tint form my world environment which is what they should also look like when i play the project. if i use this same protect on linux or windows i don't have this issues

Steps to reproduce

download the first person starter project form ether the godot asset library or form the zip provided below

then play the project with GLES3 renderer on a M1 mac, you may see this problem appear right away so you might have to play the project a couple times to encounter it but what you will se is the shadows will be completely black while in the editor they are not

Minimal reproduction project

godot-FirstPersonStarter.zip

[Calinou]

Does constant ambient lighting work? In the Environment resource, try decreasing Sky Contribution to 0 and set a custom ambient light color (with Energy above 0.0).

[TuxTheAstronaut]

ok it looks like sky contribution is what is not working if i just set a custom ambient light color that will work

[mchauta]

This looks like the same issue I'm having. Also on M1 mac but haven't tried on other Mac yet. I isolated it to the procedural sky in the environment node on my project. It's also odd because if you go into the editor while the game is running and go to remote and mess with the values on the environment, then it will fix itself until you restart the game again. This is while running but before I change the sun energy level and return it back to it's original value: then after messing with the value :

[mchauta]

Forgot to mention another odd behavior I experienced when I first discovered this was that if my scene was open in the editor when it ran, it worked correctly, but if a different scene was in focus in the editor (like my title scene) it would not work correctly. Never works on export.

[lexusinator]

Same problem here. 3D scene doesn't light correctly, no matter what I do. (sky contribution, using a directional light, no light, etc.) Works on windows in the same project, doesn't work on my M1 Macbook. That's really a critical bug, as it makes working in 3D basically impossible on my Mac.

I used a HDRi from Poly Haven: https://polyhaven.com/a/evening_meadow

Windows version: Windows 10 21H1 (Geforce GTX 1060 GPU) MacOS version: Monterey 12.3.1 on M1 Pro (Built-in GPU) Godot version: v3.4.4.stable.official [419e713a2]

Windows:

MacOS:

If one would want to fix this bug, where should one start to look? Is it a problem with Metal?

[clayjohn]

If one would want to fix this bug, where should one start to look? Is it a problem with Metal?

It will be a problem with MacOS's OpenGL implementation (which is deprecated as far as I know). I would start by inspecting the environment map in Renderdoc or a similar frame debugging tool. That should help give you an idea about where the process is breaking down (it could be an issue loading an HDRI, or an issue converting it to an OpenGL texture, or perhaps the issue occurs while filtering the HDRI into a radiance map for reflections)

[lexusinator]

Small update: Tested it on my Macbook with Godot v4.0.alpha8.official [917fd6574] and there it works. (I also made the shader more pretty, but that's beside the point)

So it assumedly works on Vulkan, doesn't on OpenGL.

inspecting the environment map in Renderdoc or a similar frame debugging tool

Sadly, I couldn't find a tool that was like Renderdoc on Mac, I tried the Xcode one but couldn't make sense of it... :(

[clayjohn]

@lexusinator could you try it using the GLES3 renderer in (Godot v4.0.alpha9.official](https://downloads.tuxfamily.org/godotengine/4.0/alpha9/) To use the GLES3 renderer select OpenGL3 under projectsettings>drivers or run the editor from the command line using the command line option rendering-driver opengl3

[lexusinator]

@clayjohn Ok! Did that, without any other changes it looks like this:

[clayjohn]

@clayjohn Ok! Did that, without any other changes it looks like this:

Wonderful thank you! Environment maps work a little different in 4.0 compared to 3.x. But the fact that it's working in GLES3 in 4.0 means that it should be possible to fix this issue in 3.x!

[elim2g]

What are the odds this is fixed with 3.5? My project is far too large to port to GD4 alpha, but I feel like this is a substantial rendering bug for an entire platform. I'm not opposed to working through the engine source myself to narrow down where it dies, but if there is already work being done it on it I'd rather not exert the effort.

[Calinou]

What are the odds this is fixed with 3.5? My project is far too large to port to GD4 alpha, but I feel like this is a substantial rendering bug for an entire platform. I'm not opposed to working through the engine source myself to narrow down where it dies, but if there is already work being done it on it I'd rather not exert the effort.

3.5 is in RC stage right now and is nearing release, so this will have to wait for a future 3.5.x release to be fixed (or 3.6). It's not a trivial bug to fix, especially if you don't know its cause.

We don't know what's causing this bug in 3.x, so feel free to look into narrowing it down :slightly_smiling_face:

[clayjohn]

To add to Calinou's comment, it looks like no one is actively working on this, so a fix won't be in place for 3.5.

Someone needs to compare the environment map generation code in 3.x and in 4.0 and see if they can spot what is going wrong (worst case scenario, they can probably just copy the code from 4.0). In 3.x the relevant code is here https://github.com/godotengine/godot/blob/70951b3a9c977fc328e603c3d489bcc57278660d/drivers/gles3/rasterizer_storage_gles3.cpp#L1678

in 4.0 it is here https://github.com/godotengine/godot/blob/e24e4935ffc13715cf7a3dff189ac69d0c7a44e7/drivers/gles3/rasterizer_scene_gles3.cpp#L926

[lexusinator]

@clayjohn Ok! Did that, without any other changes it looks like this:

Wonderful thank you! Environment maps work a little different in 4.0 compared to 3.x. But the fact that it's working in GLES3 in 4.0 means that it should be possible to fix this issue in 3.x!

Sorry, I should have said, but it does not appear to be working in GLES3 in Godot 4. 😅 If you compare it with my other screenshot above, that was taken in Godot 4 with Vulkan (where it works), you'll see that the water and boat are much too dark, and that's exactly the problem we also have in Godot 3 with GLES3.

My test environment with the custom water is a bit special I admit, maybe I should take some screenshots in a more "default" test scene...

[clayjohn]

@lexusinator Ah, okay, do you mind just testing using the MRP from the original post?

[lexusinator]

@clayjohn Ok, so I downloaded the project file from OP and tested between Godot 3.4.4 and Godot 4.0.alpha9 GLES and Vulkan. I first took the screenshot in 3.4.4, then imported it into Godot 4, did minimal changes to make it work, then took one screenshot with Vulkan and one with GLES3. The changes were some missing materials on the blocks and in the WorldEnvironment. I didn't touch the new Sky I created for the WorldEnvironment, which is probably why it looks darker than in Godot 3.4.4.

But sadly, as you can see, I wasn't able to reproduce the issue in Godot 3.4.4., there it looks like it should and is not blacked out, but instead I found new issues in Godot 4 on GLES3. The triangles of the faces seem to render in the wrong order. (I think) And everything is super reflective.

The project in its broken state can be found here: godot-FirstPersonStarter.zip

The Vulkan one seems alright, albeit a bit darker than in Godot 3.4.4.

Godot 3.4.4:

Godot 4.0.alpha9 (Vulkan):

Godot 4.0.alpha9 (GLES3):

---

I suspected the HDRi map to be the source of my issue, so I changed the default ProceduralSky to a PanoramaSky, loaded the HDRi and did the whole thing again. Now it breaks in Godot 3.4.4 again and the scene is much too dark. (the, or at least my, original issue) In Godot 4 Vulkan seems to work again, but GLES3 is broken geometry-wise and seems to dark rendering-wise?

Godot 3.4.4.:

Godot 4.0.alpha9 (Vulkan): (the play window is a bit blurry because of the wonky hiDPI setting)

Godot 4.0.alpha9 (GLES3):

---

And because the MeshInstances seem super broken (they are also weirdly scaled after importing?), I tested it again with an even simpler scene (in the same project). This time the project stayed on Godot 4 GLES3, I tested the default ProceduralSky vs. the PanoramaSky with the HDRi. Now both seem to work fairly well? (except on the MeshInstances)

Find this project here: https://www.dropbox.com/s/0itvna7h01vaobi/godot-FirstPersonStarter-panorama.zip?dl=0

Godot 4.0.alpha9 (GLES3) with ProceduralSky:

Godot 4.0.alpha9 (GLES3) with PanoramaSky and this HDRi:

I also found the default material on a MeshInstance and a new StandardMaterial3D render differently? See the spheres.

---

Verdict: I'm confused. 😅 Rendering a scene in 3.4.4. seems to work with ProceduralSky, but not with PanoramaSky. (so, my original issue) Previously, even ProceduralSky didn't work. In GLES3 in 4.0.alpha9 the rendering of multiple MeshInstances of the same type seems broken, but the rendering with ProceduralSky and PanoramaSky seems to work quite well. At least in a simple scene with newly created primitives. Vulkan in 4.0.alpha9 seems to work without problems.

But as OP said, that could maybe change on the next restart of my laptop. But that's as much time as I could invest today.

[clayjohn]

@lexusinator Thank you for your comprehensive review.

With respect to GLES3 in 4.0, glad to see the sky is working, but it looks like there is a lot of work to be done to fix up mesh rendering (also we need shadows to do a proper comparison).

I'm not sure if we are any closer to figuring out what is going wrong on MacOS (when using PanoramaSky). Perhaps try playing around with texture import settings, maybe Mac has troubles with HDR textures? Could be useful to try the same HDRI in an LDR format.