Add lightmap layers

[gaudecker]

Describe the project you are working on

3D first person stealth game that requires toggleable lighting and the performance of baked lighting.

Describe the problem or limitation you are having in your project

Currently if you want to toggle baked lights you need to partition your scene into individually lit parts and the show/hide the LightmapGI. This is hacky and clearly not an intended use case. It is also impossible to vary the lights (e.g. have a flicker effect) or having more than one lightmap per mesh.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

To overcome this limitation, I propose the concept of lightmap layers.

Instead of baking lights into a single lightmap, have a way to specify a lightmap layer for each light. When baking, each layer would then be baked into a separate lightmap.

During rendering the layers would be additively mixed.

In order to leverage these layers, the LightmapGI API would include a method for changing the opacity/visibility of each layer.

This would allow to have toggleable/breakable/flickering lights without having to resort to expensive dynamic lighting.

This approach would also be backwards compatible with the current baked lighting workflow, as lights would by default bake on layer 1.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

Statement: I'm not an expert on either 3D rendering nor Godot's internals. I have no idea how difficult these changes would be to implement, so I try to keep things as high-level as possible.

At least the following changes would be required to make this proposal work:

• Add a lightmap_layer property on Light3D. (Also on LightmapProbe, which should also be aware of layer opacity/visibility)
• Add a method to change the opacity/visibility of a lightmap layer in LightmapGI.
• Add a method for changing the opacity/visibility of a lightmap layer in RenderingServer.
• Allow more than one lightmap texture on a geometry instance. (I'm not sure how the lightmap is rendered, but with the assumption that the lightmap texture is a uniform on some shader, allow to have multiple uniforms and mix them in the fragment shader.)
• Extend LightmapGIData to contain all layer textures & data.

Regarding emissive materials, I'm not sure how to handle these. Maybe have a way to specify a lightmap layer for these as well.

If this enhancement will not be used often, can it be worked around with a few lines of script?

I think this would be enormously useful for most projects using baked lighting.

Is there a reason why this should be core and not an add-on in the asset library?

This is an enhancement of an existing feature, so I think it belongs to the core.

[Calinou]

• Related to https://github.com/godotengine/godot/issues/15727.

Unfortunately, this would make the scene shader much more complex for a feature that probably won't be needed often. This has a performance and maintenance impact, even if you don't use the feature in question.

Storage and memory requirements would also be pretty high considering the expectations of lightmap texel density in modern games. You could get away with storing 4 layers per texture if you forewent the ability to use colored lightmaps (or even 8 if you also used SDR lightmaps instead of HDR), but this will impact visuals negatively if you intend to use fully baked lighting (as opposed to baking indirect light only).

Real-time lights can often be used for specific lights that you need to toggle after baking. Remember that you can use Light3D distance fade properties to improve performance, as this allows you to disable shadows for distant lights (or even the light itself).

[ParsleighScumble]

It would also be useful for moving parts in the environment or a pre-baked day/night cycle. You can get results similar in quality to offline rendering if you use this just for indirect lighting. For extensive changes to the scene you would need to stream in the new lightmap from disk. I believe The Witness used this for certain movable objects in the world but it's not widely used because it's more complex and the tooling isn't that easy to make usable. Personally I don't think this should be a priority right now. But if we did add it, we should have opacity for lightmap layers (i.e. multiply each active lightmap in the shader by a coefficient between 0 and 1 and accumulate them to get the final contribution for the lightmap) rather than simply toggling visibility as that's more useful. We would need to take a code generation approach in the shader in order to prevent additional overhead in the more usual case and have some way in place to deal with the stuttering from the initial pipeline state changes.