Stage Level Namespace Editing

[crevilla]

Description of Proposal

This is the proposal for stage level namespace editing in USD.

Contributing

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

[meshula]

Rendered version here: https://github.com/crevilla/OpenUSD-proposals/tree/PROPOSALS/proposals/namespace_editing

[lbiasco-sie]

This looks great, thanks @crevilla! I have two general questions: First, are you able to give a rough estimate on how long this work might take to complete? Especially with finishing the relocates feature it seems like no small feat, so I won't hold my breath.

Second, has there been any consideration on how to manage namespace edits for stages/layers that aren't open? It seems beyond the scope of this system and is probably better left for smart use of an asset resolver, but I'm sadly coming from a games ecosystem where resolving versions is more restricted, so I'm curious if you had any thoughts on the problem.

[crevilla]

This looks great, thanks @crevilla! I have two general questions: First, are you able to give a rough estimate on how long this work might take to complete? Especially with finishing the relocates feature it seems like no small feat, so I won't hold my breath.

Second, has there been any consideration on how to manage namespace edits for stages/layers that aren't open? It seems beyond the scope of this system and is probably better left for smart use of an asset resolver, but I'm sadly coming from a games ecosystem where resolving versions is more restricted, so I'm curious if you had any thoughts on the problem.

To answer your first question, we expect this work to be completed for one of the release in 2024. You'll likely see the in progress work trickling in over the next few releases but with the caveat that the code will be subject to change until the official release.

For the second question, I'm assuming your talking that the unopened stages/layers are ones that depend on the layers of the opened stage you're editing? That's obviously tricky as you typically need to open the stage/layer to analyze what dependencies on namespace in other layers it has. If your goal is to never open these layers at all that seems infeasible. If your goal is to not have to keep these dependent layers open, then I could a potential for having a utility that does the dependency analysis on potential dependent layers and caches only that information to be analyzed when namespace edits occur. But, yes, that's definitely way out of scope for this particular proposal.

[marktucker]

I'm having waking nightmares just thinking about the difficulties of doing this, so first let me commend your bravery! :)

A question: I don't think you specifically mention instance proxies, but I was wondering what you intend to do in the case of instance proxies as source or destination targets for deletes/renames/moves? For most normal USD edits you actually can effectively override instance proxies by adding an inherit arc to the instanceable prim. And this approach could work for the "soft delete" case you describe (and maybe for the "relocate arc" as well?). Is this an approach you've considered to allow these operations?

And I just wanted to raise a flag about "soft deletes"... Any time you "delete" a prim by deactivating it, you essentially leave a little land mine in your scene graph. If you try to create a "new" prim at or below a deactivated location, the new prim disappears into the ether. If you are smart enough to know that you need to reactivate your ancestors, then the "deleted" stuff comes back. Obviously this problem isn't unique to this feature, but I fear it will pop up a lot. A user renames A to B (which leaves a soft-deleted A lying in wait). Then the user says "no, never mind, rename B back to A" - sorry, not allowed... But if I then move B to C, and try to move C back to B, no problem! Because B could be truly deleted.

[crevilla]

I'm having waking nightmares just thinking about the difficulties of doing this, so first let me commend your bravery! :)

A question: I don't think you specifically mention instance proxies, but I was wondering what you intend to do in the case of instance proxies as source or destination targets for deletes/renames/moves? For most normal USD edits you actually can effectively override instance proxies by adding an inherit arc to the instanceable prim. And this approach could work for the "soft delete" case you describe (and maybe for the "relocate arc" as well?). Is this an approach you've considered to allow these operations?

And I just wanted to raise a flag about "soft deletes"... Any time you "delete" a prim by deactivating it, you essentially leave a little land mine in your scene graph. If you try to create a "new" prim at or below a deactivated location, the new prim disappears into the ether. If you are smart enough to know that you need to reactivate your ancestors, then the "deleted" stuff comes back. Obviously this problem isn't unique to this feature, but I fear it will pop up a lot. A user renames A to B (which leaves a soft-deleted A lying in wait). Then the user says "no, never mind, rename B back to A" - sorry, not allowed... But if I then move B to C, and try to move C back to B, no problem! Because B could be truly deleted.

Sorry for the delayed response but I can address both your questions. As far as instance proxies we don't intend to have namespace editing de-instance any instance prims and we're going to bonk any edits that involve modifications to individual instance proxies. While adding an inherit to an instanceable prim is a way of decoupling an instance prim from its current prototype, it's not the only or even necessarily standard way of accomplishing this operation and this API doesn't feel like the appropriate place to handle how we de-instance a prim.

As far as "soft deletes", we are aware that the namespace location is now "dead" and you can't move a prim to the dead location even though there isn't a namespace prim there. This ends up being necessary because you can't truly move a different prim to the dead location without it picking up the opinions from composition that necessitated the soft-delete in the first. We actually feel that the fact that you CAN still create a new prim under a deactivated location is an issue and we have a task where hope to update the DefinePrim, OverridePrim, and CreateClassPrim methods to not allow creation of prims under deactivate prims or instance proxies. Additionally, with the addtion of relocates, edits that required them will leave behind dead namespace locations (just like deactivation) for the original prim path. The only prim that can be moved to the dead relocated from location would be the prim that was relocated from that namespace path in the first place.

[marktucker]

As far as "soft deletes", .... with the addtion of relocates, edits that required them will leave behind dead namespace locations (just like deactivation) for the original prim path. The only prim that can be moved to the dead relocated from location would be the prim that was relocated from that namespace path in the first place.

Thank you for the responses, and particularly for this clarification. I was wondering how "relocates" would behave in this situation.