Implement optional offline baking for ReflectionProbes to improve performance and quality

[jcostello]

Describe the project you are working on

3D Environment Lighting

Describe the problem or limitation you are having in your project

Currently, when playing a scene, the Reflection Probes bake at initialization, which is noticeable and doesn't make sense since it was previously baked in the editor.

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

Use the baked information from the editor when the update_mode is set to once

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

See above

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

You can delay the scene with a black screen but you don't know for sure how much time it will take to bake.

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

Reflection probes are core

[clayjohn]

I guess we could add an option to bake ReflectionProbes in editor and then use the baked Cubemap when running. We can't just reuse the existing one in the editor as it is generated when the scene is loaded in editor and consequently won't be generated when the game is not run from the editor.

The only major holdback I see here is that we will need to explore efficient texture compression strategies otherwise just loading the ReflectionProbe will be as slow as rendering it

[Calinou]

I don't think baking reflection probes suits Godot's editing workflow. Having to bake reflection probes manually to see changes adds a lot of friction to the level design process, and requires you to ship large data along with your game (something VoxelGI and LightmapGI already require – let's not make it worse).

This will also not resolve other issues related to effects that take some time to fully converge. When using advanced 3D rendering effects, you generally want to add some kind of fade transition when loading a scene. This is also required for TAA[^1], volumetric fog[^2] and SDFGI[^3] to fully converge.

[^1]: TAA always requires 16 frames to be rendered to fully converge. [^2]: By default, volumetric fog requires 10 frames be rendered to (perceptually) fully converge. This can be changed by adjusting Volumetric Fog Temporal Reprojection in the Environment resource. [^3]: By default, SDFGI requires 30 frames to be rendered fully converge. This can be changed in the project settings.

You can do so using a ColorRect node that covers the whole screen, and fade it out using an AnimationPlayer. I recommend using a duration between 0.5 and 1 second which should be good enough for most use cases.

[clayjohn]

I don't think baking reflection probes suits Godot's editing workflow. Having to bake reflection probes manually to see changes adds a lot of friction to the level design process, and requires you to ship large data along with your game (something VoxelGI and LightmapGI already require – let's not make it worse).

We could easily make it optional. ReflectionProbe could have three options (Baked, Update Once, and Update Always). Another nice thing about baking is you can resolve dependency issues in advance. Right now, ReflectionProbes draw in tree order, which means that the first reflection probe will not capture reflections in its reflection. If you bake offline, you can ensure that all objects that are in the reflection look decent when baking.

[jcostello]

@Calinou The color rect will only hide the issue but again, you dont know how much time it will take to bake.

@clayjohn I like that it solves the dependency issues. It would be a nice fix

[VantaGhost]

I think we definitely need a way to use cubemap or panorama images as reflection probe source textures, and be able to bake and save these from reflection probes. This would allow more control on a per game basis on how the game looks and performs. Some games just don't need dynamic reflection probes and would benefit greatly from the artistic control provided by the option to use a baked texture resource. Not to mention the reduced memory needed if our games could reuse cubemaps on different probes around the game world

[VantaGhost]

My personal use case would be a game that has large areas of moving level, where even "once" updated probes will be updated constantly as they move around with the level geometry, that from the perspective of the probe would not change enough to justify re-rendering. And on an artistic level, it is more important to have something reflecting that mostly resembles the game environment, than no reflections at all. But for performance reasons, the current probes are not usable in this case.

[atirut-w]

My personal use case would be a game that has large areas of moving level, where even "once" updated probes will be updated constantly as they move around with the level geometry, that from the perspective of the probe would not change enough to justify re-rendering.

There's already an option to only update in certain cases (initial load, etc.), but yeah. Being able to bake it and edit-time will be a great addition. Most other engines already have this AFAIK.

[VantaGhost]

I thought probes only have the "once" and "always" modes. And "once" actually updates anytime the probe itself moves if I'm not mistaken. But yes, most engines support baked reflections and it's needlessly limiting for Godot not to, real-time modes will still be an option.

[bertodelrio256]

with global shader variables you can specify a cubemap and access it via your shader code. the problem is, if you want to bake a cubemap from the current scene to use, you cant do that. one solution would be to provide read access to the reflection probes in the scene via custom shader.

[atirut-w]

That effectively does the same thing as a global reflection source, i.e. a skybox. The point of reflection probes is that you can have multiple reflection sources so you can have e.g. an indoor room that doesn't unrealistically reflect the sky for some reason.

[bertodelrio256]

Agreed.