BoxBoxCollider is not commutative

[felix-ri]

I have an error with 2 kinematic entities, that have the CollisionRule.NoSolver.
I want to know, if they intersect or not. For that, I check the entity.CollisionInformation.Pairs.
It sometimes gives false negatives.
I found out that the BoxBoxCollider.AreBoxesColliding() wasn't detecting the collision.
It produces a different result when the parameters are switched.
Here is a sample code:
https://gist.github.com/felix-ri/9cca08a4970572d82cf1e351707aa30e

[RossNordby]

Noncommutativity is expected due to tiny numerical differences when the collision is at numerical limits.

Here, though, there's an added problem of edge candidate axes being almost aligned and causing a numerical error severe enough that an obvious penetration gets ignored. That's a bug.

A quick workaround would be to replace the BoxBox handler in the NarrowPhaseHelper. Change https://github.com/bepu/bepuphysics1/blob/master/BEPUphysics/NarrowPhaseSystems/NarrowPhaseHelper.cs#L20 and https://github.com/bepu/bepuphysics1/blob/master/BEPUphysics/NarrowPhaseSystems/NarrowPhaseHelper.cs#L155 to use GeneralConvexPairHandler rather than BoxPairHandler.

That won't fix the BoxBoxCollider itself, of course, but if you're looking up values in the Pairs set, it'll use the convex-convex handler instead of the BoxBoxCollider.

Fixing the BoxBoxCollider itself would also be doable, but pretty annoying. I'd like to avoid spending that much time on v1.

[RossNordby]

It would only be necessary on the edge-edge tests (A.X x B.X, A.X x B.Y ...), since they're the only ones capable of being non-unit length.

For reference, rarb here can be thought of as 'summed extent of boxes along axis candidate', where the given axis candidate is not necessarily unit length. It works as a boolen test outside of numerical corner cases because the tl value (which is 'translation between boxes along axis candidate) is operating in the same scale.

Unfortunately, because the edge-edge tests have non-unit length candidates, using a fixed epsilon against the equivalent abs(translation - spanAlongAxis) value isn't quite enough. Small values can be created either by low magnitude axes, or by small boxes. A fixed epsilon would not distinguish the two cases.

This could be worked around:

• Scale the epsilon by an approximation of the shape sizes, so the epsilon would be working primarily on the axis-scaled penetration depth along the axis, or
• Explicitly compute the length squared of the edge-edge axis candidate created from the cross product, and if the magnitude is too small (dot(axis, axis) < epsilon), don't consider the candidate. This avoids any concern around shape scales since the axes being crossed are both known to be unit length since they're pulled from the shapes' orthonormal rotation matrices.

Because I assume, that changing to GeneralConvexPairHandler would have a bigger performance impact than adding these checks.

It's been a while since I've benchmarked anything in v1, but that might be worth checking before doing any significant work. The difference definitely isn't as large as the gap between box-box and hull-hull in v2.

[felix-ri]

I tried out the GeneralConvexPairHandler, but it not only had a performance impact, the Simulation also got less stable. (towers previously standing tall are collapsing now).

The Second workaround with the comparision of edges seems sensible to me. Did I understand this correctly:
If the normal-normal phase did not find a separation and an edge-edge case has parallel edges, we can assume, that there is no separation in this edge-edge case?

This seemed to work. Is that, what you had in mind? I'm still not sure if I indexed the Matrix correctly.
Or should I really do a full dotproduct of the forward/right... vectors of the Matrix with the UnitVectors?

            //Now for the edge-edge cases.
            //A.X x B.X
            ra = aY * absBR.M31 + aZ * absBR.M21;
            rb = bY * absBR.M13 + bZ * absBR.M12;

            if (Math.Abs(Math.Abs(bR.M11) - 1) <= .000001f)
            {
                if (Math.Abs(t.Z * bR.M21 - t.Y * bR.M31) > ra + rb)
                {
                    return false;
                }
            }

            //A.X x B.Y
            ra = aY * absBR.M32 + aZ * absBR.M22;
            rb = bX * absBR.M13 + bZ * absBR.M11;
            if (Math.Abs(Math.Abs(bR.M21) - 1) <= .000001f)
            {
                if (Math.Abs(t.Z * bR.M22 - t.Y * bR.M32) > ra + rb)
                {
                    return false;
                }
            }

            //A.X x B.Z
            ra = aY * absBR.M33 + aZ * absBR.M23;
            rb = bX * absBR.M12 + bY * absBR.M11;
            if (Math.Abs(Math.Abs(bR.M31) - 1) <= .000001f)
            {
                if (Math.Abs(t.Z * bR.M23 - t.Y * bR.M33) > ra + rb)
                {
                    return false;
                }
            }

[RossNordby]

Did I understand this correctly:
If the normal-normal phase did not find a separation and an edge-edge case has parallel edges, we can assume, that there is no separation in this edge-edge case?

Yup. Another axis candidate will find the separation if there is any. Unless I'm forgetting something :P

This seemed to work. Is that, what you had in mind?

Pretty close. You could compare the absBR.M__ > 1 - epilson to simplify the condition a bit. Notably the absBR matrix already includes a failed attempt at dealing with this issue from years past, apparently- if you use the absBR you may want to remove the epsilons added to its components. Can't remember much of my intent from a decade+ ago, but I think that's right.

The indexing looks correct. The first element of the row is associated with the X component of each basis vector. So, that condition checks if the basis vector from B being used is parallel with the A-local X axis, which is what you want for the AX x () tests.

[felix-ri]

I removed the Epsilons from the absBR and used the checks if(absBR.M__ < 1 - Toolbox.Epsilon){ //do the actual check }
It worked, but I got a case, where it signalled a Collision, but did not return any contacts.
I readded the Epsilons and changed the check to if(absBR.M__ < 1 ){ //do the actual check } and now it returned contacts again.
It seems, that the contact generation needs these Epsilons

[RossNordby]

Guess me circa 2010 had some reason :P