[MAYA-107682] usdz export writes incorrect texture paths

[dgovil]

Describe the bug

This is an issue that builds on #795.

The resulting usdz file now does contain the texture, but it now contains the entire full path hierarchy to the file instead.
See this screenshot showing the usdz files hierarchy. Note, this could potentially be revelatory for certain people if the hierarchy included project names etc...

The usdz file is attached :
asset.usdz.zip

The resulting usd file inside the usdz also does not point to the correct texture path, instead pointing to the path as it was in the Maya file.

def Shader "file1"
{
    uniform token info:id = "UsdUVTexture"
    asset inputs:file = @../sourceimages/checkerboard.png@
}

The workaround of disabling the block of code mentioned in #795 works to let us workaround this behaviour.

While the change in the #865 partially fixed the original issue so the texture is included, it actually creates a different issue as described here. Apologies for not catching this sooner, as the change in the PR did satisfy a specific part of our pipeline that obscured the second part of this issue. Testing in a fully vanilla environment exposes this next bit which is still problematic.

Steps to reproduce
Steps to reproduce the behavior:

1. Open Maya project from [MAYA-107167] USDZ export writes paths that aren't inclusive to the usdz #795
2. Export usdz file
3. Expand the usdz file and look at the resulting file and USD texture reference path as described above.

Expected behavior
I would expect the texture to be written such that it's using the same relative path as the maya material does, just inlined into the Maya file.
If the texture lives outside the Maya workspace, then it would be best to keep the old behaviour where it was stored in 0/textureName.jpg etc....

Specs (if applicable):

• macOS Catalina and Big Sur
• Compiler version: Apple clang version 12.0.0 (clang-1200.0.32.5) (reproducible on older clang versions too)
• Maya 2018.5 and 2020.0
• Maya USD commit SHA ddcd319
• Pixar USD commit SHA d8a405a1344480f859f025c4f97085143efacb53

[JGamache-autodesk]

Are you using the compatibility='appleArKit' export option? If not, does it fix this issue when you do?

[dgovil]

@JGamache-autodesk I did try that, but it didn't change the results. Still the same issue unfortunately

[JGamache-autodesk]

I am not able to reproduce the issue you are having. Could you expand on how you export the scene by pasting the Maya command that was used for step 2?

[dgovil]

Sure, so I did a fresh build from
345ab28

Maya Workspace: bugreports.zip

Little diagnostic script that exports the file, then prints out the usdz contents and then the texture file path

from maya import cmds
import zipfile
import os
from pxr import Usd
from pxr import UsdShade


path = os.path.join(os.path.dirname(cmds.file(q=True, sn=True)), "asset.usdz")

# Write the file out
cmds.mayaUSDExport(
    f=path,
    exportSkels="auto",
    frameRange=(1,100),
    compatibility='appleArKit'
)

# List the zipfile hierarchy
with zipfile.ZipFile(path) as zf:
    zf.printdir()
    
# Check with USD what the path is
stage = Usd.Stage.Open(path)
prim = stage.GetPrimAtPath("/AssetGroup/Looks/pxrUsdPreviewSurface1SG/file1")
shader = UsdShade.Shader(prim)
tex = shader.GetInput("file").Get()

print(tex)

And the output when run.

The last line shows the texture path on the file prim. This almost matches the Maya workspace except it adds the .. prefix.
To be correct, it should be something like @Users/dhruvgovil/Documents/maya/projects/bugreports/sourceimages/checkerboard.png@assuming the current texture path in the usdz.

The second last line shows the path to the actual texture in the usdz. Previously, this would be in a numerical directory within the zip. e.g. the path would have been: 0/checkerboard.png instead. The numerical directory itself isn't important other than preventing collisions in texture names.

File Name                                             Modified             Size
asset.usdc                                     2020-12-07 10:39:12         2859
Users/dhruvgovil/Documents/maya/projects/bugreports/sourceimages/checkerboard.png 2020-09-23 14:31:38        68309
@../sourceimages/checkerboard.png@

[dgovil]

Okay, so I was running through a debugger, and it seems like the issue may be that the extension type check that is there is getting the incorrect value?

(sorry ignore the refcount highlighting there...the important variable is the cstr representation of the expanded variable)

If I understand the intention here...this block is only meant to run for usda/usdc files, and skip if it's a usdz. However since it's picking up as a usdc extension, it's running and therefore creating the incorrect usdz file?
if (fileExt != UsdMayaTranslatorTokens->UsdFileExtensionPackage)

The usdz writer writes out a temp .usdc file, which is probably what's tripping up the logic here.

[santosg87]

@JGamache-autodesk I am able to reproduce this issue internally as well. we have a Jira item logged for it already.

[JGamache-autodesk]

This bug was reproduced on OS/X, but not on Windows and Linux where the texture path is correct: @0/checkerboard.png@. I will have to find out why OS/X requires a two-step export.

[dgovil]

(I know y'all are out for a well earned holiday break, but posting here before I forget)

Just doing some digging, but in writeJob.cpp in _BeginWriting there's this (condensed) code block:

if (fileExt == UsdMayaTranslatorTokens->UsdFileExtensionPackage) {
        // We don't write to fileNameWithExt directly; instead, we write to
        // a temp stage file.
        _fileName = _MakeTmpStageName(TfGetPathName(fileNameWithExt));
}

_MakeTmpStageName always picks the .usdc extension. I don't see any platform specific code up till this point, so it should happen on win/linux too from a quick skimming of the code.

I'm going to try and put the original file name into the ExportArgs for retrieval later, since I don't see any where that it is accessible otherwise

[dgovil]

I've opened a PR for the fix: #1028

[kxl-adsk]

PR #1028 has been merged. @santosg87 please validate and close this issue.