Spirula Studio: a cross-vendor 3D Gaussian Splatting trainer that skips Python and COLMAP

The problem Spirula Studio removes: a Python stack and a separate COLMAP run

A conventional Gaussian splatting setup asks you to assemble several pieces before you see a single splat. There is a Python and PyTorch environment, a structure-from-motion step usually handled by a separate COLMAP install, and a training script that expects the two to agree on file layout. Spirula Studio compresses that into one self-contained binary. The README states the pitch directly: training from raw photo or video to splat to textured mesh, with no Python/PyTorch and no separate COLMAP install.

The audience is narrower than the tagline suggests, and that is a good thing. It is for people whose GPU is not an NVIDIA card, or whose NVIDIA card is old enough that the CUDA path is awkward, and who still want to train rather than only view splats. The topics list points the same way: cross-vendor, Vulkan, VRAM optimization, 360-camera. If you already have a working CUDA pipeline and a Python environment you trust, the value proposition here is convenience and portability, not raw throughput. The README itself says the CUDA backend may be faster or slower than Vulkan depending on the GPU driver, with the difference generally within a few percent. That is a portability claim, not a speed claim, and it should be read as one.

Two backends, one training core: how the Vulkan and CUDA paths differ

The build system exposes a single switch, `SS_BACKEND`, and the README lays out a table of what each value gets you. The Vulkan backend is described as cross-platform and cross-vendor, the most tested option, working on all major GPUs, faster to build and producing a smaller binary. The CUDA backend is labelled legacy, for CUDA-capable NVIDIA GPUs. Both, according to the README, provide the same training and meshing functionality.

The asymmetry is in the additional features column. Native structure-from-motion, frame extraction from videos and AI masking are listed only for Vulkan. So the end-to-end workflow announced on August 8, 2026, which the README describes as frame extraction, AI masking, native SfM, meshing and batch training accessible from both GUI and CLI, is a Vulkan-backend story. Choosing CUDA buys you a familiar execution path and nothing else in this table.

On the training side, the README names one strategy combining advantages of MCMC, IGS+ and MRNF, plus quantized training for VRAM efficiency, a modified bilateral grid and PPISP for exposure and white balance correction, and native 360-degree and equirectangular support. The quantization claim is the specific one: up to 10 million SH3 Gaussians in 8 GB VRAM. Treat that as a configuration target the authors publish, not as a guarantee for your scene, because Gaussian count and VRAM use also depend on image resolution and the number of training views.

Installing a release versus building the Vulkan backend from source

The shortest path is the Releases page. The README says binaries for Windows, Linux and macOS are there, and that you select the one for your platform, download and unzip it, then double click to open the GUI. There is no package manager step and no environment to activate. If you are on a remote or cloud GPU, the README points at the CLI and says to run `spirula --help` for details.

spirula --help

By default, the README states, `spirula train` serves a viewer on an HTTP port that you can forward over ssh and watch in a browser. That is the intended remote workflow: train on the cloud machine, forward the port, watch progress locally.

spirula train

Building from source is the other route, and it is where the platform differences show. On Linux, after installing the Vulkan SDK and cloning the repository, the README gives a single build script invocation:

cd spirula-studio/
bash build_develop.bash -DSS_BACKEND=vulkan -DSS_ENABLE_PATENTED=ON

On macOS the same script runs first, then two extra targets wrap the binary into an app bundle and a disk image. The README notes MoltenVK is automatically fetched by CMake and statically linked by default, so the resulting app runs without a separately installed dependency.

cd spirula-studio/
bash build_develop.bash -DSS_BACKEND=vulkan -DSS_ENABLE_PATENTED=ON
cmake --build build --target macos_app
cmake --build build --target macos_dmg

On Windows with MSVC there is a batch wrapper, and the README says a successful build yields `build\spirula.exe`. Whichever route you take, the flag `-DSS_ENABLE_PATENTED=ON` appears in every example, and it is not cosmetic. The README explains it enables GPU video decoding instead of shelling out to ffmpeg, roughly 15x faster frame extraction and no ffmpeg install, but states that AVC/HEVC bitstream parsers carry third-party patent exposure and that enabling it makes you responsible for local patent compliance. Turning it off is a legitimate choice.

Where Spirula Studio is the wrong tool, and what the README leaves open

The clearest boundary is the masking path. The README states that masking needs a SAM checkpoint, which the GUI downloads on first use and caches, and that the checkpoints are Meta's models under Meta's licenses, with SAM 2.1 under Apache-2.0 and SAM 3 under a non-standard Meta license. They are never bundled, and the GUI shows the terms before fetching anything. On the command line you must point `--model` at a file you downloaded yourself. If your environment cannot reach the download, or cannot accept those terms, the AI masking feature is unavailable to you even though the rest of the pipeline works.

Second, the CUDA backend is the wrong choice if you want the SfM, frame extraction and masking components, because the README's feature table lists those only for Vulkan. A CUDA build is a training and meshing build.

Third, the README does not document rollback. There is no described procedure for reverting a training run, undoing a quantization setting, or restoring a previous model state. Release cadence is fast, with v2026.9.8, v2026.9.10 and v2026.9.13 all landing within a week, and the README does not say whether datasets or checkpoints written by one build remain readable by the next. If you need reproducibility across versions, pin a release and keep your own copies of inputs and outputs.

Finally, the repository's own `pyproject.toml` is explicit that there is no Python package to install. Its comments state that the Python package is gone, that `spirula` is a standalone executable built with CMake, and that what remains under `reference/python/` and `scripts/` are hand-run tools rather than a package. Anyone arriving from a `pip install` habit will find nothing here, by design.

How it compares with OpenSplat and other CUDA-first trainers

OpenSplat is the natural comparison, and the difference is architectural rather than incremental. OpenSplat is a C++ and LibTorch implementation of 3D Gaussian Splatting that targets the CUDA execution path. Spirula Studio's default and most tested backend is Vulkan compute, which is what lets the same binary run on AMD, Intel and Apple Silicon GPUs as well as NVIDIA. That is the whole point of the project, and it is why people searching for Gaussian splatting on a Mac or on an AMD card end up here.

The second difference is scope. A CUDA-first trainer typically expects you to bring your own structure-from-motion output, which in practice means running COLMAP first. Spirula Studio folds frame extraction from video, native SfM, AI masking and meshing into the same binary, at least on the Vulkan backend. That reduces the number of tools you have to keep working together, and it also means you inherit Spirula Studio's choices for each stage instead of swapping in a preferred SfM implementation.

The third difference is licensing posture. Spirula Studio is GPL-3.0, and its build offers an optional patented-code flag that you decide on. A CUDA-first trainer built on LibTorch inherits a different dependency and licence picture. Neither is automatically better; they constrain different things, and the choice depends on whether you are shipping a product or producing a dataset.

Maintenance, releases, and the GPL-3.0 obligation to think about

The repository is not archived, and the last push was on 2026-09-15. Releases are frequent and dated: v2026.9.13 on 2026-09-13, v2026.9.10 on 2026-09-10, v2026.9.8 on 2026-09-08. The news entries in the README track a similar rhythm, with metric scale on September 10, LoMa feature support on September 3, macOS validation on August 14, and the end-to-end Vulkan workflow plus multilingual support on August 8. That cadence is the upgrade cost: there is no long-term support branch described, so staying current means re-downloading binaries or rebuilding, and rebuilding means re-checking the `SS_BACKEND` and `SS_ENABLE_PATENTED` flags each time.

Licensing is GPL-3.0. If you distribute a modified binary, the usual copyleft obligations attach, and this is not legal advice. There is a second layer that is easy to miss: the optional patented-video flag, the SAM checkpoints with their separate Meta terms, and the LoMa dependency the SfM module can use. Each carries its own conditions. A team that merely runs the tool internally to produce meshes has a different exposure than one that ships the binary inside a product.

Editorial conclusion

Adopt Spirula Studio if your machine has no CUDA-capable NVIDIA GPU, or if you want video-to-splat-to-mesh in one binary without a Python environment. Do not adopt it if your pipeline depends on a specific CUDA-only extension, or if you need a documented rollback path, because the README does not describe one. Verify three things before you commit: that the release matching your platform and date exists on the Releases page, that your GPU's driver exposes the Vulkan features the build expects, and that `-DSS_ENABLE_PATENTED=ON` is a decision your legal position can support, since AVC/HEVC bitstream parsers carry third-party patent exposure.

Frequently asked questions

Official sources

1. harry7557558/spirula-studio on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases