The AssignMaterial LOP's Binding Strength is super cool for forcing a top-level assignment to descendants (keeping the prim pattern simple).
Is a similar approach possible using RenderGeometrySettings LOP? I have a hierarchy of assets which contain lookdev (i.e. material assignments as well as subdivision/displacement settings). I would like to override the subdivision/displacement attributes on the child meshes inside a parent asset, but would like to avoid a prim pattern that targets each mesh prim, as this is costly. Would much rather target the parent asset alone and have my settings override the child prims? Is this possible? (If something is feasible via Python LOP+pxr API I can do that too)
Opinion Strength for RenderGeometrySettings?
1568 3 2-
- Tim Crowson
- Member
- 250 posts
- Joined: Oct. 2014
- Offline
-
- jsmack
- Member
- 8173 posts
- Joined: Sept. 2011
- Offline
-
- Tim Crowson
- Member
- 250 posts
- Joined: Oct. 2014
- Offline
-
- goldleaf
- Staff
- 4259 posts
- Joined: Sept. 2007
- Offline
Material Bindings are different by nature, not because they are relationships. The binding strength is a characteristic of USD material bindings in general, which I'd agree is pretty cool
Unfortunately, primvars don't have that sort of behavior (that I'm aware of, at least), it's always the closest to the gprim which gets applied. This seems like it should be a pipeline decision/convention, to not put geometry render primvars on the gprims directly, but keep them up near the top of the asset, to make it easier to control. If that isn't possible, then I'm not sure there's any other way apart from targeting their various prims to update the render settings primvars.
If the prim pattern is the expensive part, you could also store the prim pattern result as a collection, which lives with the asset, to expedite tooling to update those render settings somehow.
Hope that helps!

Unfortunately, primvars don't have that sort of behavior (that I'm aware of, at least), it's always the closest to the gprim which gets applied. This seems like it should be a pipeline decision/convention, to not put geometry render primvars on the gprims directly, but keep them up near the top of the asset, to make it easier to control. If that isn't possible, then I'm not sure there's any other way apart from targeting their various prims to update the render settings primvars.
If the prim pattern is the expensive part, you could also store the prim pattern result as a collection, which lives with the asset, to expedite tooling to update those render settings somehow.
Hope that helps!
I'm o.d.d.
-
- Quick Links