How to get which AutoApply Schemas apply to a certain Type


I’m looking at trying to figure out how to convert a base type, e.g DiskLight to its child Types, like PxrDiskLight.

I have found in the schema registry and in the SdrRegistry that I can found out, from the PxrDiskLight, the type it applies to. However, I cannot find the logic that goes the other way, which must exist, because if I have a USD file, this will auto apply the known schemas to my Prim of type DiskLight.

I know I could loop through all the registered auto-apply schemas and store an opposite map, but that feels like a problem already solved somewhere in USD.

Worth noting that although this is in the USD section, I am avoiding creating a USD Prim, since the data source itself isn’t a USD Prim. However I felt this question made more sense being in USD than Hydra due to the nature of where I believe the logic lives to do this.

Any help welcome!

Hi James,
I don’t believe we expose such a query, nor do we provide a direct query “derived IsA schemas” query, although you can hop over to the TfType for a Typed schema and query its derived TfTypes there.
If there were such a query, would you expect that when querying for auto-apply schemas (I assume you intend only API’s that can only be applied to the named schema?), you would always want only those that target the schema specifically, or would API’s that target a base-class-schema of the type also be included?
I agree we likely have cached the inverse map inside the Registry, but we’d need to decide on the right API before exposing it, and depending on the answer to the above question, we might need to augment what we cache…

Hey Spiff,

Thanks for confirming, and a good question indeed, I think it would be ideal for at the API level to provide the same response which would happen inside USD when it is acting on the auto-apply schemas. Essentially I am trying to mimic behaviour done by USD when upconverting base types of Lights.

To expand further, I am looking at passing UsdLuxLights in a way render delegates, like hdPrman, will understand which means updating shaderID’s from a non-USD data source to be the shaderID they would expect (and USD would be passing to them via the auto-apply schema workflow).

I have written a small python snippet (which arguably doesn’t fulfil the full API discussed above, but gets me a step further and might help others), which will provide a reversed auto-apply list. The inner loop could be updated to fulfil this behaviour if required, it’d likely require querying the schema’s parent schemas and searching for those again in a recursive manner.

One of those situation’s it appears that all the data is there, so not urgent on the list, it was more a query to see if I was missing some API call somewhere.

from pxr import Usd
# Reverse the schema registries auto-apply api schema map to make it 
# easier to query later from the position of being provided a base type.
schema_registry = Usd.SchemaRegistry()
auto_apply_schemas = schema_registry.GetAutoApplyAPISchemas()
reverse_apply_schema_dict = {}
for auto_apply_schema, apply_to_list in auto_apply_schemas.items():
    for apply_to in apply_to_list:
        # store it as a list incase multiple auto apply's apply to
        # a single Type Schema.
        l = reverse_apply_schema_dict.get(apply_to, [])
        reverse_apply_schema_dict[apply_to] = l

With the RenderMan Discovery Plugin’s loaded I get the response of:

{'MeshLightAPI': ['PxrMeshLightAPI'], 'VolumeLightAPI': ['PxrMeshLightAPI'], 'RenderPass': ['RiRenderPassAPI'], 'Camera': ['PxrCameraAPI', 'PxrCameraProjectionAPI'], 'DistantLight': ['PxrDistantLightAPI'], 'RectLight': ['PxrRectLightAPI'], 'SphereLight': ['PxrSphereLightAPI'], 'RenderSettings': ['PxrOptionsAPI', 'PxrRenderTerminalsAPI'], 'CylinderLight': ['PxrCylinderLightAPI'], 'RenderVar': ['PxrDisplayChannelAPI'], 'PortalLight': ['PxrPortalLightAPI'], 'DomeLight': ['PxrDomeLightAPI'], 'DiskLight': ['PxrDiskLightAPI']}


Thanks again!