Problem with proximity tests for sensors with TriMesh shape

[eldyer]

Sensors with a TriMesh shape only produce intersection proximity events when objects touch its actual triangles, not when they are completely inside the sensor.

According to @sebcrozet, proximity tests could be implemented for well oriented and closed triangle meshes.

[sebcrozet]

Thanks for opening this issue @eldyer! I transferred this to the ncollide repository as this is actually due to the way proximities are computed for triangle meshes by ncollide.

Explanation for other readers of this issue: this is not considered as a bug because this is a limitation of triangle meshes (which exist on any physics engine). Triangle meshes represent only the boundary of your solid, and do not have any guarantee of even being closed nor properly oriented. Therefore it has no concept of what is “inside” or “outside”. That’s why you will only get an intersection proximity event when your objects touch the actual triangles of the triangle mesh.

The common alternative is to decompose your mesh into multiple convex components (which have an interior).

Now I find this limitation quite unfortunate too and would like to go a step further. Contact point computation is extremely difficult (and not well-defined mathematically) when another collider is fully inside a triangle mesh. On the other hand, I believe proximity tests (which is what you need if I understand correctly) could actually be done as long as your triangle mesh is well oriented and closed.

[sebcrozet]

I started addressing this issue in the proximity_inside_trimesh branch. Unfortunately, I've realized that what I did there only works when the object completely inside of the trimesh has only one connected component. Shapes with several connected components (which may happen for compound shapes, some triangle meshes, or heightfields with deleted triangles) may yield weird results. I've not found yet an efficient way of dealing with shapes with multiple connected components.