Callback/State reading for BroadPhase Rebuild

[MohitSethi99]

Am I missing something or Jolt doesn't provide a callback or any way to read the state of BroadPhase rebuilding. It would be great to have a callback or something like a method that returns a bool that if BroadPhase has been rebuild or still in process as It takes quite a few frames while it builds it.

[jrouwe]

What is the issue you're trying to solve? I see the broadphase rebuild as an implementation detail that does not really affect any of the API calls you make. You can get false positive hits if you do a broadphase only query, but this normally only leads to a bit of extra work in the narrow phase. All other APIs should be identical regardless if the broadphase is building or not (which only happens during PhysicsSystem::Update btw).

[MohitSethi99]

BroadPhase updating takes a few frames so I was thinking to do it before simulating anything (like a pre-physics update pass). So I can spend some time on loading screen or whatever and then start the simulation. But if BroadPhase updation happens during PhysicsSystem::Update, I don't think there is a direct way I can do that. Maybe doing the simulation to update braodphase (load time) and resetting the state somehow and then simulating it again?

[jrouwe]

If you're coming from the loading screen, I would recommend calling PhysicsSystem::OptimizeBroadPhase after everything is loaded and before the first game update. This call can be done from another thread if it turns out that the optimize call causes a frame drop in the loading screen. After this call returns, the broadphase will have finished its update.

[MohitSethi99]

https://user-images.githubusercontent.com/29519295/192092888-2b44b33a-fc9d-4ceb-b020-76131ae4f516.mp4

Setup: 1 static ground, 100 dynamic bodies (they're coinciding, don't know if that's the problem). System configuration: i9 11950H, 32GB DDR4, RTX 3080 Have 15 threads assigned to Jolt

I added OptimizeBroadPhase call before update but my framerate seems to drop significantly for first few frames.

[MohitSethi99]

That was it, the issue was with coinciding bodies, Profiled with optick, solving position constraints was taking most of the time til all the bodies were not coinciding with each other. Here is a small test with 289 (17x17) cube grid. Closing the issue. Thanks :)

https://user-images.githubusercontent.com/29519295/192094647-4455b9b3-b0f3-488c-9fee-10113c76a2bf.mp4

[jrouwe]

Good to hear you fixed it! You should indeed take care not to have many bodies start at the same position. This will effectively reduce the physics simulation to a single threaded simulation and it will also add a ton of extra work in collision detection and penetration resolution.