Geogram: a C++ geometry processing library with exact predicates and parallel Delaunay

What Geogram solves, and who it is written for

Geogram is a C++ programming library, not an application. The README describes it as "a programming library with geometric algorithms" and splits its surface into two layers. The upper layer is geometry processing: surface reconstruction, remeshing, parameterization and texturing, intersections and boolean operations, and constructive solid geometry. The lower layer is the machinery those features stand on: exact numbers and exact predicates, Delaunay triangulations in 2D and parallel Delaunay triangulations in 3D, a multithread-friendly 2D constrained Delaunay triangulation that supports intersecting constraints in arbitrary precision, mesh data structures for surfacic, volumetric and hybrid meshes, geometric search structures for intersection and raytracing, spectral mesh processing, and a linear solver that runs on CPU and GPU.

The intended reader is someone building a tool that needs these kernels: a reconstruction pipeline, a mesh repair step, a boolean operation between solids, or a solver on a mesh. The README points to GraphiteThree as an experimental 3D modeler built around Geogram, which is a useful signal about the boundary: if you want to click on a mesh, that project is the layer above this one. Geogram itself is the library you link against. The README also states that the project received the Symposium on Geometry Processing Software Award in 2023, and traces its history to work that started in Y2K and continued through the former ALICE Inria project, with results from more than 30 research articles.

That history explains the shape of the API. This is not a library designed around a small set of convenience calls. It is a collection of algorithms that were each written to support a paper, then maintained together so the results stay reproducible. Expect to read per-module documentation rather than one tutorial that covers everything.

Exact predicates, Delaunay and the mesh data structure underneath

The mechanism that ties the library together is arithmetic. The README lists "Exact numbers / exact predicates" as a lower-level algorithm, and the 2D constrained Delaunay triangulation is described as supporting intersecting constraints in arbitrary precision. In practice this means the triangulation and boolean layers do not have to guess whether a point lies exactly on a segment: the predicate answers that question exactly, and the combinatorial structure stays consistent. Anyone who has debugged a mesh kernel that flips a triangle because of a floating-point tie will recognize why this is listed as a foundation rather than a feature.

On top of that foundation sit the triangulations. Delaunay in 2D, a parallel Delaunay in 3D that the README calls highly efficient, and a 2D constrained variant that the README notes is multithread-friendly and accepts intersecting constraints. The mesh data structure is described as memory efficient and able to hold surfacic, volumetric and hybrid meshes, which matters because a reconstruction or remeshing pass usually produces one kind of mesh and consumes another. Search structures for intersection and raytracing (AABBs, KdTrees and similar) are listed alongside, so spatial queries do not require a separate library.

Above these sit the geometry-processing operations: reconstruction, remeshing, parameterization and texturing, boolean operations and CSG. Each has its own wiki page linked from the README. The layering is the point. If you only need exact orientation tests, you can take that piece; if you need a full remeshing pipeline, the same predicates are already underneath it. The cost is that the library is large, and the README does not present a minimal subset to start from.

Building Geogram with CMake and running a first program

The README does not inline build instructions. It points to the wiki page titled "Documentation, how to compile, tutorials...." for compilation, and the repository layout confirms the build system: a top-level CMakeLists.txt, a cmake/ directory, and configure.sh and configure.bat at the root. The presence of both scripts suggests the intended path is to configure first, then build with CMake. The exact flags are documented on the wiki, not in the README, so check that page before running anything.

A conventional sequence against a checkout looks like this. The configure script prepares the build directory, then CMake builds it:

./configure.sh
cmake --build build -j

What you should see is a configured build tree and compiled library targets. The README does not document the resulting directory names or the exact target names, so read the output of the configure step rather than assuming a path.

For a first real use, pick a lower-level algorithm rather than a full pipeline, because the predicates and triangulations have the smallest surface area. The README links each module to its own wiki page, and those pages carry the tutorials. The programmer's reference manuals, generated with Doxygen, are published separately at brunolevy.github.io/geogram. The README's own example of a downstream project is GraphiteThree, which is the reference for how the library is consumed in a larger application.

If you would rather not write C++ at all, the README lists language bindings maintained outside this repository: Rosetta geogram for Python, Node.js, WebAssembly, TypeScript and Lua; pyGeogram for Python and Lua; Geogram.jl for Julia; and a Rust crate for the predicates. Those are separate projects. Installing Geogram itself does not give you the Python module.

Where Geogram is the wrong choice

The clearest limitation is packaging. The README does not present Geogram as a package you pull from a language package manager. There is no pip install in the README, no npm package for the core library, and no single-header distribution. The bindings that do exist are hosted in other repositories, which means a Python user is depending on a project that tracks Geogram rather than on Geogram itself, and version skew between the two is a real risk that the README does not address.

Licensing is the second thing to check before you build anything on top of it. The README shows a BSD 3-Clause badge linking to opensource.org, but the repository's licence field is reported as NOASSERTION, meaning the file was not recognized as a standard identifier. The repository does contain a LICENSE file at the top level. Read it. A badge is not the same as the licence text, and the two need to agree before this goes into a product.

The third limitation is scope. Geogram is a library with no graphical interface; the README places the modeler in a separate project, GraphiteThree, described as experimental. If your team's need is to inspect and edit meshes interactively, this repository is not that tool. And if your problem is a single well-known operation, such as computing a convex hull or a 2D triangulation of a few thousand points, the build and integration cost of a full geometry-processing library is hard to justify against a smaller dependency. The FAQ page, linked from the README under the comparison heading, is where the project itself discusses how it differs from other geometry-processing libraries; the README does not summarize that comparison, so read it there rather than expecting an answer here.

How it differs from a mesh-oriented library such as CGAL

The obvious alternative for exact geometric computation in C++ is CGAL, and the difference in approach is worth stating plainly. CGAL is built around a traits-and-concepts design: algorithms are templates parameterized by a kernel, and you choose or write a kernel that supplies the number type and the geometric primitives. That design gives you a great deal of control over the arithmetic and lets one algorithm run over several kernels, at the cost of template-heavy code and long compile times.

Geogram takes the opposite route. Exact predicates are a component of the library rather than a parameter you thread through every algorithm, and the README presents the triangulations, the mesh data structure and the search structures as concrete types. You get a smaller number of decisions to make and, in return, less freedom to swap the underlying arithmetic. The README also emphasizes parallel and multithread-friendly variants (the 3D Delaunay and the constrained 2D triangulation), which is a different emphasis from a design that prioritizes kernel genericity.

The practical consequence is about where the friction lands. With a traits-based library, the friction is usually at compile time and in the type signatures you must satisfy. With Geogram, the friction is at the build and documentation level: you configure a large CMake project and then read per-module wiki pages. Neither is better in the abstract. If your team already has a kernel abstraction it wants to keep, a traits-based library fits that shape; if you want the algorithms to be concrete and the parallelism built in, Geogram's shape is closer. The README points to its FAQ for this comparison rather than making the argument itself, which is a fair place to look, though it means the answer is one link away from the front page.

Maintenance, releases and the cost of upgrading

The repository is not archived, and the last push was on 2026-09-24. Releases are frequent relative to the project's age: v1.9.9 on 2026-04-08, v1.10.0 on 2026-05-27, and v1.10.1 on 2026-09-01. The README carries badges for a release workflow, continuous and nightly workflows, an Emscripten workflow and a Doxygen workflow, and links to published CI reports for the continuous and nightly runs. Taken together, those are the maintenance signals the repository actually offers.

The upgrade cost is not documented in the README. There is no migration guide, no statement about API stability between minor versions, and no note on whether v1.10.x preserves source compatibility with v1.9.x. The version numbering moves from v1.9.9 to v1.10.0, which suggests the project treats the middle number as meaningful, but the README does not say what a major or minor bump guarantees. If you depend on a specific algorithm, pin a release tag and read the release notes for that tag before moving.

The nightly and continuous reports are the closest thing to a compatibility signal: they exercise the build across configurations, so a change that breaks compilation shows up there rather than in a changelog. That is useful for a team that builds from source, less so for one that wants a supported binary distribution. The README does not mention prebuilt binaries for any platform. On licensing, the badge says BSD 3-Clause while the repository metadata says NOASSERTION; the LICENSE file is the document that governs, and this is a question for your own legal review, not something a README badge settles.

Editorial conclusion

Adopt Geogram if you are writing C++ that needs Delaunay triangulations, exact predicates, mesh data structures or remeshing, and you are willing to build it with the repository's CMake configuration and read the wiki for each module. Do not adopt it if you want a Python-first geometry stack, a GUI modeler, or a small single-header dependency: the language bindings live in separate projects such as pyGeogram and geogram-rosetta, and the GUI work lives in GraphiteThree. Before committing, verify the licence text in the LICENSE file, since the repository does not carry a standard SPDX identifier, and check the wiki page for the specific module you need, because the README only links to them.

Frequently asked questions

Official sources

1. BrunoLevy/geogram on GitHub
2. Issues
3. README
4. Releases