Using the presence of hydroelastic hint to enable rigid-deformable contact is undesirable

[xuchenhan-tri]

Currently, for a rigid geometry to be able to come into contact with a deformable geometry, it needs a surface mesh representation. To get a mesh representation for a rigid geometry from a shape description, we need a resolution hint to advise how the discretization into surface mesh should be done(except e.g. when the shape already prescribes an obj file).

As of the write up of this issue, the resolution hint information is assigned to rigid geometries via the "resolution_hint" ProximityProperties in the "hydroelastic" group, and the surface mesh representation for contact with deformable geometries is created using the same recipe/semantic for creating rigid hydroelastic surface meshes. Furthermore, the existence of the "resolution_hint" hydroelastic property is used as the sole criterion to enable the geometry to interact with deformable geometry through contact.

This "couples" deformable-rigid geometry contact with hydroelastic contacts and produces unexpected behaviors. For example, when a user switches a geometry from using hydroelastic contact to point contact (and consequently removing the "resolution_hint" hydroelastic property), the geometry will lose its ability to interact with deformable geometries. This even confuses our developers.

I would like to "decouple" deformable-rigid contact and hydroelastic contact and intend to use this issue to discuss possible solutions and track progress. However, I don't have the bandwidth to tackle this in the short term, so I'm assigning the issue to the component lead.

@rpoyner-tri @jwnimmer-tri @SeanCurtis-TRI @amcastro-tri

[xuchenhan-tri]

I'm building my reasoning on the following premises:

1. All proximity geometries should collide with each other by default.
2. Rigid geometries need a surface mesh to collide with deformable geometries. Without a surface mesh representation, a rigid geometry has no way of knowing whether it's in contact with a deformable geometry.
3. Making surface mesh from shape requires resolution hint (for most shapes).

Therefore it follows that, if a deformable geometry is present in the proximity engine, then all rigid geometries need either

1. a resolution hint, via user specification, or failing that, via a reasonable default value, or
2. a flag to opt out of deformable rigid contact.

To achieve 1, we can either create a new resolution hint property specifically for deformable-rigid contact or pull the hydro property out of the hydro group and use the same resolution hint for both hydro contact and deformable rigid contact.

[DamrongGuoy]

Related to

• 17676

[SeanCurtis-TRI]

Decoupling is nice, but we should probably also consider this problem through the lens of the "auto-hydroelasticize" efforts. It seems that many of the problems that effort was intended to address for enabling hydroelastic contact generally has a direct analogy for deformable contact. If I were to summarize the answer from that domain would be: the user shouldn't have to decorate their model for contact to happen, and should only have to tweak their model to tune as necessary.

@rpoyner-tri Is my understanding out of date? Is my application of that problem to this inappropriate?

[jwnimmer-tri]

Those lessons apply, but I think the summary already affects that.

The user shouldn't have to decorate their model for contact to happen, and should only have to tweak their model to tune as necessary.

Right. Xuchen's proposal in the second post already says that if there is no specific hint on a geometry, we would fall back to a default hint. That's consistent with how the proximity property defaults are set up in the hydroelasticate PR, and consistent with your quoted summary of the principle.

The important difference proposed in this issue vs what's on master is that "All proximity geometries should collide with each other by default." Right now on master, rigid-deformable contact is opt-in. This proposes making it opt-out.