Our servers are run single threaded. I’m observing the ComputeIntermediateSpatialAcceleration taking > 1ms in some cases which is a lot more than we can afford.
We have geo collection components, but only with physics enabled on the client.
On the server we have typical characters, gameplay actors, and static mesh actors with typical kinematic based collision settings. We don’t run animation on the server and clear out the mesh pointers on our skeletal mesh components. We do have some skeletal mesh components still around, but not doing anything.
Our only collision on the server should be typical overlaps, sweeps, and traces.
The level this trace is in is a world partition world without server streaming enabled.
I’d like advice on how to audit what is going into this physics tick on the server, and how to reduce the cost of it.
Edit:
Done some debugging, looks like after load in to our largest level (that has no server streaming) we have 170k static particles and 2400 dynamic.
I assume the 170k is a large number and impacts the spatial acceleration build time, but not sure.
Hi Daniel,
There are some tuning parameters in PBDRigidsEvolution.cpp at the top which may help out, specifically:
CHAOS_API int32 AccelerationStructureIsolateQueryOnlyObjects - Try turning this on
CHAOS_API int32 AccelerationStructureSplitStaticAndDynamic - Check this is on (It should be)
CHAOS_API int32 GAccelerationStructureCacheOverlappingLeaves - Try turning this off. This may help your case, but slow down scene queries as a consequence
It is probably worth checking that your static bodies aren’t moving at all as well - that way they should be lowish cost after the initial build since the static only structure isn’t changing if there is no static movement. 170K static particles is high though. How large is this map and how many players are you budgeting for? 1ms is far from terrible as well, but we can see if they is able to be improved.
All the best
Geoff Stacey
Developer Relations
Epic Games
Hi Daniel,
Based on the number of players, and if that means that a lot of the map may not be visited by one of the players during a match/playthrough - then Lightweight actors could be a good idea to reduce the numbers of static actors as well (this also saves memory). There is a good community article here: https://dev.epicgames.com/community/learning/tutorials/zweW/light-weight-instances-ue5.
For geometry collections as well, there are some tuning parameters in GeometryCollectionPhysicsProxy.cpp, specifically
bool bCreateGTParticleForChildren - this is set as true normally, if you set it to false it won’t actually make the child bodies until a destruction event occurs.
For collisions, favour implicit geometry where possible (ie Spheres, Cubes etc), keep Mesh geometry as low as gameplay will sensibly allow - avoid long thin triangles, tiny triangles or huge triangles.
Insights and Chaos Visual Debugger are the primary tools I’d use in this case, but if there is anything specific you are looking for I can find out.
Geoff
Map is like 4 x 4 x 6 km. 6 players. 36k total world partition actors.
I’ll experiment with those numbers. We’re aiming for 6.25 ms for a server instance.
I haven’t looked close enough / tested enough to see what gameplay or what part of the level causes it to go to > 1ms. Most of the time its 0.25ms or so.
We do a reasonably high number of overlaps and scene queries so a little cautious about disabling the GAccelerationStructureCacheOverlappingLeaves .
We haven’t done any true optimization of static mesh actors and their collision in the scene. Any recommendations there in a nanite world as it relates to this?
I do plan on looking at the dynamic particles to see of any could be made static.
Any other debug commands or ways to inspect the state without modifying the code?