Broadphase rebuild #139
-
|
I now watched your GDC talk, very interesting. One thing that you mentioned is the broadphase rebuilding, and you said you rebuild the tree and then swap it, so that it can be accessed in a multi-threaded way. When you said "we do this", it wasn't clear to me, whether "we" referred to Jolt in general, or the game and how it integrates Jolt. Ie. does Jolt rebuild/optimize the broadphase automatically as needed already or not? In my engine, I am adding and activating bodies one by one, which you mention is pretty bad. Of course most of that happens in the first frame when the level is loaded. Should I keep track of this and trigger a rebuild at some point? Should I just rebuild the broadphase for dynamic objects every frame? Are there helpers to do this in the background as you do in the game? Also you mentioned that the navmesh generation may run for several seconds, but you said that you swap the broadphase trees at the end of the frame. Just out of curiosity to clarify, does each navmesh generation step just keep using that one tree for its entire duration, no matter how long it takes, or do you somehow tell it at the end of the frame to now continue with the new tree? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
This is how Jolt does it in general, it's part of PhysicsSystem::Update.
After loading I would recommend calling PhysicsSystem::OptimizeBroadPhase once to fully rebuild the tree (this you can do from a background thread but take care to not modify any bodies while you're doing this). Also when you're loading objects, try to collect all bodies that you're loading and add them as a single batch. If you don't, things will still work but it will be less efficient (in the first few frames).
I don't think it takes a couple of seconds, I think I said it takes more than a frame. We keep the old tree until the next physics update. At that time we'll lock the broad phase (see BroadPhaseQuadTree::FrameSync) and wait for any query that is still ongoing. Only the broadphase query part of the navmesh generation needs to have finished by that time, after that we've collected a list of TransformedShape which we can use to query triangles without requiring additional locking. |
Beta Was this translation helpful? Give feedback.
-
Adding things in a single batch can be tricky in a general purpose engine, since other code may already rely on some state being updated right away. But I'll give it a try, maybe it's actually no problem. Though, I assume this is mostly because of internal locking and so on, right? If I call OptimizeBroadPhase, at least the runtime performance after that should not benefit from batched vs. non-batched insertion, no? |
Beta Was this translation helpful? Give feedback.
-
|
If you add bodies one at a time, the resulting tree will look like this (this was made by defining JPH_DUMP_BROADPHASE_TREE and then running FunnelTest):
After the PhysicsSystem::Update / OptimizeBroadPhase it will become a properly balanced tree:
So it's not an issue if you add 1 body at a time during initial load if you call OptimizeBroadPhase at the end (although, if you had added all bodies as a batch you wouldn't need to call OptimizeBroadPhase). It becomes a bigger problem if your game supports streaming and you need to add 1000s of bodies while the game is running. Calling OptimizeBroadPhase is not an option there (because you'll drop a frame) so collision queries and the physics update will be slow until PhysicsSystem::Update rebuilds the tree (which is at least 1 frame, but since we only update 1 tree per frame it may be more depending on the amount of trees you have). |
Beta Was this translation helpful? Give feedback.
If you add bodies one at a time, the resulting tree will look like this (this was made by defining JPH_DUMP_BROADPHASE_TREE and then running FunnelTest):
After the PhysicsSystem::Update / OptimizeBroadPhase it will become a properly balanced tree:
So it's not an issue if you add 1 body at a time during initial load if you call OptimizeBroadPhase at the end (although, if you had added all bodies as a batch you wouldn't need to call OptimizeBroadPhase).
It becomes a bigger problem if your game supports streaming and you need to add 1000s of bodies while the game is running. Calling OptimizeBroadPhase is not an option there (because you'll drop a frame) so collision queries and the physics…