A scene is a cloud of Gaussians.

A splat is a Gaussian blob carrying four things: a mean μ (where it sits), a covariance Σ (how it stretches and tilts), a color c, and an opacity α. The covariance is stored factored, Σ = R S S^⊤R^⊤ — a rotation and two scales — so however hard the optimizer pushes the parameters, Σ remains a valid ellipse.

Rendering is nothing more than drawing every Gaussian, sorted by depth, and alpha-blending them front to back. That is the “splatting”. In 3-D, each ellipsoid is first projected to the image plane; here we stay in 2-D, where a splat already is its own projection.

The real contribution of 3-D Gaussian Splatting isn’t the blob — it’s the loop. Render the Gaussians, compare the result with a photo, and backpropagate the pixel error into every parameter: positions drift, ellipses stretch and rotate, colors and opacities settle.

Adaptive density control adds, clones, or splits Gaussians where the representation needs more detail and prunes low-opacity primitives; practical 3DGS training also periodically resets opacity. The rendering core can be summarized in three lines:

So far the camera never moved. But the entire point of a scene representation is that one set of world-space Gaussians must explain every viewpoint. As the ego travels, each splat’s parameters (μ, Σ, c, α) stay fixed — what changes is the projection: the image position shifts with parallax, the footprint scales with 1/depth and skews with viewing angle through the projection Jacobian, splats slide out of the frustum and are culled, and the depth ordering that drives alpha blending reshuffles.

This pose-dependence is exactly the lever SLAM will pull in §4: because the render R(𝒢 ; T) changes smoothly with the pose T, you can differentiate it — and solve for where you are.

In §3 the ego moved, but its pose was always given. SLAM drops that assumption: a sensor moves through an unknown scene, and both the map and the trajectory must be estimated — simultaneously. Gaussian-Splatting SLAM alternates two optimizations against the same differentiable representation:

Tracking: freeze the Gaussians, adjust the current pose T until what the map predicts matches what the sensor just measured. Mapping: freeze recent poses, then insert and refine Gaussians wherever the observation is poorly explained. Frame-to-model alignment can reduce local odometry drift, but it does not guarantee global consistency: model error, weak geometry, dynamics, bad initialization, and uncorrected loops can still move the map away from reality.

The 3-D representation preserves the core primitive but adds substantial machinery: ellipsoids with Σ = R S S^⊤R^⊤, view-dependent color (commonly spherical harmonics), visibility-aware projection, depth sorting, tiled rasterization, and GPU optimization. That fast differentiable renderer is what makes Gaussian maps attractive inside estimation loops.

Systems such as Gaussian-SLAM and SplaTAM use RGB-D images and frame-to-model photometric/geometric objectives, keyframes, and online Gaussian insertion/refinement. Architectures vary: early systems do not all include loop closure or global bundle adjustment, while later work explicitly adds global-consistency mechanisms. Local tracking by itself cannot remove all accumulated drift.

LiDAR methods require sensor-specific rendering and geometry rather than merely swapping one scalar loss. For example, Splat-LOAM refines Gaussian primitives through spherical projection of LiDAR measurements. A differentiable forward model helps, but successful estimation also depends on observability, calibrated noise and sensor models, correspondence or visibility handling, robust optimization, and initialization.