[meshcat] SetTransform should fail fast for transforms with non-uniform scaling

[RussTedrake]

During my attempts to apply the cross product as a transform in the visualizer, my MeshcatCones were coming out warped.

It turns out that Three.js, which Meshcat is built on top of, does not properly support all Transforms.
https://github.com/mrdoob/three.js/issues/15079 https://github.com/mrdoob/three.js/issues/3845 (and it is unlikely to get that support)

We should fail fast with a helpful warning if a user calls the Matrix4d form of Meshcat::SetTransform to save the next person the few hours I lost going down this rabbit hole.

[RussTedrake]

I believe that the correct check for this would be to reconstruct the same matrix decomposition math that three.js provides and meshcat uses. Then we should check two invariants: 1) does multiplying out the decomposition give back the original 4x4 transform? 2) is the scaling from the decomposition uniform?

The second test is because it's not only the individual transforms that are represented with the decomposed representation, but also the composition of transforms from the kinematic tree; so if you have a non-uniform scaling anywhere in the meshcat tree, the child objects/transforms will all be impacted.

Clearly our Meshcat::SetTransform(..., RigidTransform) entry point shouldn't have to pay for this check, and that's by far the most heavily used one. But I think we should check the invariant on all direct calls to Meshcat::SetTransform(..., Matrix4d).

@joemasterjohn -- I'll leave this one for you to fix and/or delegate.

[jwnimmer-tri]

I don't philosophically object to the checking, but I'll ask for the record -- do we even need the Matrix4d overload at all? Another option would be to deprecate and remove it.

[RussTedrake]

Yes, we definitely need it. For instance, I believe the way we draw arrows in our force vector visualization is with a non-rigid transform (it's a cylinder that gets squeezed to a point in one axis). And there are other important visualizations that will be done this way. Requiring rigid is too strict.

[jwnimmer-tri]

That requirement makes sense. Is a Matrix4d the best way to accept that data from users, rather than say a Vector3d scale?

[RussTedrake]

I believe Matrix4d is the right API. This would correspond to the "general transform", T, as described in the multibody notation: https://drake.mit.edu/doxygen_cxx/group__multibody__quantities.html And, as that documentation says, "The relationship between two spaces – it may be affine, projective, isometric, etc. Every X_AB can be written as T_AB, but not every T_AB can be written as X_AB."

Scaling is not the only need beyond RigidTransform; and separating a transform into its individual components (rotation, translation, scale) runs into exactly the limitation that they've realized in Three.js.