MeshLib vs libigl: 3D Boolean Operations Benchmark

For many engineers, libigl is the first library that comes to mind for geometry processing research: a broad collection of algorithms behind a simple header-only interface. But how does its exact boolean pipeline behave on production-scale data? We ran libigl and MeshLib through our 2026 boolean benchmark — large scans, a degenerate dental mesh, and three edge cases — and collected the numbers below.

What is MeshLib?

MeshLib is a commercial-grade open-source 3D geometry SDK with a C++ core and native bindings for Python, C#, C, and JavaScript. Unlike research toolkits, its boolean engine is engineered for production pipelines: it stays fast on multi-million-triangle scans and tolerates the imperfect meshes real scanners produce, automatically converting non-manifold input into a processable form.

What is libigl?

libigl is a widely used open-source geometry processing library that grew out of academic research at ETH Zurich and NYU. It offers a broad set of algorithms behind a header-only C++ interface, with Python bindings available. Its boolean operations rely on exact arithmetic, which makes them dependable on clean input. The library is distributed under a mix of MPL-2 and GPL-3 terms, which is worth reviewing carefully before commercial use.

MeshLib vs libigl comparison results

Testing setup — Apple M5 MacBook Air (10-core CPU, 32 GB unified memory), macOS 26. We report the minimum over 10 iterations per operation; mesh I/O is excluded from the timings. To access the input and result meshes used in our tests, visit this link.

Nefertiti Case

This scenario involves large meshes (2M Triangles each) with complex topology, representing a common challenge in 3D boolean operations.

Meshes were slightly shifted.

Meshes were slightly shifted.

Meshes were slightly shifted.

	MeshLib 3.1.3.249	libigl
Nefertity – Union​	0.09 (0.26)	21
Nefertity – Intersection	0.08 (0.23)	21
Nefertity – Difference	0.08 (0.23)	23

Comments

Both engines return correct results on the clean two-million-triangle scans, so the Nefertiti case is a pure throughput test. The gap is dramatic: libigl needs 21–23 seconds per operation, while MeshLib finishes each one in under a tenth of a second. Numbers in braces are MeshLib’s one-time geometric precomputations — even with those included, the difference stays around two orders of magnitude. In an interactive tool, one of these is a click and the other is a coffee break.

Dental Case

In this case, we simulate dental models (≈500K Triangles) with degeneracies and coinciding surfaces, reflecting real-world scenarios encountered in medical applications.

	MeshLib 3.1.3.249	libigl
Dental – Union​	0.04 (0.06)	4.3
Dental – Intersection	0.05 (0.08)	4.3
Dental – Difference A-B	0.05 (0.07)	4.4

Comments

Degenerate triangles and coinciding surfaces do not break libigl: its exact-arithmetic pipeline survives the dental scan and produces correct output in about 4.3–4.4 seconds per operation. MeshLib completes the same operations in 0.04–0.05 seconds. When a workflow processes hundreds of dental cases per day, that difference compounds quickly.

Simple Objects Case

In this case, we compare how algorithms behave when handling complex geometries.

Boolean Union of meshes, one with a hole aside from the intersection part.

Boolean Union of meshes, one with a hole into the intersection part.

Boolean Union of meshes, one with self-intersections into meshes’ intersection part.

	MeshLib	libigl
Holed, Not Intersected	Yes	No
Holed Intersected	No*	No
Self- Intersections	No**	Yes

Comments

On the qualitative cases the two libraries differ in profile. libigl declines both scenarios that involve meshes with holes — its boolean path expects closed, well-formed input — while MeshLib processes the hole that stays clear of the intersection zone. libigl does resolve self-intersecting input thanks to exact arithmetic, an operation MeshLib deliberately treats as ill-defined.

* MeshLib does not support the representation of non-manifold meshes and automatically converts them to a manifold form.** The results of such operations are not well-defined, leading to a mesh with numerous inconsistencies, such as self-intersections and degeneracies. In fact, it is not a secret that MeshBoolean operations may eventually fail outright. To explain why this might happen and what to do to avoid such outcomes, we invite you to read this overview of reasons for flawed Mesh Boolean operations.

Why choose MeshLib SDK for 3D boolean operations over libigl?

libigl remains a fine research companion — broad, well-documented, and free. Shipping a product changes the equation: MeshLib delivers the same boolean correctness at roughly 90–250× the speed, accepts the imperfect input real scanners produce, ships supported bindings for C++, Python, C#, C, and JavaScript, and comes with commercial licensing and professional maintenance instead of GPL-flavored legal review. If booleans sit on your product’s critical path, the benchmark numbers speak for themselves.