I've seen a few references mentioning this, but I have still not been able to figure out how to make this work.

I have geometry coming in with a SOP import. I have an attribute 'texture' which is the path to a texture I'd like to use for a given object (this started as material_override, but I wrangled this on the SOP side before bringing it into USD). I've tried a Principled Shader, using a USD primvar reader to read the string into the basecolor_texture input to the principled shader, but it doesn't seem to affect the texture. I haven't been able to find anything in MaterialX that would even suggest this should work.

Any suggestions for this. Ideally, I'd like to get something that can render with XPU, but even CPU would be a good start.

To summarize:

1. SOP import imports the attributes.
   
2. I do have a primvars:texture attribute which is the string.
   
3. In my material network, I have a usdprimvarreader feeding into the principled shader basecolor_texture. This doesn't seem to work, even if using the fallback value.
   

Thanks,
David

Some additional insight.

If I use an Assign Material node, and an override Vexpression of: it does seem to replace my textures. The problem is that it replaces all of them with the same texture.

I tried but this just results on no texture being applied.

I feel like I'm close here.

Ok, I've got this working, at least with the Principled Shader and the CPU Karma renderer.

The 'texture' var was coming over as a string array. Even though I was having the SOP import divide them up into separate primities, the texture var was still an array. This was fixed by using the following vexpression in the Assign Material node:

Any idea if something similar can be done with a MaterialX shader. It'd be nice to be able to see the individual textures in an XPU render.

There's been a bit of discussion in the MaterialX group about texture variation. The issue with MaterialX is that they need to be able to enumerate all textures prior to rendering for some renderers (like GL), so driving a texture with a primvar is not really feasible.
When using Karma and MaterialX, you can intermix Usd Preview nodes and MaterialX nodes (this may not be documented, but it's true). So, you should be able to feed a Usd Primvar reader into a Usd UV Texture then feed that into a Mtlx Standard Surface. This should work with both CPU and XPU.

P.S. It will not work with other renderers though.

When using Karma and MaterialX, you can intermix Usd Preview nodes and MaterialX nodes (this may not be documented, but it's true). So, you should be able to feed a Usd Primvar reader into a Usd UV Texture then feed that into a Mtlx Standard Surface. This should work with both CPU and XPU.

I tried this, and it works great with the CPU renderer, but I just get a dark grey surface when using the XPU renderer. If I just use the USD UV Texture with a fixed name, that does work, but it doesn't seem to work with the primvar reader on XPU.

Thanks,
David

I stand corrected. String primvar support in XPU is still in its infancy.

Any idea on where string primvar support is in the XPU roadmap? I'm trying to decide if I should see if any of this will work in Redshift, or just deal with the CPU renderer for now.

We have used Redshift until December last year with Solaris and USD and until then string variables were not supported there either with no plans to change that (that we were aware of).

PS: Our workaround was to use a switch with all textures loaded in the material and use an integer primvar to select which texture to use. I'm guessing that would work in Karma as well - albeit it limits the scope of how many textures one can reasonably use and it needs to be pre-defined.

d3zd3z
Any idea on where string primvar support is in the XPU roadmap?

The answer to this is more complicated than it might appear.

What you're asking for in essence is not just "when will string primvar support be working in XPU", but actually "when can we have something within a shader trigger the loading of a texture".

That kind of feature is called "on-demand texture loading".

We're looking into this, but it's actually a very large job (given the disconnect of the GPU from the CPU) so will not happen overnight. So perhaps somewhere between 6months -> 1year. But I cannot be certain sorry.

Thanks for the inquiry though.
Its useful to hear that people are attempting this kind of thing
Cheers

brians

d3zd3z
Any idea on where string primvar support is in the XPU roadmap?

The answer to this is more complicated than it might appear.

What you're asking for in essence is not just "when will string primvar support be working in XPU", but actually "when can we have something within a shader trigger the loading of a texture".

That kind of feature is called "on-demand texture loading".

We're looking into this, but it's actually a very large job (given the disconnect of the GPU from the CPU) so will not happen overnight. So perhaps somewhere between 6months -> 1year. But I cannot be certain sorry.

Thanks for the inquiry though.
Its useful to hear that people are attempting this kind of thing
Cheers

For crowd that's a important feature.
Do you know if has been some development in rendering crowds on the gpu (not just talking about Karma here)?
Because It uses a lot of memory...
Last time I used that in Karma (CPU) I couldn't use the agents as instances (or some kind of It) due to some errors when binding the material variations, so I don't know how much that feature can help on the amount of memory needed, but, with that said, I didn't feel much difference from Mantra on the same scenario (although I didn't compare).

I've thought a little more about accessing different textures procedurally on XPU in MaterialX.
Two workarounds exist

1) Use a switch node

So if you had (eg)5 textures, you could simply feed all 5 textures into a switch node, and then drive the selected parameter with an integer primvar.

This does not scale very well, and will slow down with large amounts of textures (especially on CPU device), but its an option

2) Use UDIMs

So udims allow you to specify a grid of textures and then access them procedurally within the shader.
Simply add the integer coordinates of the grid location to your 0->1 UV coordinate to access what texture you want


Attached is an example of both being used

brians
Two workarounds exist

unfortunately people spoiled by properly working solution in Mantra (and possibly Karma CPU) will not be easily satisfied by tedious workarounds, even though may be grateful if a workaround exists that may meet their needs

traditionally, you can literally have 1 shader and then feed it 1000 textures using prim attributes without even touching the geo keeping it packed alembic
it just makes things so easy and effortless to set up especially if named properly

I thought that since engines like Unreal support Virtual Texture Streaming from disk that this is not an issue anymore for GPU and theoretically OGL and GPU renderers could all just stream pixels on demand the same way, but granted I don't know the details so maybe it has some drawbacks that would make it not a viable solution

mark
The issue with MaterialX is that they need to be able to enumerate all textures prior to rendering for some renderers (like GL), so driving a texture with a primvar is not really feasible.

how does it know which UDIMs it will needs if it can't pre-evaluate st primvar?
I assume it will just load all that match the pattern even if they may not be necessary?

tamte
unfortunately people spoiled by properly working solution in Mantra (and possibly Karma CPU) will not be easily satisfied by tedious workarounds, even though may be grateful if a workaround exists that may meet their needs

It is something we're aware of and working towards.

tamte
I thought that since engines like Unreal support Virtual Texture Streaming from disk that this is not an issue anymore for GPU and theoretically OGL and GPU renderers could all just stream pixels on demand the same way,

I'm not sure how Unreal are doing it, but there are two conceptual ways to do this

1) unified memory
https://developer.nvidia.com/blog/unified-memory-cuda-beginners/ [developer.nvidia.com]

We really like the idea, but it comes with issues that currently make it unusable.

The main one is that we cannot access the memory on the CPU if the GPU is doing any work without the application being terminated by the driver. And this means any work at all...
So its impossible for us to use when we have an open system like Houdini with plugins that might also be making use of the GPU as well :/

It also means we'd need to double all our data in memory, so the CPU device could also run.
There are also quite a bit of performance issues when used with Optix.
We're talking to NVidia about potential improvements, but I don't think this issue will resolve itself anytime soon.

2) on-demand loading
https://on-demand.gputechconf.com/siggraph/2019/pdf/sig913-texture-paging-in-optix.pdf [on-demand.gputechconf.com]

This is where we load the textures on demand, which is what NVidia actually recommends (over unified memory).
They even maintain an example library.
This is the one we plan to implement over the next one/two release cycles.

tamte
how does it know which UDIMs it will needs if it can't pre-evaluate st primvar?
I assume it will just load all that match the pattern even if they may not be necessary?

Yes, XPU currently pre-loads all the texture data.
So in this case it will pre-load ALL UDIMs, whether they're needed or not


Brian

Hello, i am wondering if there has been any updates in regards to this. Specifically in regards to XPU.

Bumping this topic to see if this has been updated in Houdini 20.0? It works in CPU but not XPU, is XPU planned?

Bumping this too.
Texture variation like in Mantra is uber useful in procedural stuff.
Any update on the roadmap from staff would be great!

Elliot Stronge
Bumping this topic to see if this has been updated in Houdini 20.0? It works in CPU but not XPU, is XPU planned?

PaoloGiandoso
Bumping this too.
Texture variation like in Mantra is uber useful in procedural stuff.
Any update on the roadmap from staff would be great!

Hi
We are working towards this, but it's hard to say when it will drop.
I doubt in any of the H20 daily releases, so most likely in a future .5 or major release.
Thanks for your patience.

ps:
In the meantime, you could check out the MtlxUDIMOffset node, which allows for shader/primvar-driven texture variation. It converts an integer index to a UDIM coordinate, which loads that corresponding texture from disk. So instead of using a whole-string to load a texture, you can number your textures on disk as 1,2,3 etc... and use an integer prim-var to load it from disk instead. This works with XPU now.

brians
I doubt in any of the H20 daily releases, so most likely in a future .5 or major release.
Thanks for your patience.

Hi
Thanks for the update Brian.
I just checked and it it seems non uniform string primvars are not supported in 20.5 Karma XPU yet unfortunately.
Although, on this [www.sidefx.com] link describing the features of Karma XPU 20.5 I did read "on demand texture loading" is now a thing.

Textures
Textures used by shaders are loaded from disk on-demand in tiles (eg 128×128). They are also loaded into GPU memory on a per-tile basis. If XPU detects the GPU memory as being full mid-render, it will evict non-essential memory and continue rendering. This process will repeat until the render is complete. The GPU will slow down significantly when in this “eviction” state. GPU memory usage can be monitored via the on-screen render stats render stats, as well as showing when eviction has been detected.
GPU tiled/sparse textures can be disabled via the KARMA_XPU_OPTIX_SPARSE_TEXTURES environment variable
Geometry primvar data is also loaded on-demand.

Earlier you wrote:

brians
The answer to this is more complicated than it might appear.
What you're asking for in essence is not just "when will string primvar support be working in XPU", but actually "when can we have something within a shader trigger the loading of a texture".
That kind of feature is called "on-demand texture loading".

brians
This is the one we plan to implement over the next one/two release cycles.

So I do wonder if now that on-demand loading is solved, support for string primvars will follow suit.

brians
In the meantime, you could check out the MtlxUDIMOffset node, which allows for shader/primvar-driven texture variation. It converts an integer index to a UDIM coordinate, which loads that corresponding texture from disk.

Thanks Brian, I am not sure it will work for my case, but it is an option more to keep in mind that is sure.
About this last method, you previously wrote:

brians
Yes, XPU currently pre-loads all the texture data.
So in this case it will pre-load ALL UDIMs, whether they're needed or not

Does it mean this method won't be very efficient, correct?

That is some good investigating

PaoloGiandoso
I just checked and it it seems non uniform string primvars are not supported in 20.5 Karma XPU yet unfortunately.

Unfortunately, we have not had a chance to get this feature into H20.5 as we hoped. But it is a high priority for us, so we're at least aiming for the next release.

PaoloGiandoso
About this last method, you previously wrote:

brians
Yes, XPU currently pre-loads all the texture data.
So in this case it will pre-load ALL UDIMs, whether they're needed or not

Does it mean this method won't be very efficient, correct?

H19.5 had to pre-load everything (so was not efficient at all with UDIMS).
Since H20 we have had on-demand loading, meaning UDIMS are efficient now