maya-usd
maya-usd copied to clipboard
[EMSUSD-623] Variant selection that affects MayaReference prim does not update Reference
Describe the bug With an Variant Set on a USD prim, where one variant contributes nothing, and the others each contribute a MayaReference prim with different paths, changing the variant selection does not behave as expected after the first time.
Steps to reproduce
- Load the
asset.usda
layer (attached in zip) - make suremodel.usda
and the two rigs are in the same directory - Expand the proxy in the outliner to the
/cube
prim - - Set the
rig
variant tolayout
. - Observe a rig reference loads
- Set the
rig
variant tonone
- Observe the rig reference did not unload.
- Set the
rig
variant toanim
- Observe the rig reference did not change.
Expected behavior When making a Variant selection that affects the composition of a MayaReference prim, the scene should update accordingly.
Attachments
Specs (if applicable):
- Centos 7
- Maya 2023.3
- Maya USD 0.23.0
- Pixar USD 21.02
hi @ika-rporter, thank you for reporting the issue you are seeing!
I am investigating the behavior on my side, and it seems to be working as expected, unless I am missing something?
https://github.com/Autodesk/maya-usd/assets/3026529/87da8b50-5704-4054-b1a8-1e592235faab
Hi @santosg87
That's interesting. Were you testing against the 0.23.0 build, or against the latest dev? If the later y'all may have already fixed this! :)
Here's a recording of what we're getting. Is it possible there's some MayaReference prim behavior setting we're not aware of?
https://github.com/Autodesk/maya-usd/assets/68026610/11f6fb34-3729-4366-a077-c8f165604771
Hi @santosg87
Rewatching your original video with fresh eyes I realize that no, it's not working as expected. When you switch from rig:layout to rig:anim, it should have remapped the reference so it loaded the animation rig instead of the layout rig. Instead it seems to have just unloaded the rig reference altogether. I'm sorry if that wasn't clear from my original repro steps.
thank you for the info @ika-rporter! I will dig a bit deeper on this to see if we can narrow down the issue. I am not 100% sure we understand the issue itself, but i will try to build a simplified case on our side!
cheers!
@santosg87 Let's see if I can explain it better.
Our Assets have multiple types of rigs available. Each type of rig is contributed via MayaReference under a Variant selection. Using the AL proxy, when you change Variant selection, the reference is replaced with the path for the selected rig variant. This behavior is not present using the Maya proxy - it gets "locked in" on the first rig variant you select.
AH! Thats makes a lot more sense! I was trying to understand the visual behavior, but this understanding makes a lot more sense!
thank you for clarifying! :)
I'm poking at this issue at work today and have found an imperfect workaround. If you use 'Cancel Editing as Maya Data' before you change the variant selection, it behaves as expected when you make the selection.
Hi @ika-rporter, we found the culprit. Both MayaReference prims in your example have the same name of 'rig'. We're going to have a look at this on our side but in the meantime I just wanted to let you know that if you give the MayaReference prims unique names, it works.
Hi @womanyoyoyo-adsk Thanks for looking into that! Unfortunately our pipeline expects/requires the prim to be named /rig. We can look into renaming it but in the short term, our SubtreeInvalidate notice observer will continue to serve as a workaround.
@ika-rporter Ok. Thanks for this feedback. Keep you posted on our fix.
just updating the tag with an internal ticket ID :)
Hi,
We are on Maya2022 and have a similar setup as is reported here where we load a MayaReference on a rig prim. I can't get the reference to load at all. It seems that is is possible due to ufe v3 vs v2 things as the devkit for Maya2022 only works with UFE 2.2.1. Could someone confirm this is the case for Maya2022? Would love to have this still working for Maya2022.
Repro: Open Maya2022 and load this asset in above and try and change to load prim.
To note: This works perfectly fine in Maya2022 with Animal logic's proxyshape which we are running currently but want to move over to the autodesk one.
Centos 7.9 Maya 2022.4 Maya USD 0.25.0 Pixar USD 21.11
Hello,
We're encountering the same issue with MayaReference
within variants, with a similar asset structure, an unique MayaReference
prim with its mayaReference
attribute changed by variant selections.
Our expectation in this scenario is is to get only one maya reference
node created per MayaReference
prim, regardless of the variant selections. This would enable us to swap rig representations while retaining maya reference edits, to switch between multiple levels of rig detail with shared compatible animation. The intended workflow resembles "proxy references" within a native Maya scene.
Additionally, we've encountered another scenario that appears to share similarities beneath the surface. I'm mentioning it here in case it could be addressed alongside #EMSUSD-781. It might be different story, I can file a separate issue if necessary:
We have a custom USD prim schema along with custom UsdMayaPrimReader
and UsdMayaPrimUpdater
with AutoPull
support. We aim to synchronize some of the pulled data with USD, automatically, without user discarding and re-editing. In the reader and/or updater, we would like to have the opportunity to execute "in-place updates" of maya in response to changes in USD. Ideally, we'd like it to happen:
- At Maya scene read time.
- Whenever there are live changes on the pulled prim.
Initially, I had hoped to leverage Reader::Read() or Updater::editAsMaya(), considering that PrimUpdaterManager is monitoring USD in order to autoEdit prims. But, after changing a prim attribute, I've been warned very fast that:
# Warning: Cannot edit an ancestor (|world|stage1|stageShape1/world/customPrim) of an already edited node.
Best regards
@jufrantz what version of MayaUSD are you using? this fix should be available for MayaUSD 0.26.0 and above. :) regarding that second behavior you are encountering, I think logging a new issue would be ideal here, so we can track and discuss the work required for it.
Cheers!
Thank you @santosg87,
I tried maya-usd 0.26 it behaves definitely better than 0.25. Unfortunately it still doesn't meet our needs.
I tested with this files maya-usd_variant_ref_workflow.zip
With rig.usd:
def Scope "Asset" ( prepend variantSets = "Rig" )
{
variantSet "Rig" = {
"VariantA" {
def MayaReference "MayaRig"
{
bool mayaAutoEdit = 1
asset mayaReference = @./rig-variantA.ma@
}
}
"VariantB" {
def MayaReference "MayaRig"
{
bool mayaAutoEdit = 1
asset mayaReference = @./rig-variantB.ma@
}
}
}
}
And I get this behaviour:
https://github.com/Autodesk/maya-usd/assets/40573039/fe64b250-3d93-40be-a6d5-07fcaa4f59c4
- Upon selecting variantB, a new rig reference is created.
- Reference edits made to the previous reference are not applied to this new one.
- The initial rig reference (from variantA) remains loaded, yet it becomes invisible in both the outliner and viewport.
I also tested with this rig structure maya-usd_variant_ref_workflow.2.zip rig.usd:
def MayaReference "Asset" ( prepend variantSets = "Rig" )
{
bool mayaAutoEdit = 1
variantSet "Rig" = {
"VariantA" {
asset mayaReference = @./rig-variantA.ma@
}
"VariantB" {
asset mayaReference = @./rig-variantB.ma@
}
}
}
In this case variant selections failed to create/load the reference, despite the MayaReference prim is correctly composed by USD.
Ideally, we would greatly prefer that a single reference node be maintained for all variant paths, with its filepath updated according to the selected variant opinions. This would enable reference edits to be reapplied seamlessly, and previous reference data would be unloaded, thereby fully satisfying our artists.
As an example, in native maya, this functionality can be achieved through the use of proxy references
:
https://github.com/Autodesk/maya-usd/assets/40573039/1e14caa7-7c5f-40d9-a425-063e8f77f6c7
PS: sorry to hijack your issue @ika-rporter, if we don't expect the same behaviour. I'll file another one in this case.
Cheers
No worries, @jufrantz.
Your issue is different than what we're seeing - in our scenes, Maya doesn't react to changing the variant again after the first selection.
I've opened a new issue for the last concern #3623