Hi guys, is there a way to use GeomSubsets as the primitives for the Render Geometry Settings LOP to affect only those primitives from that subset? I'm trying to have a specific set of primitives be tessellated and displaced (I'm using redshift renderer). Or if render geometry settings is not the way to do it, is there a better way to accomplish this? Any help would be appreciated!

GeomSubsets can only be used to bind different materials. Primvars don't even register on subsets, including render settings.

I would avoid using subsets at all, as they are very limiting and known to be buggy.

jsmack
GeomSubsets can only be used to bind different materials. Primvars don't even register on subsets, including render settings.

I would avoid using subsets at all, as they are very limiting and known to be buggy.

Thanks @jsmack

What would be a recommended workflow for a situation like this?

Although geometry subsets are limited in what they can do (assign different materials to different parts of your geometry), AFAIK they do that thing fairly well. We'd be happy to look at any hip files that show them not working for this task...

As to the original question, as @jsmack says, you can't use primvars to set different values on different subsets of a mesh. If your USD data is already authored with subsets, you can use the Split Primitive LOP to split a single Mesh primitive with Geom subsets into a bunch of Mesh primitives. Then you can assign primvars any way you want to those separate meshes. Or if you're generating the geometry data as well, instead of generating geometry subsets (from SOP primitive groups presumably), you can author a path or name attribute on each polygon in SOPs to generate multiple meshes during the import.

mtucker
Although geometry subsets are limited in what they can do (assign different materials to different parts of your geometry), AFAIK they do that thing fairly well. We'd be happy to look at any hip files that show them not working for this task...

As to the original question, as @jsmack says, you can't use primvars to set different values on different subsets of a mesh. If your USD data is already authored with subsets, you can use the Split Primitive LOP to split a single Mesh primitive with Geom subsets into a bunch of Mesh primitives. Then you can assign primvars any way you want to those separate meshes. Or if you're generating the geometry data as well, instead of generating geometry subsets (from SOP primitive groups presumably), you can author a path or name attribute on each polygon in SOPs to generate multiple meshes during the import.

I used the name attribute as you mentioned here and it works well, but I'm happy to learn about the split primitive LOP.
Thanks @mtucker and @jsmack

mtucker
Although geometry subsets are limited in what they can do (assign different materials to different parts of your geometry), AFAIK they do that thing fairly well. We'd be happy to look at any hip files that show them not working for this task...

I may vary well be scared from a memory of instability than aware of any current misbehavior.

Fair enough. But please submit bugs if you hit any such problems in the future (at least if they cause problems with Karma or HoudiniGL - this is an area where a third party render delegate could easily be at fault). Thanks!

mtucker
you can use the Split Primitive LOP to split a single Mesh primitive with Geom subsets into a bunch of Mesh primitives. Then you can assign primvars any way you want to those separate meshes. Or if you're generating the geometry data as well, instead of generating geometry subsets (from SOP primitive groups presumably), you can author a path or name attribute on each polygon in SOPs to generate multiple meshes during the import.

I assume that will not work if you have a single subd geo as splitting that will not result in the same limit surface
also bringing such split geo back to sops (e.g. by downstream departments) for further processing will have different topology than the desired seamless geo
so I'd personally consider splitting geo a last resort workaround or rather not even consider it to avoid issues

not being able to easily author primvar overrides on geom subsets is a big limitation especially since they are so commonly used for material parm overrides

tamte
I assume that will not work if you have a single subd geo as splitting that will not result in the same limit surface
also bringing such split geo back to sops (e.g. by downstream departments) for further processing will have different topology than the desired seamless geo
so I'd personally consider splitting geo a last resort workaround or rather not even consider it to avoid issues

It wouldn't make sense to apply different render settings if the subsets were part of the same mesh. It sounds like in this case, the subsets are different topological meshes, but one organizational mesh.

tamte
not being able to easily author primvar overrides on geom subsets is a big limitation especially since they are so commonly used for material parm overrides

It's only a lack of convenience. There's nothing a geomsubset can represent that a uniform primvar can't. It would be convenient to be able to author indexed primvars, using subsets for the indices.