Vulkan Mobile backend: Environment lighting and reflections are twice as dark as they should be

[Calinou]

Godot version

4.0.dev (2a9dd65)

System information

Fedora 34, GeForce GTX 1080 (NVIDIA 470.74)

Issue description

When using the Vulkan Mobile backend, environment lighting and reflections appear twice as dark as they should be.

Vulkan Clustered

Vulkan Mobile

Vulkan Clustered with Ambient Light Sky Contribution set to 0.5

This makes environment lighting consistent with the mobile backend, but this doesn't adjust reflections. Since Sky Contribution can't be set above 1.0 and Energy does not affect sky contributed lighting, it's not possible to brighten ambient light on the Vulkan Mobile backend to bring it back to the level of Vulkan Clustered.

Steps to reproduce

• Add 3 MeshInstance3D nodes to the scene: 2 with the fallback material, and 1 with a fully metallic and non-rough material (to see environment reflections).
• Add a DirectionalLight3D node and a WorldEnvironment node.
• Switch to Vulkan Mobile backend in the project settings (search for back end).
  • Note: The MRP linked below already uses the Vulkan Mobile backend by default.
• Notice how environment lighting is twice as dark (but not the DirectionalLight3D itself).
• Switch back to Vulkan Clustered backend and restart the editor. Decrease Ambient Light > Sky Contribution in the WorldEnvironment to 0.5. Notice how lighting now looks very similar to the mobile backend's.

Minimal reproduction project

test_vulkan_clustered_vs_mobile_environment_lighting.zip

[Calinou]

I've tried to fix this by using the luminance multiplier to multiply specular lighting. However, the appearance still isn't completely right:

diff --git a/l.diff b/l.diff
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/servers/rendering/renderer_rd/shaders/scene_forward_mobile.glsl b/servers/rendering/renderer_rd/shaders/scene_forward_mobile.glsl
index 6911cab27b..1ace099ae4 100644
--- a/servers/rendering/renderer_rd/shaders/scene_forward_mobile.glsl
+++ b/servers/rendering/renderer_rd/shaders/scene_forward_mobile.glsl
@@ -899,6 +899,7 @@ void main() {
 #endif //USE_RADIANCE_CUBEMAP_ARRAY
 		specular_light *= horizon * horizon;
 		specular_light *= scene_data.ambient_light_color_energy.a;
+		specular_light *= sc_luminance_multiplier;
 	}
 
 #if defined(CUSTOM_RADIANCE_USED)
@@ -919,6 +920,7 @@ void main() {
 #endif //USE_RADIANCE_CUBEMAP_ARRAY
 
 			ambient_light = mix(ambient_light, cubemap_ambient * scene_data.ambient_light_color_energy.a, scene_data.ambient_color_sky_mix);
+			//ambient_light *= sc_luminance_multiplier;
 		}
 	}
 #endif // !USE_LIGHTMAP

Doubling ambient lighting makes things too bright however. (sc_luminance_multiplier is 2.0.)

Default mobile backend

Specular lighting doubled

Ambient and specular lighting doubled

[clayjohn]

I can't reproduce this on Beta8 the lighting brightness doesn't change between the forward_plus and mobile backends. This must have been fixed sometime in the last year by another change

[Calinou]

I can still reproduce this in 4.0.beta 8a98110 (Linux, AMD Radeon RX 6900 XT with Mesa RADV).

You can check this in the demo projects' 4.0-dev branch on Truck Town or Platformer 3D after switching them to Forward Mobile: https://github.com/godotengine/godot-demo-projects/tree/4.0-dev

(Platformer 3D uses reflection probes, but Truck Town doesn't.)

Platformer 3D

Forward Plus	Forward Mobile

Truck Town

Forward Plus	Forward Mobile

PS: --rendering-method mobile is valid syntax, but it appears to do nothing on both demos, even though --rendering-method gl_compatibility works. I had to change the backend through the project settings to take the Forward Mobile screenshot.

[BastiaanOlij]

Hmmm, I'm not certain, I know one issue we have on mobile is that we only have 10 bits of color precision, not 16 bits, as we need to use 32bit color buffers, 64bit color buffers kill performance on mobile GPUs, while 32bit buffers often have additional optimisations to minimize bandwidth transfering data between tiled memory and texture storage.

The A2R10B10R10_UNORM color format used is also a normalised format, so valued from 0.0 - 1.0, which we scale up to 0.0 - 2.0

It can simply be a bug in how radiance colors are mixed in, possibly we're forgetting the take the luminence multiplier into account something. As we divide all colors by 2, to get the 0.0 - 2.0 range when we're storing 0.0 - 1.0, we might be forgetting to multiply it in these conditions.

[clayjohn]

Looks more like an issue with blurring the radiance map. We are losing energy with successive applications of the cubemap roughness shader. By the time we reach the last level the entire thing is almost black.

Mobile

Clustered

Okay, after some exploration, it is clear that the issue comes from the cubemap downsampling phase