I'm creating a physics-based application using Bullet. I'd like to be able to switch the collision detection engine between a variety of alternatives (e.g. Bullet's collision detection, SOLID or I-COLLIDE), for benchmarking purposes.
Is there an easy way to integrate third-party collision detection into my application? Or will I just have to write wrappers consisting of new versions of the classes relating to btCollisionDispatcher?
Alternative Collision Detection
-
Erwin Coumans
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Alternative Collision Detection
It depends which level you want to integrate / replace the collision detection.
1) You can replace the entire collision pipeline, and fill in the contact details in 'btPersistentManifold' objects, just before calling the constraint solver. This can be done by deriving your custom dynamics world from btDiscreteDynamicsWorld, and implement your own mainloop (stepSimulation), reusing the bits you want. The constraint solver needs a collection of contact points between rigid bodies, for each overlapping pair those are stored in "btPersistentManifold". So you could fill in the contact points using the external collision detector, with or without contact point frame-persistence.
2) re-use the Bullet collision framework, and implement the existing interfaces for broadphase and narrowphase. This would fill some gaps, such as contact persistence and gathering multiple contacts. Some other libraries (SOLID in particular) don't provide multiple contact points. So if you would implement btSolidBroadphase and btSolidConvexConvexCollisionAlgorithm.
3) Replace only some low-level algorithms. See Bullet/Extras/ExtraSolid35 as an example how to replace Bullet's GJK sub-simplex solver, or EPA penetration depth by Solid 3.5.
Each of the 3 methods are possible. Key points are wether you want to have contact point persistency, and the ability to gather or compute multiple contact points. Bullet works fine without contact persistency, but better with -> The constraint solver stores the previous frames applied contact impulse in each contact points, for better convergence.
What method do you prefer?
Thanks,
Erwin
By the way, the open source IBDS library uses Bullet and SOLID with a different constraint solver. It adds the option to compute multiple contact points for polyhedra, for both Bullet and SOLID.
http://www.impulse-based.de/
1) You can replace the entire collision pipeline, and fill in the contact details in 'btPersistentManifold' objects, just before calling the constraint solver. This can be done by deriving your custom dynamics world from btDiscreteDynamicsWorld, and implement your own mainloop (stepSimulation), reusing the bits you want. The constraint solver needs a collection of contact points between rigid bodies, for each overlapping pair those are stored in "btPersistentManifold". So you could fill in the contact points using the external collision detector, with or without contact point frame-persistence.
2) re-use the Bullet collision framework, and implement the existing interfaces for broadphase and narrowphase. This would fill some gaps, such as contact persistence and gathering multiple contacts. Some other libraries (SOLID in particular) don't provide multiple contact points. So if you would implement btSolidBroadphase and btSolidConvexConvexCollisionAlgorithm.
3) Replace only some low-level algorithms. See Bullet/Extras/ExtraSolid35 as an example how to replace Bullet's GJK sub-simplex solver, or EPA penetration depth by Solid 3.5.
Each of the 3 methods are possible. Key points are wether you want to have contact point persistency, and the ability to gather or compute multiple contact points. Bullet works fine without contact persistency, but better with -> The constraint solver stores the previous frames applied contact impulse in each contact points, for better convergence.
What method do you prefer?
Thanks,
Erwin
By the way, the open source IBDS library uses Bullet and SOLID with a different constraint solver. It adds the option to compute multiple contact points for polyhedra, for both Bullet and SOLID.
http://www.impulse-based.de/
-
console
- Posts: 18
- Joined: Thu Sep 04, 2008 10:25 am
Re: Alternative Collision Detection
Thanks for the information.
I think I'll go with the first option. I'm benchmarking the collision detection engines for research purposes, and I think I'd probably be misrepresenting their execution times with the other options.
I think I'll go with the first option. I'm benchmarking the collision detection engines for research purposes, and I think I'd probably be misrepresenting their execution times with the other options.