Support DAE meshes (by adding DAE loader to upstream VTK)

[hongkai-dai]

The HSR robot comes with DAE file, would be helpful to support it, rather than converting it to obj file using meshlab

[liangfok]

Extra credit for also supporting .stl files. 😄

[gizatt]

Any hope of this happening in the near future? This functionality is implied to already exist by Drake documentation (see drake/docs/models.rst), which is awkward.

[Lucy-tri]

Oops, yes, just now saw that models.rst is wrong. I will fix shortly.
When this issue is fixed, please be sure to update models.html (doc/models.rst) with any changes.

[hongkai-dai]

I am not working on it, I will unassign myself, as I am not the expert on the geometry world.

[SeanCurtis-TRI]

This looks like something that belongs in my wheelhouse. I'll put it on my plate.

[Lucy-tri]

Note that currently there is Drake code to set any mesh filename extension to "obj" and try to open that file (in geometry.cc

drake/drake/multibody/shapes/geometry.cc

Line 277 in 203a9a8

string Mesh::FindFileWithObjExtension() const {

).

[tri-ltyyu]

Still relevant. Leaving in backlog.

[SeanCurtis-TRI]

I'm closing for now. We're up to our ears in OBJ without any plan in the forseeable future to branch out. When it's a concrete need, we can revisit this.

[jwnimmer-tri]

In #14219, I started us on a path to resolve this.

The ergonomics of manually converting and vendoring third-party robotics meshes are awkward -- we need to track where they came from, licensing, and upgrades are a manual process. It's much easier if we can just refer to the *.dae file directly from the third-party hosting already in place.

We have many geometry-related mesh tools in play, mostly as a large suite of different visualizers. They all speak obj, but beyond that have mixed support for other formats. Instead of teaching them all about all formats, we'll consolidate on obj as the lingua franca, by converting other formats to obj before use. At the moment, we're doing that at compilation time, but in the future it could be at runtime.

In #14219, I added stl2obj to handle the *.stl case using VTK tools, with the PR2 as an example.

In order to support *.dae, I'd like to request that VTK add some limited support for parsing *.dae meshes as well. We definitely need the geometry and probably need materials. No lighting, cameras, animation, etc.

Here are some examples of robotics-related *.daes that we'd like to be able to convert to obj:

• HSR https://github.com/ToyotaResearchInstitute/hsr_meshes/tree/master/meshes
• Cinder block https://github.com/RobotLocomotion/drake/tree/master/examples/atlas/sdf/cinder_block_2/meshes
• Kinova https://github.com/Kinovarobotics/kinova-ros/tree/master/kinova_description/meshes
• Franka https://github.com/frankaemika/franka_ros/tree/kinetic-devel/franka_description/meshes/visual

[SeanCurtis-TRI]

@jamiesnape We'll want to spin this up.

Actions:

• Triage the examples above and enumerate the DAE features we want supported in a requirements document. (@SeanCurtis-TRI)
• Review requirements document and produce estimate/bid (@jamiesnape and @SeanCurtis-TRI and @ToffeeAlbina-TRI)
• Schedule work (@jamiesnape and @SeanCurtis-TRI and @ToffeeAlbina-TRI)
• Schedule Drake VTK update to incorporate new feature.

@jamiesnape does this seem right? Feel free to edit this checklist to account for things I've missed.

[jamiesnape]

Yes, seems good to me.

[EricCousineau-TRI]

While the above checklist seems only catered towards DAE, I'd like to expand this to STL. Jeremy's comment above leads me to believe that his request is that "DAE meshes can be loaded at runtime too", meaning it would be nice to have STL meshes also be loaded at runtime.

The solution in #14219 is build-time only (e.g. genrules that convert).

Context: https://stackoverflow.com/questions/65101327/how-to-use-ros-urdf-package-in-drake

[jwnimmer-tri]

That should be a separate issue; please revert the edits.

[EricCousineau-TRI]

Reverted in terms of "I did step on Sean's toes b/c he owns the issue".

However, with Sean's above checklist, I disagree that this should be separate, and would like to await Sean's response on how he wants carving:
Suggested title: "Support DAE/STL meshes in Drake's Perception and Illustration consumers (VTK, etc.)"

[jwnimmer-tri]

My request did not imply runtime support for different file types across all of geometry. My request is only about VTK support for DAE loading, so that we can do build-time conversion. If you want to advocate for on-the-fly mesh conversion, you can do that elsewhere.

[EricCousineau-TRI]

Ah. I misread your comment, then. I assumed your request meant, "I want to load DAE meshes in Drake via VTK", not meaning on-the-fly conversion, but side-stepping it entirely (e.g. RenderEngineVtk, etc., loads that mesh type).

However, Sean's follow-up does not indicate to me that the requirements are tailored for build-system conversion only. Pending that clarification from Sean, sure, I'll open up a separate issue.

[jamiesnape]

I am reading this completely as a VTK feature request that that we are considering. Scheduling the Drake update as the last checkbox here is the rebuild of the binaries, a minor part of the administrative and technical work. Actually using the new VTK will probably spawn a different issue. Looks like we are already using the VTK STL reader. If that needs any improvement, create yet another issue.

[EricCousineau-TRI]

OK Yeah, gotcha. In that case, I'd love it if the "build system" aspect of this could be encoded in the title.

I'll make a low-priority follow-up issue about possibly supporting other meshes at run-time (e.g. for downstream consumers); at a minimum, part of that (or this?) issue could be docs to clearly state the workflows for using OBJ meshes.

[jwnimmer-tri]

Closing as not planned. Adding a DAE loader to VTK is not the best technical approach to adding DAE support to Drake.

We have #19109 open now to consider the overall problem of DAE support, and we'll iterate there as the main tracking issue for DAE support moving forward.