Repository navigation
Conversation
Previously we were only reading the number of coefficients that `radiance:sphericalHarmonicsDegree` indicated we should get. In order to preserve data, we now load all of the coefficients possible.
johnhaddon
reviewed
Oct 15, 2026
johnhaddon
left a comment
johnhaddon
left a comment
Member
There was a problem hiding this comment.
Thanks Eric! LGTM, with one simple suggestion for strengthening the tests. Could you fix that while squashing in your fixup commit please, and then I think we're good to go...
Comment on lines
+5286
to
+5296
| self.assertEqual( readPoints["type"].data, typeData ) | ||
| self.assertEqual( readPoints["P"].data, positionsData ) | ||
| self.assertEqual( readPoints["orientations"].data, orientationsData ) | ||
| self.assertEqual( readPoints["scales"].data, scalesData ) | ||
| self.assertEqual( readPoints["opacities"].data, opacitiesData ) | ||
| self.assertEqual( readPoints["projectionModeHint"].data, projectionModeHintData ) | ||
| self.assertEqual( readPoints["sortingModeHint"].data, sortingModeHintData ) | ||
| self.assertEqual( readPoints["radiance:sphericalHarmonicsDegree"].data, degreeData ) | ||
| for i in range( 0, nCoefficients ) : | ||
| self.assertEqual( readPoints[f"radiance:sphericalHarmonicsCoefficients:{i}"].data, coefficientsData[i] ) | ||
| self.assertEqual( readPoints["Cs"].data, displayColorData ) |
Member
There was a problem hiding this comment.
Seeing each property tested individually made me wonder if something would fail if we did self.assertEqual( readPoints, cortexSplats ). It seems that passes though, so since it is a stronger test I think it's worth doing that instead.
ericmehl
force-pushed
the
gSplatsWrite
branch
from
October 15, 2026 13:29
622f596 to
ca72db1
Compare
Collaborator
Author
|
Thanks @johnhaddon! I firmed up that test and squashed everything down. I'll wait to push the merge button, but it should be ready to go. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds write support to USD for
ParticleField3DGaussianSplatobjects.It also changes the reading of
ParticleField3DGaussianSplatslightly. Previously, we were only loadingradiance:sphericalHarmonicsCoefficientsthat theradiance:sphericalHarmonicsDegreeindicated were used. That meant you would not load data if the degree indicated fewer coefficients were used than what were present( # coefficients = ( degree + 1 ) * ( degree + 1 ) ).Now we're treating the degree and the coefficients as more-or-less independent quantities. They are related though, so I'm warning if they don't agree and continue loading.
Writing has some similar edge cases that might be worth more discussion. Since we're collecting the
ParticleField3DGaussianSplat:#primvars into a single vector, some decisions need to be made if the data isn't formatted correctly. My goal is to keep as much data as possible to let the user make fixes if needed. I believe the only data that will be lost from this code is if a coefficients primvar has a valid index (likeParticleField3DGaussianSplat:15) but non-V3fVectorDatatype or non-Vertex interpolation. The fallback in that case is ideally to write the data out as a separate variable, but to USD the:#suffix gets interpreted as a namespace with a number as the name and it is warned as being invalid.Perhaps we should not emit our own warning and let USD complain? The
ParticleField3DGaussianSplat:#format is something of our making, so my thought is we should be the ones making the warning.Checklist