Sorting Out 3DGS File Formats

01 Quick reference: start with the big picture

Start with this table to get a feel for all eight formats. Each one has its own section below.

02 PLY (original, uncompressed)

This is the de facto common language of 3DGS — the format the original Inria paper outputs directly. Every point keeps its position, size, orientation, and opacity, plus the way its color shifts with viewing angle, which makes PLY the largest file size of any format here. Nothing has been thrown away, so a PLY can still be converted into any of the others later.

In the wild ── This is the exact output of the official Inria implementation, and the exports from Polycam, Luma AI, and XGRIDS LCC Studio follow the same layout. SuperSplat reads and writes it directly, which makes PLY the hub for editing too.

03 SPLAT (antimatter15)

A simple format created for splat (antimatter15), one of the earliest web viewers. It throws away the way color shifts with viewing angle, which is what makes files roughly half the size of PLY.

04 KSPLAT (mkkellogg/GaussianSplats3D)

A compression format built specifically for the Three.js library GaussianSplats3D. Data is split into chunks and designed for progressive streaming, rendering each chunk as it arrives — even a large scene shows its first frame almost immediately.

05 SPZ (Niantic Spatial)

A compression format developed by Niantic Spatial (Scaniverse) that's becoming something of an industry standard. It was also adopted as the compression method for glTF's KHR_gaussian_splatting compression extension (09). It has been refined over several revisions: the current version loads quickly, and you can check how big a scene is without unpacking the whole file. It stays a single file, which makes it the safe choice when you don't know what the recipient will open it with.

In the wild ── Scaniverse exports SPZ, and Niantic open-sourced it under MIT (nianticlabs/spz). The stated compression is roughly 1/10 the size of the equivalent PLY.

06 SOG (PlayCanvas)

Developed by PlayCanvas and sometimes described as "WebP for Gaussian Splatting." It borrows the machinery of image compression, so the same scene comes out dramatically smaller — the smallest of any major format. The catch is that it isn't a single file but a folder of assets, so take care over how you package it when handing it off.

A single-file .sog — all the assets zipped together — is also available. The spec is published in the official PlayCanvas documentation.

07 RAD (Spark)

A streaming-only format from Spark, the Three.js renderer, that stores several levels of detail side by side. You build and save the coarse-to-fine versions ahead of time, and at viewing time only the parts you need are fetched. A rough version appears instantly, and more detail streams in as the viewpoint moves. Locahun 3D's own viewer builds its custom parallel decoding and LOD control around this RAD format as well.

In the wild ── Our own viewer gets a first frame out of a RAD approaching a gigabyte in a matter of seconds, and camera moves after that come up with no wait. The only primary sources for the format are Spark's documentation and source code — there is no standalone spec document like SPZ's or SOG's yet.

08 LCC / LCC2 (XGRIDS)

A container format developed by XGRIDS for handling city-scale scenes with LOD (level of detail). Rather than a single file, it's made up of metadata describing the levels of detail plus a folder holding the actual data, stored as either SOG or SPZ. PortalCam scans include one of these folders in the LCC Studio export.

09 glTF (KHR_gaussian_splatting)

The official Khronos extension, currently being standardized, for storing 3DGS inside glTF/GLB. A release candidate has been published and it's now in the final stages toward formal ratification. Compression uses the SPZ method donated by Niantic Spatial. Its biggest significance is the shift away from a proliferation of proprietary formats toward building on top of glTF, a general-purpose 3D standard. Cesium adopted it to support LOD streaming in 3D Tiles, making it possible to deliver city-scale 3DGS with geographic coordinates. Conversion tools like gsbox also support PLY⇄GLB.

In proper standards fashion, a file can also carry a plain point-cloud fallback so that viewers without 3DGS support still show something. Read the spec in the Khronos glTF repository.

10 So which one should you use?

One core principle first. Compressed formats like SPZ, SOG, and KSPLAT get smaller by throwing information away, and once compressed, the original quality cannot be recovered. Whatever you pick for delivery, keep the PLY straight out of training as your master and derive per-use-case copies from it. Format selection is not about choosing a master — it's about choosing how you deliver and hand off.

With that in place, here's a rough guide by use case. Use it together with our comparison of 3DGS-capable software and tools to decide which format to use with which software.

• Passing data to another DCC (Houdini, Blender, etc.) ── PLY. More tools now read SPZ directly (3ds Max, for one), but PLY is still the only format every tool is guaranteed to open
• Publishing and sharing on the web ── Decide by what your viewer supports. If you're displaying through the PlayCanvas family (SuperSplat, Spark), go SOG for maximum compression (note it's a folder, not a single file). If you need one file to hand around, or you can't predict the recipient's setup, SPZ is the safe pick
• Switching LOD in a city-scale scene ── LCC2 if you're on XGRIDS' SDKs (UE5/Unity); Cesium's 3D Tiles + glTF (09) if you want an open standard with geospatial coordinates. Remember to check LCC2's proprietary license
• Streaming a scene far too large to fit in GPU memory ── RAD. Spark-only, but it's currently the only format that ships every level of detail together and delivers them piece by piece
• Building a custom viewer with GaussianSplats3D ── KSPLAT. Gets the benefit of progressive display
• Long-term storage and distribution on a standard ── glTF (KHR_gaussian_splatting) is where this is heading, but it hasn't been finalized yet. For archival today, the reliable setup is a PLY master plus compressed derivatives

As for SPLAT: there's little reason to adopt it for new work. It has no formal spec and drops the view-dependent color — even for "just want a quick look" cases, tossing the PLY straight into a viewer like SuperSplat is faster and safer.

Converting between formats is mostly covered in one place by splat-transform.