Failed to create UFE scene item for Rprim?

[pierre-ed]

We are confronted to an intriguing issue when mouse-selecting prims in Maya's viewport.

Whenever a MayaUsdProxyShape is directly parented below |world, the mapping from the path from the UFE selection to a valid USD prim from the proxyshape's stage seems to fail, raising the following exception:

// Warning: Failed to create UFE scene item for Rprim '/Proxy_cubeShape_0x1be4a8b0/cube' // 

Strangely enough, putting the proxyshape directly below |world seems like a guarantee for this bug to show up in our scenes: while we can properly select prims from a proxyshape located at |group1|world|proxyshape, we still cannot do the same with |world|group1|proxyshape for instance. Note that our test layer does not contain any prim with a name which could collide with either world or group1.

There are explicit mentions of an expected leading |world in the paths processed by maya_usd. But most of these seem restricted to the case where the macro UFE_V2_FEATURES_AVAILABLE is undefined.

So I guess my question is: At the end of the day, is this specific location in the Maya hierarchy off-limits for proxyshapes for good? Is simply protecting it with a naemspace on our end a viable solution?

Again, thanks a lot for your help and hard work.
Cheers,
---Pierre

Specs

• OS & version: CentOS Linux release 7.6.1810 (Core)
• Compiler & version: gcc (GCC) 6.3.1 20170216
• Maya version: Maya 2022.3
• Maya USD: 0.15.0
• Pixar USD: 21.11

[ppt-adsk]

@pierre-ed to be really clear: do you have an actual transform node at the top level of the Maya scene whose name is "world"?

[pierre-ed]

Hi! Thanks for your reply.

That's exactly it: I have a transform node |world, which directly stores a mayaUsdProxyShape. I attached a screenshot of my scene for clarity's sake. :)

Cheers.

[ppt-adsk]

@pierre-ed you may be running afoul of a backward compatibility feature we put in a while back, which will strip a leading "|world" path component from paths. That backward compatibility is probably no longer needed... But it would be delicate to take it out. Can you rename your top-level transform to anything other than "world"? Apologies for the hassle.

[pierre-ed]

Yes, ensuring backward compatibility is always tricky. :)

I am afraid entirely renaming my top transform is impossible on my end, but I could prefix it with a namespace.
Do you think it would reliably prevent those issues?

Also, I am currently unable to know for sure whether the binaries I am using have been compiled with the macro UFE_V2_FEATURES_AVAILABLE properly defined.
Would those errors persist if it was the case in your opinion?

[ppt-adsk]

Namespacing sounds good, please try it out and report your findings. UFE_V2_FEATURES_AVAILABLE won't change anything, the backward compatibility is in the code since UFE v2.

Once you report back, I'll file an issue from this discussion, I think we should get rid of this "|world" backward compatibility feature and see if anyone complains :)

[pierre-ed]

Thank you for your confirmation.
We'll go with namespacing and let you know if we run into any trouble. :)