WIP: Async physics
Perform the physics update asynchronously.
Roughly, main thread push to the task scheduler the actors' movement queue and fetch the actors' new position from previous frame. That means that there is an additional frame difference between what is rendered and where the actors really are.
It is relatively playable, with caveats:
the movement speed is not correct, and not constant (it is lightly "pulsating"). I think it is becauseIt seems I was just hallucinating
PhysicsSystem::mTimeAccumshould take into account the time it took to do the simulation, and not only the time between push and fetch.
there are unresolved races - might crashit should not :)
- for the engine subsystems that use physics data (projectiles, ai pathfinding) I opted to interrupt the background physics thread and use whatever state the collision world is in. That means that 2 consecutives calls to eg.
castRaybetween the same objects can give 2 differents results. If "something" rely on that it might become broken.
Apart from that, it is just an extension of !215
To test, just set the
solver num threads (I should rename that to 'async threads' btw)
- 0 means sequential
- 1+ means async In case Bullet doesn't support multithreading, 1+ will be set treated as 1
Sequential was not tested at all.
Bullet with singlethread only lightly (without TSAN). Almost completely clean traces.