3

I'd like to define two new classes of Shape:

  1. Mesh class that allows vertices/faces to be passed in directly (current Mesh class only takes in a filepath), and
  2. Cone class that supports proximity queries (MeshcatCone is the only existing one, I don't see why cones should be complicated since they are convex.)

In my setup, I have downloaded prebuilt binaries of drake, meaning I cannot directly modify the ProximityEngine class. I saw this post on defining a new child of ShapeReifier, but I can't replace ProximityEngine since it is used everywhere. Any ideas on how I could do this?

alvin
  • 137
  • 7

1 Answers1

3

Sadly, there is no affordance for dynamically increasing the set of Shapes that SceneGraph knows about.

Both of your requests are very sane and have been on the Drake team's radar. So, that suggests the best way to do this is to write some code to submit to Drake. Since we already intend to do both of those things, that should very much grease the path. They just haven't been a strong priority yet.

For the first case, the Mesh type, see the open issue #15263.

There is no existing issue for the Cone (although converting the MeshcatCone to full Shape is a known goal.

I'd recommend the following:

  • While the mesh-from-data would be helpful, it's not strictly necessary. At the time you'd instantiate the mesh with data, you could write that same data to disk and pass in the file name. Passing the data would save you a trip to the disk, but the end result would be the same (with much less work and cooperation from Drake).
  • You should open an issue about the Cone shape. You'll find the Drake developers happy to help you write and submit a PR. This one would provide very unique value. As you said, right now, you can't use Cone for anything but meshcat visualization. More utility would be a benefit. The details about how one would go about that can be discussed in the issue.
Sean Curtis
  • 1,425
  • 7
  • 8
  • Sure, I can temporarily do that work-around for meshes, but eventually I would like to avoid writing/reading from disk. Maybe I can make a PR for that open issue. For Cones, I've made a [new github issue](https://github.com/RobotLocomotion/drake/issues/18147). – alvin Oct 20 '22 at 17:01
  • I read your comment on that old PR issue for Mesh. Why wouldn't it be as simple as defining a new constructor for Mesh that optionally accepts vertices/faces/etc. Then modify ProximityEngine::ImplementGeometry() to check if a member shared_verts_ has been populated, and if so, use that instead of reading from file? – alvin Oct 20 '22 at 17:18
  • 1
    For the github issue, I'll address Cone-related stuff specifically here. As for the mesh: The single greatest challenge is not simply to do some minimum thing to get data in, but to make sure it's a public API that will not interfere with future needs. Also, we need to make sure that we know the boundaries of where such a Mesh falls short -- we have visualizers that rely on file paths to load meshes (and not data buffers). So, would this be a short-term expedient for proximity only? Etc., etc.. The periphery introduces complexity. – Sean Curtis Oct 21 '22 at 21:35