Is it really production ready? I can’t rely on it, since it causes perfomance spikes, when you try to fast rotating the camera around in semi-complex scenes. It’s not acceptable for fast-paced games.
This is a quote from what written on docs:
"On the other hand, you should watch out for very fast movement near objects, large disocclusions, and camera cuts. "
But there’s no info about what might you do, if you need such things.
I know that the root of this problem is cache invalidation. Is there any method to keep off screen cache, maybe? Or is there any other thing to do in terms of optimization, so it can be suited for fast-paced?
I switched to shadow maps for now. However, visually, VSM is much better tech, to abandon it.
Recently just tested Lyra and toggling Nanite off and on ended up in 20% more GPU usage. Now imagine the overhead on actual complex meshes(Cough, Remnant II).
I would stick to CSM’s and distance field shadows for now.
Epic needs to just FIX CSM’s jagged lines, at least for static objects for love of god.
It’s not much related to my topic.
You don’t have to use Nanite if you don’t need it also. Overall, Nanite have nothing to do with core of this problem.
Back to topic, Shadow Maps have such peaks too btw, especially when scene have many objects. You can create an empty test map with 10k cubes, for example.
VSM, on the other hand, outperfom Shadow Maps in such scenario, and have much less noticeable peaks of cache invalidation (if this is core of this problem for them also, idk actually).
In short, VSM is better on handling a lot of objects, but lose to Shadow Maps, when a lot of light sources (especially overlapping ones) exist.
So my question is still about keeping off-screen cache or other solutions.
I also discovered this command: r.Shadow.Virtual.Cache.MaxUnreferencedLightAge
But I don’t understand, does it even do anything?
It’s not much related to my topic.
You don’t have to use Nanite if you don’t need it also. Overall, Nanite have nothing to do with core of this problem.
Yes it does and for any future reader I’m going to elaborate. You’re worried about performance in fast motion. VSM’s on non-nanite meshes causes dramatic artifacts as the camera moves.
So when you add Nanite to fix the VSM camera-motion glitching problems, you not only have to deal with the massive performance loss of VSM’s but lose 20% of your GPU’s power(If it’s playing at it’s recommended resolution)
Use CSM and distance field shadows. If you keep geometry optimized, CSM’s will benefit it.
Even walking in city sample causes VSM’s to spike insanely. Idk what your trying to make but most likely it’s faster than walking on foot.
I don’t get about what artifacts are you speaking of, but Nanite is not related to my problem.
My problem is not about fast motion, it’s about cache behavior and perfomance peaks when it needs recalculation in VSM. You can achieve these spikes by just standing still and only aggressively shaking your camera.
You can disable VSM cache to see what i’m talking about. That way you will get raw perfomance in infinite recalculation.
Switching to CSM is not a solution, it’s just fallback, since it have exact the same problem, but less noticeable on lower shadowmap resolutions. And what about soft light?
I like the performance, I can see in the visualization mode the map is picking up quite a bit of detail; lots to like.
However, there is a set of very obvious seams around the player (use the clip-view visualization mode).
I’d like a way to push those cutoffs/LODs out a ways, much like one can do with the tessellation-LODing on the virtual heightfield mesh… Otherwise, when running, flying around or whatnot, it’s very visually obvious when the shadows step-up in quality/quantity and breaks immersion.
Some type of dither/stippling between the LODs might be doable?
EDIT: playing around with nanite/non-nanite foliage. The shadows look GREAT (IMHO) but suffer from that LODing effect where the quality of shadows noticably drops, even at just man-running speeds. Quality is there, the motion/LODing, not so much…
seems like out of vram issue.
As docs say, "Conceptually, virtual shadow maps are just very high-resolution shadow maps. In their current implementation, they have a virtual resolution of 16k x 16k pixels. Clipmaps are used to increase resolution further for Directional Lights. "
you can also try to play around with r.Shadow.Virtual.Clipmap.* values.
maybe lower settings on these cvars can let you push r.Shadow.Virtual.ResolutionLodBiasDirectional further.
