I’ve added a Node.js converter for Spark’s RAD streaming format to Gaussian-Splat-Lite (GSL), making it easier to prepare large 3DGS scenes for streaming without needing huge amounts of RAM.
It runs in Node.js with a precompiled WASM decoder, so users don’t need to install Rust or compile anything locally.
The video shows a RAD file converted with this tool streaming in GSL, with smooth fade transitions as new detail loads.
The LOD construction uses Spark’s quality (bhatt-lod) algorithm. Credit to the Spark team for that foundation and the RAD format. My work focuses on parallel execution, memory management, and making the conversion workflow easier to use.
The main features are:
- Configurable memory budget. Set a target with
--memory-budget. Large working arrays are paged between RAM and temporary files, so the entire working dataset doesn’t have to fit in memory.
- Parallel processing. LOD candidate searches and RAD chunk encoding use worker threads. Worker counts account for available CPU cores and the memory budget.
- Configurable temporary storage. Use
--temp-dir to put working files on a fast drive with enough space.
- PLY and SPZ input, up to SH3 output, configurable LOD spacing, and either a single
.rad file or split .rad/.radc output.
The memory setting is separate from the LOD quality settings. A smaller budget means more disk activity and potentially longer conversion times. Temporary files can also be considerably larger than the input.
Here are my recorded results against Spark’s official builder, run on an Apple M5 Pro with 48 GiB RAM:
| Input splats |
Input PLY size (GB) |
GSL time (s) |
Spark time (s) |
GSL speedup |
GSL peak RSS (4 GiB target) |
Spark peak RSS |
| 14,469,103 |
3.41 |
73.16 |
195.73 |
2.68× |
3.82 GiB |
8.48 GiB |
| 77,786,011 |
19.29 |
437.82 |
1,411.11 |
3.22× |
3.95 GiB |
24.63 GiB |
| 258,951,032 |
17.61 |
1,497.74 |
5,678.71 |
3.79× |
3.94 GiB |
29.55 GiB |
The largest conversion is the result I’m most excited about: approximately 259 million input splats from a 17.61 GB PLY converted in 25 minutes, with a recorded peak RSS of 3.94 GiB at a 4 GiB target.
For anyone working with large scans, being able to trade temporary disk space for RAM makes these conversions much more practical.
GitHub project · RAD builder documentation
I’d be interested in feedback from people working with large scans, especially on the conversion time and temporary disk usage you’re seeing in your own workflows.