Game Development Reference
One of the most common mistakes made with the Bullet physics engine is to as-
sume that the existence of a manifold is enough to signal a collision. This res-
ults in detecting collision events a couple of frames too early (while the objects
are still approaching one another) and detecting separation events too late (once
they've separated far enough away that they no longer pass the broad phase).
This often results in a desire to blame Bullet for being sluggish, when the fault
lies with the user's original assumptions. Be warned!
Manifolds reside within the collision dispatcher (a core Bullet object we created back
for as long as the same object pairs keep passing the broad phase. This is useful
if you want to keep querying the same contact information between pairs of objects
over time. This is where the persistent part comes in, which serves to optimize the
memory allocation process by minimizing how often the manifolds are created and
Bullet is absolutely riddled with subtle optimizations and this is just one of them.
This is all the more reason to use a known good physics solution like Bullet, in-
stead of trying to take on the world and building your own!
The manifold class in question is btPersistentManifold and we can gain ac-
cess to the manifold list through the collision dispatcher's getNumManifolds()
and getManifoldByIndexInternal() functions.
Each manifold contains a handful of different functions and member variables to
make use of, but the ones we're most interested in for now are getBody0() ,
getBody1() , and getNumContacts() . These functions return the two bodies in
the object pair that passed the broad phase, and the number of contacts detected
between them. We will use these functions to verify if a collision has actually taken
place, and send the involved objects through an event.