I’m dealing with the pinned wrap mode for UsdGeomBasisCurves for the first time, and unless I’ve misunderstood something, there seems to be a bit of a discrepancy between the documentation and the handling in Hydra. The documentation for UsdGeomBasisCurves says the following :
For a curve with initial point P[0] and last point P[n-1], the phantom points are defined as. P[-1] = 2 * P[0] - P[1] P[n] = 2 * P[n-1] - P[n-2].
So, a point is to be added at each end of the curve, with the vector between it and the endpoint being the same as the vector between it and the preceding point.
But HdsiPinnedCurveExpandingSceneIndex instead just duplicates the endpoints in place, adding one duplicate for catmullRom and two for bspline curves. This does cause the endpoints to be interpolated, but with the following differences from the documented method :
A slight difference in shape.
A reasonably significant difference in dPdv, causing textures in V to be somewhat bunched up at the ends.
Additional memory use for bspline curves.
What approach would you recommend to someone needing to do their own evaluation of pinned curves? The documented method seems superior so I’d prefer to use it, but if the HdsiPinnedCurveExpandingSceneIndex is becoming the de facto standard then maybe I should match that?
It would be great to get some guidance here please. Standards are great until different folks start interpreting them differently, and I want to be a good citizen. Should I follow the UsdGeomBasisCurves documentation or the HdsiPinnedCurveExpandingSceneIndex example?
Hi @JohnHaddon , sorry it took some time to get all the ducks in a row. The TL;DR is that you should absolutely go with the UsdGeomBasisCurves specification. We hope to update the HdsiPinnedCurveExpandingSceneIndex code (which hdPrman uses) in a near-term release, and are working with partners to get Storm updated also, though that may take longer.
The replication code in the scene index is an artefact of an early implementation in our pipeline whose behavior has to be matched on our active shows. But we have a plan for how to introduce the new, superior behavior while preserving the existing look internally.
Storm is more complicated because there are real GPU performance/scalability concerns, but folks at NVidia have a great idea of swapping basis functions in the shader to achieve the desired behavior without point-expansion, and are going to try to prototype that. But we may have a gap where Storm behavior differs slightly from renderers that follow the spec. Just rest assured it is our intention of bringing all our supported renderers up to the spec.
Thanks for flagging this issue - it had gotten lost in the deluge
