Hi there, Our project is currently on 5.6.1.
We are seeing CPU hitches on the Steamdeck and our lower spec machines (i5-7600, GTX 1070, 16GB RAM) [High spec machines aren’t effected as badly]
The hitches occur while traversing our world partition maps. From our insights captures, we can see that when a cell is removed or added. There is a large GPU stall in UpdateGlobalDistanceField, which then causes the CPU to stall waiting on the GPU.
We have confirmed this is the global distance field issue, by disabling mesh distance field generation and the stalls no longer happen. They also do not happen on non world partition levels.
We have tried;
- Reducing the world partition cell sizes down, that helps a little.
- We have thought about doing larger cells and larger loading distance, but that uses extra memory that we would prefer not do.
- Reducing the Global Distance Fields max distance in the world settings, kinda helps.
- Increasing r.AOGlobalDistanceField.MinMeshSDFRadiusInVoxels helps a lot.
- Increasing r.AOGlobalDistanceField.MinMeshSDFRadius helps a little.
On steamdeck and low spec pc we use SWRT so we require the mesh distance fields.
Is there anything obvious we are missing or any levers we can pull, to reduce the amount of hitching this is causing.
Running around our levels becomes quite hitch heavy, with it constantly updating the GDF.
Thanks in advance
Craig
[Attachment Removed]
Hello,
Sounds like you’re on the right track!
Reducing the world partition cell sizes down, that helps a little.
What sizes are you using? We’ve seen cases where moving from 64 to 32 cell size reduces update spikes by 10ms.
Try reducing the number of instance/object counts contributing to the SDF by unchecking Affect Distance Field Lighting on the instances or potentially GenerateMeshDistanceField=False for small static meshes that don’t need to contribute (clutter). Known culprits include using PCG to spawn a bunch of instances with Affect Distance Field Lighting enabled.
Some other things to check. Make sure you’re using
r.AOGlobalDistanceFieldStaggeredUpdates 1
r.AOGlobalDistanceFieldCacheMostlyStaticSeparately 1
r.AOGlobalDistanceFieldPartialUpdates 1
Try lowering r.AOGlobalDistanceFieldClipmapUpdatesPerFrame to 1 instead of 2 after loading in the level or teleporting.
You can also try lowering r.AOGlobalDistanceField.NumClipmaps from 4 to 3 on low end devices which will tradeoff a bit of speed/mem for quality
You can try lowering the r.AOGlobalDFResolution to 96 or 64 with lower quality
If your hitches also include allocations you can try increasing pre-allocation using r.AOGlobalDistanceField.OccupancyRatio
After you load in the level or teleport you can try disabling r.AOGlobalDistanceField.RecacheClipmapsWithPendingStreaming to avoid full cache updates, but you might get some stale GDF data.
If you’re traversing quickly - (vehicle) you can try r.AOGlobalDistanceField.FastCameraMode 1 which will
- Multiply MinMeshSDFRadius by 10x and MinMeshSDFRadiusInVoxels by 5x (reducing the number of objects in the GDF)
- Reduce clipmap updates to 1 per frame (instead of 2)
- Add an extra clipmap and shifts the view origin ahead based on camera velocity, so the GDF anticipates where you’re going
Hope that helps!
[Attachment Removed]
Good Morning
Thank you for all this info.
Our cell size is currently at 48m, I tried reducing this down to 32m as test on the SteamDeck. It did help a little, but when we traversed to a point that loaded a lot of cells it just compounded the stall.
These are all set currently by default
r.AOGlobalDistanceFieldStaggeredUpdates 1
r.AOGlobalDistanceFieldCacheMostlyStaticSeparately 1
r.AOGlobalDistanceFieldPartialUpdates 1
Forgot say tried these ones as well r.AOGlobalDistanceFieldClipmapUpdatesPerFrame=1, r.AOGlobalDFResolution=32
I’ll give this one a shot r.AOGlobalDistanceField.NumClipmaps I ignored it initially as the wording of the desc was slightly confusing.
Our maps can be quite small and dense, so it might a case of just trying to disable Affect Distance Field Lighting on as much as we can, while still keeping Lumen SWRT looking good on lower hardware.
I will report back with how it all goes.
Thanks
[Attachment Removed]