LightmapGI baking does not work on Apple Silicon Mac when the project renderer is Compatibility

[etherealxx]

Tested versions

• Reproducible in: v4.4.beta3
• Not reproducible in: v4.3.stable

System information

Godot v4.4.beta3 - macOS Sonoma (14.5.0) - Multi-window, 1 monitor - Metal (Mobile) - integrated Apple M1 (Apple7) - Apple M1 (8 threads)

Issue description

Upon doing LightmapGI baking on my Apple Silicon Mac while the project is on Compatibility renderer, this shows up.

and here's the error.

  ERROR: drivers/gles3/storage/texture_storage.cpp:763 - Condition "t->is_render_target" is true.
  ERROR: Failed loading resource: res://lightmap_gi.exr. Make sure resources have been imported by opening the project in the editor at least once.
  ERROR: scene/3d/lightmap_gi.cpp:878 - Condition "t.is_null()" is true. Returning: LightmapGI::BAKE_ERROR_CANT_CREATE_IMAGE
  ERROR: scene/3d/lightmap_gi.cpp:1293 - Condition "save_err != BAKE_ERROR_OK" is true. Returning: save_err

Switching the project to either Mobile or Forward+ won't show this error, and baking works normally. However this is not a normal behavior since baking works normally on Compatibility render on Linux. (My device is Ubuntu 20.04)

---

In addition, opening said baked lightmap back to Compatibility will result in error.

That error shows up, and crashed my engine. (This one was not the MRP)

Full crash log: https://pastebin.com/7hLrbfii

Steps to reproduce

• Download and open the MRP project
• Open lightmap_gi.tscn
• Make sure currently the renderer (top right) is Mobile)
• Click on the LightmapGI node, then click Bake Lightmap
• Save the bake file anywhere

At this point, baking should happen normally.

• remove the lmbake and exr file from the filesystem dock
• reset the light data property of the LightmapGI node
• change renderer to Compatibility, and let the project restart
• repeat the same step above to bake
• notice that now the baking is failed with errors

Minimal reproduction project (MRP)

mac-lightmap-bug.zip

[etherealxx]

v4.3.stable has this warning on the node in Compatibility, but the baking process itself works fine. The warning no longer appears on v4.4.beta3

[akien-mga]

Lightmap baking from Compatibility/OpenGL was implemented in #87386 in 4.3, and the (then incorrect) warning was tweaked in #97416 for 4.4. The process implies creating a RenderingDevice (i.e. Vulkan/Metal/Direct3D 12) to run the compute shaders.

Maybe this doesn't work as expected with Metal, CC @stuartcarnie.

[Gaffen]

Issue reproducible on the following system too:

Godot v4.4.beta3 - macOS Sequoia (15.3.0) - Multi-window, 2 monitors - OpenGL 3 (Compatibility) - Apple M1 Max - Apple M1 Max (10 threads)

[Calinou]

Does it work with the rendering driver for macos set to vulkan in the Project Settings? (Remember to restart the editor after changing it.)

[solitaryurt]

Confirmed issue on MacOS Intel X86_64 4.4-beta2 Forward+ builds fine, compatibility is broken.

[stuartcarnie]

Does it work with the rendering driver for macos set to vulkan in the Project Settings? (Remember to restart the editor after changing it.)

@etherealxx confirmed it works if the renderer is Mobile (which is Metal), and that the problem is only if the renderer is Compatibility.

I can also confirm that it works fine on macOS if the UI renderer is RendererRD based (Forward+ or Mobile), but breaks if UI renderer is Compatibility. I wonder if this is broken on other platforms?

I will take a look to see if there is anything macOS specific causing the issue.

[stuartcarnie]

Appears unrelated, but I'm seeing the error inside the gles3 code that probably needs to be fixed, as it isn't releasing the texture:

[stuartcarnie]

The lightmap_gi.exr file is correctly generated:

However, when the LightmapGI::_save_and_reimport_atlas_texture function is executed (Retrieving textures phase), it expects to reload the compressed textures, which are bptc and astc, both of which report false for the GLES3 driver:

[etherealxx]

Does it work with the rendering driver for macos set to vulkan in the Project Settings? (Remember to restart the editor after changing it.)

doesn't work (error shows up) both on vulkan and metal

[stuartcarnie]

Thanks @etherealxx, I expected that outcome, as these settings don't affect baking.

The issue is that the macOS OpenGL driver does not support BPTC or ASTC compression, which is required by the backing process when it re-imports the textures. I expect this issue is not limited to macOS, and may occur on other platforms when using the compatibility renderer, as apparently only about 50% of OpenGL platforms support ASTC per GPUInfo.

We'll need other Godot team members to weigh in on possible solutions.

[clayjohn]

@etherealxx as a workaround you can disable texture compression on the generated lightmap ext file in the import settings. That will restore the behaviour of 4.3 and earlier.

[etherealxx]

@clayjohn thanks, it works atleast for running the game with the baked lightmap. Btw as a note, without your workaround, if i export a game project with a baked lightmap to iOS with Mobile renderer (both vulkan and/or metal rendering device), it'll look pinkish like this on iPhone 12.

Despite it looks fine when being ran from the editor on the Mac Mini on Mobile renderer

[BlueCube3310]

thanks, it works atleast for running the game with the baked lightmap. Btw as a note, without your workaround, if i export a game project with a baked lightmap to iOS with Mobile renderer (both vulkan and/or metal rendering device), it'll look pinkish like this on iPhone 14.

Despite it looks fine when being ran from the editor on the Mac Mini on Mobile renderer

This is most likely due to the fact that we now force ASTC to decode in the ldr color space, even for hdr textures, which causes hdr textures to break. This should be fixed by #102461

[darksylinc]

This is most likely due to the fact that we now force ASTC to decode in the ldr color space, even for hdr textures, which causes hdr textures to break.

That's unlikely to be the reason: if I'm reading this correctly the problem is being reported for iOS. iOS uses MoltenVK, and MoltenVK does not provide VK_EXT_astc_decode_mode extension. And if using the native Metal backend, there is no such toggle either.

[darksylinc]

I shall point out that there is no DATA_FORMAT_ASTC_4x4_HDR_BLOCK in Godot (rendering_device_commons.h).

The Image class in core/io/image.h properly has HDR variants:

• FORMAT_ASTC_4x4
• FORMAT_ASTC_4x4_HDR
• FORMAT_ASTC_8x8
• FORMAT_ASTC_8x8_HDR

But RenderingDeviceCommons::DataFormat not having HDR ASTC formats is a big blocker to getting HDR ASTC running on Vulkan and Metal backends. It would only work in Compatibility (and Compatibility is broken on mac because Apple only offers minimum support)

Edit: I'm putting up together a PR. Edit 2: The PR is up.

[BlueCube3310]

#102782 should fix this, I disabled bptc and astc when testing to ensure a similar scenario to this issue and it appears to work

[etherealxx]

Hi, will this be fixed before 4.4 release? ( just asking ) I saw some PRs but idk if one of them will fix the bug or not.

[BlueCube3310]

Hi, will this be fixed before 4.4 release? ( just asking ) I saw some PRs but idk if one of them will fix the bug or not.

I don't think so, but a fix will most likely be backported to 4.4.1

[etherealxx]

In addition, opening said baked lightmap back to Compatibility will result in error. That error shows up, and crashed my engine. (This one was not the MRP)

So in 4.4.1.rc2, when i bake on Mobile and switch to compatibility, it no longer crashes the engine, but it shows this error over and over hundred times

 ERROR: drivers/gles3/storage/texture_storage.cpp:1792 - Parameter "texture" is null.

@/clayjohn's workaround still works if done before switching to compatibility

[BlueCube3310]

Could you check whether this is still an issue in 4.5-dev3?

[etherealxx]

Still a problem in 4.5-dev3

[clayjohn]

Looks like the problem is just with the texture compression mode. Setting it to Lossless makes the issue go away.

I can confirm that all VRAM compressed EXR imports are broken

[etherealxx]

Is Lossless the best setting to fall back into? Because in my testing VRAM Uncompressed also works fine.

[clayjohn]

Is Lossless the best setting to fall back into? Because in my testing VRAM Uncompressed also works fine.

Both are roughly the same. VRAM uncompressed should load slightly faster while Lossless will take up less space on disk. In either case, we should have a fix merged very soon, so whatever you choose will just be a temporary workaround

[etherealxx]

so baking works now in Compatibility (4.5.dev4), but there are error messages still

Done baking lightmaps in 00:00:00.
  WARNING: (14) drivers/gles3/storage/texture_storage.cpp:751 - Image format BPTC_RGBFU not supported by hardware, converting to RGBHalf.
  ERROR: drivers/gles3/storage/texture_storage.cpp:1795 - Parameter "texture" is null.
Done baking lightmaps in 00:02:00.

also the exr thumbnail is blank somehow, despite it being imported just fine (i think? there's no import error anymore when changing it)

The thumbnail is not blank when using VRAM Compressed + HDR Disabled (default is VRAM Compressed + HDR Opaque Only after baking), or using any other compress mode