Densification and pruning

A COLMAP sparse point cloud might hand the optimiser a few tens of thousands of points to start from; a finished scene routinely has one to several million Gaussians. Nothing in the maths so far explains where the rest come from: densificationTraining-time process that clones and splits Gaussians in under-reconstructed regions and prunes low-opacity ones. is the training-time process that grows and shrinks the Gaussian population as it goes, and it’s also the single biggest reason splat file sizes vary so wildly between two scenes that look similarly complex on site.

Two failure modes, two responses

Every 100 iterations during the densification window (iteration 500 to 15,000 in the reference implementation), the optimiser checks each Gaussian’s average view-space positional gradient, how much moving that Gaussian would reduce the current error, averaged over recent training steps. A high gradient means that Gaussian is under pressure to move because it isn’t explaining the pixels around it well enough yet, and the original 3D Gaussian Splatting paper’s Adaptive Density Control (ADC) heuristic treats a high-gradient Gaussian one of two ways depending on its current size. If it’s small, the region is under-reconstructed: geometry needs more primitives there, so the Gaussian is cloned, an identical copy placed alongside it, and both continue optimising from slightly different starting points. If it’s large, the region is over-reconstructed: one Gaussian is straining to cover an area that actually needs more than one, so it’s split into two smaller Gaussians, their scale divided by a factor of roughly 1.6, initialised near the original’s position and left to separate as training continues.

Pruning: the other half of the balance

Densification without removal would only ever grow the Gaussian count. Every few thousand iterations the optimiser also resets opacities toward a low value, and prunes outright any Gaussian whose opacity has fallen below a small threshold, on the reasoning that a near-transparent Gaussian contributes nothing measurable to any pixel and is safe to discard. opacity pruningRemoving Gaussians whose opacity has fallen below a small threshold during training, on the assumption that a near-transparent Gaussian contributes nothing to any rendered pixel. Keeps splat counts from growing unboundedly alongside densification. is what keeps a scene from accumulating dead weight: Gaussians that briefly helped fit one training view, then became redundant once nearby geometry converged, or Gaussians whose scale grew so large they’re covering empty space no camera ever needed filled. This periodic opacity reset also has a second job: it forces every surviving Gaussian to re-earn its opacity from the current state of the scene, which catches floaters that would otherwise sit at a moderate, stable opacity indefinitely.

Why counts explode in some scenes and not others

Densification runs are driven by gradient magnitude, which correlates directly with how much detail a region still has left to explain. A scene with a lot of high-frequency structure, foliage, patterned brickwork, fine railings, keeps triggering high gradients in those areas long after flatter walls and floors have converged and stopped densifying, which is why two architecturally similar buildings can produce splat files of very different sizes: one might have a garden or ornate facade the other doesn’t. This gradient-driven growth is also known to have a real weakness. A 2024 paper, AbsGS, showed that when two neighbouring Gaussians push each other’s gradients in opposite directions, “gradient collision”, their averaged gradient can look small even though the region is genuinely under-reconstructed, so an over-large Gaussian in a detailed area can survive far longer than it should and show up as persistent blur. AbsGS’s fix, summing the absolute value of each pixel’s contribution to the gradient rather than letting opposite-signed contributions cancel, is now implemented as an optional strategy in widely used training libraries alongside the original heuristic.

A different framing: densification as sampling, not heuristics

The clone/split/prune rules above are hand-designed heuristics, tuned thresholds that work well in practice but were not derived from an underlying theory of what the “correct” Gaussian population should be. A 2024 paper revised through February 2025, 3D Gaussian Splatting as Markov Chain Monte Carlo, reframes the whole Gaussian set as samples drawn from a distribution describing the scene, and replaces cloning and splitting with a “relocation” step that moves low-opacity Gaussians to more useful positions while approximately preserving that underlying distribution, plus a small noise term on position at every step. This removes several of ADC’s tuned constants and, in the libraries that have adopted it as an alternative training strategy, tends to produce more consistent quality across scene types without the same sensitivity to how good the initial COLMAP point cloud was. It’s a sign of where the field has moved since 2023: from “here is a heuristic that worked on our benchmark scenes” toward density control with a more principled justification for why it should generalise.

In practice

If a splat trained from a sparse or low-overlap capture comes out patchy, with obviously under-filled geometry in some regions and reasonable detail in others, that’s densification starved of gradient signal in exactly the areas COLMAP under-registered, not a training-length problem you can fix by running more iterations. And if a scene’s file size is far larger than a similar one you’ve captured before, checking Gaussian count before assuming compression settings are wrong is worth the five minutes: a dense, detailed region can genuinely justify millions of extra Gaussians under gradient-driven densification, and no amount of retuning SOG quantisation will shrink a scene that’s carrying real, warranted geometric complexity.