Distant local lights keep constantly invalidating their VSMs

Development Rendering
, ,
1

While debugging our VSM invalidation, we noticed an issue with distant local lights (either point or spotlights) that causes them to constantly be invalidated even without any movement of either the world or camera.

This seems wasteful and unnecessary? Or is there a reason this needs to happen that we are missing?

2

Steps to Reproduce

Open the attached project and:

  • Enable the Cached Page VSM debug viewmode
  • Move closer and further away from the spotlights
  • Note how at a certain distance they start to constantly invalidate their shadow every few frames
  • Enable the “Debug Draw Distant VSM lights” show flag for the viewport
  • Note that the distance beyond which this happens aligns exactly with them being considered “distant lights”

Or alternatively this can also be easily reproduced from scratch:

  • Open/create any map that uses VSMs (such as the default template maps)
  • Place a bunch of small local point or spotlights
  • Follow the above repro steps

This was tested and confirmed to occur in both 5.5 and 5.6.

3

Hello,

Thank you for reaching out.

I’ve been assigned this issue, and we will be looking into these invalidations for you.

4

Hello,

The behavior you are seeing is intended.

Distant lights (lights with only 1 page in their shadow map) will be invalidated in a Round-Robin fashion, with the max invalidated each frame controlled by the CVar “r.Shadow.Virtual.MaxDistantUpdatePerFrame”. You can disable these invalidations by setting the CVar to 0.

For more information on these invalidations, please check the end of the function “FShadowSceneRenderer::PreInitViews(…)” in ShadowSceneRenderer.cpp, where the Round-Robin light list in calculated.

The invalidations are performed in “FShadowSceneRenderer::AddLocalLightShadow(…)” from the same file - look for “ScheduledFrameNumber”, around line 444.

Please let us know if this helps.

5

Hi,

I think the above just about covers it. We round robin them and because of that they are free on the frames off, which means we don’t handle invalidations (e.g. moving object / WPO) so for there to be some updating we do this instead. It could be improved, especially with static / dynamic separate caching, or tracking if anything actually invalidated but these things would add complexity that may not be worth it. We’ll see if there is a simple way to improve the visualization to separate these out better.

Best,

Ola

6

Thank you for the investigation. That makes sense.

I suppose they keep doing so even on a static camera to prevent having to keep track of which ones have been invalidated since the last time the camera was stopped?

Debugging other invalidation issues does get a bit more annoying with these guys flickering everywhere, so some way of separating those out in the debug viewmodes might be nice to have, but at least it’s good to know why it happens, thanks!

7

Hello,

Thank you for the reply.

We are handing these further questions to another team for investigation and consideration.