Spent the past few days banging my head against a brick wall with ghost objects, and now that I understand what's going on better, hopefully I can explain my problems.
btManifoldArray manifoldArray;
btBroadphasePairArray& pairArray = ghostObject->getOverlappingPairCache()->getOverlappingPairArray();
int numPairs = pairArray.size();
for (int i=0;i<numPairs;i++)
{
manifoldArray.clear();
const btBroadphasePair& pair = pairArray[i];
//unless we manually perform collision detection on this pair, the contacts are in the dynamics world paircache:
btBroadphasePair* collisionPair = dynamicsWorld->getPairCache()->findPair(pair.m_pProxy0,pair.m_pProxy1);
if (!collisionPair)
continue;
if (collisionPair->m_algorithm)
collisionPair->m_algorithm->getAllContactManifolds(manifoldArray);
for (int j=0;j<manifoldArray.size();j++)
{
btPersistentManifold* manifold = manifoldArray[j];
// [A]
btScalar directionSign = manifold->getBody0() == m_ghostObject ? btScalar(-1.0) : btScalar(1.0);
for (int p=0;p<manifold->getNumContacts();p++)
{
const btManifoldPoint&pt = manifold->getContactPoint(p);
if (pt.getDistance()<0.f)
{
// [B]
}
}
}
}
If I work in , then it reports precise collisions with the ghost object. Great. But the problem is, that it only reports collisions if the rigid body is colliding with the edge of the ghost object - as soon as the rigid body is fully submerged in the area trigger, it stops reporting.
[A] is reporting all the time, so great, I can use that to detect whether objects are inside the ghost object. But nope, bad, only checks against AABB (I want it to be accurate).
Secondly, why even iterate over the contacts and check the distance anyway? I tested this on a mobile device and performance completely dies, but it's fine if I just check if the number of contacts is > 0.
Finally, I'm trying to get all this to work with reporting Enter and Leave callbacks - it's not a problem if I use the [A] method, since then a list comparison is easy. But if I use , due to no distinction between Enter and Leave and lack of a callback when submerged, if an object is spawned already inside an area trigger, then when it leaves it thinks it entered vice versa.
Someone please prevent me from ripping my hair out.
I've also considered doing (numContacts > 0) as opposed to checking their distances, though from some testing I've found that sometimes contact points have a positive distance, which means they do not actually represent a shape overlap. This seems to occur for a very short time when objects are moving apart; perhaps a delay to keep the contact points around for efficiency in case the objects are oscillating close to each other and contact points would otherwise be generated and destroyed excessively. Still, checking numContacts>0 seems to be a pretty good approximation, just not quite as precise as ensuring their distances are less than 0.
As for not registering collisions when one shape is fully inside another, I'm guessing you are using a concave shape for your ghost, in which case this is intended/standard behaviour. This is because convex shapes have some nice properties allowing one to clearly define what constitutes the "inside" vs "outside" of the shape, while concave shapes (in general) don't. So if you need to know if your shape completely engulfs another one, it will have to be convex. You can do this either by choosing one of the convex primitive shapes available if one suits your needs, or by constructing a compound shape from convex shapes that together approximate your desired shape. One way to do this automatically is to use the HACD decomposition utility that is included with the Bullet package. This decomposes arbitrary meshes into convex hulls which can then be combined into a btCompoundShape. Flix has been kind enough to provide code for using HACD with Bullet in this way: http://bulletphysics.org/Bullet/phpBB3/ ... ACD#p24568
Thanks for your reply dphil, much appreciated. As you pointed out it was indeed because the ghost was using a concave shape - not intentionally I have to be honest, I assumed all my ghost shapes were convex, but obviously not
Hmm, the (> 0) check looks spot on visually, but I see what you mean. I guess the distance check is fine if you're not targeting mobiles (or consoles perhaps), because it's pretty expensive.
Glad to help. On a related note, another theory I had about the rarely seen positive contact point distances was if the shape margins - but not the shapes themselves - are overlapping. These margins are typically very thin. Not sure though. Maybe someone else has figured it out and can enlighten us .
