Is it possible to use a relative path in a primvar to drive the path of a texture? It works well with an absolute path, but setting the path as relative makes the texture disappear.
I have set my path to be relative to the HIP file, to the layer setting the primvar and to the root layer (all three files live in the same folder).
Thanks

F

The best approach in LOPs for all file paths is to specify absolute paths in LOP node parameters. As long as the primvars/attributes have a data type of "asset" (not "string"), the USD ROP should process these absolute paths and turn them into relative paths (relative to the layer where the opinion is being written). I've attached a simple example which shows a few limitations:
1. I couldn't figure out how to make a SOP Import LOP create an "asset" type primvar. It would only create "string" primvars. So I used a Wrangle LOP instead, which provides more control ver the authored data type.
2. The Wrangle LOP didn't provide an easy way to author a uniform-interpolation primvar that I could see, so I had to change the interpolation metadata with a Configure Property LOP.
3. The varying-per-polygon texture only works in Karma, not HoudiniGL. This might be a limitation of USD Preview Surface, which doesn't technically support driving the file path on a Texture shader using a primvar (but Karma makes it work anyway).

I'm going to submit a couple of RFEs to make these tasks easier, but my initial claim about the use of file paths and saving to USD I believe holds true.

Yes! It works!
I just tried it with an EditProperties LOP and an asset property and it also works. This makes it slightly more user friendly than using VEX to create primvars. And it sets the interpolation to "constant" instead of "uniform" which is fine for what I need.
However, it does not work when using the <UDIM> token. The texture simply does not load in Karma.

F

Prior to 19.0.588 there was a bug in Karma that might be relevant:
* Fixed issues in karma when scanning filenames for case-sensitive UDIM patterns.
And prior to 19.0.549 there was another UDIM issue:
* Updated Houdini's USD library. Fixes display of UDIM textures when there is no 1001 tile.

Any chance those are the problem in your setup?

I made some slight modifications to the hip file I posted, renamed the textures to "butterfly.1001.pic" and "butterfly.1002.pic" and it still seems to work (even using 19.0.498, because my simple setup avoids the above issues).

I'm using 19.0.589 so I shouldn't be affected by those bugs.
It works with your new hip file directly in Houdini. But when I save a usd file and load it as sublayer in Solaris, it doesn't work. THe same thing happened with my asset. It worked in the LOP tree, but not when loading back the exported usd file.
In fact, you can see the difference between the two in the primvar value. In the LOP tree, the path is converted to absolute path, and in the usd file it stays as relative.

This was puzzling.

I realized after some digging around that the relative-path loading from the USD file never should have worked in any version of Houdini (or USD in general). USD tries to resolve asset paths by treating relative paths as relative to the layer that contains the opinion. That's why an SdfAssetPAth value will often show up with two values (raw value and resolved value). But to resolve a path, USD insists that the resolved file path actually exist. Since files with "<UDIM>" don't actually exist, the USD asset resolver will never resolve a UDIM asset path. Which makes the render delegate fall back to using the "raw" value. Which is fine when the raw value is a full path, but no good if the raw value is a relative path.

What first confused me (and made me think this should be working) is that there is one narrow case that does work with UDIMs: if you have a UDIM path that is an attribute on a UsdShade node that is part of a material network, then hydra (not USD) will resolve the relative path for you. But in this case, the relative path is in a primvar, not a shader attribute. So even this last-ditch effort by hydra to resolve the relative UDIM path won't work (because hydra doesn't deal with geometry primvars in the helpful way it deals with shader asset attributes).

My confusion was then reenforced because in my 19.0.498 build I have a beta version of the Houdini omniverse connector installed. And when running that version of Houdini, my relative UDIM SdfAssetPaths were being resolved at the USD level (which also made them work through hydra). But that's not standard behavior so I think omniverse must be installing an asset resolver that deals with resolving UDIM files using a similar approach to what hydra does to resolve UDIM paths in material networks. This is why I was seeing very different results from you, even in the scene graph details pane.

But when I realized this might be the problem, I removed the omniverse plugin and now I'm seeing the same (broken, as expected) behavior that you're reporting.

Unfortunately this means I have to take back my original answer and say "no, this doesn't work". You have to make UDIM paths attributes on your UsdShade prims, rather than primvar, or the render delegate won't be able to find them. Or you have to use absolute paths. Sorry for the confusion.

Thanks for looking into this, Mark.

So if I want to file an issue on the USD github, what would it be? I guess the real solution would be to have the default USD asset resolver to resolve the <UDIM> token properly from primvars. Fixing the Hydra behavior would only solve the problem when rendering through Hydra, so that is not a good solution.

We really want this workflow to work with USD since we have been using it for a while in Katana and we are looking to move our lookdev department over to Solaris.

F

Yeah, I can't think of any foolproof way to do this other than as part of the asset resolver.

Hello!
Was there any progress on this, or did you find anything that can solve the issue with relative udim paths?

you can see a thread talking about it on AOUSD.
https://forum.aousd.org/t/texture-map-variants/2005/3 [forum.aousd.org]

We are all waiting for Pixar to implement it correctly in hydra so renderers don't have to deal with this.

F