Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Need CalcShapeAndPose(TriangleSurfaceMesh&) #22372

Open
RussTedrake opened this issue Jan 2, 2025 · 0 comments
Open

Need CalcShapeAndPose(TriangleSurfaceMesh&) #22372

RussTedrake opened this issue Jan 2, 2025 · 0 comments
Assignees
Labels
component: geometry general Geometry infrastructure or topics that defy categorization into other geometry components priority: low type: feature request

Comments

@RussTedrake
Copy link
Contributor

Related to #20444.

The MuJoCo XML documentation specifies that

when a non-mesh geom type references a mesh, a geometric primitive of that type is fitted to the mesh.

We already have an InertiaCalculator in the parser which calls multibody::internal::CalcSpatialInertia(TriangleSurfaceMesh&). I think that we need the same thing for calculating the shape and pose.

The mujoco spec is not completely clear as to what the defining property of this geometry is. I would think that you'd want the tightest outer approximation, with some sub-optimality permitted to avoid the fact that this would be a combinatorial problem (ironically, GCS can often solves these problem instances well).

  • The mujoco implementation is here and seems pretty simple.
  • We already have geometry::internal::ObbMaker which computes an oriented bounding-box. Note that this uses PCA to figure out the main direction. That seems just wrong to me (why should the number of vertices in the mesh impact the orientation of the calculated shape?)

If I were to write an approximate outer approximation, I would probably do something like finding the maximum pairwise distance (admittedly, that's quadratic in the number of vertices), and then take another pass to find e.g. the minimum radius of the cylinder/capsule/etc once the combinatorial hardness is broken by having picked the direction of the long axis. Based on only a very quick glance at the mujoco code, that appears to be what they are doing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: geometry general Geometry infrastructure or topics that defy categorization into other geometry components priority: low type: feature request
Projects
None yet
Development

No branches or pull requests

2 participants