Revise Use of Layer Metadata in USD

[spiffmon]

Revise Use of Layer Metadata in USD

As OpenUSD's use has grown since its initial release, especially in disciplines outside its initial target of animation and VFX, some elements of its design have been exercized and leveraged beyond Pixar's initial vision for them. One, in particular, has not conceptually scaled well to the complexity of scenes people now often build.

This proposal re-examines USD's use of layer metadata, first explaining the various ways in which it is currently used in USD, then noting where and why it has been problematic. Finally it will provide new guidelines for when to encode a concept in layer metadata, and propose that several core concepts currently expressed as layer metadata be migrated to applied schemas.

Supporting Materials

Rendered proposal text here.

Contributing

• [ X] I agree to and accept the Supplemental Terms.

[dgovil]

I generally like this proposal. I had a question: does everything in these APISchemas also automatically become a valid layer metadata key? I assume we still allow people to set the "global layer" hint as we do today, but taking Physics and ColorSpace, would they also allow for globally setting the keys too?

[spiffmon]

@dgovil , I would argue to deprecate (at least strongly discourage authoring with warnings, while keeping backwards compatibility with a long tail) the existing global layer hints (except, as stated, for the color config data), and nothing that we introduce as properties in API schemas would be reflected as layer metadata. I know we can think of it as a "fallback", but it also becomes a ODR issue that will create confusion (I just set the global layer data, but it's not having any effect, #$@#$!!)

[dgovil]

Would the expectation then be that every single prim needs to author these? Or would it be inheritable through the hierarchy such that only the top level of any hierarchy needs it?

[spiffmon]

😱 I had thought I'd made it clear that all such API's would be namespace inherited because nobody in internal review called it out, but rereading, I can see that it's not! I will correct that. I think for most of these things, we'd only expect/need to see them on root prims, and (coming through the reference/payload) on prims where we compose in other assets.

[dgovil]

Awesome. Yeah that makes sense to me then. It's essentially moving the metadata from the pseudo root to actual root prims with the option for better granularity through the hierarchy.

Especially if the current set of layer metadata are supported for the foreseeable future so current assets don't break.