Hi,

I am trying to assign a unique shader (shading network) to multiple assets, each asset will have a different set of textures with a consistent naming for the shader components. How do I assign the group of textures to a specific asset?, the goal is to avoid duplicating the same shading network setup n times, thinking about a couple of options:

- using a relative texture file path for example: "/path/to/texture/<asset_name>/basecolor.<UDIM>.ext", a primvar "asset_name" is assigned to the specific model/asset and will expand automatically in rendertime.

- to have something similar to the "Material Variation" Node, It needs to be able to target a specific location and edit the texture file path.

what is solaris/usd way to approach this subjects?


Cheers
R.

Hi. I would be keep to see how a setup like this could work as well.

Best

One solution is to use primvars. You author a primvar attribute on each asset, with the value specific to that asset. See attached.

Hi thanks for that! Best

Thanks Rafal this is exactly what I was looking for, now i have a few more questions

1) Ive tried on Karma and it works fine, by switching to Redshift it does not work, is this due to redshift implementation? or do I need to do something differently? Arnold would use a userdata node instead to catch the value of the primvar, would redshift need its own set of nodes to achieve it? do the usd nodes always work across delegates?


2) Assuming to deal with tens or hundreds of textures, what is the an elegant way to put them all together in a sort of texture package assigned to the asset? would be just an automated process to generate those primvar nodes? or is there a different way to assign multiple primvars?

Cheers,
Roberto

1) It doest not work in Redshift because the textures in that example are .pic files (specific to Karma and not handled by Redshift). Try using some other texture files in the Edit Properties nodes.

It's true that in general each renderer will have own geometry data reader shader (eg, like you said, userdata node in Arnold), and therefore only that renderer will produce the desired rendering. But this example has only the standard USD shader primitives, and therefore any USD-complient renderer should render it correctly (except for the file format as I mentioned above).

But, yes, Redshift would have its own set of shader nodes to render it correctly. Both groups of shader nodes (for Arnold and RedShift) would be located in the same network, it's just one group would lead to the first input ofthe Collect VOP node, and the other group would lead to the second input of that node. Each group can use own version of "PrimVar Reader" shader.


2) USD is quite explicit in nature, so you will need to specify each primvar explicitly. If you have hundreds of textures, you could rely on some naming convention, and then use Python LOP or Wrangle LOP to read the directory, process the available files, figure out the USD primitives they correspond to, and set the appropriate primvar attributes on them.

Users seasoned in production will probably have better suggestions, though.

Thanks for the answer, by changing the file with a readable format for redshift doesnt work. In the meantime Ive found out on redshift forum that redshift does not support string type attributes, I did test with other data types successfully just to prove the method but with strings fails. I am wondering if there is another way I can circumvent the missing feature?
R.

Ruspa
redshift does not support string type attributes

It will be hard (ie, impossible) to take advantage of primvars for texture paths, then.

Other approach will involve duplicating shader network, in a sense, which is what you wanted to avoid. However, if you take advantage of material referencing, you are not really duplicating everything. The Assign Material LOP has facilities to achieve just that. See the attached example:
- the geometry does not have primvars, but instead it has (custom) attributes
- the Assign Material LOP reads these custom attributes and computes the material parameter overrides
- if the material prim has input attributes, you can simply override them
- if the material prim does not have input attributes, the Assign Material LOP allows you to specify path to the shader prim inside along with its input attribute to override

The result is a bunch of new materials assigned to geometry pieces. The new materials are referencing/specializing a base material and overriding only the texture file of the base material.

EDIT: Btw, this technique also applies to situations where the shader primitives in the USD material don't have any Primvar Readers to drive the shader inputs that you want to override.