OpenSplat: a portable, AGPL 3D gaussian splatting implementation that outgrew its original repo

The pitch in one paragraph

OpenSplat is a free C++ implementation of 3D gaussian splatting, positioned as portable, lean and fast. It does exactly one thing: it takes camera poses plus sparse points from a photogrammetry project and computes a scene file you can view, edit and render elsewhere. Those scene files come in four formats, `.ply`, `.splat`, `.spz` and `.rad`, and the point of supporting all four is portability rather than completeness. Nothing here renders in a viewer for you. The output is the deliverable.

The input side is broader than the marketing line suggests. Accepted sources are ODX, the format from the same organisation; OpenSfM; COLMAP; OpenMVG, which arrived in the 1.1.5 cycle; and the nerfstudio custom dataset layout. In practice that means you can point it at the output of most existing structure-from-motion pipelines without converting anything, which is the single feature that most often decides whether a splatting tool gets used at all.

The repository description advertises CPU and GPU support for Windows, Mac and Linux, and the README adds a graphics card is recommended but not required. A CPU run is described as roughly one hundred times slower. For a dataset you process once, that is a defensible trade.

Four GPU backends, one CMake flag

The build matrix is the technical core of the project. There are four documented paths, selected through a single `GPU_RUNTIME` option.

CUDA is the reference path. You need `nvcc` on your PATH and a working `nvidia-smi`, then a LibTorch build that matches your CUDA version. On macOS the default runtime is `MPS`, and if the Metal compiler is missing the build quietly falls back to CPU. You can force CPU-only with `-DGPU_RUNTIME=CPU`. ROCm through HIP is the AMD path, requiring ROCm installed at `/opt/rocm` and a matching LibTorch, with `PYTORCH_ROCM_ARCH` set for your card.

The common CPU build is four commands:

git clone https://github.com/pierotofy/OpenSplat OpenSplat
cd OpenSplat
mkdir build && cd build
cmake -DCMAKE_PREFIX_PATH=/path/to/libtorch/ .. && make -j$(nproc)

That sequence is what nearly every path in the README reduces to, which is a good sign for a project whose hardest problem is usually dependency setup rather than code. OpenCV is a requirement for all builds, installed on Debian-family systems with `sudo apt install libopencv-dev`.

There is a wrinkle worth flagging. The ROCm section tells you to match LibTorch to ROCm 5.7, yet the repository carries `Dockerfile.rocm6`, `Dockerfile.rocm6.3.3`, `Dockerfile.rocm6.4.0` and `Dockerfile.rocm7`. The images have moved forward; the prose has not. Trust the Dockerfiles over the version number in the README.

Containers, and what is inside them

The Docker path is the tidiest way to get a reproducible environment, and it starts with one command from the repository root:

docker build -t opensplat .

The default image is parameterised through build arguments at the top of the Dockerfile, which is where you find out what the maintainers actually test against:

ARG UBUNTU_VERSION=22.04
ARG TORCH_VERSION=2.2.1
ARG CUDA_VERSION=12.1.1
ARG CMAKE_CUDA_ARCHITECTURES=70;75;80
ARG CMAKE_BUILD_TYPE=Release

Ubuntu 22.04, LibTorch 2.2.1, CUDA 12.1.1 and architectures spanning 70 through 80 is a deliberately old baseline, which is the right choice for a tool people run on machines they do not control. The Dockerfile also carries a conditional path for Ubuntu 20.04 that adds Kitware's apt repository so a newer CMake is available, installs the CUDA toolchain by calling a script under `.github/workflows/cuda/`, and fetches LibTorch by reconstructing the download URL from those same build arguments.

That last detail is worth noting for anyone automating builds: the image does not pin by digest, it derives its own download URL at build time. Reproducible enough for daily work, and not reproducible enough to call an audit trail.

The source layout tells you what it can do

Reading the file names is a fast way to understand scope. The core pipeline is visible in `project_gaussians.cpp` and `rasterize_gaussians.cpp`, with a `rasterizer/` directory holding the lower-level renderer, and `spherical_harmonics.cpp` handling the view-dependent colour term that makes splats look like photographs rather than fog. `undistort.cpp` and `cv_utils.cpp` cover image correction, and `cv_utils` explains why OpenCV is still a dependency even after the 1.2.2 release removed the calibration dependency it once used.

Training support is real rather than aspirational. `simple_trainer.cpp` builds behind `OPENSPLAT_BUILD_SIMPLE_TRAINER=ON`, which the ROCm instructions show, and the 1.1.5 cycle added the ability to continue training from an existing PLY. `ssim.cpp` provides the perceptual metric that makes a training loop meaningful, and `kdtree_tensor.cpp` points to the spatial index used for neighbourhood queries. `sysinfo.cpp` handles hardware detection, which is how one binary can fall back across backends.

Format support is distributed by filename in the same way: `point_io.cpp` handles reading and writing points, `rad.cpp` covers the RAD format, and `nerfstudio.cpp`, `colmap.cpp`, `opensfm.cpp` and `openmvg.cpp` are the adapters for each accepted input. Four input adapters and one simple trainer in a flat, readable layout is a reasonable shape for a codebase of this size.

Releases, moves and a repository that changed address

The version history is short and recent. Version 1.1.5 landed in August 2026 and is dense with fixes: a NaN problem on Metal, consistent behaviour for `downscaleFactor`, a Pangolin-based visualizer, corrections to that visualizer's image distortion, continued training from PLY, OpenMVG support, and removing an unnecessary standard C++ dependency. Version 1.2.0 arrived a few days later with zip input support, masks, external dependency removal, tinyglm and fuller OpenCV-based undistortion. Version 1.2.2, published on the same day as the most recent push, removed the unused OpenCV calibration dependency and fixed a tile-bin overflow in the compressed image cache.

One oddity: the comparison link on the 1.2.2 release jumps from 1.2.0, so there is no 1.2.1 tag. Meanwhile a `VERSION` file sits at the repository root, which means version data exists in two places and only one of them is tied to a release.

The bigger story is the move. A banner announces that OpenSplat has joined the WebODM ecosystem, and the repository is now `WebODM/OpenSplat`, but the README's build instructions, the clone URL in every code block, and the pull request links in several release notes still say `pierotofy/OpenSplat`. Contributors followed the redirect without breaking anything, which is convenient and also means the first-run instructions you are reading come from the previous owner. The license is AGPL-3.0, which deserves its own look before anyone builds a service on it.

What the AGPL means for commercial use

The license is the least technical and most consequential choice in the project. AGPL-3.0 covers the library and the tool. Running it as a command-line converter on your own machine creates no distribution event and nothing is owed. Wrapping it in a hosted web service that users interact with over a network is exactly the case the AGPL was written to cover, because section 13 obliges you to offer those users the corresponding source of your modified version.

For a research tool, a hobbyist, or an internal pipeline this is a non-issue. For a commercial photogrammetry product that wants to expose splat conversion as a feature, it is a legal review item, not a footnote. The README does not discuss licensing at all, so a reader has to notice the `LICENSE.txt` file themselves.

It is worth putting that next to the funding arrangement. The README offers a paid pre-built Windows binary through a checkout hosted by a third party, framed as a time-saver that also supports the project. That is a straightforward commercial arrangement for a personal-use build, and it exists alongside rather than instead of the AGPL terms on the source.

Where it sits against the alternatives

The comparison searches around this project split into three camps, and OpenSplat's position in each is clear.

Against research implementations, OpenSplat wins on deployment breadth and loses on raw training throughput, because the systems it is measured against typically assume one specific accelerator and are tuned for it. Against viewer software, it is not a competitor at all: it produces files for those viewers rather than trying to replace them. And against the paid desktop applications in the same category, the argument is cost plus control, offset by the fact that the paid Windows build is the only route to a binary without a compiler.

Two smaller notes complete the picture. A Pangolin-based visualizer now ships in the tree, which gives you a way to inspect a training run without leaving the project. The repository also carries an `AGENTS.md`, which tells you the maintainers expect automated tooling to be part of the workflow rather than an afterthought.

The honest summary is that OpenSplat optimises for the person who already has a photogrammetry pipeline and needs a converter that will run on whatever machine is in front of them. If that is you, the build is short and the formats are broad. If you want the fastest possible training loop on a single accelerator, the ceiling here is set by the portability you actually asked for.

Editorial conclusion

OpenSplat has quietly become the reference implementation you can build anywhere, and the reason is that it kept every hardware path alive instead of optimising for one. CUDA, HIP, Metal and a working CPU fallback each have a documented build, the input side accepts whatever your photogrammetry tool already produced, and the output side writes the four scene formats viewers actually read. The costs are equally concrete. The AGPL is the real adoption constraint for commercial service work, the README still instructs you to clone a repository that has since moved, and the ROCm guidance on the page is older than the images in the tree. Build from a tag you have read, and read the CMake options rather than trusting the prose.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. WebODM/OpenSplat on GitHub