Hi,

I´m trying to randomize some textures for a crowd sim with the assign material LOP.
I do have the id (primvars:id) attribute in the parent primitive, but not on the geometry prims which I´m assigning the shader.
The VEX function usd_attrib don´t read the inherited (?) attribute from the parent prim. So…

1. Does the prim really inherit the attribute(s) from the parent prims? (At least, I see It in the scene graph details)
2. Makes sense reading the inherited attribs with the usd_attrib function?
3. Right now, what´s the best approach, copying the attrib from the parent prim or building the path to the parent prim that has the attrib?

Using the “usd_parentpath” function I´ve managed to get the attribute, but the doubt still remains about the inheritance of attributes…

It´s working for the crowd. I´m using random textures to geo subsets and It´s really cool to work this way with LOPs, but (in my mind) It would be easier if I could find the attributes in the child prim instead of getting them from the parent prim that has the attribute assigned to It.
Here I´m using a for loop to transverse to the parent prim.

I have used this approach before and it seems to work, for primvars at least:

Tim Crowson
I have used this approach before and it seems to work, for primvars at least:

from pxr import UsdGeom
stage = hou.pwd().editableStage()
prim = stage.GetPrimAtPath("/path/to/some/prim")
pvAPI = UsdGeom.PrimvarsAPI(prim)
primvar = pvAPI.FindPrimvarWithInheritance("some:attribute:name")
primvarValue = primvar.ComputeFlattened()

That´s cool, thanks! But It would be very good if the vex function could read “with inheritance”

What is the reason for targeting the child prim, instead of the level where the primvar is located?

It doesn't matter where the material is assigned, as the inheritance is a material property.

jsmack
What is the reason for targeting the child prim, instead of the level where the primvar is located?

It doesn't matter where the material is assigned, as the inheritance is a material property.

The reason is: I´m shading crowds. The attribute is in the parent prim and I have to target (to change the shader and textures) a geometry subset, in this case, the skin. Each agent has It´s own skin texture.

Here is the scene. I can´t share the textures, but I´ve stashed the agents so anyone that wants to help can visualize It.

1. In the first image, the assign material is overriding the textures of the skin of the agent “claudia”. We can see the binding of the texture in the scene graph details.
2. In the second image, the target is different, It targets the skin subset of the agent “carla” (AFAIK). So, in my mind, the second assign material should only override the textures of the agent “carla”, not the other one.

I've submitted a couple of bugs thanks to this hip file. One is that I can't load the stash SOP because you didn't share your packed agent definition files. But that's okay… I think I get the gist of the issue from your images. Which leads to the second bug, which is that the Assign Material LOP doesn't necessarily make unique new material names. Your first and second Assign Material LOPs are both creating overridden versions of the source material, but they are both creating a new material with exactly the same path. So the carla material just overwrites the claudia material. It really should detect there is already a material with the auto-generated new name, and make the name unique.

I think you can avoid this issue by using a single Assign Material LOP, using the multiparm in place of the existing chain of Assign Material LOPs. An Assign Material LOP used this way will introduce another level in the scene graph hierarchy that ensures each override material's path is unique.

mtucker
mat_overrides.hipnc (1.5 MB)

Thanks! Sorry about the stash thing, I should´ve checked that before sending.
I wasn´t sure on how solaris was handling the overrides. I thought they were just attributes set on the primitives, not new materials.
Changing the setup to 1 assign material doesn´t solve the problem, but since now I know how Solaris is doing that (thanks again for the info), I found a solution: I duplicated the material and changed the name. It´s not as clean as It could be, but It's working for now!

I´m attaching the agents here, so you can further dig into the file if you want.

Thanks again!

guilhermecasagrandi
Changing the setup to 1 assign material doesn´t solve the problem,

That was fixed just a few days ago, so should work in a daily build.

Also, both `@foo` and `usd_attrib('foo')` read the attribute value directly from the primitive. We may need `usd_primvar()` to evaluate the inherited primvar from parents.

Assign Material LOP creates new Material prims (that specialize the base material) and authors new parm values (overrides) on it, and this ability makes it suitable for overriding parameters of materials that don't have a primvar reader to drive the variation. But, since you are using principled shader, you should be able to use primvars directly on the geoemtry to drive the variation. In this case, you can use Wrangle LOP to author the `primvars:baseColor_texture` on skin of the agents (I think).

rafal
But, since you are using principled shader, you should be able to use primvars directly on the geoemtry to drive the variation. In this case, you can use Wrangle LOP to author the `primvars:baseColor_texture` on skin of the agents (I think).

in the past it wasn't possible to assign primvars to GeomSubset prims, just materials, was this limitation lifted

tamte
past it wasn't possible to assign primvars to GeomSubset prims

Indeed setting a privar on a GeomSubset does not seem to work.

rafal

guilhermecasagrandi
Changing the setup to 1 assign material doesn´t solve the problem,

That was fixed just a few days ago, so should work in a daily build.

Also, both `@foo` and `usd_attrib('foo')` read the attribute value directly from the primitive. We may need `usd_primvar()` to evaluate the inherited primvar from parents.

Assign Material LOP creates new Material prims (that specialize the base material) and authors new parm values (overrides) on it, and this ability makes it suitable for overriding parameters of materials that don't have a primvar reader to drive the variation. But, since you are using principled shader, you should be able to use primvars directly on the geoemtry to drive the variation. In this case, you can use Wrangle LOP to author the `primvars:baseColor_texture` on skin of the agents (I think).

Thanks Rafal,

But the “usd_attrib” VEX function doesn´t seem to get the inherited attribute either (at least for primvars, since we get those kind of attribs with the copy to points LOP).
If you need, I can send you another file.

guilhermecasagrandi

rafal

guilhermecasagrandi
Changing the setup to 1 assign material doesn´t solve the problem,

That was fixed just a few days ago, so should work in a daily build.

Also, both `@foo` and `usd_attrib('foo')` read the attribute value directly from the primitive. We may need `usd_primvar()` to evaluate the inherited primvar from parents.

Assign Material LOP creates new Material prims (that specialize the base material) and authors new parm values (overrides) on it, and this ability makes it suitable for overriding parameters of materials that don't have a primvar reader to drive the variation. But, since you are using principled shader, you should be able to use primvars directly on the geoemtry to drive the variation. In this case, you can use Wrangle LOP to author the `primvars:baseColor_texture` on skin of the agents (I think).

Thanks Rafal,

But the “usd_attrib” VEX function doesn´t seem to get the inherited attribute either (at least for primvars, since we get those kind of attribs with the copy to points LOP).
If you need, I can send you another file.

I think Rafal was referring to hypothetical functionality, not what Houdini does now.

jsmack
I think Rafal was referring to hypothetical functionality, not what Houdini does now.

Correct. I've submitted an RFE 108954 to implement usd_primvar() that will evaluate a primvar, including potential “inherited” values from primitive's ancestor.