Setting Primvars on Materials

At Siggraph this year, it was pointed out that USD supports authoring primvars on the Material prim, as a way to improve discoverability, and in essence to author a “fallback” primvar value the material would use unless the geometry itself provided the same primvar.

I’ve tried this with the latest USD, but I can’t get the described behavior to work. The material (/World/Materials/preview_material_primvar_on_mtl) has primvars:displayColor set to a pink color. However Storm only draws the green fallback value, as authored on /World/Materials/preview_material_primvar_on_mtl/usdprimvarreader1.

Am I missing something else, that would enable primvars-on-material to work as outlined? Or perhaps I misunderstood? I also tried blocking the fallback value on the primvar reader, but that just gave 0,0,0 as the color.

Thanks!

mtl_primvar_test.usda (2.5 KB)

1 Like

Hey @chris.rydalch , can you try hdPrman? I’m afraid this feature was deployed on an “as needed to get final renders to match with Katana” basis, and possibly a Storm implementation was overlooked. Also, does H1/H2 make a difference? If H2 also does not work, can you file a GitHub Issue for Storm? :pray:

Did you try to use the “official” type color3f[] instead of float3[]?

Thanks @spiff, Hydra2 does indeed make the difference. With USDIMAGINGGL_ENGINE_ENABLE_SCENE_INDEX=1 Storm correctly recognizes primvars:displayColor on the Material, and that value gets replaced by “more local” primvars on or inherited by the gprims.

I haven’t had a chance to test with hdPrman yet, but seeing it work with Hydra2 and Storm is good enough conformation.

@ThomasKumlehn I’m not sure why it shows “float3” on the left-side of usdview, because the data is color3f (see Meta Data on the right)… but in any case Hydra2 seems to be the key.

Thanks!

I suspect that this is because the underlying value does not store semantic roles. Semantic roles only get encoded in the typeName field.

The typeName ought to be enough of a hint though?