# GLIM 3D mapping framework: architecture, setup, and adoption limits

> GLIM is a C++ framework for globally consistent 3D mapping across LiDAR, RGB-D, and related range sensors. It suits mapping specialists who need factor-graph scan matching, GPU options, manual correction, and extension points, but the repository does not provide a self-contained installation procedure.

**koide3/glim** — GLIM: versatile and extensible point cloud-based 3D localization and mapping framework

- Repository: https://github.com/koide3/glim
- Website: https://koide3.github.io/glim/
- Stars: 1,888 · Forks: 295
- Language: C++
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/koide3-glim

## Where GLIM fits in a 3D localization stack

GLIM addresses the mapping and localization stage that must turn a sequence of range observations into a spatially consistent 3D representation. Its core problem is not simply aligning each new scan to the previous one. The framework instead minimizes registration error across multiple scans on a factor graph, with the stated aim of retaining consistency across the complete map. That distinction matters when trajectories drift, when scans overlap only indirectly, or when separate mapping sessions need to be corrected or merged.

The intended audience is engineers working with 3D LiDAR, RGB-D, inertial localization, or extensible SLAM systems in C++. GLIM removes sensor-specific processing from its central approach, so its documented scope includes spinning LiDAR such as Velodyne HDL32e and Ouster OS1-32, non-repetitive scan devices such as Livox Avia and MID360, solid-state LiDAR such as Intel RealSense L515, and RGB-D cameras such as Microsoft Azure Kinect.

That does not mean every sensor can be connected without adaptation. It means GLIM defines a common range-mapping framework rather than limiting the graph and map representation to one device family. ROS and ROS2 integrations are optional, and Docker images are published separately as koide3/glim_ros2. The main repository also points to glim_ext for examples such as explicit loop detection and LiDAR-visual-inertial odometry. Those related packages matter when deciding whether GLIM alone supplies the integration behavior an application needs.

GLIM is therefore less appropriate as a plug-and-play recorder and more appropriate as a mapping framework embedded into a larger localization system. Its value lies in the registration and optimization model, while sensor ingestion, odometry, loop closure, and application interfaces may depend on selected modules or companion projects.

## GLIM factor-graph registration and data flow

The documented core is direct multi-scan registration error minimization on a factor graph. Individual range observations enter the mapping process as scans, registration relationships are expressed as factors, and optimization seeks a globally consistent arrangement of those relationships. The README also states that GPU acceleration is supported for mapping speed and quality, although it does not define a universal GPU code path or guarantee that every estimation module behaves identically.

GLIM offers multiple estimation modules rather than one fixed pipeline. According to the README, they cover scenarios ranging from accurate mapping with a GPU to lightweight real-time mapping on a low-specification PC such as Raspberry Pi. This is an important architectural boundary: hardware selection is tied to module selection, not to a single documented performance profile.

The map is not presented as an immutable output. GLIM includes an interactive interface for manually correcting mapping failures and refining results. Its gallery also shows manual loop closing, merging multiple sessions, segmentation, and removal. These examples indicate that GLIM treats graph and map editing as part of the workflow, although the README does not document the internal file format, undo model, or exact interaction sequence.

Extensibility is implemented through global callback slots. According to the README, these slots expose internal mapping states and permit additional constraints to be inserted into the factor graph. The mechanism is more specific than a general plugin promise: extensions can both observe mapping state and alter optimization constraints. The companion glim_ext repository provides examples, but it is separate from the core repository, so core functionality should not be conflated with explicit loop detection or LiDAR-visual-inertial odometry.

## Dependencies and the incomplete installation boundary

GLIM is a C++ project with a dependency stack rather than a standalone executable distributed with a single installer. The mandatory dependencies are Eigen, nanoflann, GTSAM, and gtsam_points. CUDA, OpenCV, OpenMP, ROS or ROS2, and Iridescence are optional. The presence of CMakeLists.txt, cmake/, package.xml, and docker/ confirms a source-based CMake and ROS-oriented repository layout, but the README does not provide the commands needed to configure, compile, or install it.

The project directs readers to https://koide3.github.io/glim/ for documentation and to Docker Hub for koide3/glim_ros2 images. The README states that GLIM has been tested on Ubuntu 22.04 and 24.04 with CUDA 12.2, 12.6, and 13.1, as well as NVIDIA Jetson Orin with Jetpack 6.1. These are stated platform combinations, not a substitute for an installation recipe. Because no build commands, Docker invocation, launch command, or minimal configuration file are given here, this article cannot safely provide a first-run shell tutorial.

The official documentation is therefore the required next source for setup. A new user should locate the exact dependency installation, CMake configuration, compilation, and execution instructions there before assuming that a platform combination alone is sufficient. The distinction matters for evaluation: GLIM may fit the target platform, yet the core repository alone does not establish a reproducible installation path from the README.

ROS2 should not be mistaken for the core C++ library. The README links koide3/glim_ros2 as a related package and koide3/glim_ros2 as the Docker Hub repository name. Projects requiring ROS2 message integration or container-based operation need to evaluate that package and its image separately.

## Version changes that affect GTSAM and CUDA deployments

GLIM's update log gives adopters a concrete compatibility concern. The v1.2.0 entry adds support for GTSAM 4.2a9 and GTSAM 4.3a0, CUDA 13.1, and intensity visualization. The v1.2.1 entry adds backface culling, while v1.2.2 fixes errors involving GTSAM 4.3a1. A June 2025 notice says that the base GTSAM version changed and instructs users to rebuild and install GTSAM 4.3a0 together with gtsam_points 1.2.0.

These entries imply that dependency compatibility is version-sensitive. A GLIM source checkout should not be paired with an arbitrary existing GTSAM or gtsam_points installation. The README explicitly calls for rebuilding GTSAM after a base-version change, which is a larger upgrade action than merely relinking GLIM. It also suggests that moving between GLIM versions may require reviewing the GTSAM, gtsam_points, and CUDA combination rather than following the GLIM version alone.

The repository has no GitHub releases, so GitHub's release page is not a dependable source for release artifacts. Version information instead appears in the README update log. The documentation does not state a stable release channel, semantic-version policy, backward-compatibility guarantee, or migration procedure beyond the listed fixes and dependency notices. Commercial support is offered through the contact address printed in the README.

The MIT license permits use under its terms, including commercial use subject to the license conditions. The README also asks academic users to cite the GLIM paper. Those are usage obligations and requests respectively, not substitutes for reviewing the LICENSE file in the deployed source.

## GLIM limitations and explicit loop-closure boundaries

The clearest limitation is that GLIM's central promise depends on adequate scan relationships and optimization behavior. The README does not provide failure thresholds, minimum overlap requirements, convergence guarantees, or guidance for dynamic environments. It also does not claim that every mapping problem can be repaired through the interactive interface. Manual correction is available, but that is an operator workflow, not an automatic recovery mechanism.

A second boundary concerns loop closure. The core repository presents globally consistent mapping, while glim_ext is described separately as containing an explicit loop-detection example. Unless that companion package and its required odometry path are included, users should not describe GLIM as providing turnkey automatic loop closure. Likewise, GLIM's mention of LiDAR-visual-inertial odometry is an extension example, not evidence that visual and inertial processing are bundled in every deployment.

Third, GPU availability is not enough to choose the correct module. GLIM supports GPU acceleration but also advertises a lightweight real-time module for a low-specification PC. Without module-specific measurements in the README, neither the GPU path nor the lightweight path can be judged by broad feature labels alone. The project is the wrong choice when a team needs certified timing, a fixed hardware support matrix, or documented memory limits and cannot investigate those separately.

Finally, the release evidence is narrow. There are no GitHub releases, and the README provides version notes rather than formal compatibility declarations. This makes source builds and dependency verification part of adoption rather than an afterthought.

## GLIM compared with sensor-specific SLAM packages

A real alternative is a sensor-specific SLAM package that bundles driver ingestion, front-end odometry, loop detection, optimization, and visualization into one application configuration. GLIM takes a different route by separating a common range-based mapping framework from sensor-specific processes and exposing mapping internals through callback slots. The practical difference is the location of integration work.

With GLIM, a team can choose among estimation modules and insert constraints through the global callback mechanism. This is attractive when the same map representation must support LiDAR, RGB-D, custom constraints, manual graph edits, or companion odometry components. It also creates a larger evaluation surface because the team must align CMake, GTSAM, gtsam_points, CUDA, ROS2, and any extension package.

A sensor-specific SLAM package is more attractive when the application needs one supported sensor, an established launch configuration, and a documented path from input to globally optimized map. The trade-off is less ability to change the graph and mapping internals through GLIM's callback design. It may also remove the need to engineer a custom mapping stack around the framework.

The choice should therefore follow system boundaries. Choose GLIM when global registration quality, extensibility, or interactive correction are primary requirements. Choose an integrated SLAM application when deployment simplicity and a documented end-to-end configuration matter more. Based on the repository layout and README, GLIM is the more demanding framework option.

## Maintenance signal and adoption check for GLIM

The repository is not archived, and its last push was on 2026-10-08. That supports treating the codebase as receiving recent changes, but it does not prove API stability or production fitness. The README's latest listed version is v1.2.2 from 2026-07-12, while GitHub has no formal releases. Maintenance evidence and release maturity are therefore different signals here.

The most immediate adoption check is dependency alignment. Confirm the GLIM version, GTSAM version, gtsam_points version, CUDA version, and target operating system before copying any existing build cache. The stated validation includes several recent CUDA releases, yet exact supported combinations should still be checked against the official documentation for the selected GLIM module.

Sensor integration is the second check. Confirm that the relevant ingestion path exists for the actual device, whether it is spinning, non-repetitive, solid-state LiDAR, or RGB-D. If ROS2 is required, inspect koide3/glim_ros2 rather than assuming the core repository includes the full runtime. If global constraints or automatic loop detection are required, inspect glim_ext and establish which algorithm supplies those constraints.

GLIM is best suited to teams prepared to own the integration around a factor-graph mapping core. It should not be selected as a turnkey application. The first decisive step is to follow the official documentation for a matching Ubuntu, CUDA, GTSAM, and gtsam_points configuration.

## Conclusion

GLIM fits research and engineering teams that need direct multi-scan registration, manual map correction, or custom constraints for 3D localization and mapping. It is a poor fit for users expecting a turnkey sensor package, a one-command build, or built-in loop detection. Verify the official GLIM documentation, the mandatory GTSAM and gtsam_points versions, your target sensor path, and the exact v1.2.2 dependency configuration before adoption.

## FAQ

### What sensors can GLIM use for 3D mapping?

GLIM is designed as a range-based mapping framework rather than a sensor-specific pipeline. The README lists spinning LiDAR, non-repetitive scan LiDAR, solid-state LiDAR, and RGB-D cameras as supported categories.

### Does GLIM provide automatic loop closure?

The core project minimizes multi-scan registration error on a factor graph, while the separate glim_ext repository provides an explicit loop-detection example. The README therefore does not support treating automatic loop closure as a standalone core feature.

### What are the mandatory dependencies for GLIM?

The mandatory dependencies are Eigen, nanoflann, GTSAM, and gtsam_points. CUDA, OpenCV, OpenMP, ROS or ROS2, and Iridescence are optional.

### How are GLIM and glim_ext related?

glim_ext is a related package containing example extension functions, including explicit loop detection and LiDAR-visual-inertial odometry estimation. GLIM provides the global callback slots through which such additional constraints can access internal mapping state.

### Can GLIM build with GTSAM 4.3a1?

The v1.2.2 update specifically says it fixes errors on GTSAM 4.3a1. Earlier update notes cover GTSAM 4.2a9 and 4.3a0, so compatibility should be matched to the selected GLIM version.

## Sources

- [Issues](https://github.com/koide3/glim/issues)
- [koide3/glim on GitHub](https://github.com/koide3/glim)
- [License: MIT](https://github.com/koide3/glim/blob/master/LICENSE)
- [Project website](https://koide3.github.io/glim/)
- [README](https://github.com/koide3/glim/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/koide3-glim