Help me with contactTest

[MaxDZ8]

I am still using 2.78.
In my game, I have an object which spawns other entities. Those spawned entities are kinematic actors.
Because I don't want to decouple their graphics from their physics too much and I don't want them to just pop out. I've set up my "spawner" mesh to provide a "spawn point" which is inside the graphics mesh, as well as the physics hull.

The next step to make the spawned actor work is to allow it to be sweeped out of the spawner mesh.
To do so, I've provided a special functionality which selectively ignores certain rigid bodies when sweeping the kinematic actor. Problem is when populating this list, the results don't match what I expect. My current filter is

Code: Select all

struct ContactSet : btCollisionWorld::ContactResultCallback {
	std::map<const btCollisionObject*, TouchInfo> touches;
	btRigidBody *you;
	btScalar addSingleResult(btManifoldPoint &cp, const btCollisionObject *colObj0, int partId0, int index0, const btCollisionObject *colObj1, int partId1, int index1) {
	if(cp.getDistance() > .0f && you == colObj0) return 1.0f; // not touching
	if(cp.getDistance() < .0f && you == colObj1) return 1.0f; // not touching
	if(touches.find(colObj1) != touches.cend()) return 1.0f; // already stored one, not interesting.
		TouchInfo add;
		for(asizei loop = 0; loop < 3; loop++) add.encroaching[loop] = cp.m_normalWorldOnB[loop] * cp.getDistance();
		for(asizei loop = 0; loop < 3; loop++) add.normal[loop] = cp.m_normalWorldOnB[loop];
		add.otherHandle = colObj1; // id is not relevant here
		for(asizei loop = 0; loop < 3; loop++) add.pointOther[loop] = cp.getPositionWorldOnB()[loop];
		for(asizei loop = 0; loop < 3; loop++) add.pointYou[loop] = cp.getPositionWorldOnA()[loop];
		add.world = false; // not relevant anyway!
		touches.insert(std::make_pair(add.otherHandle, add));
		return 1.0f;
	}
};

This works fine in one important case but when it comes to the context above, it fails. The spawned object (a sphere) is indeed colObj0 but has a >0 distance. I think that's what's happening.

CompletelyEncroached.png

In other words, the distance vector is computed from the sphere and it's correctly reported positive as it "points out", however it doesn't take in consideration the sphere is completely inside.
By another point of view, the bounduary of the hull is considered "bidirectional" and does not influence the direction of the encroaching distance.

It should really be the other way around instead: either being inside shall negate encroach distance or ... better idea... the manifold should be owned by the hull... but I guess this wouldn't make much sense.
So, I need:

• A quick recap at my understanding of manifold points (because I'm no more sure I got them right)
• Do you think the above analysis is correct / makes sense?
• How would you fix/troubleshoot this problem?

[MaxDZ8]

After quite some grief, I've isolated the data involved in the previous tests to a minimal example.
Here is some output.

Code: Select all

--Redacted--
See update note.

So far, it was my understanding btManifoldPoint was basically a "touch" vector from point A to point B, with distance being positive (A-->B) when B is near A and negative when B is inside A.
This meant if I wanted to consider (A<--B) instead, I'd have to consider its inverse sign.
As a consequence, I've always assumed if distance is positive a sweep would have no hits.

As above, this does not seems to be correct.

Is there anyone able to help me? I can post source.

UPDATE: it appears my compiler got super-lazy today, it has always been running an old executable. A clean build apparently fixed this problem but I'm still investigating this behavior. Anyway, the posted values are not valid anymore.

[MaxDZ8]

An update for anyone which might be having similar issues in the future.
It turns out that the bug was in the export process for this specific asset.
Because of the way the collision shape was generated, it would happen to be rotated 90 degrees. This obviously produced different results and since my debug collision drawer is really cheap, it was hard to spot the problem.