[geometry] Non-determinism in signed distance results (proximity generally)

[SeanCurtis-TRI]

Issue #13736 called out non-determinism in contact results that was leading simulations that should deterministically proceed along the same trajectory to diverge (with #13737 addressing that issue). However, as outlined in these comments (comment1, comment2), the same reasoning needs to be extended to distance queries. Such that, if I ask about distance between A and B, or B and A, I'll get the same result, down to the last bit. And sets of results should be guaranteed to be consistently ordered so operations that sequentially operate on the distance results will likewise perform the math in a consistent order.

As of 2024-07-09 we have the following methods in ProximityEngine with the following properties:

• [x] ComputeSignedDistancePairwiseClosestPoints(X_WGs, max_distance)
  • Results sorted.
  • [x] #21698
• [x] ComputeSignedDistancePairCLosestPoints(id_A, id_B, X_WGs)
  • Results sorted (answer consists of a single pair).
• [x] ComputeSignedDistanceToPoint(p_WQ, X_WGs, threshold)
  • Results not sorted.
  • [x] #21709
• [x] ComputePointPairPenetration(X_WGs)
  • Results sorted.
• [x] FindCollisionCandidates()
  • Results sorted.
• [x] HasCollisions()
  • n/a; single bool returned.
• [x] ComputeContactSurfaces(representation, X_WGs)
  • Results sorted.
• [x] ComputeContactSurfacesWithFallback(representation, X_WGs, surfaces, point_pairs)
  • Results sorted.
• [ ] ComputeDeformableContact(deformable_contact)
  • Results apparently not sorted.. The also appear unsorted where they are computed and in the class in which they are stored.

[jwnimmer-tri]

To be very clear, there are two distance queries that appear to be missing determinism, and we need to fix both (or prove that it's already fixed) before calling this done:

• ComputeSignedDistancePairwiseClosestPoints
• ComputeSignedDistanceToPoint