Define the nature of "default material" properties

[SeanCurtis-TRI]

(NOTE: This discussion is in context of geometry used for the "illustration role" -- i.e. displayed in drake_visualizer or mesh_cat. However, the principle can easily extend to other geometry roles.)

Description

A geometry can have an arbitrary collection of properties in service of a particular role. The question is where do those property values come from and how do "default" values come into play?

Geometry passes through several stages before it's actually exercised in SceneGraph.

• Specified in an SDF/URDF file
• Parsed
• Instantiated in SceneGraph
• Consumed by a system that cares about geometry and its properties.

SDF Specificaiton and Parsing

The SDF specification (as an example) indicates while there is no default material for a visual element, if a material is defined it does have default values for diffuse, specular, ambient, and emissive. That suggest, that if the specification has a <material> tag but no <diffuse> tag, the parser would be inclined to provide a diffuse value of (as currently specified) [0, 0, 0, 1].

This has issues:

• Coming out of parsing, properties aren't easily distinguishable between a value that assumed a default value and a value that had been specified with that value.
• This interferes with downstream property consumers to provide global defaults.
• An equally unspecified property in an SDF file may lead to a different result as the same unspecified property in a URDF file.

Consuming unspecified properties

In PR #10164, parsing the currently omits missing properties from the instantiated material property values deferring to the downstream consumers' individual policies for responding.

The concrete example of that is in geometry_visualization.h which is compatible with any geometry with an illustration role and provides a default diffuse value if one hasn't been specified. While the API doesn't currently support it, the API in geometry_visualization.h could support a user-defined default color in place of the hard-coded value.

How to resolve?

1. Go with the current implementation where we ignore SDF/URDF "default" values for missing tags.
2. Respect all published documentation of the file formats we parse at the cost of not having consistency across inputs or the ability to set runtime defaults.
3. Extend properties so that we can look at a value and distinguish if it was added automatically or by an explicit user action. This would merge the two behaviors at the cost of increased complexity.
4. More?

[jwnimmer-tri]

@SeanCurtis-TRI I'm curious to get your revised thoughts here, given recent designs of #13689.

[SeanCurtis-TRI]

@jwnimmer-tri Is there something specific you have in mind?

As I read this, what sticks out to me is that this is, ultimately, a comment on sdformat's intermediate representation. We map sdf::Foo to drake::Fooish. The sdf::Foo populates lots of fields without telling us whether it came from the .sdf file or from sdformat itself. That remains true even in the face of #13689.

Eventually, things like <drake:perception_properties> and <drake:illustration_properties> may have named drake properties that would shadow sdf/urdf material properties (my current implementation in resolving #13689 has avoided making this decision). That choice would definitely be related to this issue, but, as my language might suggest, it's not clear to me that that feature would be a good thing. And even then, when we depend on the model-declared material, we're right back in the center of this issue.

So, I see these issues as largely orthogonal. However, I may simply be missing something that stood out to you.

[jwnimmer-tri]

You're right, they are mostly unrelated.