Sharing a single Maya reference node across multiple USD variant selections

[jufrantz]

Is your feature request related to a problem? Please describe.

As of maya-usd 0.26.0, when an "autoEdited" MayaReference prim exists under multiple usd variants, maya-usd variant selection will swap maya references this way:

https://github.com/Autodesk/maya-usd/assets/40573039/369029f7-2cf1-4722-89c0-c518fcb414a0

• Upon selecting variantB, a new maya reference node is created for /Scene/Component{Rig=VariantB}/MayaRig MayaReference prim.
• Reference edits made to the previous reference are not applied to this new one.
• The initial rig reference created for /Scene/Component{Rig=VariantA}/MayaRig remains loaded, yet it becomes invisible in both the outliner and viewport.

We aim to leverage this variant pattern to offer multiple levels of detail of rig for the same asset. We want to allow artists to begin with a basic level of detail and later enhance their rig to include additional controllers, deformers, etc. However, the current system falls short as it does not preserve reference edits when switching between different LOD, hindering the ability to switch back and forth efficiently.

Describe the solution you'd like

Our ideal solution would be to maintain a single reference node across all variant selection paths, with the ability to update its file path based on the selected variant. This approach would:

• Ensure that edits to the reference are consistently reapplied,
• Automatically unload data from the previous reference.

If feasible, we are open to developing internally a custom MayaReference reader/updater to achieve this. But, based on my initial understanding, integrating such functionality with the existing PrimReader/Updater logic appears to be complex and not straightforward.

Additional context

Here is the USD scene we used for testing maya reference variants: maya-usd_variant_ref_workflow.zip

As an example, in native maya, this functionality can be achieved through the use of proxy references. This is the method we used historically in animation scenes:

https://github.com/Autodesk/maya-usd/assets/40573039/ffd13d23-6d05-4e9d-a386-0b4c28c9f1c3

Best Regards, Julien

[womanyoyoyo-adsk]

Hi @jufrantz ,

Thanks for the file and the desired workflow. You list multiple issues here and I'll try to have them logged.

Firstly, I've been playing with your provided example and I believe that if the mayaReference prims are named uniquely then the ref edits will apply to the correct Maya Reference. I've fixed this in the attached zip. Inside the variants both MayaReference prims were named 'MayaRig'. This is certainly allowed in USD but it is a limitation of ours right now - the Maya Reference and it's allocated prim get out of sync. Do you mind confirming if the attached zip with unique MayaReference prim names fixes the issue of ref edits not getting applied to the correct ref?

new_variant_ref_workflow.zip

I read your post here #3096 too. Thanks,

Natalia

[jufrantz]

Thank you for your reply @womanyoyoyo-adsk,

I did try your scene with maya-usd-0.26.0. I made small adjustments; I removed these overs under Component in scene.usd to keep mayaAutodEdit enabled. I thought this change might be unrelated.

         variantSet "Rig" = {
             "VariantA" {
                 over "MayaRig1"
                 {
                     bool mayaAutoEdit = 0
                 }

             }
             "VariantB" {
                 over "MayaRig2"
                 {
                     bool mayaAutoEdit = 0
                 }

             }
         }

Unfortunately, it seems to me that the behavior remains the same. In both cases we have 2 reference nodes, each corresponding to a variant selection, and they don't share their reference edits made in maya. @santosg87 mentioned in #3096 that the issue with prims with identical names across different variants has been addressed in maya-usd-0.26.0, this could explain that we get similar results.

Additionally, in the example I provided, I intentionally named the prims the same within both variants, expectating that this could lead to maya reference edits shared across variants.

Thanks once again, Julien

[womanyoyoyo-adsk]

Hi @jufrantz ,

I reread your original post and my apologies for not understanding what you first explained. I've made the video below with a possible solution. I've added a Maya reference in the USD hierarchy and on that Maya reference I've added a proxy. When adding a Maya reference into a USD hierarchy, we are still leveraging all the Maya reference capabilities including the proxy functionality that artists are used to. This solution is a bit different than what you're proposing - the artist would have to switch back and forth on the rig using the old Maya Reference proxy switch, and then to switch to its USD cache the artist would use the variant.

https://github.com/Autodesk/maya-usd/assets/49446314/3a667e12-d016-485f-8930-96a847ec6b60

If no good, I'll check with the team if one Maya Reference node connecting to multiple Maya references in variants is feasible. Let me know what you think.

Thank you!

Natalia

[jufrantz]

Thank you, @womanyoyoyo-adsk , for your suggestion.

It appears that your approach is good for swapping rig LODs. However, our requirements extend to integrating 'rig' variations with other USD variations within our pipeline. For example, we may establish a USD 'modeling' variantSet (modelA, modelB) alongside a Maya 'rig details' variantSet (highDef, lowDef), resulting in four distinct Maya rig files (modelA-highDef-rig.ma, modelB-highDef-rig.ma, modelA-lowDef-rig.ma, modelB-lowDef-rig.ma). The modeling variantSet will also affect USD data and artists should be able to modify it directly in USD without the necessity of switching a Maya proxy separately.

Your proposal, however, made me consider that a system involving a 'proxyManager' node could be partially achieved through a custom maya-usd PrimReader for our specific needs. This approach seems feasible for implementation internally. I'm sharing details in case it contributes to the ongoing discussion. I've experimented with this concept, and it appears partly effective:

1) When an artist selects the 'highDef' rig variant, the custom PrimReader is invoked, generating a reference node e.g. "HighDefFooRN". The PrimReader links it to a proxyManager "FooPM" dedicated to the MayaReference prim.

2) Upon selecting the 'lowDef' variant, "HighDefFooRN" becomes orphaned, and the PrimReader is invoked again by PrimUpdaterManager for this new selection. It creates another reference node "LowDefFooRN" associated with "FooPM". The new maya proxy reference is activated, edits previously made on HighDefFooRN are shared, HighDefFooRN is unloaded, victory !

However, I've encountered a challenge:

3) If the artist now reverts to the 'highDef' rig variant, the PrimReader (and PrimUpdater) isn't triggered anymore since maya data was initially created at 1). The previously orphaned HighDefFooRN is reused unchanged.

In case 3), a further update to Maya data would be necessary, involving merely the re-activation of "HighDefFooRN" once it has been de-orphaned. It seems possible to also monitor USD changes on our end to trigger these "missing" updates, but it might overlap somewhat with the functionality of PrimUpdaterManager, I don't feel comfortable with that.

I'm keen to know whether this is in line with the objectives of maya-usd. Is this a recommended direction for us to pursue? Your insights on this matter would be greatly appreciated.

Julien

[womanyoyoyo-adsk]

Hi @jufrantz,

Do you mind providing an example file of the model with the USD and rig variants? I tried to duplicate the scenario in the attached zip but I do not think I have it right.

example.zip

We haven't seen this workflow before!

Thanks, Natalia

[pierrebai-adsk]

As I understand it, the situation now is that it works for you by using the USD variant notification to do the rig swap? Your only concern is that of the order of these notifications vs the orphaned nodes?

I can tell you that the orphan are switched by listening to these same USD notification about variant switches. I suppose that since we are registering our listener before yours, it happens that the behaviour is in the correct sequence? So your concern is that this is merely chance and not strictly guaranteed?

[jufrantz]

Hello,

Tank you both for your inputs.

@womanyoyoyo-adsk,

Sure, here is an example: nested_rig_variants.zip The interesting file is asset.usd. It defines 3 variantSets:

• animation: which can be either  cache or mayaRig.
• modeling: modelA or modelB. The variantSet is incorporated into both animation variants. For cache, you can get 2 payloads model(A|B).usd
• rigDetails, high or low. This is nested within mayaRig=animation and modeling variants. We can get 4 mayaReferences, namely model(A|B)-(high|low)-rig.ma.

@pierrebai-adsk,

It does not completely work yet. I am currently experimenting with this PrimReader/Updater logic:

• MyPrimReader creates an unloaded proxy reference under its own pull parent. The reference is associated with a shared proxyManager with a proxyTag authored on the prim.
• MyPrimUpdater::shouldAutoEdit() returns true.
• MyPrimUpdater::editAsMaya() activates the proxy reference according to the proxyTag value. This will load the reference and unload previously active (loaded) reference. 

I am trying to implement a custom listener to trigger "missing" updates . My first try is to monitor directly MayaUsdProxyStageObjectsChangedNotice, inspired by PrimUpdaterManager AutoPull feature. The custom listener re-triggers MyPrimUpdater::editAsMaya whenever the pulled prim is modified, allowing for proxy reference swapping when necessary. 

This is operational but very fragile/hacky. The listener gets an appropriate notice (i.e. when the associated dag is un-orphaned), following a modification to CustomData:Maya:Pull:DagPath by OrphanedNodesManager.

I didn't experiment with Ufe notifications yet, but, as you mentioned, I would need to ensure my listener is called after OrphanedNodesManager's, which appears to be challenging at first glance.  

Best regards, Julien

[swillisart]

Just wanted to chime in here to second this as a desired workflow for us as well. re-using a reference node to swap representations is a very modular solution that is utilized by native Maya but not USD payloads. Preserving the existing reference node edits and swapping the underlying data beneath it is required for both LOD and any Archetype/Prototype assets.