Shrinking 3DGS File Size

Updated August 2026 with the full current format landscape: compressed PLY, SPZ v4, SOGS and SOG, World Labs’ .rad, glTF, USD, and the training-time techniques behind them.

A raw 3D Gaussian Splatting capture is big. The .ply file that training produces routinely lands in the hundreds of megabytes, and large scenes clear a gigabyte — for a long time the most common critique of an otherwise fast, photoreal representation.

Shrinking a splat is now a solved problem several times over. The solutions come in two layers: storage formats that compress what training produced, and training-time methods that produce fewer, leaner Gaussians in the first place. This guide maps both — what each option is, how much it saves, who supports it, and which one to reach for.

Why splat files are so large

Every Gaussian in a scene stores a position, a rotation, a per-axis scale, an opacity, and its color — including up to three bands of spherical harmonic (SH) coefficients that model how color shifts with viewing direction. In the reference implementation that adds up to roughly 232 bytes per splat at full float32 precision, and the SH coefficients account for the majority of it. Multiply by a few million Gaussians and a single capture lands in PLY territory north of half a gigabyte.

When the original 3DGS authors analyzed the memory footprint, they distilled it into three levers: how many Gaussians a scene uses, how many SH coefficients each one carries, and how much numeric precision the attributes are stored at. Every format and method below pulls on one or more of those levers, usually finished off with an entropy coder.

The format landscape: what you actually ship

Training still overwhelmingly produces a PLY. What you deliver to a viewer, an engine, or a customer is increasingly something else. These are the options, roughly in order of how aggressively they compress.

PLY — the uncompressed baseline

The reference output of 3DGS training and the one format everything can read. It stores every attribute at full precision, which makes it the right master copy for archiving and editing — and the wrong thing to put on a web page. Treat PLY like RAW photos: keep it, don’t serve it.

Compressed PLY — the one-click win

PlayCanvas pioneered a compressed variant of PLY that groups splats into 256-splat chunks and stores quantized attributes relative to each chunk’s bounds, taking ~232 bytes per splat down to 16. In PlayCanvas’s own guitar example, a 132.8 MB PLY became 8.7 MB. SuperSplat exposes this as a simple checkbox on export, alongside a control for how many SH bands to keep — since v2.7 the export dialog puts both on one screen. No retraining, no new toolchain, and tools that understand the convention still read it as a valid PLY.

.splat and .ksplat — the early web formats

Before today’s options existed, community web viewers defined their own binary formats: .splat quantizes position, scale, color, and rotation into roughly 32 bytes per splat and simply discards spherical harmonics, while .ksplat (from the GaussianSplats3D three.js viewer) offers configurable compression levels that can retain them. Both still circulate, but for new work they have largely been superseded by SPZ and SOG.

SPZ — Niantic Spatial’s “PLY v2”

Scaniverse developed SPZ internally and Niantic open-sourced it under an MIT license in late 2024. It organizes attributes column-wise — positions with positions, rotations with rotations — quantizes them, and compresses the result, delivering files about ten times smaller than PLY while staying deliberately simple to implement. That simplicity is the point: SPZ positions itself as a sensible-defaults successor to PLY rather than a maximum-compression format.

SPZ v4, released in May 2026, replaced the original single GZip stream with six parallel ZSTD streams — one per attribute class — cutting encode time on a 34-million-splat scene from 3:26 to 1:08 and time-to-first-render by 33–52%. The 10-million-point cap is gone, SH degree 4 is supported, and SH quantization is configurable from 3 to 8 bits (5 bits is the recommended sweet spot; 3 bits pushes compression to ~18x for previews). The header is plain text, so you can read a file’s metadata without a decompressor, and a new extension system allows vendor features without forking the spec.

Adoption is broad: Babylon.js, OctaneRender 2026.4, Bentley iTwin, 3DVista, and Postshot, which writes SPZ v4 directly and can cap SH degree at export — letting one trained scene ship at several sizes without retraining.

SOGS and SOG — splats as images

Self-Organizing Gaussians (SOGS), from Wieland Morgenstern’s team at Fraunhofer HHI, is the cleverest trick in the toolbox: sort the Gaussians so that similar ones sit next to each other, unroll each attribute into a 2D grid, and hand those grids to an ordinary image codec. The data becomes a set of images, and image codecs are extremely good at compressing images.

The idea first shipped as gsplat’s PNG compression in Nerfstudio — about 8 MB per 500K Gaussians. PlayCanvas then implemented it with WebP: in their demo, a four-million-splat church scene shrank from roughly 1 GB to 55 MB — a 20x reduction with spherical harmonics intact, decodable by any browser with standard image support.

The naming now covers a small family. The original SOGS ships as a folder of WebP images plus a meta.json; SOGS v2 is PlayCanvas’s refined iteration (supported in Spark since v0.1.10); and .sog bundles the same image-coded data into a single portable file. Production adoption spans SuperSplat, Babylon.js 9, D5 Render’s XR tour pipeline, and the Mapmost WebGL SDK.

.rad — World Labs’ streaming radiance field format

The newest entry solves a different problem. Introduced with the Spark 2.0 preview in February 2026 and released in April, World Labs’ .rad (RADiance field) format is built for streaming rather than minimum file size. It stores a precomputed level-of-detail splat tree — every splat is a leaf, and each parent is a merged, lower-resolution version of its children — and supports HTTP Range requests, so a scene appears instantly in coarse form and refines as bandwidth allows. Paired with Spark’s GPU memory paging, it renders scenes with hundreds of millions of splats on mobile hardware, and its ExtSplats encoding offers a higher-precision 32-byte-per-splat mode with float32 centers for large coordinate systems.

If SPZ and SOG answer “how do I make this file small,” .rad answers “how do I make a file I never have to fully download.”

glTF — the interoperability baseline

In February 2026, the Khronos Group announced KHR_gaussian_splatting, a glTF 2.0 extension release candidate that defines a cross-platform baseline for splats, with ratification targeted for mid-2026. Splats are treated as a specialized interpretation of mesh primitives — viewers that don’t support splatting can still fall back to rendering a point cloud. The baseline is deliberately uncompressed and GPU-ready, leaving compression to future extensions. PlayCanvas Engine 2.21.0 already loads glTF splats, and this is the format to watch for engine and pipeline interchange.

USD and USDZ — splats in production pipelines

OpenUSD 26.03 added a native Gaussian splat schema (UsdVolParticleField3DGaussianSplat, proposed through the AOUSD Emerging Geometry Interest Group), letting splats sit in a USD stage alongside meshes, materials, lights, and cameras with full layering and referencing. Houdini Solaris picked it up natively, and Scaniverse now exports USDZ bundles that package a splat together with a splat-derived mesh for NVIDIA Isaac Sim — the path into robotics simulation and Physical AI workflows. USD is a container rather than a compressor: the win is pipeline citizenship, not byte count.

3D Tiles and geospatial streaming

For city-scale and geospatial work, Bentley iTwin added 3D Tiles alongside SPZ export, bringing splats into the Cesium-style tiled streaming world where the client only fetches the tiles in view. Mapmost’s MMGS service format follows the same logic for its WebGL mapping SDK.

Format comparison at a glance

Shrinking the splat before you save it

Formats compress what training produced. The other half of the story is producing fewer, leaner Gaussians in the first place: pruning redundant primitives, allocating spherical harmonic bands only where a scene needs them, and quantizing attributes with shared codebooks. Postshot’s export-time SH capping and SuperSplat’s band selector are the practical, everyday face of this; the research behind it goes deeper.

Case study: how the original authors cut 3DGS by 27x

The original authors are back and are addressing some of those criticisms, which they have distilled into three observations: the number of 3D Gaussian primitives used to represent a scene, the number of coefficients for the spherical harmonics, and the precision required to store Gaussian primitive attributes. This is by no means the only project that has tackled the memory issue since the release of 3DGS, but it does provide a great view into what makes up the memory footprint behind Gaussian Splatting.

The first observation was that the original 3DGS method generated an excessive number of 3D Gaussian primitives, many of which were redundant, leading to an unnecessary increase in memory usage. This redundancy was particularly prevalent in areas of the scene where detailed reconstruction was not required, yet a dense cluster of primitives existed.

To address this, the team developed a resolution-aware pruning method that dynamically adjusts the number of primitives based on their necessity for accurate image representation. They introduced a two-step algorithm that first calculated a redundancy score for each primitive based on its contribution to the rendered view and then culled primitives that fell below a certain utility threshold. This approach effectively reduced the total count of primitives by about 60%, significantly decreasing the memory footprint. This might sound a little familiar conceptually to how RadSplat evaluates their Gaussians.

Interestingly, this comes right on the heels of a paper that revisits the densification stage of Gaussian Splatting. I’d be curious to see how the two papers could be applied to one another.

The second observation related to the use of SH bands, which are employed to model directional radiance. The original method used three SH bands for all primitives, regardless of whether the scene’s visual complexity required that level of detail. This one-size-fits-all approach led to an over allocation of memory resources.

The researchers tackled this by implementing an adaptive adjustment method for SH bands during the training phase. By analyzing the contribution of each SH band to the visual appearance of the primitives and assessing multi-view consistency, they were able to reduce the number of SH bands dynamically. This revised new method ensures that only essential data is retained, thereby reducing the memory required for storing these elements.

The final observation was that many of the attributes associated with the primitives, such as opacity and color, did not require high dynamic range or precision, yet they were stored with high precision which led to wasteful memory utilization.

To optimize memory usage for these attributes, they introduce a codebook-based quantization approach. This involved clustering similar values and replacing them with indices to a shared codebook, thus storing only the index rather than the full precision data. Additionally, they applied half-float quantization to further compress the data size without significantly affecting the visual output. This approach drastically reduced the memory requirements for storing primitive attributes.

These updates resulted in reducing the file size by 27 times and 1.7X speed boost for rendering.

They have created a viewer that still retains spherical harmonics to include view dependent effects. They have two different modes: a light one and a heavy. The light version runs smoothly on moderate devices like an M2 laptop, while the heavy version requires more powerful GPU support. Check out their Project Page here!

So which one should you use?

• Archiving and editing: keep the raw PLY as your master; compressed PLY when size matters.

• Web pages and product viewers: SOG/SOGS or SPZ — both decode fast in browsers and keep view-dependent color.

• Sharing straight from mobile capture: SPZ. It is what Scaniverse speaks natively, and support is everywhere.

• Huge or unbounded scenes: .rad with a LoD-aware renderer like Spark, or 3D Tiles for geospatial work.

• DCC, engine, and simulation pipelines: glTF (KHR_gaussian_splatting) or USD/USDZ.

• Quick size cut with zero new tools: re-export with fewer SH bands — SuperSplat’s compressed PLY checkbox or Postshot’s SPZ v4 export with degree capping.

Frequently asked questions

How much smaller can a 3DGS file actually get?

Format-level compression alone delivers 10–20x (SPZ ~10x, SOGS ~20x, and SPZ’s 3-bit SH preview mode ~18x). Combine that with training-time pruning and adaptive SH — the original authors demonstrated 27x — and a multi-hundred-megabyte capture can comfortably become a few tens of megabytes.

What is a .rad file?

A streaming format for Gaussian splats introduced by World Labs with Spark 2.0 in 2026. It stores a precomputed level-of-detail splat tree and loads progressively over HTTP Range requests, so massive scenes appear instantly in coarse form and refine as data arrives — built for streaming enormous scenes rather than minimizing file size.

What is the difference between SOGS, SOGS v2, and .sog?

All three are Self-Organizing Gaussians: attributes sorted for coherence, stored as image grids, and compressed with image codecs. SOGS is the original folder-of-WebPs-plus-meta.json layout, SOGS v2 is PlayCanvas’s refined second iteration, and .sog bundles the same data into a single portable file.

Should I use SPZ or SOG for the web?

Both work well. SOG typically compresses harder (~20x vs ~10x) and decodes with the browser’s standard image support, while SPZ is simpler, has first-party tooling from Niantic Spatial, and is more widely supported across engines and DCCs. If your viewer supports both, test with your own scenes; the visual difference is usually negligible.

Does compressing a splat hurt visual quality?

Attribute quantization is mostly imperceptible — formats reserve precision where it matters. The visible trade-off is spherical harmonics: dropping or heavily quantizing SH bands reduces view-dependent effects like glints and sheen. SPZ v4’s 5-bit SH setting and SOGS’s image coding both retain harmonics at a fraction of the original size.