Test data sets for `KHR_gaussian_splatting`

[javagl]

This issue is intended for collecting ideas about possible test data sets that could be helpful for the upcoming ratification process of the KHR_gaussian_splatting extension.

Note: The goal of this issue is NOT to collect links to data sets where someone used some Python script to convert some photos into PLY data and somehow convert this to glTF. The primary goal here is to have test data sets that are useful for checking details of the behavior of a renderer, regarding the compliance with the specification, and specifically the behavior of a renderer for splats in glTF.
(Yes, the test data sets could eventually include a few "real-world" data sets. But these should be carefully selected and curated. Maybe they could contain some water or metal surfaces to show the effects of spherical harmonics. Or to put it that way: The real-world data sets that are used for testing should look "nice" - in line with the idea of the "Showcase" assets in the glTF-Sample-Assets repository)

Rotation tests

This is important. The coordinate systems of PLY files - oh dear. The following screenshots show some possible test cases. They all contain "unit cube corners" that are important for illustrating the overall orientation of the data. Beyond that, these tests are

• for rotations around x, y, and z
• each contains 10 rotated splats
• the position of the splats is interpolated between -50 and +50 along the respective axis
• the color is interpolated from "white" to the color for the respective axis
• the scaling factor will be z=3 for the x-axis, x=3 for the y-axis, and y=3 for the z-axis
• the rotation angle will be interpolated from 0 to 90 degrees around the respective axis

Mixing meshes and splats

At the time of writing this, I think that there is no renderer that can read and render glTF files that contain meshes and splats. However, the test cases for the basic functionality could be trivial: An example primitive of a "unit cube splat", and a unit cube mesh. In one case, the mesh is scaled to be half the size of the splats. In the other case, it is scaled to be twice the size of the splats.

Here, previews, showing the splats (left) and the meshes (right). In the first screenshot, one can see the "dots" that are currently rendered by BabylonJS instead of the splats:

Depths tests

A test data set that contains "disc-shaped" splats, ordered from back to front, with slight offsets. This could be useful for checking the sorting behavior of a renderer:

Scaling tests

The goal here would be to make sure that the scaling factors from the splat data are applied properly. The reason why this is tricky: There are different conventions or expectations of whether the scaling factors are given in log-space, or in linear space, and it is easy to mix this up.

So I think that ~"something like this" could be important. But I am not sure what could be a sensible test here. I tried to create an example data set for testing this:

But... this does not really make sense in its current form: There is no sensible place where these white dots could be inserted. The intention here was to place them "at the ends of the (scaled) splat". But the splats do not have an "end". They are infinitely large - at least, in theory. If someone has ideas about sensible tests for the scaling: Chime in...

Spherical harmonics tests

This is important, in order to check whether a renderer properly takes into account the transform matrix of a node that the splats are attached to. The rotation of splats and their spherical harmonics is fairly non-trivial in the most generic case. So the following could be a test for this:

• The test contains six splat mesh primitives
• Each splat mesh primitive contains the usual "cube corner" splats, and a splat at the center, where the spherical harmonics coefficients have been carefully selected so that it looks...
  • red from the right, cyan from the left
  • green from the top, magenta from the bottom
  • blue from the front, yellow from the back
• These primitives are attached to nodes that contain rotations of
  • 0 degrees around x
  • 90 degrees around x
  • 180 degrees around x
  • -90 degrees around y
  • 90 degrees around y
  • 270 degrees around x

This means that in each of the 6 cases, a different side of the "unit splat" is facing the viewer. It should look like this:

Mixed spherical harmonics degrees

It's by no means self-evident that a viewer could handle this. So here is an example that contains the "unit splat" data, once with a spherical harmonics degree of 2, and once with a spherical harmonics degree of 3.

The crucial point for renderers is: They will (likely) have to combine the splats from all mesh primitives into a single set of splats (in one form or another), in order to sort all splats by their distance to the viewer. And they have to cope with the fact that the mesh primitives may contain splats with different spherical harmonics degrees. How they are doing that? That's up to them.

Additional tests

One could create arbitrary combinations of the aforementioned "building blocks". For example, the "Scaling tests" data could be attached to multiple nodes in the glTF, each with a different scaling factor:

This could eventually include non-uniform scaling, or rotations, or whatnot. Other cases that may be considered are animations (specifically: the animation of a rotation of a node that a splat data set is attached to, which might require to perform the spherical harmonics rotations of the splats in each frame...).

Before this is addressed, there should be a clearer idea about the scope of the tests.

---

I occasionally posted some test data sets as ZIP files (e.g. in the extension pull request). But it might make sense to try and collect them in one place, and get a clearer idea about which features should be tested - and how.
(EDIT: See the comments below for the latest state of the data)

[javagl]

An experiment for test data that could be used for checking the scaling behavior.

• It contains 5 sets of splats.
• The sets have scaling factors in x-direction of 0.25, 0.5. 1.0, 2.0, and 4.0.
• Each set contains "many" splats (2 x 2500 for now), covering a range of 10.0 along the y-axis
• The x-positions of the splats are chosen based on the scaling factor

Specifically, the positive/negative offsetX of their position is computed as

float centerOpacity = 1.0f;
float alphaCutoff = 1.0f / 255.0f;
float numStandardDeviations = (float)Math.sqrt(-2.0f * Math.log(alphaCutoff / centerOpacity));
float offsetX = 0.5f * numStandardDeviations * (scaleLinearX + scaleLinearX);

The idea here is: Only when their alpha value is below 1/255, they are supposed to be "really transparent". And these 2500 splats cause a ridiculous "overplotting", so that they are supposed to appear (nearly) fully opaque, even at the border. The result should then look something like this:

When zooming closely to the bottommost ones, it will look like this:

One can see that they are juuust so touching (with literally 1 pixel between them).

When a renderer does not apply the scaling correctly (or does have some unexplained scaling factor anywhere), then they will overlap, or form a gap.

(EDIT: See the comments below for the latest state of the data)

[javagl]

Someone pointed out an error in the example data: The opacity values had been stored with the assumption that they should be in [-Inf,+Inf] (there had been some back and forth in the extension PR). But apparently, the OPACITY accessor should not store opacity, but alpha values (i.e. in [0,1]).

The updated data sets are attached here:

EDIT: For the latest state, see the comments below.

[javagl]

There had been requests to include at least one "real-world" data set in these tests. Of course, everybody will be eager to contribute their data set, saying "Look, our data is one of the 'official' test data sets!". But we'll have to figure out which data set will be included, exactly - and how.

For now, I took one data set that was offered under CC0 license ("Public Domain"), from https://note.com/steam_studio/n/ne9736d94f162 :

The data set is available in different sizes and quality levels. I took the smallest one for now (with ~140k splats), and converted it into a glTF with the KHR_gaussian_splatting extension. The file is ~32MB, which is a bit too large to be attached to a GitHub comment.

EDIT: For the latest state, see the comments below.

If other data sets should be added, then ... well, converting them is not too much efffort...

[NorbertNopper-Huawei]

@javagl That's great, and I think just a few are sufficient.

[NorbertNopper-Huawei]

@javagl Can it be, that the splat are exported with non-linear scale? Can you please also share one with linear scale?

[NorbertNopper-Huawei]

Also, it would be great to add the PLY itself in the ZIP as well.

[javagl]

@NorbertNopper-Huawei You're right. The update had already been pending since we had that discussion ( javagl/JSplat#13 ), but I hesitated to merge it, because the specification has not yet been updated.

However, I now merged it.

Here is the latest state of the "small" test assets, using linear scale:

gltf-splat-examples-2026-03-30-linearScales.zip.zip

The "real world" data set, this 'cactus', has been updated to also use linear scales, and the ZIP now also contains the original PLY file:

https://javagl.de/splats/cactus_splat3_30kSteps_142k_splats-2026-03-30.zip

[NorbertNopper-Huawei]

Works, I can not upload the screenshot here. Will send via 3D Formats.