Hi;

I'm really struggling hard to wrap my head around a conceptual issue I'm having with USD/Solaris.

I have a setup where I'm procedurally scattering a bunch of trees around a patch of ground. The way I'm doing this is firmly rooted in pre-Solaris Houdini thinking:

• In SOPs, I have a Python node that looks at a folder of tree models I have on disk. It randomly selects a model, and sets primitive string attributes to the texture files needed for this tree (let's call this string attribute "basecolor_texture"). THe trunk/leaves each get their own shaders.
  
• I use Copy/Stamping to iteratively do the above step over a number of points. My material assignment happens on the left side of the Copy node, at what I'm considering a per-tree level. A critical reason that I use copy-stamping is that I'm procedurally-modifying each model before I stamp it to add variation. This extends beyond simply randomizing color or N or whatever - I'm doing significant geometry modifications, which is the thing that keeps me away from using the Instancer node in Solaris (I'm unsure how to modify geometry using the Instancer).
  
• What I end up with is a bunch of polygons, each of which have unique values for "basecolor_texture" at a primitive level, as well as unique shop_materialpath attribute values.
  

I can append a "name" node after the Copy/Stamping to create a name for this conglomeration of trees. In Solaris, I see a single prim in my Scene Hierarchy, with GeomSubsets that seem to correspond to the shop_materialpath attributes (so, a subset for the geometry that has a leaf shader assigned, and a different subset for trunks).

I can also see a primvar for the basecolor_texture string attribute on this one prim...it's a big list, it looks like it's per-point. Karma and the principledShader seem to be able to make sense of this, but MaterialX and Redshift cannot - elsewhere on these forums I'm told that this approach is not so great for MaterialX, so I'm trying to rethink how I do this.

While I'm not explicitly using the Instancer node in Solaris, I understand that what I am doing is - at least conceptually - instancing. I'm doing it in Sops though, rather than at the USD/Stage level. I'm aware my scene hygiene could be better - I think I want to be naming each individual tree, on the left side of the Copy node, rather than naming everything in one big blob afterwards, right? This should yield one USD prim per tree, which seems like tidier scene hygiene.

What I can't wrap my head around is how to manage the material assignment, and setting the paths for my textures. Ideally I would use a single shader for this...does this happen inside Sops and get pulled into Solaris? Or better to do the material assignment in LOPS? If the latter, how do I get the texture paths into a form that makes the various renderers happy (which is to say - I think - one constant basecolor_texture value per USD prim, rather than the per-point primvar that I seem to have now)?

dhemberg
I understand that what I am doing is - at least conceptually - instancing.

Nope, it's not instancing since the geometry is one giant primitive soup. Even if it were individually named primitives, it still wouldn't be instancing unless the geometry is instanced. Creating packed geometries in sops can translate as instances in solaris.

dhemberg
I can append a "name" node after the Copy/Stamping to create a name for this conglomeration of trees. In Solaris, I see a single prim in my Scene Hierarchy, with GeomSubsets that seem to correspond to the shop_materialpath attributes (so, a subset for the geometry that has a leaf shader assigned, and a different subset for trunks).

Using one name makes a single mesh, using geomsubsets for material assignments. The prim attributes for texture paths turn into a 'uniform' array attribute (per face). This works with the karma principled shader, but like you said some renderers don't support driving texture paths with shaders.

The USD way would be to create a material per texture path value. The material can be a reference to an existing material with an over. One way to create "referenced materials with layering" is to use material overrides to set the texture path rather than primitive attributes. This is still limited to the principled shader, but it demonstrates the layering.