We are suffering from lots of artefacts with the VSM from our directional lights, as showcased in the videos. It appears in multiple cases, like shadowcasting particles, or WPO materials casting shadows. We had this issue in earlier versions of the engine, but it was solved by using r.Shadow.Virtual.Cache.StaticSeparate=0, however since that is deprecated in 5.6 the issue is back. I have failed to reproduce the issue in an example project. The same simple scene in a clean version of the engine, with the same DefaultEngine.ini file, does not have the same problem, but we have not made changes to any of the rendering systems involved (or any rendering afaik). Our project started already in 5.0 and have been upgraded with each version. Are there any clues to where we should be looking to identify the culprit?
If the assets were migrated into the test project and the issue did not persist, then it would to worth investigating if a ResavePackages would help the issue, provided one hasn’t already been run.
There is a console variable to constantly invalidate directional lighting. It might be checking if ‘r.Shadow.Virtual.Cache.ForceInvalidateDirectional 1’ alleviates the issue or if the results differ per frame.
With that same console variable set, running PIX or DumpGPU and checking what is being written into the shadow map would be interesting to know as it seems the result is sometimes correct in those videos.
Best regards,
Chris
Unfortunately that command does not change the results. We are suspecting a broken merge, we have noticed that .usf files sometimes break their formating during engine upgrades. Are there any specific ones we should look closer at to see if we can find the culprit there?
It’s hard to tell if the issues are during the VSM write stage or during their usage.
Short of sanity checking the history of the entire Shaders/Private/VirtualShadowMaps/, I’d probably start looking at VirtualShadowMapCacheInvalidation (and GPUInvalidation) in case it’s an issue with the VSM pages not invalidating correctly as the older console variable would suggest, and maybe Projection.usf, but the latter has a lot of headers associated with it.
I hope that helps.
Best regards,
Chris