Modification of nodes in NDR/SDR registry's?

Community USD
1

Is it possible to modify the nodes in the NDR/SDR registry’s?
Specifically we would like to be able to;

  1. Remove nodes from the registry.
  2. Modify node properties
    e.g. The source file for a shader was modified and the default value of a parameter has changed.

From looking at at the ndr/registry code and vaguely remembering an old thread about this (which I cannot seem to find) I am fairly certain the answer to this question is no.

2

Correct - the registry is currently immutable, beyond its lazy parsing policy. The key aspect of its design that would need to change is that instead of handing out raw pointers, it will need to hand out weak node pointers, and clients use them safely. You also wouldn’t be able to directly modify Nodes, but you’d be able to remove and replace them. We might be able to take this on in the next year, though we’d need to first have a good story, worked out with the community, on what the “client upgrade” story will be.

3

@spiff - Thank you for confirming.

This leads to my next question, which is can anyone offer guidance on how to solve the following?

We are writing discovery and parser plugins for MDL.
The NdrIdentifier’s that we create are done so by a function that is effectively a direct copy of the _GetIdentifierForAsset function in ndr/registry.cpp:

OpenUSD/pxr/usd/ndr/registry.cpp at release · PixarAnimationStudios/OpenUSD (github.com)

If we have detected that a MDL module has changed on disk we update the registry by creating new SDR nodes. The SDR metadata that we pass to the _GetIdentifierForAsset function contains a version field.

e.g.
So on first load the sdr metadata might look like
{“version”: 1}

and after a module has been reloaded:
{“version”: 2}

The problem with this approach is that anytime we want to call something like the following, the only way to ensure that the “correct” identifier (the one which points to the most recent version of the node in the registry) is used would be to ensure that the SDR metadata on the underlying prim is updated.

    api = UsdShade.NodeDefAPI(prim)
    sdr_node = api.GetShaderNodeForSourceType("mdl")

While this is doable what I think would help here would to have a way for a plugin to define how the NdrIdentifiers are created.
Perhaps something like adding a additional method, GetIdentifierForAsset, to the NdrParserPlugin.
The logic for the default implementation would be identical to _GetIdentifierForAsset , however developers could override it if need be.
Then inside of NdrRegistry::GetNodeFromAsset we could call the plugin implementation vs _GetIdentifierForAsset, e.g.

    NdrIdentifier identifier =
        parserIt->second->GetIdentifierForAsset(asset, metadata, subIdentifier, sourceType);

Does that seem reasonable? Or perhaps I am overlooking something and there is a better/existing way to handle something like this?

4

@spiff just bumping this thread. Any thoughts on Derek’s last suggestion?