Russ Tedrake

#21810 has landed. @wrangelvid ... shall we consider this complete and close the issue?

Deferring the CalcSpatialInertia call in the parser is a relatively straightforward fix. I've opened #21649 to pull in the failing models and provide test coverage for that fix. I can...

Nice! I had noticed this, too, but had not investigated the root cause.

Thanks Jeremy. I completely agree, and would note that (1) checking properly that the mesh satisfies those conditions in the parser directly would be impractical without a geometry helper method....

I think we already support non-convex. It's not clear that would work for open faces.

The mujoco ComputeVolume() code for a mesh appears to be here: https://github.com/google-deepmind/mujoco/blob/df7ea3ed3350164d0f111c12870e46bc59439a96/src/user/user_mesh.cc#L1214 . I agree that they aren't doing anything fancy there.

My current mental model is that mujoco is probably generating physically invalid inertias for those models, but then not doing the consistency check. But that should be verified.

in #21403, i've implemented the fallback of using the volume of the OBB if the CalcSpatialInertia fails. (with a TODO reminding me that we could do better by taking the...

Hi Yuval. Indeed, I see now [here](https://github.com/google-deepmind/mujoco/blob/df7ea3ed3350164d0f111c12870e46bc59439a96/src/user/user_mesh.cc#L1378) that you catch the negative volume case and use the convex hull if needed (I did the OBB to be quick, but using...

BTW: My updated understanding is that our CalcSpatialInteria (and MuJoCo's comparable method), only declare failure -- and thus will fall back to a convex hull computation -- in the event...