🗒️ 3d-research index lesson 02 EN · IT

Lesson 02

'Traditional' splatting: kernels, not parameters

2000–2002: QSplat, EWA Surface Splatting. The problem was resampling, not learning.

Gaussian splatting was not born in 2023: it was born around 2000 with point-based rendering (Rusinkiewicz's QSplat) and formalized by EWA Surface Splatting (Zwicker, Pfister, van Baar, Gross, 2001). The problem was one of signal processing:

The problem in 2001 — you have a surface sampled by a scanner: points with estimated normals and radii. Draw them as single pixels and you get holes and aliasing: you are resampling an irregularly sampled signal onto a grid (the screen). You need a reconstruction kernel.

The EWA solution: attach a Gaussian kernel to each point in the surface domain, project it into screen space — where it stays ~a Gaussian, under a local affine approximation — convolve with an anti-aliasing prefilter, and composite. The "splat" is literally the kernel's footprint on the screen. The Gaussian is chosen for its analytical properties (closed under affine projection and convolution), not because it "explains" the data.

The epistemological point: every parameter is derived from measurement. Position from the scanner, orientation from the estimated normal, radius from the local sample density, color from the point. No optimization: a deterministic pipeline data → kernel → image.

Fig. 1 — interactive. A sampled surface (a sphere with a pattern). In points mode you see the holes between samples — zoom in to make them worse. Switch to splats and widen the radius: the kernels overlap and the surface becomes continuous again. This is traditional splatting: the radius comes from the local density, no training.
Bridge to our project — the splat producer left as a stub in 3d-viewer/lib/producers.py (point→Gaussian with scale from the local density, no training) is exactly this: Zwicker-style splatting on the points of our reconstruction. The flat renderer with pixel-points is instead the "with holes" version you see in points mode.

What's missing for this to become 3DGS

Three things, all in the same direction — turning measured quantities into estimated quantities:

  1. the kernel parameters (position, shape, orientation) become optimization variables instead of quantities derived from the scanner;
  2. color becomes view-dependent (spherical harmonics) and learned;
  3. the number of kernels becomes dynamic (densification/pruning during fitting).

The renderer stays the same (the EWA projection math is reused verbatim) — but it becomes a differentiable layer through which gradients can flow. That is the subject of lesson 04; first, though, we need to understand compositing (lesson 03).