The splat pipeline, end to end

Every Gaussian splatA single anisotropic 3D Gaussian, an ellipsoid with position, covariance, opacity and view-dependent colour, used as the basic rendering primitive of a splat scene. Millions of these together, optimised against training images, make up the scene. scene you’ll see delivered on the web passes through the same five stages: capture, Structure-from-Motion, training, compression and web delivery. Each stage has its own failure modes, its own tooling and, in this Knowledge Base, its own part. This article is the map: read it first, then follow the links into whichever stage you actually need to fix or understand today.

Capture

Everything downstream depends on the photos or video you start with: coverage, overlap, exposure consistency and whether the camera formation (ground, drone, or both) actually sees every surface that needs to end up in the scene. Capture mistakes are the most expensive to fix, because nothing later in the pipeline can recover geometry the camera never saw. See Capture strategy for camera formations, overlap targets and drone-plus-ground planning.

Structure-from-Motion

COLMAP (or an equivalent SfM/MVS tool) takes the raw images and solves for two things simultaneously: where each camera was when it took its shot, and a sparse point cloud of the scene those cameras agree on. Both outputs matter to training: the recovered poses tell the trainer exactly which ray each pixel corresponds to, and the sparse point cloud seeds the initial Gaussians before training ever touches them. A weak SfM solve, too few registered images, drifted poses, propagates straight into a noisy or geometrically wrong splat no matter how good training is afterwards. See SfM & COLMAP for what a clean reconstruction looks like and how to diagnose a failing one.

Training

Training is where a scene stops being a point cloud and becomes a splat. Starting from the SfM points, the optimiser fits Gaussian position, covariance, opacity and spherical-harmonics colour against the training images, running densificationTraining-time process that clones and splits Gaussians in under-reconstructed regions and prunes low-opacity ones. passes that clone or split Gaussians in under-reconstructed regions and prune ones that stopped contributing. Whether you drive this through the reference implementation or a GUI tool like PostShot, this is the stage with the most tunable knobs, and the one where scene-specific judgement (how many steps, how aggressive the densification, what to mask out) has the biggest effect on the final result. See Training for how those knobs actually move quality and file size against each other.

Compression

A freshly trained splat is a large, uncompressed pile of per-Gaussian attributes, far too big to stream to a browser as-is. Compressed formats like SOGCompressed splat format storing Gaussian attributes as sorted 2D image grids (typically WebP), giving large size reductions for web delivery. exist to close that gap: SOG sorts Gaussians into a 2D grid so that similar Gaussians sit next to each other, then hands the grid to an ordinary image codec, letting a general-purpose compressor do work a bespoke splat codec would otherwise have to do from scratch. This is the stage with the most direct, measurable effect on load time. See Compression & formats for size and quality trade-offs across formats.

Web delivery

The last stage is the cheapest, by design: a delivery engine like PlayCanvas loads the compressed splat, decodes it back into per-Gaussian attributes, and runs the render pipeline covered in How splats render, project, sort, alpha-blend, every frame. Nothing here should be expensive if the earlier stages did their job; a viewer that stutters is almost always inheriting a problem from capture, training or compression rather than failing on its own terms. See Web delivery for browser-side loading, streaming and performance specifics.

In practice

Treat these five stages as one pipeline with one job, not five independent tools. A problem you can see in the browser almost always has its actual root cause upstream: a hazy patch traces back to under-pruned Gaussians from training, a geometrically wrong wall traces back to a weak SfM solve, and a scene that never looks sharp no matter how you retrain traces back to capture coverage. The rest of this Knowledge Base is organised around that same order for exactly that reason: capture, Structure-from-Motion, training, compression, delivery. Alongside it sit the underlying math, editing and tooling, landmark papers and the glossary, which support every stage rather than belonging to one of them.