MeshLib: a geometry processing SDK for booleans, repair and point clouds

Geometry algorithms packaged as a multi language SDK

MeshLib is described as a 3D geometry processing SDK, and the feature list in the README is a catalogue of the operations that are hard to write and easy to get wrong.

The claim in the header is that the geometry algorithms are engineered to help software engineers process, repair, measure and optimize 3D data while reducing development time and costs. The operations named are mesh boolean, mesh repair, decimation, offset, point cloud triangulation, ICP registration and voxel processing, available in C++, C, C#, Python, JavaScript and Rust.

Six languages for one C++ core is the structural decision that defines the project. A geometry engine of this kind is a large body of numerically delicate code, and nobody wants to write it twice. Binding it six ways means a team can use it from whatever stack they already have: a Python pipeline, a C# desktop tool, a C application, a browser build through WebAssembly, or Rust, and the repository carries a wasm directory and an examples/threejs folder that show the browser path is real rather than aspirational.

The distribution channels follow the same logic. There are badges for PyPI, NuGet, npm and crates.io, and a build-test-distribute workflow in the repository's continuous integration, so the packages are built and tested rather than uploaded by hand.

The project is a company project rather than a hobby, with a website at meshlib.io, a live demo at demo.meshlib.io, a documentation site, a blog carrying a boolean library comparison, a Discord-style discussions area on GitHub, a CITATION.cff file for academic citation, and a Gitpod configuration for browser based development. The last push to the repository was on 2026-10-19, and the recent release tags are v3.1.4.297 from 2026-09-17, v3.1.3.429 from 2026-08-03 and v3.1.3.297 from 2026-07-06.

One package per language, and the Rust version is explicit

The install section is four lines, and the differences between them are worth reading.

pip install meshlib                  # Python
dotnet add package MeshLib           # C#
npm install @meshinspector/meshlib   # JavaScript / WebAssembly
cargo add meshlib@<version>          # Rust, the exact version from crates.io

Three of these are one liner installs from a public registry. The fourth is not, and the reason is worth noting. The Rust command has a placeholder for the version, with a comment that it must be the exact version from crates.io. That is a deliberate difference in how the Rust crate is versioned, and the repository has a dedicated Rust setup guide in the doxygen general pages for it.

C++ and C are the other special case, and the README sends you to the installation guide rather than trying to summarise it in a few lines. That is the right call for a C++ library, since a C++ consumer is usually integrating it into an existing CMake project rather than adding it to a fresh one, and the repository is built around CMake, with a CMakeLists.txt, CMakePresets.json, a meshlib-config.cmake.in template and a cmake directory. There is a plugin example directory as well, which suggests the engine can be extended with your own components rather than only used as shipped.

One thing to check before you commit to a language is the release discipline of that binding. The version numbers of the releases themselves are unusual, with the tag carrying what looks like a build number after the patch level, and the npm package even marks itself as including prereleases. That pattern usually means the binding versions and the core versions do not move in lockstep, so the package you install may not correspond exactly to the commit you read.

A scan becomes a solid mesh in four lines of Python

The quick start section is the fastest way to understand the API shape, and it starts with the problem most people have: a scan.

from meshlib import mrmeshpy as mm

pc   = mm.loadPoints("scan.ply")           # point cloud from any scanner
mesh = mm.triangulatePointCloud(pc)        # point cloud -> triangle mesh
mm.saveMesh(mesh, "model.stl")

Three calls. Load the point cloud, triangulate it, write the result. The meshlib Python module is imported as mrmeshpy, which reflects the underlying engine name, and every function in the examples is a module level function taking plain Python types, so the binding is a thin layer rather than an object oriented wrapper with its own conventions.

The boolean example follows the same shape and shows the error handling, which is where most geometry libraries differ.

from meshlib import mrmeshpy as mm

a = mm.makeUVSphere(1.0, 64, 64)
b = mm.copyMesh(a)
b.transform(mm.AffineXf3f.translation(mm.Vector3f(0.7, 0.0, 0.0)))

res = mm.boolean(a, b, mm.BooleanOperation.Union)
if not res.valid():
    raise RuntimeError(res.errorString)
mm.saveMesh(res.mesh, "out_boolean.stl")

Two things stand out. The result is a value with a validity check rather than an exception, so a failed boolean is a normal return path, and the error string is available when it happens. And the operation is a union of two spheres that genuinely intersect, which is the case that produces the non-manifold artefacts the README says the library avoids.

The README characterises the booleans as exact, with union, intersection and difference, plus a voxel based mode for messy input. The exact path is the one to reach for when the geometry is well formed, and the voxel mode is the fallback when it is not.

Voxel repair rebuilds the surface, and it changes your mesh

The repair example is the most instructive code in the README, and it comes with an honest caveat that many would leave out.

from meshlib import mrmeshpy as mm

mesh = mm.loadMesh("broken.stl")

params = mm.GeneralOffsetParameters()
params.voxelSize = mesh.computeBoundingBox().diagonal() / 200
params.signDetectionMode = mm.SignDetectionMode.HoleWindingRule
params.closeHolesInHoleWindingNumber = True

fixed = mm.generalOffsetMesh(mm.MeshPart(mesh), 0.0, params)   # watertight
mm.saveMesh(fixed, "fixed.stl")

The mechanism is described in the prose above it. Voxel based repair rebuilds the surface through a signed distance field, so holes, self-intersections and non-manifold edges disappear in a single pass. The voxel size is derived from the bounding box diagonal divided by 200, which is a resolution heuristic rather than an absolute figure, and the sign detection mode tells the algorithm how to decide which side of the surface is inside, with the hole winding rule used here.

And then the caveat: voxel repair resamples the surface, so the result is denser than the input, and you should add decimateMesh to bring the triangle count back down within a tolerance you set.

That is a genuinely important operational fact. A repair that quietly multiplies your triangle count is a repair that will break your slicer, your renderer budget and your file size, and the fix is a second call rather than a warning.

There is an alternative when you cannot afford to change the vertex set. The lighter, topological repair is available as fixMeshDegeneracies, fillHole and fixSelfIntersections, and is the right choice when you need to preserve the original vertices. The wider repair feature list covers self-intersections, degeneracies, tunnels, multiple edges and undercuts, and filling and stitching holes on both flat and curved surfaces.

The feature table reads like a manufacturing checklist

The what MeshLib does table is the best summary of the project, and it is organised by manufacturing task rather than by algorithm.

Beyond booleans and repair there is point cloud to mesh, with triangulation with accurate normal estimation, uniform and grid sampling, and outlier removal. There is simplification, covering decimation within a set tolerance, remeshing and subdivision that keep the details you care about. There is offset, with shell, partial and weighted offsets for 3D printing, machining and hollowing.

There is registration, with point-to-point and point-to-plane ICP plus global registration of multiple scans. There is a distance and signed distance field section, covering mesh to signed distance field and back by marching cubes, distance maps, iso-lines, projection and ray intersection. There is voxels and CT, with DICOM import and export, voxel grid processing and 3D volume rendering.

There is deformation, with Laplacian, freeform and relaxation smoothing and noise reduction. There is segmentation, semi-automatic mesh segmentation guided by a curvature metric, and graph-cut segmentation of voxel volumes. And there is collision detection, with exact and precise self and pairwise intersection tests.

The one entry that is not a geometry algorithm is the viewer, an embeddable OpenGL and ImGui viewer with UI components, with the alternative of running the algorithms fully headless. That combination is the strategically interesting part for a device product. A manufacturing application usually needs to show the result, and a separate viewer application is another dependency and another licence negotiation. An embeddable viewer means the same binary that computes the mesh can display it.

The file format support is broad as well, covering meshes, point clouds, CT scans, polylines, distance maps and G-code, with a full list linked from the README.

Benchmarks, examples and a licensing question

The README has a section headed why teams pick MeshLib, and its first line is measured, not claimed, followed by a boolean benchmark that compares MeshLib across nine libraries on a 2M triangle dataset, linked to a blog post on comparing 3D boolean libraries. The section is cut off in the version of the README available here, so the headline numbers are not in the text.

That is worth flagging rather than glossing over. A nine library comparison on a single large mesh is a useful signal, but it is one dataset on presumably one machine, and a decision to adopt should be based on running the comparison on your own geometry. The examples directory in the repository is the practical route to that, with complete runnable programs for repair, boolean, offset, ICP and triangulation in C++, C, C#, Python and JavaScript, and for boolean, decimation and loading and saving in Rust. There is also an AWS Lambda example, a Three.js example, a TypeScript example, a Java example directory, and a Unity test directory.

The licensing question is the one to resolve earliest, and it is not obvious from the badges. The repository is recorded as having a custom licence that GitHub cannot classify, with a pointer to the LICENSE file, while the project is heavily commercial in presentation: a company site, a paid-tier feel, a live demo and a comparison blog. The README itself does not spell out the terms.

So if you intend to ship a product containing this code, treat the LICENSE file as a gating document and read it before you build against the API, and if you intend to modify and redistribute the engine, get the answer in writing. This is not a legal opinion, and it is a specific instruction to check rather than a general caution.

The repository is otherwise a serious piece of engineering infrastructure: a CMake build with presets, clang-format configuration, a pre-commit configuration, a GitHub actions workflow named build-test-distribute, a regression test suite, a test data directory, separate test directories for Python, NuGet and Unity, a documentation directory, doxygen configuration and a locale directory.

Editorial conclusion

MeshLib suits a team that has 3D data in hand and needs reliable geometry out of it, whether that means a scanner output turned into a printable solid, a CAD boolean done correctly, or a mesh repaired well enough to slice, since the algorithms are the hard part and the SDK ships them with an embeddable viewer and runnable examples. It does not suit a team that needs to audit, modify or vendor the algorithm code under a permissive licence, because the repository licence is one GitHub cannot classify and the LICENSE file is the document to read. Before you commit, run the examples on your own meshes rather than on the sample data, because the voxel repair path resamples the surface and changes the triangle count, check the language binding you need is actually published, and note that the last push to the repository was on 2026-10-19 with the newest release tag v3.1.4.297 from 2026-09-17.

Frequently asked questions

Official sources

1. Issues
2. MeshInspector/MeshLib on GitHub
3. Project website
4. README
5. Releases