USD: Use "asset" type parameters instead of "string" for filepaths

[Beton1]

Version: gaffer-1.6.18.0-windows
Third-party tools: 3Delight

Description

Gaffer exports USD file paths as "string" type instead of "asset" type. This causes issues when importing the Gaffer USD file to Blender. The correct principled node tree in Blender is created, with texture nodes, but texture file paths are not found. When exporting USD from Blender to Gaffer, the import works without issue. After checking the difference between Blender and Gaffer usda files, the issue was isolated to the parameter type("string" vs "asset").

Steps to reproduce

1. Export USD file with textures from Gaffer either with scene export or USD layer writer
2. Import the file in Blender and check the shader node tree

[johnhaddon]

To be able to round-trip the USD "asset" type, we'll need some way of representing it as IECore::Data. Currently we use a raw StringData, so possibilities seem to be :

• Derive AssetData from StringData. Pros : simple, stuff looking for StringData still works. Cons : yet another type.
• Derive AssetData from Data. Pros : can't think of any. Cons : yet another type, clients needs to handle new type individually.
• Refactor to generalise GeometricInterpretation and apply it on the Data base class, with a new Asset enum value. Pros : GeometricTypedData can be ditched, along with all the problems it has caused, no new type. Cons : some ambiguitity around what interpretations can be associated with what data types, bigger effort.
• Add a separate interpretation to StringData, with String and Asset options. Pros : no new type, less ambiguity. Cons : StringData is no longer TypedData<string>, which is going to be as annoying as V3fData not being TypedData<V3f>.

[boberfly]

Hey @johnhaddon I was thinking about having an analogue to ArResolver for round-trips that go beyond filesystem paths. I haven't investigated the technical details but I am thinking along the lines of a thin wrapper/shim over ArResolver's core functionality with a registry mechanism that just has a 100% Cortex codepath to the existing functionality of file paths without any dependency on USD. IECoreUSD can then add to this resolver registry to all the ones that USD has registered in ArResolver.

It does open a can of worms to all of the codebase though for things like Scene/Image readers and writers or anything that deals with file-pathing, but I think this could be a cool way to integrate with specific pipelines - or just re-use existing registered ArResolver plugins (maybe seamlessly?)

For that reason perhaps making a new asset type isn't such a bad idea?