Shadow fade for omni lights actually stops the shadow from updating while faded out to improve performance.

[jitspoe]

This is to address #88085

• Bugsquad edit, fixes: OmniLight3D performace doesn't improve with distance fade due to shadows still updating #88085

[lawnjelly]

EDIT:
Actually, apologies, this works before I thought it did in the pipeline, didn't read properly, so is likely a good approach.

Yes, this looks good. I am also wondering whether the shadows should ever be culled out before the lights. If all the shadow casters will be rendered when light is showing, or none of the shadow casters, this PR should cover all bases. If we want shadows to be able to fade during the light, then it becomes much more tricky to deal with.

I had a little go at this this morning with #89740, although I'm now realizing it is a bag of worms, because for lights facing the viewer, we sometimes have to render casters outside the shadow range, so I've shelved that for now.

UPDATE:
Looking through this looks good to me, I will test a bit more later if I get a chance, but probably needs a look through from a 4.x rendering team, as I'm not so familiar with 4.x (although a lot is similar there are some changes from 3.x).

[jitspoe]

You can fade the shadows before the lights. There are 3 parameters on the light for the fade start (of the light), the fade start of the shadow, and the distance of the fade (shared between the 2). I've been using this by fading the shadows out at a shorter distance than the lights, so that aspect seems to work.

[lawnjelly]

Hopefully not rendering the entire shadow map as done here will mean we won't have to deal with the caching issues which are quite tricky (the shadowmap should just remain dirty, and keep trying to render until it comes within range).

[lawnjelly]

Once the nitpicks above are done this looks fine to me (the function should take a light RID if possible imo). I've tested (reasonably, hard to test every permutation) and it seems to work fine.

Probably one of the 4.x rendering team should also review when back from GDC prior to moving forward.

[jitspoe]

Updated the code. Hopefully I got everything!

[lawnjelly]

Looks fine to me.

[Calinou]

Tested locally (rebased on top of master 29b3d9e), it works as expected in all rendering methods.

Testing project: test_shadow_distance_fade_performance.zip

Not only this PR improves performance, but this also improves shadow quadrant selection for nearby lights when distant lights are faded out:

master 29b3d9e	This PR

Unfortunately, this PR doesn't improve the situation when light per-instance limits are reached in the Mobile and Compatibility rendering methods (I haven't checked Forward+ with low Max Clustered Elements project setting). We should try to make it so fully faded lights are ignored entirely at a low level, so that you can bypass per-instance light limits using distance fade. #67845 is not fixed by this PR either.

Either way, considering how much this PR improves performance, I'd say it's already in a mergeable state.

Benchmark

PC specifications

• CPU: Intel Core i9-13900K
• GPU: NVIDIA GeForce RTX 4090
• RAM: 64 GB (2×32 GB DDR5-5800 C30)
• SSD: Solidigm P44 Pro 2 TB
• OS: Linux (Fedora 39)

Type	master	This PR
1152×648 idle	1304 FPS (0.77 mspf)	4208 FPS (0.24 mspf)
1152×648 moving	582 FPS (1.72 mspf)	2608 FPS (0.38 mspf)
3840×2160 idle	546 FPS (1.83 mspf)	675 FPS (1.48 mspf)
3840×2160 moving	403 FPS (2.48 mspf)	619 FPS (1.62 mspf)

[clayjohn]

Just a little nitpick to avoid the virtual function call and duplicated code. Other than that this seems great! Good job!

[clayjohn]

Seems great! I also tested locally and confirmed that its working as intended.

Good job!

[akien-mga]

Thanks!