Deferred reification in `SceneGraph`

[SeanCurtis-TRI]

Currently, as geometry gets registered with SceneGraph and roles get assigned, the geometry gets immediately reified in the various attendant engines. While there are historical reasons for why this is true, it is no longer necessarily true. And, certainly, when updating properties of registered geometry, this can lead to redundant work. The initial geometry gets reified, never practically used, and then gets replaced when its properties get updated.

It would be better to defer reification until the geometry is actually used.

Describe the solution you'd like Registration should not reify the geometry immediately. The geometry should be reified upon events which imply requirement:

• Allocating a context
  • This implicitly includes accessing a QueryObject as that comes from a Context.
• Accessing a SceneGraphInspector.
  • Not all queries on SceneGraphInspector require reified geometry. It may be desirable to defer reification to those methods that require reification (e.g., SceneGraphInspector::maybe_get_hydroelastic_mesh()).
  • This kind of granularity may be problematic with functions whose names imply O(1) time when the first invocation would cause reification.

Note: all functions that currently reify upon registration would need to continue this behavior when called on the model stored in a context. So, those acts would need to distinguish whether deferred reification is appropriate or not.

Describe alternatives you've considered There was an immediate pain point that triggered this idea. That was of reassigning roles with properties. The implementation of this functionality blindly eliminates the old reification and reifies again with the new properties, even if the new properties would produce the identical result. With this particular aspect of the problem, it could be resolved if the process of property changes were more sensitive to the nature of the changes and could recognize if reification were actually necessary.

[jwnimmer-tri]

Is there any benchmark (or really, just a simple sample program) we could use to measure the slow-down, and assess possible speed-ups?