Feature request: identify required features from SDFormat file before requesting engine

[scpeters]

Desired behavior

Currently the sdf component provides APIs to construct Worlds, Models, and other entities from SDFormat. There is currently no mechanism to identify which gz::physics::Features are used in an SDFormat file, so the current implementation of dartsim's sdf component loads whatever it can, but this does not provide consistent behavior across physics engines.

Ideally, we should provide an API for parsing an SDFormat file and identifying the gz::physics::Features that are used within that file to facilitate a call to RequestEngine with a matching set of features. This would support granularity in feature support in SDFormat files, and avoid requiring an "all-or-nothing" approach to features, which would likely lead to no-op feature implementations in plugins to allow loading.

Alternatives considered

Instruct physics plugin implementors to implement all features with at least a no-op implementation to avoid loading problems. This was the approach taken in gazebo-classic, and we have been attempting to avoid this with gz-physics.

Implementation suggestion

Additional context

[scpeters]

Implementation suggestion

I've had previous conversations about this with @mxgrey and I'll share some of my notes and recollections from those conversations.

Several discussions and example APIs from these discussions involved enumerating the supported features with an enum type, so I'll start by focusing on two particular feature classes that already have enums defined:

• sdf::GeometryType
• sdf::JointType

For a given sdf::World or sdf::Model object, I can imagine a helper function that would iterate over all the Joint and Geometry objects and return a container (std::set?) listing all the joint and geometry types referenced within. This helper function could be included in libsdformat, as it doesn't require any gz-physics datatypes.

What would the next step be? Query whether a gz-physics Implementation plugin supports the joint and geometry types in an SDFormat file? Is it possible to programmatically construct a gz::physics::FeatureList from a collection of sdf::GeometryType and sdf::JointType values?

Or, conversely, should we pass an sdf DOM object or sdf::ElementPtr to the Implementation plugin, and let it determine if it is able to support all the feature listed therein?