Same SPZ splats. 4–7× faster to write.
SPZ is the open format for Gaussian splats, the photoreal 3D scenes now streaming on the web. TurboSPZ writes and reads the same files as Niantic's library, faster, in memory-safe code, with libspz's exact quantization, so every SPZ reader opens its output unchanged.
Built on our own TurboZstd. Byte-identical output on Intel, Apple silicon, in the browser and on any CPU.
Against Niantic's libspz on its own public reference scenes, built from source and measured in the same session. Speed is always shown with the size it costs.
The 60-second version
Gaussian splats turn photos into 3D scenes, and SPZ is how they ship.
SPZ
Niantic's open format for Gaussian splats, roughly 10× smaller than the raw PLY with no visible loss. Cesium proposed it as the compression for splats inside glTF.
Niantic's libspz
The open-source reference library that writes and reads SPZ today. It defines the format, so it is the bar any replacement has to clear, on the same files.
Write once, open everywhere
Every capture is encoded once, then opened by every viewer, increasingly in a browser tab. Write time is compute; open time is what users wait for.
A memory-safe drop-in
TurboSPZ writes standard SPZ with libspz's exact quantization and reads every version libspz reads, so it swaps in without changing a single viewer.
Watch it
Race it yourself, in this tab.
A real 786K-splat capture, decoded on two parallel worker threads in your browser: TurboSPZ against Niantic's own libspz, same bytes, then rendered with full Gaussian splatting. Drag to orbit; the cameras are linked.
What it means for the bill
Publish faster, or store less. Your choice.
The measured figures, translated.
Illustrative, from the measured figures (the Windows lower bound for encoding). A pilot measures yours.
Pick your trade
One dial: speed at one end, size at the other.
libspz has one fixed setting. TurboSPZ has three, and every one writes a standard SPZ file that libspz reads.
| Setting | File size vs libspz | Encode speed | What it is for |
|---|---|---|---|
| Fast (the default) | +7.2% / +5.7% | 4–5× faster | Ingest and publishing, where throughput is the product |
| Balanced | +2.0% / +1.3% | about libspz’s speed | Roughly libspz’s own effort |
| Max compression | −3.1% / −3.5% | 1.6× faster | Archives and CDNs, where every byte is paid for |
File size on the two reference scenes (hornedlizard / racoonfamily). Every setting's output is a standard SPZ v4 stream, verified to decode bit-exact through libspz natively and through Niantic's own WebAssembly build.
In the browser
Opens faster than Niantic's own decoder, in the browser.
Splats are increasingly viewed in a browser tab, so we put TurboSPZ against Niantic's libspz on the hardest footing: both compiled to WebAssembly SIMD, both decoding the exact same file. TurboSPZ reads v2, v3 and v4 and decodes each faster: the older gzip-framed v2/v3 by ~1.8×, and current v4 by ~1.27×. Two choices drive the gap: TurboSPZ hands its output straight to the GPU without copying it, and a streaming viewer reuses its decode state from frame to frame.
Browser decode throughput by SPZ version: TurboSPZ vs Niantic libspz, both WebAssembly
Browser decode throughput, TurboSPZ vs Niantic libspz (both WASM SIMD128), decoding the same file per version, SH degree 3, scene-averaged over hornedlizard (786K) + racoonfamily (933K). Higher is faster. v2 ~1078 vs 595 MiB/s (1.81×); v3 ~1007 vs 568 (1.77×); v4 ~1078 vs 847 (1.27×).
Every version, every machine
Faster than libspz across versions and machines.
Three SPZ versions, three machines, all against libspz at 1.0×. TurboSPZ leads on Intel and in the browser on every version, and wins current v4 on Apple silicon. On older v2/v3 files read natively on a Mac it matches libspz's decoder, and the browser lane, which every platform runs, keeps it ahead.
Decode speedup vs libspz: every version, every backend
Decode throughput vs libspz, both reading the same file per version. Browser is warm WebAssembly SIMD128 vs Niantic's libspz compiled to WebAssembly. Native v4 cells compare both libraries on the whole machine; TurboSPZ also wins strictly one thread against one thread (1.17–1.21×). Scenes hornedlizard (786K) + racoonfamily (933K), SH degree 3.
Write
Faster on every scene, machine and version.
Encode speed on every core against libspz, on two Gaussian-splat scenes: same input, same color detail, libspz's exact quantization. libspz has no parallel writer for either format. The two charts use different baselines: v4 against libspz's own v4 encoder, legacy v2/v3 against its single-threaded zlib writer, which is why the legacy margin is larger.
v4 · zstd
Multicore encode speedup vs libspz (v4)
Parallel encode speedup, TurboSPZ vs libspz, v4 (zstd), by scene and machine, SH degree 3, at the default setting (files 5.7–7.2% larger). Intel (AVX2) and Apple silicon (NEON) produce byte-identical output. One core against one core is ~4–5× (AVX2 3.7×/4.2×, NEON 4.6×/4.9×).
legacy v2/v3 · gzip
Multicore encode speedup vs libspz (legacy gzip)
Parallel encode speedup, TurboSPZ vs libspz's single-threaded zlib legacy writer, v2 and v3 shown separately (within ~2%; gzip dominates), by scene and machine, SH degree 3. TurboSPZ's parallel encoder reaches ~500 MiB/s on Apple silicon; single-thread is ~2.8–3.6×. Files are also 0.85–1.42% smaller. Same-session libspz baseline built from source.
Read
Every decode mode, every platform, measured the hard way.
Every decode figure compares TurboSPZ and libspz reading the exact same libspz-written v4 file, so this is decode speed alone, not a file advantage. On Windows TurboSPZ wins every mode: ≥1.17–1.21× on one thread, ≥1.40–1.46× on the whole machine, and up to ≥3.6× in a streaming viewer that reuses its decode state across frames. On Apple silicon: 1.17–1.19× on one thread and 1.32–1.38× on the whole machine.
An earlier version of this page reported a single-thread loss on Apple silicon (~0.89×). Deeper measurement showed that comparison was skewed in libspz's favor: it wasn't one thread against one thread. Measured strictly one against one, with output verified identical, TurboSPZ wins that pairing too.
Not just v4
Writes every version, not just the newest.
Plenty of SPZ in the wild is still the older gzip-framed v2 and v3. TurboSPZ writes those too, in exactly the form libspz produces, smaller and far faster.
Standard files
The standard, exactly
TurboSPZ writes the standard single-member gzip SPZ that everything reads, checked against libspz's own output. It produces the format exactly, not a re-interpretation.
Smaller
~1% under libspz
On the gzip-framed versions TurboSPZ writes 0.85–1.42% smaller files from the identical splat data, and the same bytes on every CPU.
Faster
Up to ~33× on every core
libspz writes these versions on one thread; TurboSPZ writes them in parallel as one standard file, ~27–33× faster on a multicore Mac, and ~3× even thread for thread.
Drops into the pipeline
A library swap. Not a migration.
- - Zero migration. TurboSPZ uses libspz's exact quantization and writes standard SPZ v4, so every downstream reader (Niantic, Cesium, glTF viewers) opens your output unchanged.
- - Faster to write: ~4–5× on one core, up to ~7× on every core, on Intel and Apple silicon, at the default setting (5.7–7.2% more bytes).
- - Faster where splats are viewed. 1.3–1.8× faster than Niantic's own decoder in the browser on v2, v3 and v4, handing data straight to the GPU. Native v4 decode wins every mode too.
- - Size is a setting, not a given. The speed-first default, a libspz-matched balanced setting, or max compression at 3.1–3.5% smaller while still 1.6× faster. Every setting stays readable by libspz.
- - Reads every SPZ version libspz reads: v1, v2, v3 and v4, and writes v2, v3 and v4. Legacy v2/v3 reads run ~1.86–2.14× faster on Intel and at parity on Apple silicon; v1 decodes bit-exact against Niantic's native and WebAssembly decoders.
- - The same bytes on every CPU. AVX2, NEON, WebAssembly SIMD and a scalar fallback produce identical files: reproducible builds, cacheable artifacts, no per-CPU surprises. AVX-512 and SVE2 are opt-in.
- - Memory-safe throughout, with no unsafe code in the libraries you link, plus a C library and header for existing integrations. Entropy coding is our own TurboZstd.
How this was measured
- Niantic's public reference scenes hornedlizard (786,233 splats) and racoonfamily (932,560 splats), SH degree 3, against fresh same-session libspz baselines built from source. Machines: Windows, Intel Arrow Lake, AVX2; Apple Silicon, NEON; browser, WebAssembly SIMD128.
- "One thread" is strictly one thread against one thread; "whole machine" lets each library use everything the box offers; "warm" is a streaming viewer reusing decode state across frames. Decode figures read the identical libspz-written v4 file. Windows decode ratios are lower bounds against the strongest libspz baseline measured there.
- File sizes compare each TurboSPZ setting with libspz's fixed default; every output is verified readable by stock libspz, native and WebAssembly.
- The live race decodes in your browser against Niantic's published WebAssembly build, so its numbers are yours, not ours.
Bring five of your splat captures.
A pilot runs both libraries on your own captures, on your own machine: same splats in, standard SPZ out, at the setting you choose. You keep the numbers.
TurboSPZ is licensed through the Bitruvius Developer Hub and ships as compiled binaries.
SPZ is an open format published by Niantic Labs / Niantic Spatial, Inc. References to Niantic, Cesium and glTF identify the products and ecosystems being compared or interoperated with; no affiliation, sponsorship, or endorsement is implied. libspz is published by Niantic Labs under the MIT License, and the live demo runs Niantic's unmodified reference decoder under that license. TurboSPZ is an independent implementation of the SPZ format that uses libspz's exact v4 quantization. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware. Full third-party notices: Attributions.