vsg::SharedObjects ends up with many duplicate vsg::BindViewDescriptorSets instances

[AnyOldName3]

If a VSG-based app loads several models (e.g. glTF or 3D Tiles) over its lifetime, and attempts to share state with a vsg::SharedObjects instance, its _sharedObjects[std::type_index(typeid(StateCommand))] ends up full of identical vsg::BindViewDescriptorSets. This is because when a model is loaded, and StateCommands are shared, the BindViewDescriptorSets' layout->setLayouts[0], a vsg::ViewDescriptorSetLayout has not yet had its compile method called, so its _viewDescriptorSetLayout member is nullptr, whereas the instances already in SharedObjects used for models that have been rendered have had that method called, and so have a non-null value. vsg::ViewDescriptorSetLayout::compare compares this field, and so that means the new BindViewDescriptorSets instance is considered distinct. However, before the newly-loaded model is rendered, the ViewDescriptorSetLayout instance will be compiled, and its _viewDescriptorSetLayout member will be set to the same pointer as the already-shared value had.

This can be demonstrated by loading a 3D Tiles tileset that uses similar/the same materials in different tiles, and waiting for it to load higher-detail LoD and/or panning around so distinct tiles are paged in on different frames. If you then inspect the contents of the SharedObjects instance (either by pausing with a debugger or adding something to the application that compares shared objects to each other), there will be plenty that compare equal to each other.

There's also other junk that ends up hanging around, e.g. for every mesh in every loaded model, there's an orphaned GraphicsPipelineConfigurator with no way of ever being used again even if an identical pipeline is required again.