Fix for GLES3 radiance cubemap update

[patwork]

Info

With this fix, changing the WorldEnvironment's sky colours in Compatibility mode updates the radiance cubemap automatically, just as it happens in Vulcan. The same applies to the Preview Environment button in the editor.

The logical condition is now the same as in the Vulcan version. Could I ask for a review by the authors of the original pieces of code? @clayjohn @BastiaanOlij

godot/drivers/gles3/rasterizer_scene_gles3.cpp

Lines 935 to 936 in 6681f25

	// Update radiance cubemap
	if (sky->reflection_dirty && (sky->processing_layer > max_processing_layer || update_single_frame)) {

godot/servers/rendering/renderer_rd/environment/sky.cpp

Lines 1273 to 1274 in 6681f25

	// Update radiance cubemap
	if (sky->reflection.dirty && (sky->processing_layer >= max_processing_layer || update_single_frame)) {

Bug

Previously, making changes to the sky colours in Compatibility mode only produced an effect in the background of the scene. 3D objects were still illuminated by the previous environment, as the cubemap was not regenerated.

Lighting of objects was updated only after reloading the scene or creating a new WorldEnvironment or setting the process_mode in Sky to SKY_MODE_REALTIME.

1. scene
   

2. after changing sky colors in preview
   

3. after saving changes into worldenvironment
   

Notes

I don't know to what extent this is normal behaviour, but for both GLES and Vulcan, in the default process_mode (SKY_MODE_AUTOMATIC), the radiance cubemap regenerates after a some delay (in Vulcan even after a few seconds). When SKY_MODE_REALTIME mode is enabled, the map regenerates immediately (maybe this mode should be selected by default when working in the editor?).

[clayjohn]

I don't know to what extent this is normal behaviour, but for both GLES and Vulcan, in the default process_mode (SKY_MODE_AUTOMATIC), the radiance cubemap regenerates after a some delay (in Vulcan even after a few seconds). When SKY_MODE_REALTIME mode is enabled, the map regenerates immediately (maybe this mode should be selected by default when working in the editor?).

I think this is because it is updating over a few frames and the editor, by default only redraws when something changes. Can you double check by wiggling the mouse in the viewport to see if that makes it update right away?

[BastiaanOlij]

Interesting typo. Seems to indeed make sense, if I recall correctly we're processing +1 once all the layers are filled and we need to create the final result. So in GLES we just ended up not doing that final step.

[BastiaanOlij]

I don't know to what extent this is normal behaviour, but for both GLES and Vulcan, in the default process_mode (SKY_MODE_AUTOMATIC), the radiance cubemap regenerates after a some delay (in Vulcan even after a few seconds). When SKY_MODE_REALTIME mode is enabled, the map regenerates immediately (maybe this mode should be selected by default when working in the editor?).

This is an interesting remark, because we're spreading updating the radiance map over a few frames, and the editor will only render a frame when there is a reason to do so, this can indeed be delayed any given time.
In runtime this is not a problem as we will render every frame so the radiance map is updated with a few milliseconds.

Not sure if setting it to update always is a good fix. I think a better fix here is to enhance the logic that skips rendering the frame in the editor when nothing has changed to also check if we're done updating radiance maps, or shadow maps, or any other things we spread out over multiple frames. I think that falls outside of this issue though.

[akien-mga]

Thanks!

[akien-mga]

Cherry-picked for 4.3.1.

[patwork]

Thank you for reviews and merge.

Indeed, wiggling the mouse in the editor causes the cubemap to update faster.

[Calinou]

I think a better fix here is to enhance the logic that skips rendering the frame in the editor when nothing has changed to also check if we're done updating radiance maps, or shadow maps, or any other things we spread out over multiple frames.

Indeed, we have similar issues with TAA, volumetric fog or SDFGI.