usd: add a UsdSchemaRegistry function for identifying schematics layers

[mattyjams]

Hello!

Following https://github.com/PixarAnimationStudios/USD/commit/a32872440a542d5ef16b7be610a7a7f5a10f0294 that landed in v23.05, schematics layers read by the schema registry are no longer aggregated into a single registry.usda layer as they were in v23.02 and earlier. This has made it a bit more cumbersome for unit testing and other layer lifetime debugging as there isn't really a clean way to differentiate these now anonymous schematics layers from other layers that contain user content when using SdfLayer::GetLoadedLayers(), for example.

I added a IsSchematicsLayer() function to UsdSchemaRegistry that can be used to make that distinction and help filter out any of these schematics layers.

• [X] I have verified that all unit tests pass with the proposed changes
• [X] I have submitted a signed Contributor License Agreement

[jesschimein]

Filed as internal issue #USD-8703

[mattyjams]

Freshening with a rebase on the current dev branch (35dbce15eb3dc6c805b65135d911c246716fd192).

[spiffmon]

Just wanted to provide some visibility on our internal deliberations on this one, unsatisfying though they are. We'd rather not address the "what kind of layer is it" question in a UsdSchemaRegistry-specific fashion. Rather, the solution should be something at the Sdf-level. But we are very much torn between the tradeoffs of: a) allowing layers to be opened/created as "private", meaning they can't be looked up in the Sdf_LayerRegistry, and can't be placed onto a UsdStage b) allowing clients to create and manage their own LayerRegistries as an alternative to the global/default one.

Each has some significant drawbacks, and we haven't yet been able to identify a winner.

[nvmkuruc]

@spiffmon Client managed layer registries would be a welcome feature. Sometimes users making temporary writes to layers aren't aware that they could be affecting other stages using that shared layer.

[jesschimein]

/AzurePipelines run

[azure-pipelines[bot]]

Azure Pipelines successfully started running 1 pipeline(s).

[spiffmon]

@nvmkuruc , the biggest challenge with multiple registries aside from the extra management/API complexity is that it is easily susceptible to the "two layer problem" where we could have the same layer open in two different registries. For usdc files (and other deferred access formats) it means we could wind up with two or more stages trying to write different data to the same file/asset, which would corrupt the file. We could institute a draconian policy that all auxiliary registries will open all layers "detached", but that would mean reading in the entire contents of the assets into memory when opened, which could significantly affect performance/resource profiles. Even if we instead prevented all-but-one copy from saving out their data, the other layers may still be corrupted if that one changes the data layout in storage.

[mattyjams]

Just wanted to provide some visibility on our internal deliberations on this one, unsatisfying though they are. We'd rather not address the "what kind of layer is it" question in a UsdSchemaRegistry-specific fashion. Rather, the solution should be something at the Sdf-level. But we are very much torn between the tradeoffs of: a) allowing layers to be opened/created as "private", meaning they can't be looked up in the Sdf_LayerRegistry, and can't be placed onto a UsdStage b) allowing clients to create and manage their own LayerRegistries as an alternative to the global/default one.

Each has some significant drawbacks, and we haven't yet been able to identify a winner.

Thanks for the insight here, @spiffmon! The concerns you raise definitely make sense.

The only other idea I'd had for this specific problem was to have UsdSchemaRegistry inject some kind of info in the customLayerData in _GetGeneratedSchema() that would indicate the layer was being held open by the registry, but that's obviously still a UsdSchemaRegistry-specific solution and not really any more satisfying.

At the moment, we don't have a practical use case that requires being able to weed out these UsdSchemaRegistry "owned" layers other than our unit tests that try to ensure cleanliness when closing stages and releasing layers.