Proximity Engine needs better rigid geometry categorization

[xuchenhan-tri]

17644 introduces a new type of contact into ProximityEngine -- the contact between a rigid (non-deformable) geometry and a deformable geometry. In the future, we intend to introduce yet a another type of contact -- one between two deformable geometries. Currently we call these contact "deformable contact".

With this, there are now three types of contact supported by ProximityEngine:

1. point contact,
2. hydroelastic contact.
3. deformable contact,

and two mutually exclusive sets of geometries:

a. rigid (non-deformable) geometries, and b. deformable geometries.

Deformable geometries are relatively straightforward at the moment because they only have a single representation and they only participate in deformable contact. Rigid geometries on the other hand, can participate in none, some, or all of the three types of contact. As a consequence, they can assume multiple representations all at once. The choices include:

1. a point contact representation (stored as an FCL collision object in ProximityEngine),
2. a rigid or compliant hydroelastic representation (stored as a surface mesh (or half space) for rigid or a volume mesh for compliant in an hydroelastic::Geometries object owned by ProximityEngine),
3. a rigid representation for deformable contact (stored as a surface mesh in deformable::Geometries object owned by ProximityEngine).

These representations are not mutually exclusive, and the logic that determines which representation a rigid geometry owns is complicated.

• Each rigid geometry registered in a ProximityEngine gets a point contact representation.
• If the geometry has proper rigid hydroelastic proximity properties, then it also has a rigid hydroelastic representation.
• If the geometry has proper compliant hydroelastic proximity properties, and is supported by the hydroelastic engine as a compliant shape, then it also has a compliant hydroelastic representation.
• If the geometry has a proper resolution hint proximity property, and is supported by the deformable contact engine, then it also has a representation for deformable contact.

It is worth noting that the supported rigid representation for deformable contact is currently exactly the same as rigid hydroelastics, but the data are duplicated in hydroelastic::Geometries and deformable::Geometries.

The request is to organize these representations to cut down duplication and the potential confusion that results from it. Concrete action items involve potentially

1. renaming "deformable contact" as it may also involve rigid geometries, and reconsider the name of the internal class deformable::Geometries, which, again, may contain rigid geometries.
2. unifying rigid representations for hydroelastics and for "deformable contact" due their extreme similarity. (This would involve supporting contact between rigid half space and deformable geometries.)
3. Sometimes it's redundant to ask a rigid geometry to have a proper resolution hint property to enable its deformable contact representation. For example, we can trivially get a surface mesh representation from Shape Mesh. The resolution hint parameter is irrelevant. It is merely used as a signal for "this geometry should participate in deformable contact".

[SeanCurtis-TRI]

Some thing to keep in mind:

• Currently, the surface mesh representation of rigid geometries for both hydroelastic and deformable contact are identical. Do we intend that to be the case forever? Can we imagine circumstances where it would make sense to have them at different resolutions?
• Is the assertion that they are identical true? As I understand it, the presence of a resolution_hint property is enough to trigger the deformable contact system to generate a surface mesh for the corresponding geometry. What if that geometry is compliant hydroelastic? Then there is both a VolumeMesh and a SurfaceMesh for the same geometry id.
• Can we anticipate multiple representations per geometry id? Do we anticipate in the future that we'll ever do contact between a deformable geometry and a compliant (volume) hydroelastic mesh and not the surface mesh?

Perhaps others....

[xuchenhan-tri]

As I understand it, the presence of a resolution_hint property is enough to trigger the deformable contact system to generate a surface mesh for the corresponding geometry. What if that geometry is compliant hydroelastic? Then there is both a VolumeMesh and a SurfaceMesh for the same geometry id.

Yes, that is correct.

As for the other two points you raised, my best guess is, not likely but not unimaginable. As much as I like flexibility and generality, I'd choose simplicity over generality that may or may not be useful (that is, of course, if we have to choose).

[xuchenhan-tri]

I just got bitten with another related issue when it comes to ProximityEngine and deformables.

When adding geometries to ProximityEngine, we automatically apply certain collision filters to geometries that are registered under the same frame. The assumption behind this default collision filter needs a revisit now that we start to support deformable geometries -- only rigid (non-deformable) geometries registered with the same frame are guaranteed to be collision free.

Since deformable geometries are required registered with the world frame at the moment (see here), the symptom currently is that collisions between deformable geometries and anchored geometries are silently and incorrectly ignored.

[rpoyner-tri]

Related to @xuchenhan-tri 's last comment -- mbp/mbt make some similar assumptions that everything is more-or-less rigid. See for example https://github.com/RobotLocomotion/drake/blob/master/multibody/plant/multibody_plant.cc#L1096-L1110 .

[SeanCurtis-TRI]

collisions between deformable geometries and anchored geometries are silently and incorrectly ignored.

This slightly surprises me. Which code is invoking the collision filter check? As I look at deformable_context_internal.cc, I see the two nested loops of the set of all deformables against the set of all rigid (representations). When does the filtering happen?

[xuchenhan-tri]

collisions between deformable geometries and anchored geometries are silently and incorrectly ignored.

Sorry, I got ahead of myself. I should have said that it is the "would-be" symptom if and when we apply the collision filtering infrastructure that we have at the moment to deformable contact.

[xuchenhan-tri]

@rpoyner-tri thanks for the reference.

The headache in geometry namespace mostly comes from me trying to reconcile deformable geometries with many existing assumptions that all geometries are rigid. I'm less worried about MbP level of things because we took a different approach there. Instead of trying to fit deformable bodies into MbP, we (at least try to) keep everything deformable related in the a separate data structure, DeformableModel.

[DamrongGuoy]

I am reviewing related code and keeping this G-Doc. I don't know how to grant public access. Please feel free to make an access request if it blocks you.