We recently noticed performance spikes in “ComputeIntermediateSpatialAcceleration” and “SwapAccelerationStructures”, i.e. due to updating the broadphase. The enum in FBroadPhaseConfig suggests multiple types of broadphase are supported, so I had a few questions about how broadphase works in Chaos:
1) Does Chaos have separate broadphase structures for rigid body collision detection and scene queries?
2) Do the broadphase types (Grid, Tree etc.) refer to the structure use for collision detection, scene queries or both?
3) What is the best way for best way for a game to specify the broadphase type without Engine modification (e.g. via an .ini property)?
4) Can you briefly elaborate on how the following broadphase types work: TreeOfGrid, TreeAndGrid and TreeOfGridAndGrid. Are any of these analogous to PhysX’s Multi Box Pruning, Auto Box Pruning and Parallel Auto Box Pruning?
5) Which broadphase type would you recommend for a large, streaming open world?
Many thanks in advance for your time and advice.
Hi Graham, and thank you for your question.
The first thing I would be keen to find out is when are you seeing these spikes? Quite often these markers will show up in traces as a consequence of something else as opposed to the main issue - ie trying to stream in too many objects into the physics engine at once is a common one.
1) Yes you are completely correct - we have 2 broadphases. The scene query lives on the game thread, and allows the main thread to use scene queries whilst the physics is updating.
2,3,4,5) We only really do work now on the AABB - this is our primary supported broadphase, and works pretty well across a number of scenarios. I’d recommend you keep it as that and look into what underlying reasons there are for any costs showing up in profiling. There are quite a few levers that can be pulled to ‘tune’ this broadphase when needed (although most of the time the main issue is trying to make huge updates within one frame)
Best
Geoff Stacey
Developer Relations
EPIC Games
Thank you very much for the reply Geoff. Based on your advice, we’ll focus more on the available options to tweak the AABB broadphase instead of investigating the other types.
While you are here, I also wanted to ask about performing scene queries on the physics thread: we found a way of doing this safely by calling Chaos::Private::LowLevelOverlap() directly using FPTOverlapBuffer as the HitBuffer type, causing FAccelerationContainerTraits::GetSpatialAccelerationFromContainer to choose the physics thread’s acceleration structure. Is there a plan to expose this API for use on the physics thread in future?
My pleasure Graham,
What is the use case you are doing here out of interest?
Thank you again for the reply.
Our use case is performing wheel raycasts for a simulated vehicle. We run Chaos at a fixed timestep, so we need to perform the raycasts on the physics thread to ensure they are exactly in sync with the movement of the chassis rigid body. In fact we actually perform an overlap query around each wheel to cache nearby collision geometry, then perform raycasts against this geometry cache at the start of each vehicle simulation sub-step. Again, the overlap query is performed on the physics thread by calling Chaos::Private::LowLevelOverlap() directly using ChaosInterface::FPTOverlapHit.
Out of interest, I also noticed that you can use a convex mesh for the query shape if you call Chaos::Private::LowLevelOverlap() directly. This doesn’t appear possible if calling UWorld::OverlapMultiByChannel for example, as FCollisionShape does not support convex meshes.
Hi Graham,
That makes perfect sense, and we did similar for a vehicle game I worked on in the past in a studio very close to yours. I don’t see us exposing this in the near future though. I’ll double check with dev though.
Geoff
Hi Graham - is your question on essentially about having access to the physics broadphase from a non physics thread in the first part of the question? If so, it is worth calling out that at the moment the gamethread broadphase and phyiscsthread broadphases are copies of each other, but with a slight time lapse on the gamethread side in some cases - ie async physics where the physics tick is faster than the frame rate.