Hello! I’ve got a conceptual question about composition in USD.
How are people in practice dealing with nested overrides? From my perspective, the system being path-based is rather brittle – an override in a root file breaks if someone changes the name of a prim ten levels down, and then it’s hard to hunt that down.
Things I can see that might mitigate that:
rules where overrides should be (e.g. overrides should not be further away than 1-2 levels of the file they apply to)
strict naming rules that prevent renames in the first place
We opt for the strict naming convention. It also takes a while for modelers and riggers to get used to the fact they cannot rename of move things around in the hierarchy anymore. Once they are used to it, they think it through a little more before creating a new mesh because they know they are going to be stuck with it.
While it’s by no means a panacea, the recent addition of proper “namespace editing” in USD via UsdNamespaceEditor will take care of “fixing up” overrides, target paths for any stage you tell it to fix for you as you are making the edit, and even lets you do moves/renames non-destructively. Obviously only useful if the DCC supports it, and is operating directly on the USD data.
Collections can also help in keeping downstream consumers robust. For example, if the modeler establishes the Collections that define all the geometry that wants to be shaded by the same Material, and puts all those collections on the root prim or other agreed-upon prim, then they can change the hierarchy of the geometry as they see fit, updating the collections, and then the downstream shading artist uses those collections to bind Materials. It’s unclear whether rigging can/will submit to a similar pattern.
@spiff do you happen to have good concrete examples of files that use collections in that way at hand? I’d be curious to learn more. I only found the docs here so far.
Regarding UsdNamespaceEditor, my understanding would be that for this to work the entire structure needs to be loaded into the DCC (or at least the DCC needs to be aware of what the root is, even when only some leaf file is being edited). Is that correct?
Sorry, @herbst , I don’t have any examples handy, as we haven’t migrated our shading over to collections, yet. I believe the Maya USD exporter should have an option for it, though (we made one for the “pre merge” version of the plugin). But…
That’s correct! The code can only fix up what it knows about, and the UsdNamespaceEditor allows you to register “Dependent Stages” that will be processed when making edits on a “primary” stage. When discussing namespace editor with the games working group a couple years back, there was desire to be able to serialize edits so that a batch process could later be sent off to update other dependent assets/stages “offline”, but that’s a feature that’s not currently on our “feature complete” roadmap.
