Improve point instancer support for primvars #1731
Conversation
…rimvars on point instancer primitives as hydra-accessible primvars. Otherwise instancer-level settings applied as primvars can't be accessed by the delegate, and constant-interpolation primvars can't be used to affect prototypes marked as instanceable (where inheriting primvars doesn't work).
instancers to have their own "settings", which are not expressible as inherited primvars on the prototypes. Because inherited primvars are always constant, they will be exposed on the point instancer as constant interpolation, not instance interpolation.
|
Thank you , @marktucker ! We may need to make some time to think about the more general inherited primvars change, as it reverses a decision we had explicitly made awhile ago. In the interest of addressing the regression with velocities and accelerations ASAP, could we ask you to split this into two separate PR's? |
|
Also, in:
While I understand the second part, I don't immediately see why the prototype itself being an instance changes inheritance behavior any, as today all constant primvars will just inherit down into the (descendant, only, so again yes to part 2) protos, be they instances or not? |
|
Jumping between conversations... we believe it's plausible there are configurations where primvars are not inheriting into nested NI prototypes, but we'd consider that a separable bug needing to be fixed, if so. |
|
Thanks Spiff, I was afraid this would happen :) I put these two together mostly because I thought the second commit would conflict with the first commit if I didn't submit them both at once. As to my argument about inheriting primvars through NI prototypes that you quoted, I could easily be mistaken (thought I saw some behavior that actually wasn't there), or perhaps there is an unrelated bug causing something unexpected to happen in the setup I was testing. But I still hope my other argument for supporting inherited primvars is compelling (in light of the need for constant-value primvars to apply render settings to the PI itself). In particular it seems rather unexpected that in USD an inherited primvar can show up on a point instancer prim, but when you render it, the value is ignored (and instead you would be required to set the primvar directly on the PI prim). Would it be alright if I leave this PR as-is (since it already contains some valuable discussion), but submit a second PR that just contains the commit for registering vel/accel primvars? |
|
Yeah, your plan sounds good, Mark, and that's some good food for thought for us to discuss. What's your level of urgency on this? |
|
Separate pull request created as #1734. Urgency on both of these is not super high, but I'll follow up offline with more details. |
|
Filed as internal issue #USD-7109 |
Description of Change(s)
The scene index emulation scene delegate lost the ability to query velocities and accelerations from point instancer primitives. The first commit here restores that ability by registering velocites and accelerations as primvars on point isntancer prims.
The second commit additionally registeres inherited primvars and constant primvars on point instancer primitives. This allows access to such primvars through the point instancer primitive's HdInstancer. I believe there was also a regression here (as UsdImagingDelegate::Get would have at least pulled out constant primvar values set directly on the point instancer prim). But the support for inherited primvars is new. Constant and inherited primvars on point instancers serve two purposes. One is to allow the render delegate to have instancer-specific settings (karma and other renderers use namespaced primvars for prim-specific settings). A setting on the point instancer itself is not the same as a (inherited) setting on each prototype.
The other use case is allowing a constant-interpolation primvar to be a more efficient representation of a per-instance varying primvar (when the per-instance value is meant to be the same for all instances). Again, this is different than allowing the primvar to inherit down to each prototype because the prototype may be marked instanceable, or may not be a child of the point instancer prim.