Running physics separately from the main game loop

[Frooxius]

Hello!

I've got another question. I've seen a few references around running the physics engine separately from the main game loop at fixed rate and it's something I'm considering for integration as well. Although I'm leaning more towards doing it in sync with the main game loop instead, I want to get a bit better understanding on how some things work or how they would be approached for something like this if that's ok!

If it was running fully separately, the body transforms have to be interpolated or extrapolated to ensure they remain smooth with differing tick rates. With the low level design of BEPUv2 I figure this is completely on the integration side. I remember BEPUv1 had some helpers for buffering the states, but I don't think that's present here.

However one main thing I'm not certain if I understand correctly are queries - raycasts and sweeps. Those typically happen from the main game loop, but with the asynchronous run, the physics can be mid-update, so I assume it's not safe to execute them this way.

Would the correct approach there be to collect all the raycasts and sweeps in the game loop and then schedule to run them in the physics update loop and then sync the results back with the main game loop?

Or is there a way to run the queries safely from another thread, even if the physics engine is currently executing a timestep?

I'm just trying to get a more general understanding, so I don't need too many details on the implementation, but more just trying to get a good "angle of attack" for these things if that makes sense!

[RossNordby]

With the low level design of BEPUv2 I figure this is completely on the integration side. I remember BEPUv1 had some helpers for buffering the states, but I don't think that's present here.

Correct.

However one main thing I'm not certain if I understand correctly are queries - raycasts and sweeps. Those typically happen from the main game loop, but with the asynchronous run, the physics can be mid-update, so I assume it's not safe to execute them this way.

Yup.

Would the correct approach there be to collect all the raycasts and sweeps in the game loop and then schedule to run them in the physics update loop and then sync the results back with the main game loop?

Yup, some kind of message passing and deferred handling would probably be best.

Given that simulation and game logic tend to interact a lot, I typically advise against running them asynchronously from each other. It's doable, but there's all kinds of annoyances involved like this, with tons of opportunities for difficult to detect and debug oopsies.

If the goal is to decouple rendering rate from simulation rate, I usually recommend making the cut on the graphics side. The accessed surface from game logic to graphics is usually smaller than game logic to physics, or at least can be made smaller.

For what it's worth, in my internal projects, I've come to favor splitting things into three asynchronous timestreams:

1. High frequency input: events are pumped aggressively, and any modifications to latency-sensitive state are handled ASAP. Camera state gets uploaded to a GPU-visible ring buffer potentially thousands of times a second.
2. Logical updates: covers application/game logic and simulation. Easy queries and state accesses since they're sequentialized. Each heavy system on the logical update timestream is internally multithreaded. Performs any scene-dependent non-graphics-API related rendering work too, then uploads the rendering state into a GPU-visible ring buffer.
3. Graphics: calls the graphics API. All rendering is built to be GPU-driven, so the CPU-created command buffers submitted are extremely small and are almost entirely independent of what's in the scene. The GPU is responsible for interpolating/extrapolating render states, so the GPU can run at 144hz while the CPU is only submitting 30hz updates and everything's still smooth.

[Frooxius]

Ah thank you so much for the detailed info! This makes a lot of sense.

I think I'll stick with running it as part of the main game loop. Adding deferred query batching would really complicate the code, especially when it does multiple probing queries (e.g. do a raycast to figure out where something is, then do more raycasts around it).

I might do some updates in parallel with stages that are known to run any physics queries, but that's it. Doing separation at the graphics part (or perhaps even some parts of logic that run at higher rate) seems like a much better idea.