My gut tells me the performance gains from doing multipass in terms of prefetchare outweighed by the performance losses from having to render each object multiple times.

In practice, we can't expect every mobile project to be using fully baked lightmaps (either for package size reasons or because levels are procedurally generated), so I think improving performance of rendering multiple real-time lights with shadows is key. Even if you use fully baked lightmaps, lights have to be manually hidden after baking so they don't take up rendering time, and this means dynamic objects won't receive direct light (dynamic capture currently doesn't have an option to store direct light).

We also currently lack lightmap support in the Compatibility rendering method anyway.

2. Prefetch only applies to texture samples taken directly from interpolaters, so all the PCF5 and PCF13 samples don't benefit.

Are there any alternative approaches that could be used, such as dithering? While Godot currently defaults to hard shadows on mobile, I feel like it should be possible to have something better on mobile in 2023.

Directional Light doesn't work properly for me, I'm using your custom godot 4.1 dev build

I've created testing projects to compare shadow rendering performance in 3.x and 4.x:

• 3.x: test_shadow_3.x.zip
• 4.x: test_shadow_4.x.zip

Here are the results on my machine (Linux, GeForce RTX 4090). All tests are done in 3840×2160:

This error message is frequently spammed in the editor:

ERROR: Condition "!sli" is true. Continuing.
   at: _shadow_atlas_find_shadow (drivers/gles3/storage/light_storage.cpp:946)

Does this fix the longstanding issue where shadows ignore shader parameter POINT_SIZE for point meshes Mesh.PRIMITIVE_POINTS?

Please open a separate issue with a minimal reproduction project attached.

@clayjohn

In order to avoid lights flickering between Linear and sRGB blending, shadowed lights always have to be in a separate pass. In godotengine/godot-proposals#3959 reduz assumed we could render one positional and one directional light in the base pass, but in practice this looks really bad.

I can see why. That said, I would still try to, at least, do the directional light in a single pass merged with the non shadowed lights. Directional + non shadowed lights is the most common way to do lighting on mobile, so this as single pass is ideal.

I know this would break if you have more than one directional light, but we could have a setting allow_multiple_directional_lights on compatibility that works as you describe only if user enables it.

Also shadow filter is ok and expected to be non-pcf on mobile by default (only enable linear interpolation so it does hardware accelerated PCF4, which is per spec on GLES3).

@Calinou I am surprised performance is not similar to Godot GLES2 to be honest. We really should aim for as closest as that if possible.

@clayjohn

In order to avoid lights flickering between Linear and sRGB blending, shadowed lights always have to be in a separate pass. In godotengine/godot-proposals#3959 reduz assumed we could render one positional and one directional light in the base pass, but in practice this looks really bad.

I can see why. That said, I would still try to, at least, do the directional light in a single pass merged with the non shadowed lights. Directional + non shadowed lights is the most common way to do lighting on mobile, so this as single pass is ideal.

I know this would break if you have more than one directional light, but we could have a setting allow_multiple_directional_lights on compatibility that works as you describe only if user enables it.

Also shadow filter is ok and expected to be non-pcf on mobile by default (only enable linear interpolation so it does hardware accelerated PCF4, which is per spec on GLES3).

I already have a plan. I will move the calculation of the additional lights to after the tonemapping step in the shader. That way, we can have the first light with shadows calculated in the original pass, but still in sRGB space. Should be enough to improve performance a little bit and ensure we get the best performance possible when using only a few lights.

I still wonder why the GLES2 version of Godot 3 is faster, what do we do different there?

@reduz maybe it's faster because we don't do any of the HDR lighting calculations? All lighting is kept LDR while here we do some conversions to/from HDR while we write out LDR?

I still wonder why the GLES2 version of Godot 3 is faster, what do we do different there?

Those measurements were taken with the old version of this PR. Back then we did an additional pass per light with shadows. Now the base pass includes one shadowed light so it is much faster

I've run benchmarks again on the latest revision of this PR (rebased against master), using the same hardware, resolution and testing projects as my prior test:

Directional shadow rendering still appears broken in the running project, even though it works in the editor:

In comparison, this is how the scene looks like in Forward+ (disregard the FPS count here, I resized my window quickly):

Visual comparison in the editor:

Forward+	Mobile	Compatibility

Woohoo! Thanks!

Just noting a comment from the top post:

There is still one outstanding bug where shadow atlas textures are getting out of date with multiple shadowed lights in the scene.

I'll investigate that outstanding bug and any new reports ASAP