Hey, I'm trying to apply a huge tiled texture set to an object. In mantra everything works fine by creating a texture string on the fly with a snippet vop inside the materialbuilder. But i bought a 4090 the other day and wanted to have a go on this in Karma XPU.


I'm using a string attrib (prims) to assign two different textures to a grid. The material is a karmamtlxsubnet with a usdprimvarreader (to load the texture string) and a usduvtexture (to sample the file). This works on the CPU engine but not XPU.

Loading the texture with a mtlximage node works for both CPU/XPU but i don't see a way to drive the filename with a primvar.

There is an older topic [www.sidefx.com] on this which outlines the issues well, so I'm mostly wondering about the current state.
The 19.5 changelog states that Karma now features [www.sidefx.com] 'Delayed texture loading' and 'On-demand loading of texture tiles and mesh primvars' so sounds like it might handle it.

Is there a way to get this working on XPU?

nvki
There is an older topic on this which outlines the issues well, so I'm mostly wondering about the current state.
The 19.5 changelog states that Karma now features 'Delayed texture loading' and 'On-demand loading of texture tiles and mesh primvars' so sounds like it might handle it.

Is there a way to get this working on XPU?

I don't think that's planned to ever be supported. Mapping an unknown number of textures to the GPU will always be a problem. The preferred way to procedurally bind textures is to instantiate materials with the property on the material changed per texture. Unfortunately, because the texture path is not connectable on the mtlx image node, it makes doing so a major pain. Hopefully the texture path can be come 'connectable' without requiring it to be also 'varying'. (there's not really a way to differentiate those concepts in Houdini that I know of)

jsmack
I don't think that's planned to ever be supported. Mapping an unknown number of textures to the GPU will always be a problem.

isn't this however what on demand loading Brian mentioned in above linked thread is all about?

since you still need this for UDIMs to avoid loading all tiles
which is probably what was already implemented in 19.5

tamte

jsmack
I don't think that's planned to ever be supported. Mapping an unknown number of textures to the GPU will always be a problem.

isn't this however what on demand loading Brian mentioned in above linked thread is all about?

since you still need this for UDIMs to avoid loading all tiles
which is probably what was already implemented in 19.5

deferred loading yes, but I think the list of textures is known in advance even with UDIMs. The problem with primvars is the list of textures is not known before rendering.

jsmack
deferred loading yes, but I think the list of textures is known in advance even with UDIMs. The problem with primvars is the list of textures is not known before rendering.

i get that, in my case there would be no issue supplying a list of textures to load though. Anthough the set of potential candidates is huge (32768), there will ultimately be only around 100 unique textures visible at any time.

unfortunately UDIMs won't cover that source range

So maybe if i partition my geo into GeomSubsets, assign the same mat to them and override the shader inputs with the classic inputs:basecolor primvar thing it would work? Since then the textures are known AND assigned on usd prim level beforehand? or would that require a unique material for each tile?

jsmack
Unfortunately, because the texture path is not connectable on the mtlx image node, it makes doing so a major pain.

yea, that's kinda where the troubles continue. the usdtexture allows the texture path to be connected but has no means of loading a channel/layer of that texture. Mtlximage does, but has no dynamic texture path...

nvki
unfortunately UDIMs won't cover that source range

Its possible to extend the range covered by XPU

default limits are 10x10
But they can be changed via these environment variables (KARMA_XPU_MAX_UDIM_U and KARMA_XPU_MAX_UDIM_V)
https://www.sidefx.com/docs/houdini/solaris/karma_xpu.html#textures [www.sidefx.com]

using the <UDIM> format then V can only go to 10 (U can go to infinity)
eg filepath looks like "myfilename_<UDIM>.png", files look like myfilename_1001.png, myfilename_1002.png etc...

But using the <UVTILE> format, then you can have whatever indexing you want (with no limit to U or V)
eg filepath looks like "myfilename_<UVTILE>.png", files look like myfilename_u3_v5.png etc...

Interesting issue. I think it also shows the potential of solaris, you can bend usd without any plugins and even prototype some extensions.

Afaik the proposed way to resolve this in future is some sort of string interpolation on paths. Which for me is a bit odd, though I see the reasoning. But in realtime which I'm used to texture assets and texture samplers in materials are clearly separated as well as properties and geometry attributes. No filenames of course in shaders or any metadata about loading images.

Anyways I've tried to replicate paths resolving from primvars without mixing UsdShade and MtlX. It's actually possible in solaris currently, but it's indeed hacky.

Steps are:
1. Even though we can't create string input with MtlX it's actually limitation of current houdini integration as jsmack said. We still can connect material inputs and filepaths because UsdShade itself doesn't care. This one currently is available only through python. Also it's about the material input connection, not the connection to PrimVar reader which is not supported anyway
2. Overriding paths is not happening in network but in Assign Material LOP. Surprisingly it's quite smart already and creates correct number of permutations (ie not overriding material for every prim, but for every unique values)

So, it splits materials, but I believe it's the way it's going to work in future, just probably hidden from user. It's like pre-render switch sitting outside shading. This way it's working across HoudiniGL/KarmaCPU/KarmaXPU
The minimal example is in the attachement.
In theory this workflow can be already packed in HDA as a workaround.

I wonder how it'll work out. For example Unity Engine is infamous for their combinatorial explosion in shader variants. Like now users ask for path overriding but then they need to override every other "non-connectable" thing or token in network. If every combination creates a new material and possible shader recompilation there could be an issue.

elovikov
So, it splits materials, but I believe it's the way it's going to work in future

I definitely wouldnt be happy with this being forced on us
Assign Material, while seemingly flexible essentially bakes in the assignment so if the layer with the geo changes and the geo contains different primvar textures this wouldn't work without running through lopnet

great thing about Mantra, either attributes or stylesheets was that the assigment happened at rendertime so technically even if you kept the same .ifd, just changed the .bgeo referenced inside it all still worked

I hope USD will not force us to bake material assignemnts, seems like a step back
one thing is to try to stay compatible with vanilla USD but another to actually be user friendly and productive, ideally it would be both, hopefully USD will have some robust procedural layers

I'm not sure actually how exactly it's going to work.

One thing is that this logic will probably sit in hydra. ie usd file on disk won't contain baked variants, basically for user it's hidden. You just put something like ${primvars:normalMap}.pngor even ${primvars:pathToMaps}/normalMap.png}in your path and then renderer receives material with substitution with uniform primvar on exact prim.

I think it could work. It just rises another questions. Like for example above with 100 boxes, is it 100 materials or not. Also it's obvious to extend this to other things like switches on unified noise, color space tags whatever. That could lead that material polluted with expressions and also hides the fact that it's a template which can be resolved to potentially hundreds materials.

Some reading on the proposal:
https://graphics.pixar.com/usd/release/wp_stage_variables.html [graphics.pixar.com]

I will say that while I can appreciate the desire to put dynamism into path resolution, I'm torn about that being a DCC feature versus a USD feature. USD is already s complicated beast and this will make it more so. Eh, it's inevitable, opinion opinion opinion.

But this is completely unrelated to the OP, so apologies for that.

wow, thanks, didn't see that

so there will be stage context resolution via expression, then possibly hydra context resolution via primvars and then the actual ArResolver

usd debugging will become a thing