Limitations of modern realtime physics engines

Please don't post Bullet support questions here, use the above forums instead.
RobW
Posts: 33
Joined: Fri Feb 01, 2008 9:44 am

Re: Limitations of modern realtime physics engines

Post by RobW »

I'll definitely have a look at that, thanks Erwin.

But if the constraints are independent, then they don't really belong to the same optimisation problem, surely? Interdependent constraints can be solved simultaneously in a Jacobi scheme because the state of the variables are buffered from the previous iteration. Sorry if I'm completely missing the point before looking at the presentation :)
One could extend the common iterative methods to solve several sections of a single island simultaneously, making sure not to have two constraints working on the same body at the same time (note: that can be difficult to do efficiently). I don't think anybody in their right mind would suggest breaking up the system constraint-by-constraint, though.
This was something I thought about, but didn't get around to trying out, sadly. The sychronisation points seemed tricky and slightly undid the effect of random constraint re-ordering.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Limitations of modern realtime physics engines

Post by Erwin Coumans »

RobW wrote:But if the constraints are independent, then they don't really belong to the same optimisation problem, surely?
Although the current (sequential) Bullet implementation splits independent constraints into islands, it is generally not a good idea when parallelizing the constraint solver. We found that parallel implementations can better ignore islands and process independent constraints in parallel in the same batch.
RobW wrote: Interdependent constraints can be solved simultaneously in a Jacobi scheme because the state of the variables are buffered from the previous iteration.
Sure, Jacobi can be trivially parallelized, but PGS/SI scheme has better convergence. Given the PGS scheme, you can re-organize constraints into batches, where constraints in the same batch don't share any moving rigid body (static objects are fine). This typically leads to around 10 sequential batches, but all constraints in the batch can be processed in parallel. So if you have one big pile of 3000 objects, all in one island, you have typically 20000 constraints, leading to around 2000 constraints spread out over 10 parallel batches. Another scenario: 3000 objects that are not touching eachother, and only resting on a ground plane. Sequential version of Bullet would create 3000 simulation islands, with a single constraint, not very good for performance. The parallel version groups them all into a single batch, that can be parallelized.

Please let me know if you have more questions, after checking Harada's slides and the Bullet Gpu2dDemo implementation I mentioned before.
RobW wrote: If for some other reason, the replay runs at a different framerate (even for a single frame) then the number of internal timesteps relative to the number of "stepSimulation"'s executed might differ, and you start to get divergence due to the gravity issue. This sounds very obscure but it certainly caused us problems and took a long while to track down!
Interesting. Do you have more details or a patch that solves this problem?

Thanks,
Erwin
Post Reply