Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Maya: VariantSets not working with referenced assemblies #61

Closed
chadrik opened this issue Sep 19, 2016 · 6 comments
Closed

Maya: VariantSets not working with referenced assemblies #61

chadrik opened this issue Sep 19, 2016 · 6 comments

Comments

@chadrik
Copy link
Contributor

chadrik commented Sep 19, 2016

To create the assets used in the repro below, I first completed the endToEnd tutorial through the creation of Room_set.usd

To reproduce:

  • Create a pxrUsdReferenceAssembly and point it at Room_set.usd and set it to expanded:

    import maya.cmds as cmds
    n = cmds.assembly(name='testAss', type='pxrUsdReferenceAssembly')
    cmds.setAttr(n + '.filePath', '/projects/usd/tutorials/endToEnd/models/Room_set/Room_set.usd', type='string')
    cmds.assembly(n, active='Expanded', edit=True)
  • select 'NS_testAss:Ball_1' assembly node and open the AttributeEditor: nothing is displayed under VariantSets. 'shadingVariant' should be listed there.

I did a brief investigation, starting from the assembly Attribute Editor template, and from what I can tell the problem stems from the fact that the prim gathered by UsdMaya.GetPrim('NS_testAss:Ball_1') does not take the assembly's primPath attribute into consideration, which is '/Ball' in this case:

from pxr import UsdMaya, Usd, UsdUtils
node = 'NS_testAss:Ball_1'
usdPrim = UsdMaya.GetPrim(node)
print "assembly file:", getAttr(node + '.filePath')
print "assembly prim:", getAttr(node + '.primPath')
print "name:", usdPrim.GetName()
print "variants:", usdPrim.GetVariantSets().GetNames()

This prints:

assembly file: /projects/usd/tutorials/endToEnd/models/Ball/Ball.usd
assembly prim: /Ball
name: /
variants: []

Notice the name of the prim for the assembly is '/' instead of '/Ball'.

If I use Ball.usd and the root prim directly, I get the expected variant set:

stage = Usd.Stage.Open('/projects/usd/tutorials/endToEnd/models/Ball/Ball.usd')
rootPrim = stage.GetPrimAtPath('/Ball')
print "name:", print rootPrim.GetName()
print "variants:", rootPrim.GetVariantSets().GetNames()
name: /Ball
variants: ['shadingVariant']

It might be worth mentioning that when I select the 'NS_testAss:Ball_1' assembly node the following warning is printed in the script editor:

# Warning: UsdMayaReferenceAssembly::computeOutStageDataNS_testAss:Ball_1: Stage primPath '/Room_set'' not a parent of primPath '/Ball'. Skipping variant assignment. #
@chadrik
Copy link
Contributor Author

chadrik commented Sep 21, 2016

I did some more investigation and I may have a solution.

The warning "testAss:Ball_1: Stage primPath '/Room_set' not a parent of primPath '/Ball' indicates the problem.

  1. the root assembly points to Room_set.usd and its default prim is /Room_set
  2. the sub-assembly points to Ball.usd with an explicit prim of /Ball
  3. /Ball is not a child of /Room_set, which ultimately leads to disabling of variant sets

In order for the check to succeed, the sub-assembly should point at the same filePath as its parent, with an explicit primPath that is a child of its parent. e.g. /Room_set/Props/Ball_1

I believe the root of the problem is in usdPreadJob_ImportWithProxies.cpp:

       // If a primPath wasn't specified when importing the top-level USD
        // and the subassembly prim being considered has a reference, make
        // the nested assembly node point to that referenced file directly
        // rather than to the top-level file.
        if (mPrimPath.empty()) {
            std::string refAssetPath = _GetReferencedAssetPath(subAssemblyPrim);
            if (not refAssetPath.empty()) {
                subAssemblyUsdFilePath = refAssetPath;
                subAssemblyUsdPrimPath = SdfPath();
            }
        }

After commenting this out, variantSets appear in the Attribute Editor for sub-assemblies. Why was the above necessary? What would we lose if we removed it?

@chadrik
Copy link
Contributor Author

chadrik commented Sep 21, 2016

...and I found another solution, even easier than the last. We can skip the filePath redirection by explicitly setting the root assembly's primPath to its defaultPrim (this avoids entering if (mPrimPath.empty()) block above):

import maya.cmds as cmds
n = cmds.assembly(name='testAss', type='pxrUsdReferenceAssembly')
cmds.setAttr(n + '.filePath', '/projects/usd/tutorials/endToEnd/models/Room_set/Room_set.usd', type='string')
# must set the primPath!
cmds.setAttr(n + '.primPath', '/Room_set', type='string')
cmds.assembly(n, active='Expanded', edit=True)

Is this how the assembly node is intended to be used, or is it just a workaround for a bug? Still trying to understand when the default behavior is desirable.

@jtran56
Copy link

jtran56 commented Sep 22, 2016

Filed as internal issue #137726.

@spiffmon
Copy link
Member

Hi Chad, @mrawde and I chatted about this yesterday, and I spent some time reproing and digging a little today. Two high-level points:

  1. You've uncovered some prototype behavior (philosophy explained below)
  2. I think there is most definitely a bug in UsdMayaReferenceAssembly::computeOutStageData . The warning "UsdMayaReferenceAssembly::computeOutStageDataNS_testAss:Ball_1: Stage primPath '/Room_set'' not a parent of primPath '/Ball'. Skipping variant assignment." should not be happening, regardless of whether 'primPath' was authored. Not sure what the right fix is, but I'll add the info to the internal version of this ticket.

So, here's the problem we're trying to address (poorly) with this import code: we think there are at least two distinct forms of USD import you'd want to do in Maya. The first, which is the only one in -use (and only very very lightly) in our pipeline right now is "I am importing a usd scene containing prims with asset references on them, and I expect to add some new reference Assemblies, remove some, change namespace, and then export a completely new usd file from the resulting edits.

In this workflow, you don't want a "top-level" assembly that contains all the other assemblies, because that limits what you can edit, and you don't want your exported usd file to have a reference on the top-level prim, either. This corresponds to how we build up sets/environments in Maya: we wind up with a Maya file that has a bunch of xforms defining the set's structure, and the leaves of the dag are pxrUsdReferenceAssemblies referencing assets.

In a workflow that we imagine would be common for pipelines that do layout and animation in Maya, you instead want to import USD as a "Stage" instead of as a reference. Here, you would get an assembly at the top-level, with potentially deeply nested sub-assemblies. The top-level assembly doesn't really want to be a pxrUsdReferenceAssembly, though, it wants to be a "pxrUsdStageAssembly" that has knowledge of (and allows you to target) the top-level subLayers of the composition you are importing. The idea is that when you export this Maya scene, instead of creating a whole new USD composition, we instead send sparse edits to the subLayer of the same stage we imported. This would also trigger the codepath in which the sub-assemblies continue to reference the same file as the top-level stageAssembly, with a nested 'primPath' argument.

Since we aren't yet sure what all the requirements of this second workflow are, we put in a really ghetto way to simulate it, which you discovered - but it still doesn't result in the sparse export.

In addition to the bug that's preventing the "import a set as a set" from working properly, there's another limitation: when we do the "rest filename and primpath" thing, we are dropping all the overrides beneath the rference-root that the set may have on the referenced asset. That would need to be addressed at some point, too, though it's actually tricky to do well.

Your further thoughts on the matter will be appreciated!

@sunyab
Copy link
Contributor

sunyab commented May 29, 2020

Closing out Maya-related issues -- the Maya USD plugin has been deprecated in favor of https://github.com/Autodesk/maya-usd.

@sunyab sunyab closed this as completed May 29, 2020
@chadrik
Copy link
Contributor Author

chadrik commented May 29, 2020

Wow, this issue really takes me back! So much progress since ~4 years ago.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants