preparing for 2.82 release

[Erwin Coumans]

Yes, the new Bullet 2.82 is available now: http://www.bulletphysics.org/Bullet/php ... =18&t=9496

[Antonz]

Cg is not generic enough to develop general purpose collision detection and constraint solver. You could use Cg for a simplified implementation.

What do you mean by "architecture free"? OpenCL works on NVIDIA, AMD and Intel GPUs on all operating systems.

What about Android? There is reports on Internet that Google screwed its support completely starting from 4.3 . And it needs some rather level runtime (probably kernel mode driver) to work, right?

Also, can anyone make a small summary on those new solvers (especially all those MLCP variants) for those who are not very advanced in this field - what their benefits and drawbacks, for what types of simulations they are better prepared? I'm playing with Fork Lift demo now and see the minor difference between MLCP solver and Sequential Impulse, if any. It seems that MLCP is less bouncy when I'm rising and lowering lift with a table on it. I have read some discussions on this topic here on forum: it seems that MLCP with Dantzig is a lot heavier but can be more precise (but also in some times doesn't give a result in which case a fallback iterative solver will be used - so it's a worst case scenario for performance).

[Erwin Coumans]

What about Android?

Forget about Android: Google and in particular Tim Murray (who is working on Renderscript at Google, and ex-NVIDIA employee from the CUDA team) is actively blocking OpenCL, because they try to push Renderscript, despite the fact that Qualcomm and ARM and other mobile driver developers are willing to provide the OpenCL implementation.

Also, can anyone make a small summary on those new solvers (especially all those MLCP variants) for those who are not very advanced in this field - what their benefits and drawbacks, for what types of simulations they are better prepared?

Download the updated Bullet 2.82 release, revision 2704, and try the latest Forklift demo. The mass of the load is now 100kg, and the iterative solver doesn't deal with it well.

Right now, the default btSequentialImpulseConstraintSolver is most suitable for gaming. If quality is more important then performance, and you don't have large scale worlds, once of the MLCP solvers could be better. Robotics simulation could benefit from Featherstone and/or direct MLCP solvers. In the future, we will look into using the MLCP solver for part of the simulation, while using a faster solver for the rest.

[Antonz]

What about Android?

Forget about Android: Google and in particular Tim Murray (who is working on Renderscript at Google, and ex-NVIDIA employee from the CUDA team) is actively blocking OpenCL, because they try to push Renderscript, despite the fact that Qualcomm and ARM and other mobile driver developers are willing to provide the OpenCL implementation.

The problem is that we are developing multi-platform game and Android is one of our platforms. But thanks for this information anyway, we will stay on Bullet 2.x then even when 3.x will be released until Google changes their minds (or maybe someone buys them ).

Right now, the default btSequentialImpulseConstraintSolver is most suitable for gaming.

Thanks for information. Does MLCP also much slower in scenario where's there's only 1-3 dynamic spheres that collide with static and convex dynamic/kinematic meshes and each other? Well, I'll benchmark it anyway. Also, MLCP (specifically Dantzig) workload is flat or spiky in terms of consumed CPU time? I mean, are there some internal steps that can take up variable number of iterations?

[Basroil]

If quality is more important then performance, and you don't have large scale worlds, once of the MLCP solvers could be better. Robotics simulation could benefit from Featherstone and/or direct MLCP solvers. In the future, we will look into using the MLCP solver for part of the simulation, while using a faster solver for the rest.

I just added MLCP (I think, can't be 100% sure it works, but seems like it does) to the dynamic control demo using code from the forklift demo. When you put 10x gravity it actually improves quality quite a bit at default settings (even better at higher gravity or with large mass differences), though sequential impulse is almost as effective when you consider that you can use 20x the fps in the same execution time. Even so, it will greatly improve bullet for robotics, and I wish my hands were all thumbs for more thumbs ups!

It seems that there are only a few optimizations currently in the MLCP code (debug time vs release is small), is that planned at some time or even possible/necessary? Sadly I'm not as well versed in optimizations as I would like to be, and it is going to take me a long while just to make sense of the code for MLCP and the solvers (lot of abbreviated variable names, especially matrix/vector values, not to mention several thousand line of code). I did find a memory copy vs loop speed option in dantzigLCP, but I keep getting an error on line 1622 where btLDLTRemove seems to be trying to pass a btScalar * const where it asks for btScalar **. Is that an actual error or is it just me screwing up something?

MLCP also much slower in scenario where's there's only 1-3 dynamic spheres that collide with static and convex dynamic/kinematic meshes and each other? Well, I'll benchmark it anyway. Also, MLCP (specifically Dantzig) workload is flat or spiky in terms of consumed CPU time?

I've seen spikes in performance, but generally around 3-5ms for the dynamic control demo (reduced to 4 legs). That's quite a bit more than the 0.2 or less a SI round takes, but the increase in frame time when debugging isn't as large (~2x as opposed to ~15x) and you can increase gravity or mass ratios to flat out ridiculous levels without issue.