Generated proximity meshes should include wireframes in illustration

[SeanCurtis-TRI]

Problem statement

When Drake generates meshes for proximity purposes (e.g., hydroelastic tessellations of primitives or convex hulls), the exact features of the mesh can be difficult to make out. It may be difficult for the user to assess the complexity of the derived mesh. Without a sense of the derived mesh complexity, the user is hampered in making strategic decisions in terms of controlling that resolution (and the concomitant performance).

Proposal

In addition to rendering these types of mesh strictly with faceted surfaces (#20983), highlighting the edges would provide additional insight into the mesh topology.

It is not clear how much additional insight it would give. There are arguments in favor and against this kind of approach.

• Wireframes can help call out co-planar elements.
  • However, by definition, a convex hull wouldn't have any such elements.
  • By construction, the hydroelastic representations generally don't have such elements either.
• Faces that are naturally considered polygons would be split into triangle fans.
  • This would increase the visual noise without introducing helpful data. (Particularly relevant for convex hulls.) We'd have to exert extra effort to visualize wireframes for polytopes with polygon faces.

Nevertheless, it's worth investigating if it helps increase understanding of the model.

[jwnimmer-tri]

I'll also grab one idea that's been mentioned in related: assuming the proximity mesh is correctly faceted, instead of wireframing the proximity mesh we could wireframe the contact patch. If the problem we're trying to solve is building users' intuition about the LOD in their simulated contacts, that might be a more powerful tool.

[jwnimmer-tri]

Let's prioritize #17681 first, and then we can circle back here and see if we still need this.