[geometry] Add surface mesh, bvh, mapping and topology to SoftGeometry and SoftMesh

Previously, joemasterjohn (Joe Masterjohn) wrote…

Maybe we should save this conversation for #22069 since this PR doesn't contain any of the details of *this* algorithm (the new one) to reference in discussions. But, one subtle thing I'd want to point out first is that the new algorithm **does** work if intersecting two geometries that are tet soups. Conceptually, the boundary of an actual tet soup is well defined; it is simply every face of every tet with `num_tets` connected components. Of course, the bvh of this degenerate "surface" wouldn't provide any speedup (most likely a slowdown) over the original algorithm, but it would produce a correct surface. The new algorithm fails when asked to intersect a tet-soup with a mesh with a well-defined topology that stores the bvh of its actual surface. I'm just going to dump my thoughts about everything you brought up: The way I see the state of things right now is we have two features in production that rely on compliant vtk tet meshes having "good" topology: hydro margin and computing pressure fields for non-convex meshes. We don't currently check that the input meshes are well-behaved. We have a new algorithm on deck that provides a good (2x) speed-up in shallow penetration and a significant speedup (>10x) in deep penetration. This algorithm also depends on good topology. Parsing pressure fields from files is a proposed feature, and I'm not sure it is tied to any existing feature request or user need. I'm also not convinced that it would be a good feature to expose to users. Most users still have a hard time making the right choices from our limited set of hydro parameters for the good fields that we generate for them. I don't think they would do better with the freedom to specify the fields themselves. And, as you point out, the pressure field provided on disk would have to be *conceptually* continuous to work. That seems like an immensely complicated thing to do. Effectively, we would need to find adjacencies to check continuity across the interface of two tet faces. To be non-self-intersecting, the tets of the soup would have to intersect *exactly* at faces (non-empty, 0 volume overlap), which is almost impossible to verify using only double precision. In my experience, it is pretty rare even to see a tet soup in the wild. Most tet meshes that I've seen used in Drake come from tetwild, tetgen, or some other generating program that guarantees good topology. Tet soups also, in general, require ~6x more memory to represent a volume as compared to a connected mesh with good topology (the average valence of a vertex in a tet mesh is ~6). On the other hand, checking that an input mesh has good topology is relatively easy. I believe the correct formal requirement for input tet meshes would be: For a tet mesh M, its boundary ∂(M) should be a closed 2-manifold that is not self-intersecting. We may also want to say that we require ∂(M) to have a single connected component (because of the way we define pressure fields from maximal interior signed distance), but that isn't strictly required by any of our features. I consider all of those things relatively trivial to check. Further, having the requirement that user input meshes have good topology doesn't stop us from adding a feature for parsing a pressure field from file. Suppose the user provides a tet mesh with good topology, finite pressure values at each vertex, and 0 pressure values at each boundary vertex. In that case, it meets all the criteria of a continuous piece-wise linear pressure field that works for hydro. tl;dr - I think tet soups are bad, and we should not allow them. - We should add functionality to test that all user-input meshes have good topology to ensure our existing features always produce expected results. - Topology requirements on meshes do not stand in the way of parsing arbitrary pressure fields from file but in fact, make it easier to verify the arbitrary field is a valid hydroelastic field.

I'm happy with all that you've written. I just wanted to make sure thought was given to it. We are accumulating algorithms that require "nice" geometry with no validation of the niceness. We've already tripped over one such case (computing mass properties for a mesh that isn't so nice). It's easy to imagine that we'll have more and more landmines in the future. I just want to make sure we're clear about documenting the needs for a piece of code to work as it is intended and equally open and honest about the fact that we're not validating those requirements.

RobotLocomotion / drake

[geometry] Add surface mesh, bvh, mapping and topology to SoftGeometry and SoftMesh #22098