I’m not sure if this belongs here or elsewhere because it seems to involve Burst Physics Jobs. If it goes somewhere else, let me know.
I have a game that uses entities for the enemies. They’re on a grid system and they grow in an exponential manner (they don’t really move, just individual entities grow). I’ve noticed some poor performance so I’m trying to profile to see what’s wrong. See the two attached images.
It looks like these physics jobs (CreateRigidBodies, PrepareStaticBodyDataJob, BuildFirstNLevelsJob, CheckColliderIntegrity, etc.) are taking the most time and I don’t really understand what they’re doing. When I look them up online I only find vague threads here–nothing explaining what they do and how one might optimize them.
Currently using 2021.3.16f1. Burst is 1.8.2, Entities (and Physics) is 0.51.1-preview.21, and Jobs is 0.70.0-preview.7.
Can anyone give any guidance on what these things are and how one might optimize them?
I have the same issue. I created 140000 cubes with colliders but without rigidbodies. There’s nothing else in the scene, but the CreateRigidBodies function is taking up a lot of performance. Has anyone made any progress on this?
@EternalAmbiguity : What is taking time here is the rebuilding of the spatial acceleration structure used in the broadphase for static colliders, which is an integral part in the engine’s collision detection. Making any modification to static colliders, or adding or removing static colliders requires a complete rebuild of this structure in the current state of the engine.
This is what’s taking so long.
If you don’t touch them, then all is good and this acceleration structure is simply left untouched and the high time consumption you pointed out will simply disappear.
Note that the same is true for dynamic colliders (aka, dynamically or kinematically moving rigid bodies) but there is a separate acceleration structure tree (the dynamic bounding volume tree) which needs to be rebuilt in this case, and it’s separate from the acceleration structure for static colliders. So, if you have many static colliders that you don’t manipulate, and you have a reasonable number of dynamic or kinematic rigid bodies that move, the overhead for keeping both acceleration structures up-to-date is very low, which is the ideal case.
If you have many static colliders and you modify them, then you get the issue you are observing here.
In this Unite 2022 video, my colleague Sebastian Schoener is talking about exactly this challenge that was also encountered in the development of V-Rising.
@EternalAmbiguity : Are these colliders you are creating at run-time static or dynamic?
In either case, if they are static they cause the static BV tree to be rebuilt from scratch. And if they are dynamic they cause the dynamic BV tree to be rebuilt from scratch.
As it stands, you could create many upfront instead and then work with collision filters to disable their effect.
Adding to @daniel-holz 's comment, we’re also currently investigating ways to incrementally build the BVH tree such a complete rebuild is no longer required, which in theory should improve performance signfiicantly. This investigation is still pretty early in the process but happy to share more information as they become available.
