-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
USD API schema strength order and composition changes:
1. Authored API schemas are no longer the strongest schemas and are now instead the weakest API schemas when a USD prim definition is constructed. Most importantly this means that an authored API schema can no longer override properties that are already declared from a prim's typed schema. 2. The "default" and "hidden" fields of properties can now be composed from a weaker API if a stronger schema with the property has no opinion for those fields. 3. API schema override properties are no longer rejected for a variability mismatch; the override's variability is just ignored. This is because we don't check attribute variability when determining if a default value from a weaker schema can be composed in, so it doesn't makes sense to require a variability match for API schema override properties. 4. The result from UsdPrim::GetAppliedSchemas will no longer contain duplicate schema names when there are authored API schemas that are the same as any of the prim's built-in API schemas. A little background context on why we're only allowing "default" and "hidden" to compose right now: Our team discussed schema property definition composition and the suggestion was made that we start limited in what fields we compose since there are open questions about what to do with certain fields (like the allowedTokens listOp which likely wants more than "stronegest opinion wins" composition). So, the choice was to start with only the fields we know we want now. Allowing "default" was one of the main reasons we wanted schema property composition in the first place. Default is also required for a GenerativeProcedural prim with an authored applied HydraGenerativeProceduralAPI to still work as it did previously after making authored API schemas weaker than the prim type schema. Allowing "hidden" came up because of a internal Pixar desire to hide the "productName" property of the RenderProduct schema when our internal renderman API schemas are auto-applied to it. The productName value is expected to be generated at some point in the render submission pipeline so being able to hide it in the schema via auto-apply is a user experience win. Fixes #2336 (Internal change: 2275114)
- Loading branch information
Showing
10 changed files
with
1,238 additions
and
821 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.