As a rule of thumb performance wise you’ll want to stick to using as simple collision shapes as possible, boxes spheres etc. A whole polygon mesh shape will be really heavy.

Hello Matti,

Thanks for Your reply !

I hope You might answer one more question.. I’m probably not going to use more than 100 objects .. Do You still think it is to slow even if I will try to use the part of bullet that is using OpenCL for the collision detection ?

Should I go for PhysX by NVidia instead ? .. It would be good to not have dependencies to nvidia graphics cards..

Best Regards
Fredrik

Number of (active) collision shapes & their complexity is what build the CPU strain of the process, obviously – so, use as simple collision shapes as possible (you can use combinations to represent more complex objects) and only include the shapes you need in the calculations; if some objects are far away from the “action”, just remove them from the list of active shapes and save some calculation power. I would suggest asking this on the Bullet Forums as they are the right people to discuss this with. My experience with it is limited to a single mobile app [777-team.org] where I used a multithreaded approach to do the physics calculations in a separate thread, using some 8-50 box collision shapes at once. I have no experience in PhysX nor have no idea how much complexity can a gaming PC handle, for instance.

- M