Incorrect contact point computation of mesh-mesh collision

[jslee02]

Here is a simple test to show the incorrect contact point computation in mesh-mesh collision I mentioned in #97.

In the test, there are two meshes generated from Box as shown in below figure (rendered by DART). The two meshes are in face contact. We would expect four contact points should be at the four corners of the face of green box touching with the red box (or at least not out of the face). However, the results showed that the contact points (small blue spheres in the figure) are more than four (30 points and some of them are duplicates) and even placed at the corner of the red box. This is the result I got on my computer.

It seems that contact points are always placed at the vertices of mesh triangles rather than the exact contact point of the two colliding triangles.

This bug is crucial and easily results in unrealistic behavior in dynamics simulation. For example, the yellow box in the below figure is hanging in the air because of the ghost contact points at the right bottom corners.

[sherm1]

Very convincing! Is this specific to box primitives or does it apply in general to contact points for any meshes?

[jslee02]

I believe (without proof) this is not specific to box primitives (to clarify, mesh generated from box was tested rather than the original box primitive), but this is more noticeable when the triangle is big. For box mesh case, each triangle is the half size of the square face.

Here is another quick test of box-cylinder meshes.

There is a weird contact point at the middle of the yellow cylinder. It seems the three contact points are the vertices of one triangle of the yellow cylinder colliding with the red box, and the weird contact point is reported only because it's on the triangle.

[anna-seppala]

Has somebody worked on fixing this issue? I have similar problems when generating contact points for two OT_BVH objects with BV_OBBRSS node type; many of the contact points are duplicates and some are wildly scattered around the two objects in collision. That being said, I have not pulled the newest changes on but am working on a forked project from some time ago.

[jslee02]

I believe no one is working on this issue (at least I'm not).

[a-price]

Has there been any progress on this issue?

[a-price]

One (possibly the?) issue seems to happen around line 820 of intersect-inl.h. For the case of co-planar triangles, where both penetration depths are zero, the algorithm just returns the vertices of whichever triangle was passed in first.

[JenniferBuehler]

I was actually going to look into this soon, but probably won't get to it before in a couple of weeks time... if there hasn't been any resolution of this until then, I'll be posting here. Will follow your lead of line 820, thanks for sharing

[a-price]

I've forked a copy and added a coplanar triangle test to the issue106 branch there, which is able to reproduce the error.

One potential fix would be to handle coplanar triangles separately, returning up to 6 contact points rather than the 2 in the current setting. I suspect there's still going to be a problem with non-coplanar triangles when the penetration depths are equal, but maybe the ambiguity there is fine. Is there a design document somewhere, other than the 2012 ICRA paper? Or a reference for the triangle-triangle algorithm currently implemented?

[Moult]

Just posting a +1 that I have been able to replicate this issue with Python-fcl. Well, sort of.

This shows my attempt to recreate the original screenshot. It looks OK to me:

In this scenario, however, I start getting contact points in strange locations:

[SeanCurtis-TRI]

This long standing issue seems to crop up regularly. Probably time it gets a little love.

[sherm1]

Yeah, I guess 4 1/2 years is sufficient aging!

FYI @rpoyner-tri