CloudSignal AI

Blog

Gaussian splatting grows up: radiance fields for real products

By Ashwin Rajendraprasad Computer Vision

For years, putting a real object into a 3D experience meant a photogrammetry mesh and a lot of cleanup. Radiance fields changed the math, and by 2026 the technique is productizable, in specific places and with real caveats. This is a practitioner’s map of where it fits and where it doesn’t.

From NeRF to a scene you can rasterize

NeRF (Mildenhall et al., ECCV 2020) proved that neural scene reconstruction was possible: feed a model a set of photos and it learns to synthesize new views of the same scene. It was also slow, because rendering a novel view meant marching rays through a neural network for every pixel. That cost kept it in the lab.

3D Gaussian Splatting (Kerbl et al., SIGGRAPH 2023) kept the photorealism and threw out the bottleneck. The idea is almost blunt: represent a scene as millions of little 3D Gaussians (each with a position, a covariance that sets its shape, a color, and an opacity) and rasterize them the way a GPU already rasterizes triangles. You fit the Gaussians’ parameters to a set of input photos, then render any new viewpoint by splatting those blobs onto the image plane. There is no per-pixel network at render time, and that single change is what turned a research result into something you can put in front of a user.

Why “real time” rewrote the economics

The headline property of 3D Gaussian splatting is real-time novel-view rendering of a captured scene. That is the difference that matters for a product. If a user can orbit a real object smoothly, you have an interactive 3D viewer; if each frame takes seconds, you have a render farm. Real-time rendering is what makes radiance fields usable in an actual interface.

Be precise about which part is real time, though. Rendering a finished splat is real time and well established. Capturing a scene, meaning optimizing those Gaussians against your photos, is still an offline job for classic pipelines, and “real-time capture on a phone” is situational, not a given. When you scope a product, treat rendering speed as a solved property you can rely on and treat capture as the part you have to design around.

That split also sets expectations with stakeholders. “Real-time 3D” in a deck can mean either thing, and the gap between them is weeks of pipeline work. When someone shows you a splat spinning smoothly, you’re seeing the solved half; the question to ask is how the scene got captured, and how long that took.

The 2025–26 wave: not one technique but a stack

3D Gaussian splatting in 2026 is not a single paper; it’s an ecosystem. Surveys now catalog the extensions as distinct sub-areas: one 2025 survey organizes the field into segmentation, editing, and generation (arXiv:2508.09977). Segmentation isolates objects inside a splat. Editing moves, recolors, or removes them. Generation goes from a text or image prompt to a splat directly. Alongside those sit dynamic or 4D scenes that capture motion over time, and compression work aimed squarely at the file-size problem.

The shift worth watching is feed-forward splatting: predicting splat parameters directly, without a per-scene optimization loop. Depth Anything 3 (ByteDance Seed), covered in our monocular depth piece, is one route into this: geometry predicted in a forward pass rather than solved scene by scene. That reframes capture from “an optimization job” to “an inference call,” which is the kind of change that moves a technique from studios into products.

Where it actually fits in a product

Line the strengths up against real use cases and a short list falls out. 3D product viewers: let a shopper orbit a physically captured object instead of a modeled approximation. Virtual try-on and product visualization: place a captured object into a scene or onto a person, the kind of view-in-room experience e-commerce keeps asking for. Real-estate and space capture: walk a room the way it actually looks. Digital twins: a photoreal, navigable record of a physical space or asset.

What these share is a need for photoreal appearance, captured from photos, viewed interactively. When all three are true at once, a splat is hard to beat. It renders view-dependent effects like glossy reflections and soft, fuzzy materials (hair, foliage, fabric) that a clean mesh struggles to fake.

When only one or two are true, reach for something else. If you don’t need photoreal appearance, a modeled asset is cheaper to make and edit. If the source isn’t photographs (CAD, say, or a scene that doesn’t exist yet), generation or modeling is the right door. The splat’s whole advantage is turning real photographs of a real thing into an interactive, convincing view of it.

The blockers

Productization is emerging, not finished, and the blockers are concrete. File size and streaming: millions of Gaussians make heavy assets, and getting them to a phone or a browser tab fast is an unsolved-enough problem to shape your architecture. Editing maturity: cleanly moving, relighting, or compositing a splat is still harder than editing a mesh, so pipelines that assume freeform art direction will feel the friction. Standards still settling: the pieces are being put in place but the spec is not finished. Khronos, OGC, Niantic, Cesium and Esri are bringing splats into glTF through two extensions, KHR_gaussian_splatting for the base representation and KHR_gaussian_splatting_compression_spz for Niantic’s SPZ compression. The base extension reached release candidate in February 2026, with ratification expected in the second quarter, so the format itself is close to settled while the tooling and workflow conventions around it are still a moving target.

None of these is fatal. All of them belong in the plan before you commit, not in a retro afterward.

CloudSignal lens: splat or mesh?

The decision that matters in practice is splat versus photogrammetry mesh, and it comes down to one question: does the product need to look right or measure right?

A splat wins when appearance is the point (photoreal, view-dependent, captured quickly, viewed interactively). A mesh still wins when you need clean, explicit geometry: physics and collision, dimensional measurement, tight file budgets, or an established art pipeline that expects editable surfaces. Our read for now is that Gaussian splatting is a rendering and capture win rather than a geometry win. If your product’s value is that a real thing looks convincing from every angle, reach for a splat. If its value is knowing exactly where surfaces are, a mesh is still the honest tool.

If you’re weighing a 3D commerce build (product viewers, try-on, or space capture), that splat-versus-mesh call is worth making before anyone writes code. It’s the kind of architecture review we run often, and it’s a lot cheaper than discovering the answer after the pipeline is built.

Sources / further reading

Written by Ashwin Rajendraprasad for CloudSignal AI.