Roadmap for making glTF a first-class citizen

[SeanCurtis-TRI]

As of September 2023, glTF has gained a significant foothold in Drake. It is generally superior to obj for representing objects for visual tasks (the illustration and perception role). We want to push it further such that we can declare that people should use glTF without caveat and reservation. This represents a list of tasks toward that goal.

The list is fluid. Items may be introduced, priorities may be changed. What matters most is that the list includes the things we care about (even if it is for far off in the future). As appropriate, each item should map to an issue to facilitate discussion (not all issues truly require discussion).

Minimum viable product

• [ ] Doxygen module describing Drake's support for geometry files (kept up to date as subsequent tasks get completed).
  • [x] #20173
• [x] #20185
  • [x] https://github.com/RobotLocomotion/drake/pull/20236
  • [x] https://github.com/RobotLocomotion/drake/pull/20250
    • [ ] Amended with #20285
  • [x] #20272
  • [x] #20235
  • [ ] RenderEngineGl supports glTF
• [x] RenderEngineVtk features
  • [x] #20333
  • [x] #20486
• [ ] Meshcat
  • [ ] HDR environment maps
• [ ] Update drake_models to use glTF files
  • [ ] Also address #19935
• [ ] #20151
• [x] #20153
  • [x] #20184

Future work

• [x] #20932
• [ ] Support .glb files.
• [ ] Use glTF in proximity role.
• [ ] RenderEngineGl features:
  • [ ] PBR shader.
  • [ ] Shadows
  • [ ] Environment map (HDR)
• [x] #18743

[SeanCurtis-TRI]

cc @jwnimmer-tri

[jwnimmer-tri]

Thanks for this!

Our preference is to have one "component" label per issue, when we can. Could we consider component: geometry general and Epic labels for this issue, and then use the more specific components on the sub-issues?

[SeanCurtis-TRI]

I've made the change. I personally like the multiple labels, because it will come up if I search for proximity, illustration, or perception. Now, although it touches all three categories, it won't appear in any of them. :(

[SeanCurtis-TRI]

As I re-read the label guidance, I note:

Our preference is to have exactly one component per issue, but we allow multiple in case several components are equally relevant.

I'll ruminate on that while I decide if I restore the multiple labels. And I think it's easy to argue that the Epic label does a lot for justifying multiple components.

[jwnimmer-tri]

The motivation for single-component assignment is to have clear ownership for triage. For each component, the component owner is supposed to be keeping their house in order (closing irrelevant things, pinging for more information, etc.) across the whole issue database, no matter who is assigned. (This is important because on average the person who is assigned is ignoring the issue.) When multiple components are assigned, then the issue shows up in the scrub-iterator for multiple people, which could either cause extra work to deconflict the ownership, or allow it to fall through the cracks because each party assumes the other one is handling it.

For the observation that limiting the labels defeats the use of component filters when searching, one reply would be that searching using a component filter is wrong anyway. It will miss issues where the person who assigned the component label(s) had a different perspective than yours. Searching by keyword only is the one true god, and components are only for scrubbing, not for finding a needle in the haystack.

Now, I'm not sure if those are the globally "right" answer and you're welcome to disagree, but that's the background.