EMSUSD-1091 Save and restore non local edit target layer and anonymous layer

[csyshing]

This PR aims to fix issue-3637, the changes include three different but still highly related problems all together, I have split them to cover their own problems and added unit test accordingly:

• 0c28b99:
  • Fixes the non local edit target layer issue by extending stage->GetLayerStack() to be stage->GetUsedLayers() to include reference layers and their sub layers which are not visible in local layer stack;
  • The main code to locate a non local layer when restoring is in copyTargetLayerToAttribute() and findPrimNode() functions in file utils/targetLayer.cpp, it has assumption that: if a non local edit target layer can be constructed by a PrimNode, there must be at least one valid prim path contributes to the final composition, which must be able to find it at the time when reopening, this is the reason the code serializes one reference prim path in copyTargetLayerToAttribute() function at utils/targetLayer.cpp#L141, and will need it to reconstruct the edit target in getEditTargetFromAttribute() function at line 233.
  • We use this logic internally in our pipeline and it's been working fine for us for a few years, we haven't had other use cases to verify if this logic is also useful for other studios, that said, it's arguable a generic solution to fix this 'non local edit target layer' issue.
  • A unit test test/lib/mayaUsd/fileio/testNonLocalEditTargetLayer.py has been provided to demo the typical use case we have.
• 49d0435:
  • Fixes the problem where the root layer was anonymous layer
  • The unit test testStageAnonymousRootLayerInMaya demo-ed our use case in our pipeline that we usually configure and setup the stage (from a URI or in-memory) somewhere else, then we load the stage into Maya by creating the proxy shape and set the .filePath to visualize the content, this is why we have a root layer path point to an anonymous layer id. This commit 49d0435 was trying to correct the .filePath attribute to be the newly created anonymous root layer.
• 06b157d:
  • This is kind of related to the anonymous root layer issue but it's a different case to address if edit target layer was an anonymous sub layer

[csyshing]

Hi @neilh-adsk @wallworm, let me know if you have any chance to take a look, cheers!

[wallworm]

Hi @neilh-adsk @wallworm, let me know if you have any chance to take a look, cheers!

Our team is going to be talking about this early next week.

[seando-adsk]

@csyshing Just to keep you updated. Before proceeding with code review we will creating an internal build and send it to our QA for some testing.
Sean

[csyshing]

@csyshing Just to keep you updated. Before proceeding with code review we will creating an internal build and send it to our QA for some testing. Sean

@seando-adsk No problem and no rush, happy to discuss if any concerns.

[santosd]

Hi @csyshing, During my testing I found an issue where if I lock or mute one of the layers that is above the non local target and save the file. Maya will lock up causing me to need to end the task for Maya to close it out.
Steps to reproduce:

1. I am using the file you provided in the issue you logged: [EMSUSD-1091] Non local edit target layer cannot be saved and restored #3637
2. After running the script I open the USD Layer Editor and either Mute or Lock outer_sub_layer.usda
3. Save the Maya file.
4. Attempt to re-open the Maya file and Maya will just try to load it for a long time until the task just needs to be ended.
   Would you be able to take a look at this?
   This doesn't happen when Non-Local edit targets exist.
   There is a warning "Unresolved edit prim path." and points to the non-local layer.
   I have attached a video showing the issue.

nonLocalTest.mp4

[csyshing]

Hi @csyshing, During my testing I found an issue where if I lock or mute one of the layers that is above the non local target and save the file. Maya will lock up causing me to need to end the task for Maya to close it out.

Hi @santosd , thanks for the feedback, I will be on leave, so probably won't be able to send update soon, but I will take a look as soon as I can.

[santosg87]

On my testing, I also found another issue with the file locks. It seems our current logic for when all layers are locked will bypass this code and take over. CUrrently, our logic deals with situations when all layers are locked, and we target the session layer - if that situation is present, we will force the session layer to be the target, reproducing the original issue.

to reproduce this case:

1. run the first part of the script on [EMSUSD-1091] Non local edit target layer cannot be saved and restored #3637:

import pxr
from maya import cmds
import mayaUsd.ufe

usdFile = '/path/to/example/root_layer.usda'   # See attached zip file

# Prepare the stage
proxyShapeNode = cmds.createNode('mayaUsdProxyShape')
cmds.setAttr(proxyShapeNode + '.filePath', usdFile, type='string')
stage = mayaUsd.ufe.getStage('|world|mayaUsdProxy1|mayaUsdProxyShape1')

prim = stage.GetPrimAtPath("/root/group/sphere/group/sphere")
assert(prim.IsValid()) 

2. Lock all Layers - this should cause the session layer to be targeted, as all layers are locked.
3. run the second part of the snippet code:

# Find the pcp node for the prim
primNode = prim.GetPrimIndex().rootNode.children[0].children[0].children[0]
assert(primNode)
# For this particular case, the layer should be the deepest "geo.usda" layer
targetLayer = primNode.layerStack.identifier.rootLayer
assert(targetLayer)
# Verify target layer that it is **not** in stage layer stack
assert(targetLayer not in stage.GetLayerStack())
# Verify current edit target layer is not the target layer
assert(stage.GetEditTarget().GetLayer() != targetLayer)
# Change edit target layer
stage.SetEditTarget(pxr.Usd.EditTarget(targetLayer, primNode))
# Verify edit target layer
assert(stage.GetEditTarget().GetLayer() == targetLayer)

5. Save the Maya File
6. Reload the file - note that the session layer is now the target, and not the geo layer.

This same behavior will happen if a system lock changes before the maya File is reloaded. which seems to indicate that it's a conflict with our logic on scene load, rather than on file save.

this also seems ot get maya on a state that isn't very stable as i crashed soon after reloading the file.

I was also able to reproduce the crash @santosd mentioned above.
other than those instabilities, i haven't ran into any other major issues.