ArnoldUSD Exported USD/USDA does not package well with USDZip

[ansuter]

Describe the bug When you run ArnoldUSD export from Maya, the USD contents will use string instead of asset for inputs:filename. The result is that when running USDZip, your files don't get packaged when they should.

def Shader "file3"
{
    uniform token info:id = "arnold:image"
    string inputs:color_space = "sRGB"
    string inputs:filename = "D:/images/someimage.png"
    bool inputs:ignore_missing_textures = 1
    color4f inputs:missing_texture_color = (0.5, 0.5, 0.5, 0)
    string inputs:name = "file3"
    color4f outputs:out
}

that string should be

       asset inputs:filename = @D:/images/someimage.png@

Steps to reproduce the behavior:

1. Create a shader, attach a texture to it
2. Export from ArnoldUSD In Maya
3. Run USDZip -a {import-path}.usda {export-path}.usdz
4. List the contents of the USDZ (usdzip -l). The usdz will not reference any of the linked textures that we were expecting.

Expected behavior

1. If you change the string -> asset in a usda file, and run step 3. It'll package all the textures properly and when running usdzip -l will show all of them in the usdzip

Not Working (string inputs:filename):

>usdzip -a D:\scenes\export-with-strings.usda D:\scenes\export-with-strings.usdz

>usdzip -l D:\Scenes\export-with-strings.usdz
scenes/export-with-strings.usda

-- vs -- Working (asset inputs:filename)

>usdzip -a D:\scenes\export-with-assets.usda D:\scenes\export-with-assets.usdz
>usdzip -l D:\Scenes\export-with-assets.usdz
scenes/export-with-assets.usda
scenes/15/projection1-BP_001__backplate.png
scenes/15/projection2-BP_002__backplate.png
scenes/15/projection1-BP_003__backplate.png
scenes/15/projection4-BP_004a__backplate.png
scenes/15/projection5-BP_004b__backplate.png
scenes/15/projection6-BP_004c__backplate.png
scenes/15/projection7-BP_004d__backplate.png
scenes/15/projection8-BP_005__backplate.png
scenes/15/projection9-BP_006__backplate.png
scenes/15/projection10-BP_007__backplate.png
scenes/15/projection11-BP_008__backplate.png
scenes/15/projection12-BP_009__backplate.png
scenes/15/projection13-BP_010__backplate.png
scenes/15/projection14-BP_011__backplate.png
.....

Used Software Versions

[sebastienblor]

Actually, the textures are saved to usd as they would be saved to arnold .ass format in usual exports. And in arnold, the filename is just a string, relative to the options.texture_search_path, because arnold currently doesn't have any notion of "asset".

If the filename was an asset, we would then face another problem, which is that the filename tokens wouldn't resolve : Arnold supports different tokens, like texture<attr:geometry_param>.jpg, or udims, or other things that can only be resolved at render time. With an asset parameter, USD wouldn't be able to resolve the path and this would cause errors, which is a problem that we currently have with UsdTexture. Even if we implemented a file resolver for arnold, we would still have the issue that some of these tokens can only be resolved at render time, because they're different for each geometry assigned to a same shader.

So it's still not clear what would be the best way to get everything working as expected.

Side note, the same problem will happen for all "filenames" in Arnold (volumes pointing to .vdb, standins pointing to .ass, photometric lights pointing to .ies, etc...)

[danbradham]

Any updates on this issue @sebastienblor ?

I was hoping to make our USD assets portable and I thought I'd be able to do so using asset anchored paths. Obviously, due to the reasons you indicated I couldn't use anchored paths!

In an ideal scenario if I exported a USD with Arnold materials, the file paths would be relative to the USD file, that way we could shuttle them anywhere they need to go without breaking the texture links.

[sebastienblor]

Hi @danbradham , no unfortunately we still don't have a solution for this at the moment. As I had explained in the previous comment, the arnold way of handling relative paths is through the options texture_search_path attribute.

Texture filenames are a different paradigm for arnold as compared to usd, because some paths can only be resolved at render time, and with tokens a single filename can "resolve" to different paths in different shading trees. Because of that we can't use the usual asset resolving system in USD, where each filename resolves to a unique path. There is a special case for this in USD explicitely for the UDIM tokens, but it doesn't work well in all cases (see issues we had with that in #1129), and we need to support other tokens that USD doesn't know about.

When you export from Maya, you can set the texture search path in the render settings (tab System) to the root folder of your textures, and then you can disable the attribute "Absolute Search Path" so that the filenames are exported relatively to this path. Then when you move this to a different system/OS, you only need to change the search path (which can also be done in command line with kick), for the filenames to resolve. This is how relative paths are handled in Arnold.

That being said, we're still considering different options to improve this with usd, and maybe switch from string to asset attributes when no tokens are present, so that at least we can support anchored path when no token is used.

[danbradham]

Thanks for the follow-up and suggestions @sebastienblor . Unfortunately, I can't really justify manually adjusting the texture search path. At a base level we have so many assets, all with their own directories, that our texture search path would be absurd. I will say I have a huge appreciation for the Arnold token system in regards to resolving attribute values and other metadata from shapes. I have personally used that on productions in the past to great effect. However, I think I could live without those tokens really. I wonder how many people are using / ABusing the Arnold token system?

Ultimately, I think your proposal of switching to asset attributes when no tokens are present would be invaluable for many users like myself trying to incorporate Arnold and usd in their pipelines today.

Thanks again!

[sebastienblor]

Right, we do know that these tokens are frequently used, from the debug scenes we receive from customers. So it's something we must keep supporting. I created #1163 for that. We also had a ticket for a custom file resolver, which could perhaps also help. Cheers

[asutermo]

Right, we do know that these tokens are frequently used, from the debug scenes we receive from customers. So it's something we must keep supporting. I created #1163 for that. We also had a ticket for a custom file resolver, which could perhaps also help. Cheers

Awesome, glad to see this is still being considered.

[autodesk-oss-arnold-bot[bot]]

Issue synced internally to ARNOLD-13261

[sebastienblor]

The duplicate ticket #1163 was implemented in 7.2.1.0 and should have fixed this issue