[KHR_gaussian_splatting] Proposal to specify anti-aliasing filter

[tomas2211]

Hi, thanks for proposing to bring 3DGS to glTF - this extension looks very promising for interoperability.

While the specification goes into substantial detail on kernel shape, projection, lighting, and rendering order, I noticed that it does not currently address anti‑aliasing behavior. In practice, AA choice significantly affects fidelity, especially across varying viewing distances and resolutions.

The original Inria 3DGS implementation applies a dilation filter (size = 0.3) to the projected 2D ellipse splats, even though this detail is not explicitly discussed in the paper. This behavior can be seen directly in the rasterizer code.

Subsequent work - notably Mip-Splatting: Alias-free 3D Gaussian Splatting by Yu Z. et al. - shows that dilation filtering produces artifacts when changing resolution. They propose replacing the dilation filter with a Mip filter (size = 0.1), which removes these artifacts and ensures resolution‑consistent appearance. Since publication, Mip filtering has been widely adopted e.g.:

• SPZ defines a flag to denote Gaussians trained with antialiasing (=mip filtering) https://github.com/nianticlabs/spz?tab=readme-ov-file#header
• PlayCanvas Engine (SuperSplat): Add AA rendering support to Gsplats playcanvas/engine#7567
• Even in the original Inria repo: https://github.com/graphdeco-inria/gaussian-splatting?tab=readme-ov-file#anti-aliasing

In real scenes, this difference can be visually dramatic. When rendering splats trained with mip filtering, using dilation filtering in the renderer inflates fine structures as distance increases, while mip filtering preserves geometry consistently. The following example of a scene trained with mip filter and rendered with both options shows the effect:

Dilation filter	Mip filter

Proposal - add antiAliasing property

I propose adding a new optional property to KHR_gaussian_splatting that would define both filter type and (optionally) size:

"extensions": {
  "KHR_gaussian_splatting": {
    "kernel": "ellipse",
    "colorSpace": "srgb_rec709_display",
    "sortingMethod": "cameraDistance",
    "projection": "perspective",

    // New property
    "antiAliasing": {
      "filter": "dilation" | "mip",
      "size": <number> // optional
    }
  }
}

If not specified, default size should respect the values proposed by respective papers i.e. 0.3 for dilation and 0.1 for mip.

[tomas2211]

Hi, not sure who's the best person to tag here - perhaps @weegeekps as the author of the KHR_gaussian_splatting PR?

[javagl]

One "high-level" question could be whether this property should be part of the KHR_gaussian_splatting base extension, or whether it warrants its own (new) extension built on the existing one (like #2539 ).

I'm tagging some people in addition to @weegeekps : @NorbertNopper-Huawei @lexaknyazev (even though these are exactly the people who very likely already received a notification from this issue) - maybe they can "dispatch" this further to people who might want to chime in (I'm not good with names)

[NorbertNopper-Huawei]

I suggest to make an own extension out of it, where we collect current methods from papers for doing AA and choose the important ones - also with parametrization - which finally should go into this extension.
Of course, AA and quality is important, however one can render without these parameters and it is mainly related to the ellipse kernel how I understand this. If we would have another kernel, then the parameters are likely not usable for this one.

[tomas2211]

My main concern is simply that the current proposal does not mention anti‑aliasing at all, which leaves a gap in how renderers should interpret splat appearance. If the intent is to align with "vanilla" 3DGS behavior, the specification should explicitly state that the expected AA method is dilation filtering.

At the same time, given how widely mip‑based filtering is now used in practice, it seems reasonable for KHR_gaussian_splatting to support that variability rather than leaving it implicit.

[NorbertNopper-Huawei]

What I am asking myself, if this parameter is up to the renderer and not a data field inside the glTF extension.
I compare it e.g. with anisotropic filtering, which we also do not store in glTF, however the renderer is free to set as wanted.
The key difference is, that the data in this extension is sufficient to render the splat, however it is not defining how to render it.

[javagl]

No strong opinion on my side (due to lack of "depth" of understanding of certain aspects, and how "important" some of these things are). But couldn't this somehow be compared to things like sampler.minFilter = GL_LINEAR_MIPMAP_LINEAR, on a conceptual level?

[NorbertNopper-Huawei]

@javagl Valid point, but the value is more a hint to the renderer (splat should have a minimum size in general) and not the splat itself.

[NorbertNopper-Huawei]

Also, for a raytracer, these values do probably not help.
I think there is maybe a twist how we should think about this.
In glTF, we are also not forcing e.g. to use this tone mapping or MSAA, to achieve a specific visual result. So, this also applies to the 3DGS data. Maybe a hint, yes, but not as a default value.

[tomas2211]

The sampler.minFilter analogy is a good one — it's a piece of information needed to reproduce the result intended by the data author.

I'm actually not sure this should be framed as a hint rather than a requirement. 3DGS data is somewhat special in that many renderer settings from training get baked into the splats in a non-trivial way. The AA filter influences the parameters of the Gaussians - primarily their scale, but potentially also position and rotation. For that reason, I'd argue we should be stricter about specifying these settings, so that renderers produce a visually correct result.

[javagl]

I wasn't entirely sure about that sampler.minFilter analogy, but thought that it might fit insofar that it describes a specific detail about how the binary data (RGBA pixel values) is supposed to be visualized (and ... maybe obvious: it's also about mipmapping...).

The scope of this minFilter is very narrow and well-explored - the possible values for that property are predefined (pretty exhaustively) by the OpenGL spec.

In contrast to that, there might not be so much clarity about the proposed antiAliasing property for splats. My thought is: If something is added to the base extension, then it should be absolutely fundamental, and should make sense forever, in the exact form in which it is defined.

(Admittedly: I even had concerns about the other properties - kernel, colorSpace, sortingMethod, and projection, for this exact reason. They only have a single valid value right now, which looks a bit odd for a "specification". But it was decided to include them, by people who know the field faaar better than I do)

Some questions that I'd ask (and these are "Devil's Advocate" questions - there is no need to answer them here - the important point is that someone who eventually makes the decision should be able to answer them, confidently)

default size should respect the values proposed by respective papers i.e. 0.3 for dilation and 0.1 for mip.

Are there other possible filter values? What are the default size values for them? There are many research papers - and are there papers that proposed a value of 0.31 for a dilation filter? Are there approaches that will need additional properties, beyond filter and size? ...

---

Just as a cross-link: The SPZ format already does contain this information, as the Header defines a set of flags, with the only flag being whether antialiasing was enabled. I assume that this flag would mean antiAliasing: { filter: "mip", size: 0.1 }, for example.

[NorbertNopper-Huawei]

In contrast to that, there might not be so much clarity about the proposed antiAliasing property for splats. My thought is: If something is added to the base extension, then it should be absolutely fundamental, and should make sense forever, in the exact for in which it is defined.

The point is, that we could extend the specification, that it is required, that at single splat does have at least the size of one pixel on the screen. This is the main reason for 0.3 and could be calculated directly and/or be just a constant. Maybe it can be even solved differently.

I also share the concern, that we are just adding a parameter, which is later just a constant or is never changed. That is the reason for having a separate extension for AA, as we do not have the full overview yet and do have a final decision on it.

Also, for the raytracing community, this parameter is obsolete.

Also, related to filtering in glTF, the specification is not very strict:
https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#_filtering
One can always fallback to nearest or linear.

Again, glTF provides the data to render things, but it is not forcing to do it exactly like this. There are normally fallbacks.

Or as a comparison, we also do not store in glTF, the triangle does need a minimum size of 1 pixel and provide some parameter. And from my understanding, this 0.3 is for numerical stability. Even if it improves the visual outcome, it is not anti-aliasing.

[weegeekps]

My gut reaction to this is the same as @javagl and @NorbertNopper-Huawei's: this feels more appropriate in an extension than as a property. My reasoning for this is because my current understanding is that the different AA methods for 3DGS are more than just a constant value. To support these various methods, the shape of what is needed to be stored changes with different antialiasing methods. What Mip-Splatting needs is different than what PrismGS needs.

To me that means one should do one of the following:

• Define an explicit extension for that AA method.
• If a specific kernel specifies a specific AA method, define (or require) that method within the kernel extension spec.
• If a compression method needs to support one or more AA methods, define (or require) those within the extension spec.

The compression one is a very important one when I think about this too. Given how impactful lossy compression can be to certain values within 3DGS, different compressions may have different antialiasing methods that are appropriate.

The ellipse kernel the base extension provides is intended to be as close to the original paper's defined kernel and maths as possible. Adding a note indicating that the ellipse kernel is using dilatation filtering may be useful from a knowledge standpoint, but it's not going to impact an implementation based on the basic ellipse.