Initial implementation of parallel solvers (that have been re-added in the bullet master branch), for this video i had to disable tick and collision listeners, since they need some rework to be called in a thread safe manner without slowing down the simulation. I increased the number of brick levels from 300 to 750. (FPS limited to 60 to have a better cpu usage graph)
It runs pretty much the same as detached with single thread solver for my cpu, it might work better for cpus with more cores or maybe for different scenes, i’ll test it further, but for now it doesn’t look worth the effort.
Anyway, I’m not sure I understand how this lets you have unlimited objects unless you mean that the physics thread can slog along at 1 FPS while the visuals are still rendering at 60 FPS. At some point, you can only handle so many objects.
Of course there is no thing as unlimited objects simulation… the detached mode will allow to keep a constant (rendering) framerate while the physics update run as fast as it can, the player won’t notice if a rigidbody skips some updates, as long as it stops at the expected position and doesn’t mess with his framerate and inputs.
Bullet can also compensate slowdowns if you set a proper value for maxSubSteps.
How does the fully decoupled version deal with the controls updating the spatials?
Everything that updates the scenegraph must be called from the update loop, everything that updates the physics space must be called from the physics loop. This is already true for the parallel mode, but you can somehow get away by not doing the latter with only some jerkiness/weird behaviour as result.