GS_ICP_SLAM and the Gaussian Splatting SLAM that runs at 100 FPS

A paper release, stated as such

The repository is described as an RGBD GS-ICP SLAM system, with the heading naming it as a 100 FPS Gaussian Splatting SLAM and the badge marking it as ECCV 2024. The authors are Seongbo Ha, Jiung Yeon and Hyeonwoo Yu, and there is a project page, a paper on arXiv at 2403.12550 and a video.

The first line of the body text is the one that sets expectations: this repository is intended to substantiate the results reported in the paper. Additional features including visualization tools will be updated soon.

That is an unusual and useful thing for a repository to say outright. It tells you the code exists to make a paper's numbers checkable, not to be a supported package, and it tells you the feature set is expected to grow around the visualisation side. For an evaluator, that framing decides what to look at. You are reading a research artefact with a specific purpose, and the code you would want in a product, a clean API, a maintained build and a documented interface, is not what is being offered.

The primary language is C++, the licence is MIT, the default branch is main, and the last push was on 2026-06-20. There are no GitHub releases, so the version history is the commit log and the paper.

The audience is a computer vision researcher or a student reproducing an ECCV paper, and a robotics engineer who wants to understand what a splat-based SLAM map buys and costs.

The interesting design question in the whole system is the following one, and it is where the name comes from: how do you keep a Gaussian Splatting map in sync with a moving camera without paying the cost that Gaussian Splatting normally implies.

Why generalised ICP instead of learned tracking

The name GS-ICP names the two halves of the approach, and the interesting choice is what it does not use.

Most SLAM systems that build a rich scene representation still use a learned or feature-based front end to estimate pose, and then spend the map update on the expensive part. This system does the opposite: pose tracking is generalised ICP, a geometric point-to-plane registration over the point cloud, and the scene representation is a set of 3D Gaussians that is updated as the camera moves.

The consequence is visible in the file layout. There is an mp_Tracker.py and an mp_Tracker_unlimit.py, and a separate mp_Mapper.py. The tracker and the mapper are decoupled, and the tracking rate is a separate concern from the map update rate.

The README describes the run modes as two variants. There is a limited to 30 FPS mode and an unlimited tracking speed mode, and each has its own pair of dataset scripts, replica.sh and tum.sh for the capped version and replica_unlimit.sh and tum_unlimit.sh for the other. There are correspondingly separate Python entry points, gs_icp_slam.py and gs_icp_slam_unlimit.py.

So the honest picture is that the headline number describes a configuration where tracking is decoupled and run at the rate the CPU allows, while the map is maintained asynchronously. That is a systems arrangement, not a single optimisation, and it is the kind of thing that does not survive being ported to a different codebase without work.

The 30 FPS limit in the default scripts is a deliberate cap rather than a hardware limit, and the existence of the unlimited scripts tells you the author expects people to run both ways.

Building the environment, submodules and the renderer

The environment setup is a conda environment pinned to Python 3.9 with a specific PyTorch and CUDA combination, and it is the kind of pin that dates a release.

conda create -n gsicpslam python==3.9
conda activate gsicpslam
conda install pytorch==2.0.0 torchvision==0.15.0 torchaudio==2.0.0 pytorch-cuda=11.8 -c pytorch -c nvidia
pip install -r requirements.txt

PCL is also needed, for the fast-gicp submodule, and that is an external system dependency rather than a pip package, so it has to be installed separately on the machine.

Then the submodules, and there are three of them, each installed differently:

conda activate gsicpslam
pip install submodules/diff-gaussian-rasterization
pip install submodules/simple-knn

cd submodules/fast_gicp
mkdir build
cd build
cmake ..
make
cd ..
python setup.py install --user

Two of them are pure Python packages installed with pip, and fast-gicp is a CMake project built and then installed with setup.py. That mixed pattern is a good sign of what the submodules are: the diff-gaussian-rasterization and simple-knn projects are the standard companions to 3D Gaussian Splatting, and fast-gicp provides the generalised ICP registration the tracking depends on.

The SIBR viewer is a separate build, and it is what the reference rendering uses:

cd SIBR_viewers
cmake -Bbuild . -DCMAKE_BUILD_TYPE=Release
cmake --build build -j24 --target install

The Python requirements list is short: opencv-contrib-python, open3d, scipy, tqdm, torchmetrics, plyfile and rerun-sdk. The open3d and plyfile entries are for loading and writing point clouds and meshes, rerun-sdk is for the visualisation, and torchmetrics is for the evaluation that the paper's numbers come from.

The repository structure shows the rest of the system: the gaussian_renderer/ directory for the splatting rasteriser, scene/ for the scene representation, utils/, arguments/ for the command line, configs/, assets/, metrics.py and render.py for evaluation, plus lpipsPyTorch/ as another vendored dependency for the perceptual similarity metric.

Datasets, the directory reshuffle, and running it

Two datasets are supported, Replica and TUM-RGBD, and each has a download script.

    bash download_replica.sh

        bash download_tum.sh

The Replica one needs a manual step afterwards, because the layout the system expects is not the layout the dataset ships in. The original structure puts results, containing the RGBD images, inside each room, with the depth images sharing the frame numbering, and the expected structure separates images from depth_images, both still carrying the frame000000.jpg and depth000000.jpg naming.

The instruction is to modify the directory structure to theirs, which is the kind of step that quietly breaks a reproduction if you skip it, because the loader is looking for directories that do not exist in the download.

Running is the same in both cases, with the difference being the FPS cap:

        # Replica
        bash replica.sh
        # TUM
        bash tum.sh

and the unlimited variants:

        # Replica
        bash replica_unlimit.sh
        # TUM
        bash tum_unlimit.sh

For the visual check there are two viewers. The rerun viewer is the easier one, and it shows the means of trackable Gaussians together with the rendered image from the reconstructed 3DGS map, which is the diagnostic you want when you are trying to understand whether the splats are tracking properly:

python -W ignore gs_icp_slam.py --rerun_viewer

The SIBR path is the reference renderer, and it needs a second terminal:

python -W ignore gs_icp_slam.py --dataset_path dataset/Replica/office0 --verbose

followed by launching the SIBR application against the render size you want. The -W ignore flag on the Python invocation is there because the renderer's warnings are noisy enough to bury the useful output.

There is also a Docker path, with the details left in a README inside the docker_folder directory.

The limits of a splat-based map, and what to compare against

Three limits follow from what the system is and how it is packaged.

The first is that the map is a rendering artefact rather than a geometric model. A 3D Gaussian Splatting map is a set of anisotropic Gaussians with appearance attached, and it is what you render from, but it is not a mesh and not a point cloud you can query for collision, distance or occupancy. If your application needs the map for anything other than looking at it, this is the wrong map type, and that is a category difference rather than a quality difference.

The second is the input model. The system is RGBD, so it needs a depth stream, which in practice means a depth camera. A monocular or lidar-only robot cannot use it as is, and the paper's evaluation datasets, Replica and TUM-RGBD, are both RGBD benchmarks, so the reported behaviour is in that regime.

The third is the packaging. The environment is pinned to Python 3.9, PyTorch 2.0.0 and CUDA 11.8, and it needs a system PCL installation plus three submodules built in three different ways. None of that is a blocker, but it does mean the setup is a project rather than a command, and the version pins will age. The MIT licence applies to the repository, and the submodules carry their own terms, which is worth checking before the code goes anywhere commercial.

The alternative worth comparing against is a conventional RGBD SLAM system with a sparse or dense point cloud map, which is what a robotics stack would normally run. The difference in approach is that this system spends its budget on a map you can render realistically and tracks with geometric registration, while a conventional system keeps a geometric map and spends the budget on a more robust front end. A third option is a 3DGS mapping system that assumes a known camera trajectory, which produces a better map because it optimises globally rather than incrementally, and is what you would use if you had poses from somewhere else.

That last distinction is the one to keep in mind. A splat map maintained inside a SLAM loop is a compromise against a map optimised from known poses, and the paper's contribution is showing that the compromise is affordable at a hundred frames per second for RGBD.

Editorial conclusion

GS_ICP_SLAM is a good fit for a researcher who wants to reproduce the ECCV 2024 paper's numbers or study how a Gaussian Splatting map is maintained inside a SLAM loop, because the release is explicitly intended to substantiate the published results and the mapper and tracker are separate modules you can read. It is a poor fit for a robotics product, since the tracker assumes RGBD input, the map is a rendering artefact rather than a geometry you can query, and there is no SLAM interface for a robot. Before building on it, read the tracking speed scripts rather than the default ones, because the released 30 FPS cap and the unlimited variant are separate entry points with separate scripts, and check that the PCL dependency for the fast-gicp submodule is present on your machine.

Frequently asked questions

Official sources

1. Issues
2. Lab-of-AI-and-Robotics/GS_ICP_SLAM on GitHub
3. License: MIT
4. README