Same SPZ. No migration. 4–7× faster encode than libspz.
A drop-in replacement for Niantic's libspz with bit-exact v4 quantization — so Cesium, glTF, and Esri/I3S consumers read your output unchanged. Encode runs ~4–5× faster single-thread (both on one core), and up to ~7× with turbospz multicore vs single-threaded libspz — on x86 AVX2 and Apple Silicon NEON.
Memory-safe, SIMD-first encode and decode for SPZ — the open Niantic Labs format for 3D Gaussian Splats — over our own clean-room TurboZstd entropy layer. One codebase: AVX2, NEON, WASM SIMD128, and scalar — with byte-identical output on every CPU.
Why SPZ matters
The JPG for 3D Gaussian Splats.
Niantic Spatial
~10× smaller than PLY
SPZ is the open compression format Niantic released for 3D Gaussian Splats — roughly 10× smaller than the PLY equivalent with virtually no perceptible loss. V4 (2026) added a leaner, more extensible frame.
Cesium
SPZ inside glTF
Cesium adopted SPZ as the in-glTF compression for Gaussian Splat payloads. Every glTF-based web 3D pipeline that ships splats now ships SPZ.
Esri (via Cesium)
Splats in I3S
Esri's splat layer in ArcGIS / I3S uses Cesium's SPZ pipeline downstream. Together with TurboLEPCC (Esri's point-cloud codec), TurboSPZ completes our Esri 3D coverage.
Not just v4
Writes every version, not just the newest.
Cesium, Esri, and the glTF ecosystem standardized on SPZ — including the gzip-framed legacy formats. TurboSPZ now writes those too, emitting the exact same wire format the reference produces — byte-for-byte identical and fully spec-compliant. It's the encoder you reach for at the write step of a Gaussian-Splat pipeline: identical output, smaller and far faster.
Standard format
Byte-for-byte the same
TurboSPZ emits the standard single-member gzip SPZ the ecosystem reads — verified byte-for-byte against the reference encoder's own output. Anything that reads SPZ reads TurboSPZ's output unchanged; it produces the format exactly, not a re-interpretation.
Smaller
~1% under the reference
On the gzip-framed formats, TurboSPZ writes consistently smaller files than the reference from the identical splat data — same quality in, fewer bytes out. The output is deterministic, so the size win is the same on every CPU.
Faster
Up to ~33× multicore
The reference encodes these formats on a single thread; TurboSPZ compresses them in parallel as one standard, fully-readable file — up to ~27–33× faster on a multicore machine, and ~3× even thread-for-thread. See the encode chart below.
Headline
Beats the reference on its own format — encode, decode, and in the browser.
~4–5× apples-to-apples single-thread (both one core); up to ~7× with turbospz multicore vs single-threaded libspz. Measured on AVX2 and NEON, on bit-exact-with-libspz output.
Faster than Niantic's own libspz in WASM across v2, v3, and v4 — legacy gzip v2/v3 at ~1.8×, v4 (zstd) at ~1.27× — both SIMD128, same file.
Wins every decode mode on every platform, same v4 file: single-thread ≥1.17–1.21× (Windows) and 1.17–1.19× (Apple Silicon), measured strictly one thread vs one thread; full-machine ≥1.40–1.46× / 1.32–1.38×; and up to ≥3.6× with warm-context streaming reuse. No caveats left on the board.
libspz has one fixed setting; turbospz makes size a profile. Its max-compression profile writes 3.1–3.5% smaller files than libspz while still encoding ~1.6× faster — and every profile stays fully libspz-readable.
The new lane
Wins the SPZ decode race in the browser.
Splats are increasingly viewed in the browser, in WASM — so we put turbospz head-to-head against Niantic's own libspz on the hardest footing: both compiled to WASM SIMD128, both decoding the exact same file, in-tab. turbospz reads the v2, v3, and v4 wire formats and decodes each one faster than the reference: the older gzip-framed v2/v3 by ~1.8×, and v4 (zstd) by ~1.27×. It's the same memory-safe codec that drives the native path, compiled to WebAssembly with no special-casing. Two structural choices drive the gap in our measurements: turbospz exposes zero-copy views that alias WASM linear memory straight into a GPU upload or a three.js BufferAttribute, and for a streaming viewer it reuses its decode context across frames so repeat decodes skip buffer allocation entirely. Same file in, decoded by our roundtrip-verified codec, fewer milliseconds out — against the reference implementation from the team that designed the format.
Browser decode throughput by SPZ version — turbospz-wasm vs Niantic libspz (wasm)
Browser decode throughput, turbospz-wasm 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×).
Prove It
Race it yourself. Right here.
A real 786k-splat capture, decoded on two parallel worker threads in your browser — TurboSPZ against Niantic's own libspz wasm, same bytes — then rendered with full Gaussian splatting. Drag to orbit; the cameras are linked.
The whole matrix
Faster than the reference — across every version and backend.
One codec, three SPZ versions, three architectures — all measured against libspz as the 1.0× baseline. turbospz leads on x86 and in the browser on every version, and wins v4 on Apple Silicon. The honest exception is visible right in the bars: the older legacy v2/v3 format offers far less room for a faster decoder to pull away, so on Apple-native those land at parity with libspz's well-tuned decoder — and that's exactly where the browser lane (which every platform runs) keeps turbospz ahead.
Decode speedup vs libspz — every version, every backend
Decode throughput vs libspz, both reading the same file per version. Browser is warm WASM SIMD128 vs Niantic's libspz compiled to wasm. Native v4 cells compare both codecs at full machine; turbospz also wins the strict single-thread pairing, measured one thread vs one thread on both sides (1.17–1.21×). Scenes hornedlizard (786K) + racoonfamily (933K), SH degree 3.
Encode performance
Faster on every scene, every architecture, every version.
Multicore encode speedup vs the reference, on two Gaussian Splat scenes — same input, same SH degree, byte-identical quantization. turbospz parallelizes the encode; libspz doesn't ship a parallel writer for either format. The two charts use different baselines: v4 (zstd) is measured against libspz's own v4 encoder, the legacy v2/v3 (gzip) charts against its single-threaded zlib legacy 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 backend, SH degree 3. AVX2 (Intel Arrow Lake) and Apple Silicon NEON produce byte-identical output. Apples-to-apples single-thread encode 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 backend, SH degree 3. turbospz's single-member 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.
Native decode
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-format advantage. On Windows with AVX2, turbospz wins every mode: ≥1.17–1.21× single-threaded, ≥1.40–1.46× with tile parallelism, and up to ≥3.6× in a warm streaming-viewer context where decode buffers are reused across frames. On Apple Silicon it's the same story: 1.17–1.19× single-threaded, 1.32–1.38× full-machine.
A note on rigor, because it's how we work: an earlier version of this page reported a single-threaded loss on Apple Silicon (~0.89×) — we published it as an honest caveat. Deeper measurement showed the comparison itself was skewed in the reference's favor — the published pairing wasn't one thread vs one thread. We rebuilt the comparison strictly single-thread-vs-single-thread on both sides, re-measured, and verified output equivalence at full float precision. Result: turbospz wins that pairing too. The caveat is gone because we eliminated it.
Why switch
A library swap. Not a migration.
- - Zero migration. turbospz writes byte-identical SPZ v4. Swap the encoder and every downstream consumer — Niantic, Cesium, glTF, Esri/I3S — reads your output unchanged. No format conversion, no re-tooling, no risk to the rest of your pipeline.
- - Faster encode, lower compute cost — ~4–5× single-thread apples-to-apples, up to ~7× with multicore vs single-threaded libspz, on both x86 AVX2 and Apple Silicon NEON.
- - Win where it ships, across versions. Your splats render in the browser, and that's exactly where turbospz beats Niantic's own decoder — on v2, v3, and v4, 1.3–1.8× faster in WASM, with zero-copy views straight to the GPU. Native v4 decode wins every mode too — single-thread, parallel, and warm streaming — on both x86 and Apple Silicon.
- - Cross-architecture byte-identical determinism. The same input produces the same encoded bytes on AVX2, NEON, WASM SIMD128, and scalar — reproducible builds, cacheable artifacts, no per-CPU surprises in regression tests.
- - Size is a profile, not a fixed setting. libspz hard-codes one compression level; turbospz lets you pick the operating point — the speed-first default, a libspz-matched balanced profile, or a max-compression profile that writes 3.1–3.5% smaller files while still encoding ~1.6× faster than libspz (multi-frame parallel archive encode). Every profile stays fully libspz-readable, with no change to the wire format. Entropy layer is TurboZstd, our own clean-room Zstandard codec. Memory-safe, zero
unsafein consumer libraries; decoder build freely redistributable.
Compatibility
Bit-exact on the wire.
- - Byte-identical with the libspz v4 wire format — every Niantic, Cesium, glTF, and Esri/I3S consumer reads turbospz output with no changes to their pipelines.
- - Backends from one codebase: AVX2 + BMI2 + FMA on x86, NEON on aarch64, WASM SIMD128 in the browser, and a portable scalar fallback. AVX-512 and SVE2 are opt-in.
- - Memory-safe throughout, with zero
unsafein consumer libraries. A C-ABI shared library with a ready-to-use header sits alongside the idiomatic memory-safe API. - - The decoder-only build is freely redistributable; the encoder is license-gated.
- - Reads every SPZ version libspz reads — v1, v2, v3, and v4 — and writes v4. Drop it in front of any SPZ asset, old or new. Legacy gzip v2/v3 decode runs ~1.86–2.14× faster than libspz on x86 and at parity natively on Apple Silicon; in the browser turbospz leads across versions. v1 (float16) decode is verified bit-exact against Niantic's own native and WASM decoders.
Drop in turbospz.
Keep your wire format. Ship faster.
The same SPZ v4 bytes your Cesium, glTF, and Esri consumers already read — ~4–5× faster single-thread encode (up to ~7× multicore), a decode that beats the reference in every mode on every platform — native and browser — and an archive profile that's smaller AND faster than libspz. Talk to us about an encoder license and an enterprise evaluation, or pull the redistributable decoder to benchmark it yourself.
All figures measured on the public Niantic reference scenes hornedlizard (786,233 splats) and racoonfamily (932,560 splats), SH degree 3, against fresh same-session libspz baselines built from source. "Single-thread" figures are measured strictly one thread vs one thread on both sides; "full machine" lets each codec use everything the box offers; "warm-context" is the streaming-viewer path, where decode state is reused across frames. Decode figures compare both decoders reading the identical libspz-written v4 file. Windows decode ratios are stated as lower bounds against the strongest libspz baseline we have ever measured on that machine. Archive-profile size/speed (−3.1–3.5%, ~1.6×) is turbospz max-compression vs libspz's fixed default; output verified readable by stock libspz, native and WASM.
SPZ is an open format published by Niantic Labs / Niantic Spatial, Inc. References to Niantic, Cesium, glTF, ArcGIS, I3S, and Esri 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, clean-room implementation of the SPZ format, byte-identical with the libspz v4 wire output. Performance comparisons reflect our own measurements under the stated methodology; results vary by workload and hardware.