Gaussian Splatting as Product Infrastructure: 3D on Web

Q: What is 3D Gaussian Splatting and how does it differ from NeRF?

3D Gaussian Splatting represents a scene as millions of explicit, coloured, semi-transparent 3D Gaussians that a rasteriser blends in real time, whereas a Neural Radiance Field (NeRF) represents the scene as an implicit neural function you must query per ray. The 2023 SIGGRAPH paper by Kerbl and colleagues reported high-quality real-time novel-view synthesis — 30 FPS or better in the abstract, 100+ FPS at 1080p on the project page — with training on the order of tens of minutes, against the roughly 48 hours Mip-NeRF360 needed for comparable quality. The decisive difference for production is the explicit representation: splats compress with ordinary codecs, stream in level-of-detail chunks, and rasterise on a GPU the browser already exposes, while NeRF pays for its implicit MLP at render time at roughly seconds per frame, which is fatal for interactivity on the web.

Q: Why is Gaussian Splatting hard to ship on the web?

Because a trained scene is large. A raw splat exported as a PLY file runs at roughly 250 bytes per Gaussian — about 8.5GB for a 34-million-point capture, or 250MB to 1GB for a typical one-to-four-million-Gaussian product object — and shipping that to a phone browser over a mobile connection is the real engineering problem. The rendering was solved by the 2023 paper; the delivery was not. This is why the work that made splatting into product infrastructure across 2024 to 2026 was all about the bytes on the wire and the frames on the client: Niantic's SPZ compression format, Fraunhofer's Self-Organizing Gaussians, and PlayCanvas's WebGPU renderer. Teams that evaluate splatting by the beauty of the captured scene and treat delivery as a static-file problem discover too late that compression, streaming, and device-tiered rendering are where the product succeeds or fails.

Q: How much can a Gaussian Splatting scene be compressed?

A great deal, and the format is the highest-leverage choice in the stack. Niantic's open-source SPZ format is roughly 10x smaller than the equivalent PLY with virtually no perceptible loss, landing a typical object scene in the 25 to 100 megabyte range from a raw 250MB to 1GB; its 2026 revision (SPZ 4) removed the old ten-million-point cap, made web loading up to 20x faster, and quantises spherical-harmonic coefficients to three bits for an 18x reduction on that component. Fraunhofer's Self-Organizing Gaussians compress harder — reported at 20 to 40x versus standard 3DGS — by mapping the Gaussian parameters into a 2D grid compressed with JPEG-XL, and that format underpins PlayCanvas's streamed delivery. The practical rule is to use SPZ as a portable interchange default and reach for SOG-style streaming when the scene is large enough that 20 to 40x is the difference between shipping and not.

Q: Do I need WebGPU to render Gaussian Splats in the browser?

No, but WebGPU raised the performance ceiling substantially in 2026, and you should ship it with a WebGL2 fallback rather than assuming it. PlayCanvas shipped a compute-based WebGPU splat renderer with a WebGL2 fallback in June 2026, and the measured gains land on exactly the scenes that used to stall: on an Apple M4 Max a ten-million-Gaussian scene went from 48 to 124 FPS moving WebGL2 to WebGPU, and a thirty-five-million-Gaussian scene from 13 to 76 FPS; on an iPhone 13 Pro Max a one-million-Gaussian scene doubled from 38 to 78 FPS. Community Three.js renderers such as mkkellogg's GaussianSplats3D remain WebGL2 and are perfectly serviceable for the one-to-four-million-Gaussian objects that are the sweet spot for most product scenes. Because WebGPU browser coverage is broad but not universal, feature-detect and fall back to WebGL2 or you will blank the scene for a slice of your users.

Q: When should I use a mesh instead of a Gaussian Splat?

Whenever you need geometry. Splats have no native surface — they are a cloud of blended primitives, not a watertight mesh — so anything that requires collision detection, physics simulation, exact measurement, or clean hard-surface CAD wants a mesh, whether captured by photogrammetry or modelled directly. Gaussian Splatting is the right representation only for photoreal capture where you do not need the geometry: product visualisation, real-estate and digital-twin walkthroughs, spatial and AR scenes where the user looks but does not physically interact with the surface. Using splats where you needed a mesh is the most expensive scoping mistake in the field, because you discover it after building the pipeline. If you have a splat scene and later need interaction, you must extract a mesh from it, which adds a stage and loses fidelity. Decide the geometry question first, before you pick a capture tool.

Q: What are the honest limits of Gaussian Splatting?

Four limits are load-bearing for any production decision. First, splats bake radiance rather than decomposing lighting, so a captured object does not relight correctly when dropped into a scene with different illumination; if you need relighting you need material decomposition, not a raw splat. Second, naive 3DGS aliases under sampling-rate change — eroding on zoom-in and dilating on zoom-out — so scenes users will zoom need a mip-aware variant such as Mip-Splatting or they show visible artifacts. Third, dynamic or moving subjects require 4D Gaussian methods that add real training cost and storage; a static-splat pipeline does not become a video pipeline by wishing. Fourth, splats have no native geometry, making them poor for collision and physics without a separate mesh-extraction step. On top of these, view-dependent spherical-harmonic colour has a memory and compute cost, and editing a splat cloud cleanly is harder than editing a mesh. None of these are fatal, but a pipeline that ignores them ships artifacts.

Q: What tools capture and export Gaussian Splats for the web?

The capture and training stages are largely commoditised. Scaniverse, from Niantic, processes on-device in about sixty to ninety seconds on a phone and exports both PLY and SPZ. Polycam generates splats in the cloud from photos and exports PLY and .splat with Unity and Unreal workflows. Luma AI captures and exports PLY for desktop splat rendering. Postshot from Jawset trains locally on an RTX GPU and exports PLY and .splat. Nerfstudio with the gsplat library trains splats and exports PLY, and gsplat itself reports up to 4x less training memory and 10% less training time than the original implementation at equal quality. The consistent theme is that a usable scene comes out of a phone app in a couple of minutes; the engineering that matters is everything downstream — converting to a compressed web format such as SPZ or SOG, serving it through a CDN with level-of-detail streaming, and rendering it with a WebGPU or WebGL2 splat renderer.

Q: What does a mature Gaussian Splatting pipeline look like?

It looks like an asset pipeline, not a file. At the lowest maturity a scene is a huge PLY rendered in a native viewer on a workstation — impressive and unshippable. The first shippable level exports to SPZ, dropping the scene to tens of megabytes, and renders it in a Three.js WebGL2 splat renderer that loads on a good connection and runs on a recent phone. The next level adds WebGPU rendering with a WebGL2 fallback, Gaussian counts capped per device class, and mip-aware anti-aliasing for zoomable scenes, so the same asset performs on mobile and desktop without blanking on unsupported clients. Above that, large environments use SOG-style streamed level-of-detail served through a CDN so time-to-first-frame stops scaling with scene size. At full maturity capture, training, compression and format conversion are automated, scenes are versioned, and delivery is measured by time-to-first-frame and sustained FPS per device tier rather than by how the scene looks on the creator's laptop.

Satyam Kumar

Retour au blog

ai-architecture

Gaussian Splatting and Neural Rendering as Product Infrastructure: The 3D Capture-to-Web Pipeline (2026)

By Satyam KumarSeptember 18, 202611 min read

gaussian splatting 3d gaussian splatting neural rendering radiance fields nerf alternative spz format webgpu 3d real-time rendering 3d capture pipeline point cloud compression playcanvas splat three js splatting photoreal 3d web level of detail streaming digital twin 3d spatial computing web

Gaussian Splatting and Neural Rendering as Product Infrastructure: The 3D Capture-to-Web Pipeline (2026)

Frequently Asked Questions

Partager l'article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

Architecte AI & Cloud. J'aide les équipes à construire des systèmes qui scalent pour des millions.

LinkedIn GitHub

Gaussian Splatting and Neural Rendering as Product Infrastructure: The 3D Capture-to-Web Pipeline (2026)

Frequently Asked Questions

Partager l'article

Comments

Leave a comment