Open DamrongGuoy opened 2 weeks ago
@SeanCurtis-TRI possibly this is worth a quick read-through this morning, to see if you have any questions to ask today.
The end user API proposal was #21471. I believe the new footnote (c) speaks to this topic?
One point of clarification and one of elaboration.
Elaboration: my comment about the fact that the DistanceToPoint
infrastructure never sees a VolumeMesh makes that particular API documentation moot.
Clarification: I'm more curious how that API gets connected to these functions. That's not straightforward. For VolumeMesh
it's problematic for the reason I pointed out (there are none in the distance-to-point infrastructure) and for SurfaceMesh
it's difficult for several reasons (meshes become convex hulls for all basic ProximityEngine
operations). So, we'd need to carve a path through registration and the distance-to-point API such that data is available to feed to these new APIs. That's the part I feel we'll probably need to reason out in the next few weeks.
My interpretation of 21471 was not "moot" but rather that when the user loads model files with vtk tet meshes (as Mesh shape, i.e., without any "declare convex" annotation), the query would return the signed distance to the non-convex surface. The call to action of the overall ticket #21323 is to do whatever pluming is necessary to answer such a query (without autoconvexification getting in the way).
Fair enough.
That said, we should revisit that documentation because this implementation is no longer "volume vtk only". Currently, that documentation isn't aspirational enough.
Support:
21471
21323
3220
This change is![Reviewable](https://reviewable.io/review_button.svg)