[MAYA-106944] mayaUSDExport does not respect mergeTransformAndShape flag if node has children

[wjwilson]

Description When exporting geo from Maya to USD with the mergeTransformAndShape flag, if a node has anything parented under it the transform and shape will not be merged. In the resulting USD the child node will be merged and parented under the parent transform. The parent shape node will be a sibling along side it.

Steps to reproduce Steps to reproduce the behavior:

1. Create two cubes.
2. Parent one under the other.
3. With the parent cube selected run cmds.mayaUSDExport(file="filepath", selection=True, mergeTransformAndShape=True)
4. Resulting USD will be as follows:

   
   #usda 1.0
   (
   defaultPrim = "pCube1"
   metersPerUnit = 0.01
   upAxis = "Y"
   )

def Xform "pCube1" ( kind = "component" ) { def Mesh "pCubeShape2" { etc... }

def Mesh "pCube2"
{
    etc...
}

}

**Expected behavior**
I expect that the parent node will also have its transform and shape merged and the resultant USD would be similar to the following:

usda 1.0

( defaultPrim = "pCube1" metersPerUnit = 0.01 upAxis = "Y" )

def Mesh "pCube1" ( kind = "component" ) etc...

def Mesh "pCube2"
{
    etc...
}

}

**Specs (if applicable):**
 - Windows 10
 - Maya PR117
 - Included plugin and USD library

[santosd]

Hi @wjwilson, thank you for reporting this, I was able to replicate the results you are seeing. @wtelford wondering if you would be able to comment on the results if these are expected or something we should look into fixing?

Thank you.

[santosd]

I created an internal bug for tracking and to get work done on this issue.

[JGamache-autodesk]

A scene built the way you suggest will display almost correctly in usdView:

(
    defaultPrim = "pSphere1"
    metersPerUnit = 0.01
    upAxis = "Y"
)

def Sphere "pSphere1" (
    kind = "component"
)
{
    def Cube "pCube1"
    {
        double3 xformOp:translate = (0, -3, 0)
        uniform token[] xformOpOrder = ["xformOp:translate"]
        def Cone "pCone1"
        {
            double3 xformOp:translate = (0, -3, 0)
            uniform token[] xformOpOrder = ["xformOp:translate"]
        }
    }
}

But you will notice one big issue. The bounding box of the scene will not contain the cube and cone. This is because bounded GPrims are expected to cache the bounds of all children, so USDs bounding box computations will skip the cube and cone. The XForm schema is not bounded, so it will compute the bounding box of all children.

The rule is explained here and implemented here.

This is why UsdMayaWriteJobContext::IsMergedTransform() will refuse to merge the transforms if there are child transform present.

I did notice the same problems trying to fix issues found with some instance import code I am trying to merge. In that case, instances masters can not have merged transforms, and the annoyance I get on import is an extra transform generated for the unmerged shapes. Currently looking for a correct way to detect these shapes since we do not want to create an extra transform node on import.

[mattyjams]

Sorry, just saw this issue go by, but I would also point out that it's strongly discouraged to nest Gprims this way. See rule #1 here: https://graphics.pixar.com/usd/docs/USD-Glossary.html#USDGlossary-Gprim

That's more likely the reason why you're seeing this behavior with export, since we don't consider the hierarchy you're after to be well supported. Maya will obviously let you do this, but at export we try to wrench it back into a supported hierarchy.

[santosd]

Thanks for that info @mattyjams.

[kxl-adsk]

Based on the comment (https://github.com/Autodesk/maya-usd/issues/708#issuecomment-695012836), looks like this is the expected behaviour. Closing the issue. @wjwilson please comment if you have concerns.

[friedererdmann]

Hello, sorry to revive an old report - we currently use spaceLocators in Maya to build hierarchies. I noticed that with spaceLocators that have nested objects underneath we end up with a _shape node in the USD file. As I understand the conversation above, the separation of transform and shape makes sense for geometry that has nested objectes, but I'm wondering if it makes sense for spaceLocators, which for all intends and purposes have empty shape nodes and if those could be stripped on export?