Feedback needed on new UI - Composition Arc Authoring

[womanyoyoyo-adsk]

Hi everyone,

We are currently designing a UI which lets users author/view payloads, references, specializes, inherits and variants while on a selected prim with respect to the editTarget. This UI would show each arc in its own tab (except for sublayers - sublayer authoring will remain in the Layer Editor). Here is a rough idea of what we are thinking:

Where in Maya's UI would you expect to find this UI? Here are some possible answers:

• Attribute Editor
• Layer Editor
• A new stand-alone editor
• Somewhere else?

Thanks,
Natalia (designer on Maya USD)

[ChokmahBinah]

Hello @womanyoyoyo-adsk ,

I would suggest in a new stand-alone editor imo. :)

[santosg87]

I personally like that idea better as well. :) as a stand-alone Editor there is always the option to dock it anywhere the user might want it to be.

[womanyoyoyo-adsk]

Thank you!

[neilrubie]

I'd also be in favor of a standalone editor that a user needs to launch. Putting it in the attribute editor by default makes it almost too accessible for such an advanced tool. Obviously everyone has their own use case scenarios, but I imagine for studios, most artists consuming usd data will not be interested making these kinds edits.

[womanyoyoyo-adsk]

Thanks!

[gracekumagai]

Hi Natalia!
We agree with the previous comment. For most cases, our artists would not be looking for this data so it might be safer for it to be in a separate editor.

We were also wondering if it would be possible to delete composition arcs? Again, in most cases, we wouldn't want to accidentally delete composition arcs that have been set up for the artists.

[cking-spire]

I wonder if a few higher level GUIs would be a better choice. Some previous comments have said that they don't see artist wanting to edit these things. I don't think that is true at all. Artists absolutely need to be able to make references. Artists want to create variant sets. But I think bespoke interfaces for that stuff would be better.

[womanyoyoyo-adsk]

Hi @gracekumagai ! Thanks for you feedback. For the Composition Arc UI, we are thinking of including the following capabilities:

• View existing arcs that are authored on the selected composed prim with respect to the editTarget.
• Edit existing authored arcs. This includes the arc path, the target prim, and its list editing operation.
• Author new arcs and clear existing authored arcs.
• Author an arc that would act as a remove-as-override, author an explicit list of arcs.
• Refresh existing authored arcs.

So yes, it would be possible to delete an arc (I've referred to it as 'clear' above). In the design so far, clearing an arc would be accessed through clicking on an arc in the UI, right-clicking, and selected 'Clear'. This would be undoable.

[womanyoyoyo-adsk]

Hi @cking-spire. It is definitely our intention for artists use this new Composition Arc UI. See the bullets above for the capabilities this editor will have. One thing to note is the contents of this UI will be prim-specific, so it will change when prim selection changes (like Attribute Editor). Do you still think that a bespoke editor is best?

[cking-spire]

For the most common workflows, yes, bespoke editors will be best.

Lets talk about workflows.

Studios often need to craft a asset structure. They need to decide where to have payloads, how to use inheritance to allow for global overrides, etc. This task is often performed by a senior TD and, for the most part it is done once. In a Houdini Solaris world, this would be done by crafting a HDA. I could imagine your interface would be quite good for this task.

The modelers and lookdev artists are going to supply the inputs to that asset structure. I don't think they need or want to think about the composition arcs that much. Authoring variants is important for them. While I know that variants are in fact composition arcs, is that the best conceptual model for an artist to have to work with? It seems that there are much simpler ways to represent this to the artist.

Then there are the set construction artists. They are going to be creating lots of references, selecting variants, and need to think about instancing a fair bit. I think a bespoke interface for doing this sort of thing can be vastly more efficient than a generic composition arc GUI.

Thanks,
Chris

[womanyoyoyo-adsk]

Thanks for this info Chris.

[dgovil]

One advantage of making them standalone editors would be that they'd be easier to embed/reuse in studio specific tooling and extend as well.

…

On Wed, Mar 16, 2022 at 8:45 AM CKing-Spire ***@***.***> wrote: I wonder if a few higher level GUIs would be a better choice. Some previous comments have said that they don't see artist wanting to edit these things. I don't think that is true at all. Artists absolutely need to be able to make references. Artists want to create variant sets. But I think bespoke interfaces for that stuff would be better. — Reply to this email directly, view it on GitHub <#2179 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB4XURFEGILVKELIAUTJ73VAH627ANCNFSM5QN36GEA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[womanyoyoyo-adsk]

Good point. Thanks @dgovil .

[dgovil]

One option could be a bespoke editor with a button to launch it from the Attribute Editor. That way it's still easily discoverable, but doesn't need to necessarily be directly embedded in there.

…

On Tue, 22 Mar 2022 at 09:54, CKing-Spire ***@***.***> wrote: For the most common workflows, yes, bespoke editors will be best. Lets talk about workflows. Studios often need to craft a asset structure. They need to decide where to have payloads, how to use inheritance to allow for global overrides, etc. This task is often performed by a senior TD and, for the most part it is done once. In a Houdini Solaris world, this would be done by crafting a HDA. I could imagine your interface would be quite good for this task. The modelers and lookdev artists are going to supply the inputs to that asset structure. I don't think they need or want to think about the composition arcs that much. Authoring variants is important for them. While I know that variants are in fact composition arcs, is that the best conceptual model for an artist to have to work with? It seems that there are much simpler ways to represent this to the artist. Then there are the set construction artists. They are going to be creating lots of references, selecting variants, and need to think about instancing a fair bit. I think a bespoke interface for doing this sort of thing can be vastly more efficient than a generic composition arc GUI. Thanks, Chris — Reply to this email directly, view it on GitHub <#2179 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB4XUWFTZHBBAIPCHMK6UDVBH3KTANCNFSM5QN36GEA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Ziethriel]

I would like a way to change a prim USD Reference to a relative path. Sorry if this has already been added in Maya 2023, but my org hasn't given me access to that yet.

[sharktacos]

A common workflow is to save geometry and materials into separate files which are payloaded into an asset container like so:

asset.usda:

   prepend payload = [ 
                       @./asset_mtl.usd@,
                       @./asset_geo.usd@ ]

Am I correct in imagining that the planned design of this tool would allow for this?

[womanyoyoyo-adsk]

@sharktacos Yes, this editor would allow for that. You would select the prim you're on, go to this editor and add the two payloads.

[sanders3d]

I'm would hope that we could do all of this with right click in the layer editor. In this case I would like to set the "payload.usda" to be a payload. And the "shade.usda" and "geom.usdc" to be usd layers in the payload. At the moment we can do most of this in code but not via the layer editor.

[Ziethriel]

https://youtu.be/v6BczBnYx_M?si=hr-VrEOJCu2RD0Eh

[Ziethriel]

@womanyoyoyo-adsk I was wondering if this UI has been cut, or if it's still in development. This sounds really exciting and would be really helpful, not only for experienced USD enthusiasts, but those new to the concepts as well who are less likely to open the files and try and decipher what's in a file.

[womanyoyoyo-adsk]

Hi @Ziethriel, this UI hasn't been developed yet. We are designing for this work now.

[womanyoyoyo-adsk]

Hello, we've paused this work for now.