Fix issue where referenced scenes have incorrect UV set attribute name written out.

[ysiewappl]

Hi:

This fixes an issue related to referenced Maya scenes being written out with the incorrect varname attribute for the UV set, as it is being determined incorrectly. You can reproduce the issue by attempting to export the cube in the Maya scene with the reference in it and looking at the resulting USDA (the correct file should have map1 as its attribute name.)

Example:

        def Material "usdPreviewSurface1SG"
        {
            token inputs:usd_scene_orig:file1:varname = "map1"
            token outputs:surface.connect = </usd_scene_orig_pCube1/Looks/usdPreviewSurface1SG/usd_scene_orig_usdPreviewSurface1.outputs:surface>

This issue can be demonstrated with the following two scenes, which essentially amount to a single cube with a texture assigned, and then referenced in another scene:

scenes.zip

If you then export the cube in the referenced scene, you get the following without this fix, and even if you have MAYAUSD_EXPORT_MAP1_AS_PRIMARY_UV_SET set appropriately:

        def Material "usdPreviewSurface1SG"
        {
            token inputs:usd_scene_orig:file1:varname = "st"
            token outputs:surface.connect = </usd_scene_orig_pCube1/Looks/usdPreviewSurface1SG/usd_scene_orig_usdPreviewSurface1.outputs:surface>

This is incorrect, and causes USDView to fail to resolve the texture and display it appropriately.

This fix brings up the issue of "how do we determine which is the correct UV set name to write out"? Since we can imagine a scenario like the following, where a shadingEngine could be assigned to multiple meshes; different meshes could then potentially have different data for their currentUVset plug; how would the exporter know which one to then use for writing out the varname attribute for the file node?

For now, however, we're fixing the most common case, where a single shadingEngine is associated with a single mesh and single usdPreviewSurface material.

[JGamache-autodesk]

Finding UV linkage is indeed a complex task. I did write code to do this in #876 using a Maya command that simplifies life a lot.

However I did introduce the bug you are seeing at the same time by assuming Maya node names would never contain colons. This is not the case in a referencing context.

The fix for the issue you are having requires correcting my assumption in the following code block by properly reassembling the Maya node name:
https://github.com/Autodesk/maya-usd/blob/dev/lib/mayaUsd/fileio/shading/shadingModeExporterContext.cpp#L437
and nothing else. I can submit a PR if you want.

Jerry.

[ysiewappl]

Finding UV linkage is indeed a complex task. I did write code to do this in #876 using a Maya command that simplifies life a lot.

However I did introduce the bug you are seeing at the same time by assuming Maya node names would never contain colons. This is not the case in a referencing context.

The fix for the issue you are having requires correcting my assumption in the following code block by properly reassembling the Maya node name:
https://github.com/Autodesk/maya-usd/blob/dev/lib/mayaUsd/fileio/shading/shadingModeExporterContext.cpp#L437
and nothing else. I can submit a PR if you want.

Jerry.
Hi Jerry:

Thanks for the early reponse! I took a look at the code surrounding this which I wasn't aware of was involved in the mappings and I think I understand the intent behind this a little better now; it still worries me that essentially the UV set name that will win out being written is essentially the one that is being used the most (if I understand the code correctly), which leaves potential for confusing output if an end-user has several meshes with different primary UV set names associated with the same shading engine.

I've gone ahead and updated the code to fix the issue of formatting the node name correctly when a namespace is involved.

Will this work if we are exporting a reference that contains another reference?

You're right; I forgot namespaces will nest. Will change the code as suggested. This is now in 624fa5e35.

[JGamache-autodesk]

it still worries me that essentially the UV set name that will win out being written is essentially the one that is being used the most (if I understand the code correctly)

The most used one will get the first exported material (the one with the original name). But the code will also generate as many materials as there are UV set names to cover, so the result will match what you have in Maya exactly., The unexpected surprise will be in the number of materials created in the USD file. The import tries to re-merge the extra materials if it can detect that they were generated by Maya.
You might want to try the test scene test\lib\usd\translators\UsdExportUVSetMappingsTest\UsdExportUVSetMappingsTest.ma to get an idea how this looks.

[kxl-adsk]

Thank you for the fix @ysiewappl.

FYI. Some internal build stages run after all tests have trouble to complete and this caused PF to come back red. I checked and all jobs have passed, so we don't have to wait for DevOps to unblock the pipeline before merging this change.