Maya usdExport when the top node is locator

[BSalem]

Description of Issue

usdExport in maya is respecting all the selected object hierarchy groups till the root top node and stops evaluating when it finds a locator as a parent, then this is not written out which all wonderful that it assumes that this locator is an asset container or placer that shouldn't be written out.

I just have a suggestion here to add a flag to usdExport that tells whether or not a locator should be treated as group.

Steps to Reproduce

1. make sphere under a locator, export the selected sphere, then the sphere in usd is exported as '/sphere'
   or
2. make sphere under a group, export the selected sphere, then the sphere in usd is exported as 'group/sphere'

System Information (OS, Hardware)

Package Versions

Build Flags

[spiffmon]

Hi Belal,
Interesting... I find that behavior surprising given that this code is the only place we reason about locators, and only to treat them like transforms!

Perhaps relatedly, someone had contacted us about the fact that locators do not round-trip, since they come back in as regular transforms, and also that they have no visual representation in usdview. I don't think we have any open tasks for that, though...

[BSalem]

Hi Sebastian,
yeah.. when I tried to modify a build here for testing, I found nothing mentioning locators other than the one you've shared which is not causing the behavior I meant.
I will try to see if I can do something regarding to the different structure of the exported trees (it's all when using the -sl flag), the problem is that if a locator is a parent of the selected object and this locator is having other transform parents, then all the parent transforms are ignored although this was not expected.

[BSalem]

It turned out that usdExport is not writing a proper Xform type in the transform path definition when exporting the usd, then usdImport just ignores this transform node that didn't have a type.
So, this is either a bug in usdExport where it should set a type on the node path when exporting, or usdImport should assume the undef type as Xform, then create a group (or would be better a locator) accordingly.

The usd in case of a group appears like this:
def Xform "group1" (
....

The same usd in case of a locator:
def "locator1" (
....

so, usdImport cannot know what should it do with the undef type of the path locator1, in usdview and pxrUsdIn in katana, this undef locator is assumed a transform then the hierarchy look correct, but not in maya.

[spiffmon]

Hi Belal, Thanks for digging in further on this! We think there are a few different issues here: 1. Our scene processing is not handling locators properly in some scenarios, resulting in the "typeless def" 2. Our importer does not yet properly handle "unknown prim types". The plan we'd discussed awhile back is to create proxy/pass-through nodes in Maya for them, but we've yet to implement it. 3. We also don't properly round-trip locators in Maya, since when we dp export them at all, it is currently as simple Xforms We are working on #1 for now, which should resolve the issue you are seeing. Cheers, spiff

…

On 12/30/2016 08:50 AM, BSalem wrote: It turned out that usdExport is not writing a proper Xform type in the transform path definition when exporting the usd, then usdImport just ignores this transform node that didn't have a type. So, this is either a bug in usdExport where it should set a type on the node path when exporting, or usdImport should assume the undef type as Xform, then create a group (or would be better a locator) accordingly. The usd in case of a group appears like this: def Xform "group1" ( .... The same usd in case of a locator: def "locator1" ( .... so, usdImport cannot know what should it do with the undef type of the path locator1, in usdview and pxrUsdIn in katana, this undef locator is assumed a transform then the hierarchy look correct, but not in maya. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#129 (comment)>, or mute the thread <https:/notifications/unsubscribe-auth/AF7qaNOB9Zk4WI-G3MIeRCE-g9fWGn5_ks5rNTZFgaJpZM4LWzhC>.

[jtran56]

Filed as internal issue #141760.