Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LightmapGI: Directional lights do not bake in in compatibility renderer #92863

Closed
wojtekpil opened this issue Jun 7, 2024 · 3 comments · Fixed by #92887
Closed

LightmapGI: Directional lights do not bake in in compatibility renderer #92863

wojtekpil opened this issue Jun 7, 2024 · 3 comments · Fixed by #92887

Comments

@wojtekpil
Copy link
Contributor

wojtekpil commented Jun 7, 2024

Tested versions

  • First reproducibility in 4.3dev6. Still present in 4.3beta1 and at 5f1184e
  • Last working version: 4.3dev5

System information

Godot v4.3.beta1 - Windows 10.0.22631 - GLES3 (Compatibility) - AMD Radeon RX 6800S (Advanced Micro Devices, Inc.; 31.0.24027.1012) - AMD Ryzen 7 6800HS with Radeon Graphics (16 Threads)

Issue description

Lightmaps baked using editor in compatibility renderer do not reflect directional light influence anymore.
This seems to be a regression in recent 4.3 builds:
Expected result baked from Godot 4.3dev5, contains indirect information from red cube on ground:
Zrzut ekranu 2024-06-07 130028

Same scene baked in Godot 4.3beta1/dev6:
Zrzut ekranu 2024-06-07 130233

The issue is not present with Vulkan (Forward+)

Steps to reproduce

  1. Open MRP and try baking a lightmap from a LightmapGI node in Godot 4.3beta1
  2. Do same thing with Godot 4.3dev5 to confirm the issue is not present there.

Minimal reproduction project (MRP)

mrp.zip

@Summersay415
Copy link
Contributor

Summersay415 commented Jun 7, 2024

If you can, try to bisect which commit introduced this regression.
You know it appeared between 4.3dev5 and 4.3dev6, so use their hashes to greatly reduce range of bisecting.
4.3dev6 commit hash: 64520fe
4.3dev5 commit hash: 89f70e9

@wojtekpil
Copy link
Contributor Author

wojtekpil commented Jun 7, 2024

So it seems like reverse-z commit broke lightmap baking in compatibility:

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[d950f5f83819240771aebb602bfdd4875363edce] Use Reverse Z for the depth buffer

Not sure if my assumption is correct, but I suspect that changes to projection made Godot to use OpenGL style clip-space, but baking is done with Vulkan so it's incorrect. d950f5f#diff-0cb84c1b45f2b149fc0080b8f23b1cc760ea1fd30bbf9a38ab3f7e67fe3e7795R722

@Calinou Calinou moved this from Unassessed to Very Bad in 4.x Release Blockers Jun 7, 2024
@Calinou Calinou moved this from Very Bad to Release Blocker in 4.x Release Blockers Jun 7, 2024
@wojtekpil
Copy link
Contributor Author

wojtekpil commented Jun 7, 2024

Interesting observation is that at d950f5f it is also not working on Vulkan, so my assumption regarding projection is obviously incorrect. But LightmapGI it is working on Godot 4.3dev6 again. So seems like ReverseZ PR is breaking both renderers, but Vulkan is fixed in some commit, before dev6 release. Probably needs to be bisected again.
UPDATE:
I found a PR with fix for Vulkan: #90828 I tried to apply it on top of d950f5f to eliminate a possibility of other regressions between those two commits. Seems like it fixes only Vulkan though. So I am still positive that ReverseZ PR is the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Release Blocker
Development

Successfully merging a pull request may close this issue.

3 participants