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

Meshes without UV2 cannot contribute to LightmapGI #96538

Open
sievaxx opened this issue Sep 3, 2024 · 3 comments
Open

Meshes without UV2 cannot contribute to LightmapGI #96538

sievaxx opened this issue Sep 3, 2024 · 3 comments

Comments

@sievaxx
Copy link
Contributor

sievaxx commented Sep 3, 2024

Tested versions

  • Tested in Godot 4.3-stable

System information

Godot v4.3.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1080 Ti (NVIDIA; 31.0.15.3742) - Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12 Threads)

Issue description

Meshes that have no UV2, even when the GeometryInstance3D gi_mode is set to Static, do not appear to contribute any shadows to the LightmapGI.
image

Unwrapping the UV2 does allow things to contribute, but to me this doesn't make any sense. They should still be capable of being rasterized by the lightmapper for direct light even if they have no UV2 to allow for writing to the lightmap, and it should be up to the gi_mode to dictate if it is contributing. I'd understand if they couldn't have bounce light when use_texture_for_bounces is true, but it should still be visible to the direct light.
image

Currently this makes setting up "light blockers", like gobos (although texture gobos wouldn't work anyway without #90109), or to prevent light bleeding, annoying. You have to make sure they have UV2s, and then having a hint size small to not waste space on the atlas. There doesn't seem to be a better way to do it then that

Steps to reproduce

Just bake a LightmapGI in a scene with meshes that have no UV2 alongside meshes that do.

Minimal reproduction project (MRP)

N/A

@bikemurt
Copy link
Contributor

bikemurt commented Sep 4, 2024

The documentation mentions in several places that UV2 is required (and hence why primitives won't work for light baking). My understanding is that the baked light textures map to UV2, and not the mesh's original UV map, which might not be using maximum surface area.

The workflow for light blockers might be the main issue here.

@sievaxx
Copy link
Contributor Author

sievaxx commented Sep 4, 2024

The documentation mentions in several places that UV2 is required (and hence why primitives won't work for light baking). My understanding is that the baked light textures map to UV2, and not the mesh's original UV map, which might not be using maximum surface area.

I didn't misunderstand that, meshes obviously need UV2s to be baked into the lightmap texture atlas. But meshes without UV2s should still be considered in the lightmap raycasting/rasterization for other surfaces, even if they themselves have nothing to bake onto.

@Calinou
Copy link
Member

Calinou commented Sep 5, 2024

This was supported in Godot 3.x, but it wasn't reimplemented in Godot 4.x when the lightmapper was rewritten from scratch. The way the GPU lightmapper works may make this not technically feasible anymore as well.

I agree this would be useful for emissive surfaces that you hide after baking (or large emissive surfaces you don't want to take space in the generated lightmap textures). However, changing this behavior may change visuals in existing projects if they bake lightmaps again.

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

No branches or pull requests

4 participants