We have a tool that creates copies of prims in Solaris. These prims have asset path parameters - which, as I understand it, can be relative to where the layer is saved or absolute.
Creating copies of the master prims works works fine for the houdini scenes (/usd layers) where the master prims are created but once those are saved as usds, sublayered into a new scene and then a copy is created the resulting (copied) asset path will also be relative - however relative to the asset from the file path of the master prim layer --> in the current scene this path will not work anymore.

So I wonder if there is a python way of taking a relative asset path and turning it into an absolute. On the USD ROP, I could turn off "Use relative paths" but I'm guessing they have their reason to be there - so I'm guessing I don't want to ban them altogether.

marcosimonrbl
but once those are saved as usds, sublayered into a new scene and then a copy is created the resulting (copied) asset path will also be relative - however relative to the asset from the file path of the master prim layer --> in the current scene this path will not work anymore.

We generally recommend that you use full paths in all Houdini LOP Parameters that specify file paths, and then turn on "Use Relative Paths" on the USD ROP so that the resulting set of generated USD files can be portable, and easily moved from one directory to another (as long as everything remains in the same relative locations). You certainly _can_ turn off "Use Relative Paths" if you are never going to move your USD files, but you really shouldn't have to. I'm just trying to figure out what you're doing that is causing the asset paths to be relative to the wrong file location...

After sublayering in the USD (with the relative asset references) from disk, how are you creating "copies"? A sample hip file would go a long way here...

Thanks,
Mark

I attached an example, which contains 2 asset setups:
assetA.usd is created in /x/y/z/assetA on disc. It has a texture that lives in /x/y/z/assetA/tx/dif1.exr. In the material setup I reference this texture file as an absolute path, however when I write the usd file of assetA the output processor by default turns that into a relative path --> ./tx/dif1.exr. When I sublayer this assetA.usd into a new houdini scene the texture path I see in the scene graph detail pane is the relative one "./tx/dif1.exr".

Now however, in this new houdini scene, I create a second asset, assetB. With the help of a scripted tool I want to load any existing asset (assetA) and grab the texture from there. So my python script looks at the parameter "input:file" on the shader prim and from the assetA material and there reads the value "./tx/dif1.exr" - however now if I put this as is directly on my assetB shader it does not resolve correctly anymore.

zip file attached contains two subfolders for assetA and assetB. If you only open assetB.hip you'll see the problem.

In your python script, replace `Set(attrA)` with `Set(attrA.resolvedPath)`. Although it doesn't look like it when you print the value, `attrA` is actually an Sdf.AssetPath object, not just a string. An asset path consists of a `path` (which is the exact value as extracted from the attribute) and the `resolvePath`, which is the result of handing the `path` value to the asset resolver, along with information about which layer holds the opinion about the `path`, which allows the resolver to accurately generate the full path to the file. It is this full path that you want to put into assetB so that the Use Relative Paths feature of the USD ROP can work properly and generate the correct relative path to the exr file when writing out assetB's USD file.

Ah great, thanks!

Last question: in the documentation I read that there might not always be a resolved asset path (https://graphics.pixar.com/usd/release/api/class_sdf_asset_path.html#aa3c0d773856b74cc2641846038f06a4e) - is that a possibility in Houdini/Solaris as well or just when writing usd code yourself?

That's a good point. The resolved path will be left blank if the file can't be resolved (i.e. the resolver can't find the file at the location where it thinks it should be given the path). I think the resolved path may also be blank if the original path is in a form that doesn't map to a file on disk (which probably isn't an issue). But technically, if you want to be really conscientious, you should check if the resolved path is empty. If it is you may want to raise a warning, and you should probably set the attribute to the `path` value instead of the empty `resolvedPath`.