primvars:velocities actively pruned in Hydra 2

[robp-sidefx]

The change c55f138#diff-4058391680f6b738982c851862d178868840850626cbaa3ad17c597b6c21014f added rejection of certain primvars in UsdImagingDataSourcePrimvars such that they aren't passed along to the renderer, specifically points, velocities, accelerations.

It's unclear to me from the commit message and/or comments added what the issue with primvars:velocities was, but its active rejection is an issue for us, where we will apply this primvar to Xform prims as a means of expressing the overall velocity of an aggregate of objects.

We'd like to see this rejection trimmed back to just points but, again, admit there may be context we don't understand/appreciate.

[jesschimein]

Filed as internal issue #USD-10623

(This is an automated message. See here for more information.)

[spiffmon]

Hi @robp-sidefx , this was done to keep Hydra true to the UsdGeom OM, which explicitly calls out that normals and widths can be overridden by primvars in certain schemas, but not other intrinsic attributes. We were concerned that you might wind up getting different results from (e.g.) UsdGeomPointBased::ComputePointsAtTime() and the points a renderer actually uses (calculated using a primvars:velocities).

And in what you describe, aren't you effectively saying you're going to get different computed affine transformations over time (in subframes) in the renderers that subscribe to this use of primvars than you would get with standard UsdGeomXformable evaluation?

[robp-sidefx]

the UsdGeom OM, which explicitly calls out that normals and widths can be overridden by primvars in certain schemas, but not other intrinsic attributes.

Sorry, I've somehow missed that, and am now struggling to find it. What should I be reading? :)

aren't you effectively saying you're going to get different computed affine transformations over time (in subframes) in the renderers that subscribe to this use of primvars than you would get with standard UsdGeomXformable evaluation?

Potentially yes, but I don't find that concerning. I'd expect that any values authored were authored for a reason, regardless how minimally or enormously they affect the visual result.

We were concerned that you might wind up getting different results from (e.g.) UsdGeomPointBased::ComputePointsAtTime() and the points a renderer actually uses (calculated using a primvars:velocities).

I think there is already the opportunity for render-time "divergence" from this. Even ignoring the presence & application of velocity/acceleration data, there are cases to be made for interpolating between point positions using linear interpolation, or fitting a spline, or fitting a circular arc, or.....

[jessey-git]

There are 2 very small, blink and you miss, mentions about the primvar:foo precedence "rules":
https://openusd.org/release/api/class_usd_geom_point_based.html#ac9a057e1f221d9a20b99887f35f84480
https://openusd.org/release/api/class_usd_geom_points.html#a6ca7cc8980d11766db4a9a25801db215

Before this issue here I only knew about primvar:normals. The primvar:widths is now news to me too.