-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Comments
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.
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? |
...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 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. |
Filed as internal issue #137726. |
Hi Chad, @mrawde and I chatted about this yesterday, and I spent some time reproing and digging a little today. Two high-level points:
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! |
Closing out Maya-related issues -- the Maya USD plugin has been deprecated in favor of https://github.com/Autodesk/maya-usd. |
Wow, this issue really takes me back! So much progress since ~4 years ago. |
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:
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:This prints:
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:
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:
The text was updated successfully, but these errors were encountered: