Format landscape

Working5 min readUpdated 2026-07-09Verified 2026-07-09

A trained splat scene doesn’t ship as one obvious file. What a trainer writes to disk, what a desktop viewer can load fastest, and what a phone can pull over a mobile connection are three different problems, and by 2026 there are three or four formats that each solve one of them well. Knowing which format a given tool actually reads, rather than which one is fashionable, is most of what “picking a format” means in practice.

PLY: the universal but uncompressed baseline

PLY is what every trainer writes first: PostShot, gsplat, the graphdeco reference implementation and the other open trainers covered elsewhere in this knowledge base all export a PLY with one row per Gaussian holding position, scale, rotation quaternion, opacity and spherical-harmonics colour coefficients. Depending on the exporter, that’s 59 to 62 float32 properties per Gaussian, some tools also carry three unused nx/ny/nz normal fields inherited from PLY’s mesh-era origins, working out to roughly 236-250 bytes per Gaussian at full degree-3 SH (the PlayCanvas developer docs and independent community measurements land in that range without either pinning one exact figure). A few million Gaussians at that rate is exactly why raw PLY scenes routinely run from a few hundred megabytes to several gigabytes. PLY is lossless and universally readable, which makes it the right interchange format between trainer, editor and converter, but PlayCanvas’s own documentation is explicit that it isn’t a runtime delivery format: it recommends converting every PLY with SplatTransform before it reaches a browser.

.splat: the low-fi web-native shortcut

The .splat format, popularised by antimatter15’s early WebGL viewer, has no formal specification: it’s defined entirely by convention, a fixed per-Gaussian binary layout of around 32 bytes covering position, scale, a packed orientation and an RGBA colour, with spherical harmonics dropped entirely. That’s a real trade, not just a limitation: dropping SH removes all view-dependent colour, so .splat scenes look flatter under specular or reflective lighting than the same scene kept in a format that preserves SH. It’s still useful for quick, dependency-free demos and small scenes, but the missing spec and the flat-colour ceiling are why it never became a production default.

SPZ: Niantic’s general-purpose compressed format

SPZ, open-sourced by Niantic (the team behind Scaniverse) under an MIT licence, is currently at spec version 4, released 2026-05-05. It gets a scene to roughly a tenth the size of the equivalent raw PLY while keeping full spherical harmonics, using per-attribute quantisation, positions to 24 bits, SH coefficients to a configurable 4-8 bits per band, split across six parallel ZSTD streams that v4 introduced for faster multi-core encoding and decoding. It also carries an explicit coordinate-system field naming one of sixteen conventions, because PLY, GLB and engine-native formats each default to different axis conventions and SPZ wants to travel between them without a guessing game. SPZ ships natively in Scaniverse and in Adobe Photoshop’s Rotate Object feature, and is supported by Babylon.js and by community loaders, including one for PlayCanvas, since the PlayCanvas Engine’s own GSplat APIs don’t read SPZ out of the box.

SOG and SOGS: the format built for PlayCanvas delivery

SOG is the format this pipeline actually ships through, and it gets a dedicated page next in this part. In short: it descends from the Self-Organizing Gaussians research behind the SOG paper, sorting Gaussians into a 2D grid so that similar attribute values end up next to each other spatially, then leaning on ordinary lossless WebP compression to do the heavy lifting on the resulting image grids. PlayCanvas’s own figures put it at roughly 20x smaller than raw PLY, and roughly 2-3x smaller again than PlayCanvas’s older chunked “compressed PLY” scheme. The trade is that SOG is lossy by quantisation, deliberately, in exchange for compression ratios neither raw PLY nor a naive per-attribute scheme reaches on its own.

What’s arriving: glTF’s Gaussian splatting extension

The Khronos Group announced a KHR_gaussian_splatting extension for glTF 2.0 in February 2026, with contributors including NVIDIA, Autodesk, Esri, Niantic Spatial and Cesium, aiming to let any glTF-compatible viewer or engine load Gaussian splats the same way it already loads meshes. As of this writing it sits at release-candidate status, under community review ahead of a targeted ratification later in 2026. It defines position, rotation, scale, opacity and spherical-harmonics coefficients as standard glTF attributes with a choice of float or normalised-integer encodings, rather than prescribing one bit-packed container the way SPZ or SOG do. It’s worth watching rather than adopting: a release candidate isn’t a shipped, widely implemented format, and none of the viewers this pipeline depends on read it today.

In practice

For a PlayCanvas-delivered pipeline, PLY is what comes out of PostShot and what gets archived; it’s never what ships to a browser. SOG is the delivery format, because it’s the one PlayCanvas’s own engine, editor and SuperSplat are built to read natively, and its compression ratio against raw PLY is the best of the formats covered here. SPZ is worth keeping in mind for anything leaving this pipeline’s own ecosystem, sharing a scene with a Scaniverse or Babylon.js-based viewer, or with a partner tool that doesn’t speak SOG, since it’s rapidly becoming the common denominator compressed format across the wider splat tooling world. .splat is fine for a five-minute demo and nothing more. The glTF extension isn’t a decision yet: it’s a name to recognise the next time a viewer’s changelog mentions it, not something to build a delivery pipeline around in 2026.