Misleading usage of auto-generated compliant hydro meshes with convex shapes

[SeanCurtis-TRI]

Is your feature request related to a problem? Please describe.

We've recently expanded the support for Convex shapes. A user can declare a mesh of various types (.obj, .vtk, and .gltf) and ask Drake to use its convex hull in proximity queries. We've long had a utility that would automatically create a compliant mesh for a convex shape. When you combine those two pieces of information, it seems reasonable for a user to simply declare a mesh convex and compliant hydro and expect to get a reasonable mesh for compliant hydro contact.

However, this is not the case.

The means we use to create a compliant hydro mesh for convex shapes is simple. We create a starburst of tets from a single point (the convex shape's centroid) to all of the surface triangles. This is sufficient to create a valid tetrahedral mesh and we can compute the pressure field and its gradient on that domain (1 at the centroid, 0 at the surface).

However, the suitability of that mesh and field as a compliant contact geometry depends very much on the aspect ratio and proportions of the convex shape.

In an ideal world, the gradient of the pressure field should be parallel with the surface normals near the surface of the shape. If the convex hull is close to spherical, then this is what we get. The farther from spherical it becomes, the less true it becomes.

Imagine an elongated teardrop. The centroid will be close to the "bottom" of the teardrop. The pressure field gradients will always point towards that centroid. Near the tapered end of the tear drop, the surface normals are close to perpendicular to this direction. This has several negative technical implications and one behavioral implication:

1. The tapered end of the teardrop will be very soft. It will require a huge amount of intersection to register any pressure at all.
2. Contact at the tapered end is more likely to be culled based on relative orientation between contact normals and pressure field gradients (further eliminating the accumulation of pressure).

In essence, it effectively makes the end of the tear drop disappear with respect to contact.

Although, convenient, simply declaring the shape convex and relying on Drake to create the compliant hydro representation may produce a vastly inferior result than creating one's own tetrahedral mesh (with sufficient support of interior vertices, that the pressure field better conforms to the ideal. Currently, users are unaware of this trade off. In fact, one might claim that the current state of the documentation suggests that the two avenues are equivalent.

Describe the solution you'd like At a minimum, we should be clear in the user guide about this design choice. Users should be careful if they chose to declare a mesh convex and know what kind of failure modes to look for in order to decide if they've made a good modeling choice.

Describe alternatives you've considered A better alternative would be to change the implementation of the tet mesh for convex shapes so that we more closely approximate the ideal (pressure field gradient parallel with surface normals "near" the surface). This would better match the user's intuition and allow the user to avoid the tedious (and fraught) effort to generate their own tet mesh as well as reducing the various on-disk representations of a manipuland.

There are a number of ways to create a tet mesh with the desired property. The ideal solution would be to create the medial axis and tessellate between surface and medial axis. We can introduce approximations of the medial axis which gradually reduce the quality of the pressure field (our current implementation, where we approximate the medial axis with a single point, is the extreme limit of this approach).

One possible option would be to create an interior offset surface and then tessellate in two layers: surface to offset surface and then offset surface to centroid -- although it's not entirely clear how the pressure field would be defined across those vertices.

Some medial axis line might be a reasonable approximation for a convex shape.

Again, any higher dimensional approximation of the medial axis will probably be an improvement over the current centroid approximation.

It is worth noting, that every improved approximation of the medial axis will increase the tet count over the current implementation (offering performance hits) to trade off behavior improvements.

Additional context Add any other context or screenshots about the feature request here.

[SeanCurtis-TRI]

cc @rcory

[rcory]

Fyi, @BenBurchfiel-TRI

[BenBurchfiel-TRI]

One way to balance this would be to expose a quality flag to the user. Setting quality to 0 might use a centroid, while higher values could use better medial axis approximations. The same flag could also be used for a heuristic on granularity of tet generation. It might take a little bit of tuning, but improvement here will help usability of multiple important use cases (including support for AI generated assets).

[jwnimmer-tri]

Given the CC'd audience, I assume this was motivated by practical experience from an actual simulated experiment? Can we please document that specific problematic object as evidence and as part of a victory condition -- either here, or (if it's too secret) in an Anzu issue that backlinks here?

The current description above is generic to the point of being unactionable.

[jwnimmer-tri]

Can we get any more data / examples, please?

The exposition is convincing that a single point is bad, but offers no way to know whether any given improvement is sufficient or helpful.