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 with gi_mode disabled do not recieve indirect light from LightmapGI/LightmapProbes #91431

Open
sievaxx opened this issue May 2, 2024 · 3 comments

Comments

@sievaxx
Copy link
Contributor

sievaxx commented May 2, 2024

Tested versions

  • Reproduced in: 4.0.stable, 4.1.stable, 4.2.stable, 4.3.dev6

System information

Godot v4.2.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

Setting a mesh's GI Mode to Disabled does not allow it to receive indirect lighting from Lightmap Probes, as the tooltip and documentation suggests.
editor_screenshot_2024-05-02T023311
These meshes are the same resource with the same material, but the one on the left has it's GI mode set to Dynamic, while the one on the right has it set to Disabled. There is only a LightmapGI for global illumination in the scene, so we should expect them to both use the lightmap probes to receive indirect lighting, as the documentation describes.

This should work, since the documentation makes it seem intended for projects that blend multiple GI types, and for objects that should not be baked at all but still should receive indirect lighting e.g. player characters / npcs / dynamic props.

Steps to reproduce

Use the MRP, select the LightmapGI node and just bake the lighting. (The lmbake resource breaks without the .godot folder, so you'll have to bake it yourself.) Then run the project.

Minimal reproduction project (MRP)

MRP.zip (For 4.2)

@Calinou
Copy link
Member

Calinou commented May 21, 2024

This is done by design, otherwise there would be no way to exclude certain meshes from receiving all forms of GI. This is what the Dynamic bake mode is for 🙂

The property hint in the bake mode enum was misleading, so it was removed in 4.3: #85219

Setting a mesh's GI Mode to Disabled does not allow it to receive indirect lighting from Lightmap Probes, as the tooltip and documentation suggests.

Out of curiosity, where did you read this in the documentation?

@sievaxx
Copy link
Contributor Author

sievaxx commented May 23, 2024

That part of the tooltip/documentation has been moved to the Dynamic part now in 4.2.2 and 4.3 according to #85219 . I was still on 4.2 when i read that tooltip, and i didn't re-read it in 4.3 when I checked for what I thought was a bug and not a misunderstanding.

The old docs implied that Disabled mode would only receive GI and not contribute to any of the 3 GI methods, which is what I wanted. The new docs say that disabled can only receive from VoxelGI and SDFGI, but not LightmapGI. I still think that's a bug, it doesn't make sense to be designed to be inconsistent.

Possibly, a new mode "Receive Only" would make it clear that the other two modes are about if the object contributes to GI (and which types), and allow for receiving GI from all 3 without having to contribute to VoxelGI/SDFGI. That would allow Disabled mode to actually exclude meshes from receiving GI.

@sievaxx
Copy link
Contributor Author

sievaxx commented Aug 29, 2024

I still consider this to be a major problem with using static GI. The only way i've been able to get dynamic objects to receive "ambient" lighting is to use the dynamic GI offerings, which I DON'T want to use, on purpose. I don't understand what the point of all the light probes are for from LightmapGI, when they appear to do nothing at all. Using manually played reflection probes lets non-contributing objects receive ambient lighting, but that just makes whats happening even more confusing? I can't tell if this is a real bug that you misread as me misunderstanding the documentation, or if this really is by design, because this is a really weird design choice.

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

3 participants