Support storing available Arnold Light Shader information in the SdrRegistry

[JamesPedFoundry]

Describe the feature you'd like
Arnold Light Shaders to appear in the SdrRegistry with the Context "light" (to match the UsdLux lights already available). This would allow us to read all available light types and any custom input properties from the registry in order to build valid Light Prims and shaders ready for Hydra and USD layers.

Typically the shaders would be registered into the shader registry via the Usd Schema's which would inherit an existing light schema. Some examples we've seen use auto-apply API schemas to provide this feature, such that when the arnold-usd plug-ins are available, any RectLight could be treated as an QuadLight with any custom additional default attributes available for querying. This isn't required, since there is the existing concrete schemas, for example, ArnoldQuadLight.

Describe the solution you'd like
We should be able to search the SdrRegistry and see all the available Arnold lights via the following Python calls:

from pxr import Sdr
# A Map between the light shader_id
# (which should be stored under the
# relevant <target>:light:shaderId,
# and the actual PrimType.
all_lights = {}
for shader_id in r.GetNodeIdentifiers():
    shader = r.GetShaderNodeByIdentifier(shader_id)
    if shader.GetContext() == "light":
        print(shader_id)
        metadata = shader.GetMetadata()
        print(metadata)
        primType = metadata.get("apiSchemaAutoApplyTo", shader_id)
        all_lights[shader_id] = primType
for shader_id, primType in all_lights.items():
    print(f"{shader_id}: {primType}")

An example for the Arnold quad_light would be arnold:quad_light: RectLight or even arnold:quad_light: ArnoldQuadLight. This script could of course be modified if the Arnold lights aren't to become auto-apply schemas on the existing light types; just so long as there is a way to go from the shader identifier to the expected prim's type.

Another note is that ideally if you do go the route of storing these in the sdrRegistry, it'd be good to keep the consistency with your materials, and retain the arnold: prefix, e.g arnold:quad_light, since we can use the target information to easily derive this prefix when converting to and from the names in the registered KtoA plug-in.

I understand this example of arnold:quad_light would "break" in the script above, however this is something we can likely work around, so long as there is some information (some other metadata) on the sdrShaderNode to understand what the prim's concrete type schema should be.

Describe alternatives you've considered
We looked at the way the Arnold Lights are currently registered as API Schemas and ConcreteTyped schemas, however noticed they are not available from the SdrRegistry and don't detail how they link to the various USD base Light Types (if they do); and or which are Lights easily.

Additional context
Ideally we could use a combination of the SdrRegistry to discover relevant available valid lights, and the schema to enable us to write and read Arnold lights to/from USD layers, we can do so using this method with the UsdLux lights; we're trying to keep our tools as generic and USD friendly as possible to avoid any scenarios where we could misinterpret properties or metadata on the USD Layers for cross DCC transfer.

A bit of an update I suppose, is that by registering these in the shader registry and based on some changes that happened in USD around USD 21.05, where Lights were made to be "Connectable", such that all the input properties received the prefix inputs:. e.g intensity became inputs:intensity for the UsdLights. Unsure if that change is something to look into now or later or not at all, just a bit of extra context, likely could be another "Github issue" in itself. I mention this because I noticed the concrete schemas for ArnoldQuadLight do not currently have the inputs: prefix on the schema's registered properties. I also understand this is a much bigger and more impactful change, since it'd break existing USD layers, which happened with the native USD lights back around 21.05 timeframe...

There is also the command line tool usdgenschemafromsdr which may be helpful (although may not).

If there's anything that's unclear do let us know!
Thanks again!
James

[autodesk-oss-arnold-bot]

Issue synced internally to ARNOLD-15324

[cpichard]

Thanks for the detailed explanation @JamesPedFoundry , we'll discuss it internally very soon.