Improve and distribute meshlab_to_sdf

[jwnimmer-tri]

In #18776 we added the ability to parse an OBJ file directly into a MultibodyPlant + SceneGraph. It presumes lot of defaults for things, which is useful for certain uses cases and/or prototyping, but those defaults are not always satisfactory.

When the user needs more than we can offer with that Parser feature, they should instead write a real model file that wraps the OBJ.

To date, we have drake/manipulation/util/meshlab_to_sdf.py available to semi-automate that model file creation process, but:

• It's not installed in our binaries.
• It's somewhat brittle and awkward to use, even in a source build of Drake.
• It uses external tools (meshlab) that are not installed by default.

At this point, we should be able to do better by directly creating the SDFormat file using Drake features, without any need to shell out to meshlab.

The call to action here is to reimplement that tool, with better features, and install it as part of pydrake.

Near term, we'd want these options:

• Flag for mesh scale; default to meters.
• Flag for the object's mass xor density; default to density of water.
• Flag for model_name (which also be used as the body name); default to mesh file basename.
• Flag for body origin (default to 0,0,0). (Possibly a flag to place the origin at Bcm?)
• Flag for package URI:
  • Default value of "none" emits relative filename for the so-called "uri" (as a Drake parser extension; is not a SDFormat standard).
  • Option to pass a filename of a package.xml. The uri will refer to that package://. (We'll calculate the relative directory name to use to reach from the package.xml directory to the mesh file directory.)
  • Option to create a new package.xml in the same directly as the mesh file, using the name of the directory as the package name.

Longer term, we could image that this tool could also grow features like:

• Canonicalizing visual texture names (magic png file stuffs).
• Option to convert STL and/or DAE into mesh formats that Drake can load more easily.
• Option to convert visual meshes into more appropriate collision geometry (e.g., packed spheres).

[SeanCurtis-TRI]

Where in pydrake would this python file go?

[jwnimmer-tri]

As far as an implementation pattern, either of meldis or model_visualizer are a good example. The class is in one file, and next door there's a sub-module with a main function that can be run from the command line.

The question then is which top-level model to place it in. I hadn't thought about that yet, but my first reaction is pydrake.multibody, so it would be like python3 -m pydrake.multibody.foobarbaz --input=carrot.obj.

[SeanCurtis-TRI]

I'm fine with pydrake.multibody. Seems as good as anything else.

[jwnimmer-tri]

We should probably leave room in the command line naming design so that we can output either SDFormat or URDF (or maybe even MJCF) at the user's choice, even if for now it only does SDFormat. I could foresee users wanting the option to use a different output format.

[jwnimmer-tri]

(See also https://github.com/kevinzakka/obj2mjcf/ for related work.)

[SeanCurtis-TRI]

18886 Largely resolves this issue.

There was a question about including a cross reference to the obj2mjcf resource linked above. So, until that last piece gets added, we'll leave this issue open.

[jwnimmer-tri]

I'll circle back to #19070 soon and mention both mesh_to_model and obj2mjcf in the documentation there.

I'll most likely also update the doxygen for class Parser with cross-links. For me, that class overview is already extremely difficult to read so I'm not quite sure yet about how to swing it.

[rpoyner-tri]

First thought: probably some of the class Parser doc could be spilled to the parsing_doxygen.h or so. I'm sure parsing_doxygen.h also needs some refresh as well.

[jwnimmer-tri]

With the doc changes landed in #19070, I understand this to be complete.