Repository navigation
Gaussian splat update - #1570
Conversation
| FloatVectorDataPtr opacitiesData = nullptr; | ||
|
|
||
| pxr::VtValue opacitiesValue; | ||
| if( opacitiesAttr.Get( &opacitiesValue, time ) ) |
There was a problem hiding this comment.
If this fails, we make a PrimitiveVariable with null data, which I think will then trigger the warning about an invalid variable. But if the attribute isn't authored (which I assume would make Get() fail), we don't want to output a warning.
One simple approach to this might be to call readPrimitiveVariable() no matter the type, and then post-convert if we find halfs in there.
There was a problem hiding this comment.
I did the readPrimitiveVariable() and post-convert in 14dad38
There was a problem hiding this comment.
And a little more compact using variableData() in 51680c5
|
I fixed up the half -> float conversion, and tacked on a quick change to the wording of the changelog in 9365c41. Ready for a new look. |
murraystevenson
left a comment
There was a problem hiding this comment.
Thanks Eric, a pair of minor notes inline. It would be good to get this ready for a release today so we can include the Arnold splats support in today's Gaffer release.
51680c5 to
bfbc474
Compare
|
Thanks Murray and John, I touched up the code populating the float opacity vector and the changelog comment. I went ahead and squashed down as well to hopefully be ready to merge. I can get the Gaffer side of the splats updated as soon as the release is out. |
This changes a couple of details of the
ParticleField3DGaussianSplatloading.[]in the primitive variable name forradiance:sphericalHarmonicsCoefficientswas causing problems in Gaffer because the[character is used to start a character class in the string matcher rather than matching literally.HalfVectorDatafor opacities when the USD file provided them. To be consistent with the other Gaussian splats data types (which we always load as float) and to provide a consistent data type to users and renderer backends, we now convertopacitiestoFloatVectorData.I'm not sure if the changelog entries are strictly necessary? I guess we need something to indicate a change, but I'd be happy to simplify the entries if we think this detail isn't helpful.
I'm also not seeing a more compact way of transferring the USD half opacities to
FloatVectorDatawithout an intermediate allocation ofIECore::HalfVectorData. But if I'm missing something in the template magic that would allow that it would be nice to simplify this.Checklist