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

OpenGL: SpotLight3D shadows occasionally use the wrong texture after moving the camera away from them #92091

Closed
Tracked by #66458
Calinou opened this issue May 18, 2024 · 2 comments · Fixed by #96509
Closed
Tracked by #66458

Comments

@Calinou
Copy link
Member

Calinou commented May 18, 2024

Tested versions

System information

Godot v4.3.dev (5708a3a) - Fedora Linux 39 (KDE Plasma) - Wayland - GLES3 (Compatibility) - NVIDIA GeForce RTX 4090 (nvidia; 545.29.06) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

Issue description

When using the Compatibility rendering method, SpotLight3D shadows will occasionally start using the wrong texture after moving the camera away from them. This can be seen in the editor:

compatibility_shadow_error.mp4

Once the SpotLight3D starts using the wrong texture, this is permanent: reloading the saved scene or toggling shadows on the SpotLight3D won't fix the issue.

It seems the SpotLight3D uses the directional shadow map instead of the positional shadow atlas. This is made evident by the fact that once you enter this glitched state, hiding the DirectionalLight3D will also hide the SpotLight3D:

Working Broken
compatibility_shadow_error_working webp compatibility_shadow_error_broken webp

(The SpotLight3D node has visible = true on both screenshots here.)

No errors are visible in the output log. I haven't managed to reproduce this issue on Forward+ or Mobile, so I assume this is Compatibility-specific.

Steps to reproduce

  • Create a 3D scene with a DirectionalLight3D that has shadows enabled and a SpotLight3D that has shadows enabled.
    • An OmniLight3D with shadows enabled may be necessary to reproduce the issue as well, but it might not actually be required.

Minimal reproduction project (MRP)

truck_town_compatibility_shadow_error.zip

@Rudolph-B
Copy link
Contributor

I am taking a stab at this.

@Rudolph-B
Copy link
Contributor

I am busy testing a solution.

Basically what would happen is when trying to reuse shadow a shadow texture it would sometimes use a previously generated cubemap texture. This caused the shown behavior as well as causing the omni light to stop updating its texture.

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

Successfully merging a pull request may close this issue.

3 participants