3D Gaussian Splatting on the Web: Bottlenecks and Level-of-Detail Strategy

What 3D Gaussian Splatting Is, and How It Differs from Meshes and NeRF

3D Gaussian Splatting (3DGS) represents a scene as a large set of 3D Gaussians, each with a position, size, orientation, opacity, and color. At render time the Gaussians are sorted by depth, projected onto the screen, and blended one after another into the image. The original paper is Kerbl et al., “3D Gaussian Splatting for Real-Time Radiance Field Rendering,” published in ACM Transactions on Graphics (Kerbl et al., 2023).

Compared with a mesh, 3DGS has no explicit surface or topology. It reconstructs appearance directly from multi-view images, so fine detail and view-dependent sheen are easy to keep. The cost is that objects in the scene are not separated, so individual objects cannot be swapped or edited one by one the way mesh parts can. NeRF stores a scene implicitly in a neural network and queries it with many samples along each ray. 3DGS is explicit data and can follow a rendering path close to rasterization, which is why running it in a browser is realistic.

Where It Sits in a Digital Twin: Appearance Without Semantics

NIST IR 8356 defines a digital twin as an electronic representation of a real-world entity that lets users inspect the entity’s state and the transitions between states (Voas et al., 2025). ISO 23247 is a series of standards for digital twin frameworks in manufacturing; according to the NIST abstract, its purpose is to provide terminology and implementation guidance for manufacturing (ISO 23247 series, as confirmed by the NIST abstract).

In that framework, 3DGS supplies appearance: how the real object looks. Object boundaries, relationships between components, state, and sensor data are not in the scan and have to come from other data layers. 3DGS also offers no measurement accuracy or semantics, so putting a scan on a web page yields a scene that can be walked through, not a model that can be queried. That position sets the direction of every trade-off that follows.

The Web Bottleneck: Too Many Layers Stacked on One Pixel

Take a PLY scan of about 800 MB holding about 15 million Gaussians, to be walked through in desktop and phone browsers. The instinct is to blame the count. The measurements pointed elsewhere.

Before measuring, confirm how the data is encoded. A 3DGS PLY often stores scale as a logarithm and opacity as a value taken before the sigmoid, while some statistics commands, such as splat-transform --stats, print decoded values. Reading those as the raw numbers in the file is an easy way to reach the wrong conclusion. So the conventions were confirmed against the raw bytes first, and only then did the numbers mean anything.

With the conventions settled, the next step was fill rate: the average number of Gaussians covering each pixel. The result was about 180 layers of overlap on average, and the median Gaussian was only about 5 mm across. Every pixel on screen blends that many layers of tiny Gaussians, and that is where the time goes. The total count is not the main cause. This kind of bottleneck is called overdraw.

That difference decides what to do next. Cutting the total number of Gaussians does not necessarily cut the layers per pixel; as long as dense Gaussians still stack along the line of sight, each one still has to be sorted and blended. Conversely, a scene with a modest count but deep stacking costs just as much. For general web 3D performance practice, see web 3D performance engineering.

Hard Pruning Cannot Remove the Stacking; Merge Decimation Can

The most direct approach is hard pruning by opacity. The median opacity in this data was about 0.24. A threshold of 0.10 left about 12 million Gaussians, and a threshold of 0.20 left about 8.4 million. The count did drop, but the conclusion for this data is that hard opacity pruning does not reduce the number of overlapping layers.

The reason lies in the operation itself. Hard pruning discards Gaussians one by one on a single attribute and never checks whether the Gaussians sit on the same line of sight, so the survivors still overlap. Merge decimation combines neighboring Gaussians so that fewer Gaussians describe the same region, and on this data it was the only operation that removes depth stacking offline.

In practice the master file is cropped first, then merge-decimated to about 8 million Gaussians, and only then is the LoD tree built and split into chunks for streaming. Cropping and decimation come before the tree because every later tier and every streamed chunk is derived from that master.

Research Directions: Pruning, Compression, and Structure

A good share of follow-up research on 3DGS revolves around the number of Gaussians, file size, and memory use. What follows organizes three directions from each paper’s abstract; this article describes these papers at the abstract level only.

Pruning

The first direction is pruning. The LightGaussian abstract says the method removes Gaussians of low global significance and then applies a recovery step (Fan et al., 2024). Papantonakis et al. use resolution-aware pruning (Papantonakis et al., 2024). Neither cuts at a single opacity threshold; both rely on significance or resolution. The abstracts focus on model size and memory and say nothing about per-pixel stacking depth, so whether the same effect holds has to be measured on the actual data.

Compression

The second direction is compressing attributes. The LightGaussian abstract mentions lowering the degree of the spherical harmonics and using vector quantization to cut bit width. The Papantonakis abstract mentions adapting the spherical harmonics degree as needed, plus codebook quantization with half precision. Spherical harmonics carry how color changes with viewing angle, so lowering the degree describes that change with fewer parameters. The latter abstract also reports improvements in both disk size and rendering speed.

Structure

The third direction changes how the data is organized. Morgenstern et al. place 3DGS parameters on a two-dimensional grid by parallel sorting so that neighboring values are similar, then add a local smoothness constraint during training so the grid compresses well while keeping the original 3DGS format (Morgenstern et al., 2024). Scaffold-GS organizes local Gaussians around anchors, predicts attributes on the fly from view direction and distance, and adds or removes anchors by contribution; its abstract notes that 3DGS often produces many redundant Gaussians, and the structured anchors are meant to reduce that redundancy (Lu et al., 2024).

The compression ratios and frame rates these papers report depend on particular datasets and test hardware, and the abstracts often leave the conditions incomplete: the Papantonakis abstract says only standard datasets without naming any, the Morgenstern abstract lists no datasets, the LightGaussian abstract does not state its test hardware, and the Scaffold-GS abstract contains no numbers. For that reason this article does not quote those ratios or convert those ratios into browser results. Web deployment also brings transfer size, phone memory limits, and view-dependent chunk loading, which are not the subject of these abstracts.

Tiers and Streaming: The User Picks the Level

After the master file is ready, an LoD tree is built and split into chunks, and the browser loads what the current view needs. Quality comes in three tiers. The tiers change only the Gaussian budget, and render resolution stays fixed at 1.0. The budget works through a minimum on-screen size: Gaussians smaller than a pixel are filtered out, and the picture flickers less as a result.

The three tiers keep about 1.1 million, 2.2 million, and 3.75 million Gaussians resident, and the default budgets differ between phones and desktops. The user chooses the tier, which leaves the trade between image quality and smoothness with the user.

The on-disk size of the chunks was also tuned. Between two versions of the LoD tree, total disk size went from about 280 MB to about 200 MB (about 30% less), and the chunk count from about 240 to about 170. The 200 MB is a disk total, not a first-load size; how much is actually streamed depends on the view and the tier.

Offline build time is not the obstacle. In a test with an input of about 11 million Gaussians on an M1 Pro, building the LoD tree took about 30 seconds in fast mode and about four minutes in quality mode.

Silent Failures: Put a Preflight Check at the Entry

The most dangerous failure in a new technology is one that produces no error. With the Spark 2.1.0 viewer, for example, three common situations produce a black screen, a clean console, or only a cryptic message. The causes are these.

1. Runtime LoD idles for about 6 seconds, returns 0 Gaussians, and throws no error. On the same .sog file, loading with LoD off took about 0.9 seconds and produced about 3 million Gaussians, while turning LoD on produced 0. The fix was to use prebuilt chunk files.
2. The renderer’s LoD switch defaults to on and silently ignores data that was not built with LoD. The drawn-Gaussian count stays at 0 and the screen is black. The data side and the renderer side have to agree.
3. When an asset path is wrong, the static host answers with 200 and the home page HTML. The viewer parses the start of that HTML as data and leaves only a cryptic magic-number error in the console. The fix is a 4-byte Range request at the entry as a preflight check, turning “asset not loaded” into a readable message.

One smaller trap is format. The default format of newer SPZ cannot be read by this version of the viewer, and on this data SPZ came to about 46 MB against about 36 MB for SOG, so it was not adopted. The format should be chosen by its size on the actual data. .sog and .spz are common compressed container formats in practice, and this article draws no link between those formats and the methods in the papers above.

What the three situations share is that a failure reports nothing clear. A preflight check moves the failure up to the loading entry, so whoever investigates sees one readable cause instead of a black screen.

Record the Optimizations That Work Only on Paper

The idea behind a depth pre-pass is to write depth first with an occluder mesh and cull the Gaussians that are hidden. In theory it is the largest lever for mid-distance views, so it is often the first thing considered.

The implementation has several traps. A mesh of about 40,000 faces with polygonOffset leaves holes across the whole frame: polygonOffset is measured in depth-buffer units, which under perspective projection has almost no effect up close and over-offsets at a distance. A mesh of about 500,000 faces with a world-unit offset comes out clean in the view from above; but with the same setup, a walkthrough at human eye height brings large holes back, and raising the offset to 2.5 m does not help.

The real cause was neither face count nor offset. The occluder model and the scan matched on large structural surfaces, but objects within the scene did not line up. At eye height, near objects take up a large share of the frame, and the position error grew into large holes.

The conclusion is that a depth pre-pass does not work on assets of this kind. Remedying it would mean generating occluder geometry from the Gaussians themselves, aligning object by object, or using only large structural surfaces as occluders, and each of those is a separate project. The occluder model is not downloaded by default, which costs nothing. For anyone evaluating a project, the takeaway is that the largest lever on paper cannot always be built, so performance targets should be assessed together with feasibility.

When It Does Not Fit

In the three situations below, evaluate other routes before choosing 3DGS.

• Measurement accuracy or semantic model data such as BIM is required. 3DGS provides neither, so those needs call for meshes or the original design data.
• The content changes often. A scan captures appearance at one point in time and goes stale when the content changes, and 3DGS cannot swap parts one by one the way a mesh can.
• Most readers are on low-end phones and tiers are not acceptable. Tiers trade image quality for smoothness; if tiers are off the table, video or a prerecorded walkthrough is steadier.

For industrial equipment, where the point of the display is structure and components, a mesh route is usually evaluated first; POLISH also has an industrial 3D showcase case that shows how industrial subjects appear on the web. 3DGS suits scenes where real appearance matters and the content stays fairly fixed. For model-side optimization before and after, see 3D model optimization before and after.

What to Prepare Before Evaluating a Scan

Judging whether a scan can go on the web, and to what extent, starts with three pieces of information. POLISH’s web 3D development service begins its evaluation from these three.

• Scale and origin of the data: file size, Gaussian or point count, format, and whether the scan was captured and reconstructed in-house or supplied by someone else.
• Purpose: marketing display or measurement. This decides whether 3DGS applies at all.
• Target devices: the split between desktop and phone, and the lowest phone tier that must be supported.

Once the data is ready, contact the POLISH Engineering Team to confirm which route suits the scan.