# CloudCompare: an octree-based point cloud and mesh comparison tool

> CloudCompare compares two 3D point clouds, or a cloud against a triangular mesh, using an octree structure built for that job. Here is what it does, how to install it, and where it stops being the right tool.

**CloudCompare/CloudCompare** — CloudCompare main repository

- Repository: https://github.com/CloudCompare/CloudCompare
- Website: https://cloudcompare.org
- Stars: 4,778 · Forks: 1,219
- Language: C++
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/cloudcompare-cloudcompare

## The comparison problem CloudCompare was built around

CloudCompare started as a tool for one specific task: comparing two 3D point clouds, such as two laser scanner captures, or a point cloud against a triangular mesh. That framing matters, because it separates the project from viewers and from general purpose CAD. A viewer shows you a scan. CloudCompare is meant to tell you how one surface differs from another.

The audience follows from that. Surveying, inspection and heritage work produce repeated scans of the same object or site, and the question is usually what changed or how far the as-built deviates from the model. The README describes the software as dealing with huge point clouds, typically more than 10 million points and up to 120 million with 2 GB of memory. That number is a stated design target, not a measured result, but it tells you the intended scale is far past what a desktop viewer handles comfortably.

The same code base also processes triangular meshes, which is why the comparison can run in either direction: cloud to cloud, or cloud to mesh.

## How the octree drives comparison and distance computation

The README states that CloudCompare relies on an octree structure that is highly optimized for this particular use case. An octree recursively subdivides space into eight child cells, so a point cloud gets indexed into a hierarchy of boxes rather than kept as a flat list. For comparison work that hierarchy is what makes nearest neighbour queries tractable: instead of testing every point against every other point, a query descends only into the cells that can contain a closer candidate.

The repository layout reflects how the code is split. qCC/ holds the graphical application, ccViewer/ is a lighter viewer, libs/ contains the shared libraries, and plugins/ holds optional functionality. The README notes that optional dependencies exist mainly to support particular file formats or specific plugins, which means format coverage in a given build depends on what was compiled in rather than on the core.

That is the important architectural consequence. The octree and the comparison machinery are core; the ability to read your particular scanner format may not be. If a format is missing, the fix is a dependency and a rebuild, not a setting.

## Installing CloudCompare on Linux with Flathub

The README gives one direct install path, for Linux, through Flathub. The command is a single flatpak invocation:

```bash
flatpak install flathub org.cloudcompare.CloudCompare
```

After it completes, the application is registered under the identifier org.cloudcompare.CloudCompare and can be launched from your desktop environment's application list or with flatpak run followed by that identifier. This is the only package manager command the README documents, so treat it as the supported Linux route rather than one option among several.

The README does not give equivalent one-line install commands for Windows or macOS. For those platforms the documented path is compilation from source, and the README points to BUILD.md for current instructions.

## Building from source with CMake

Compilation is supported on Windows, Linux and macOS. The README summarises the sequence: clone the repository, install mandatory dependencies such as OpenGL plus any optional ones you need, then launch CMake from the trunk root. The repository ships a top-level CMakeLists.txt and a cmake/ directory, which is where the build logic lives.

The README is explicit that BUILD.md carries the up-to-date information, and that is the file to read before attempting a build. It also ships pixi.toml and pixi.lock at the top level, which indicates a pinned environment definition is available for reproducing a build toolchain. The README itself does not document how to use those files, so do not assume the pixi route is the endorsed one; check BUILD.md first.

One practical warning from the README's own wording: optional dependencies are needed mainly to support particular file formats or some plugins. A build that skips them will start and run, but will silently lack format support you may have expected.

## Where CloudCompare is the wrong tool

The licence is the first hard boundary. The README states the project is under the GPL, links to version 3 of that licence, and spells out the consequence: all code you mix or link with CloudCompare's code must be made public as well, and the code cannot be used in closed source software. If your product embeds point cloud processing behind a proprietary interface, this repository is not a component you can drop in.

The second boundary is the release cadence. The most recent tagged release is v2.13.2, dated 2024-07-11, preceded by v2.13.1 on 2024-03-20 and v2.13 on 2024-02-14. The default branch is master and the last push to the repository was on 2026-09-22, so development activity continues between tags, but anyone who pins to tagged releases is working with code from 2024. Building from master is the alternative, and that means accepting an untagged state.

The third is scope. CloudCompare is a comparison and processing application, not a registration or photogrammetry pipeline. If your problem is producing a point cloud from photographs, or aligning scans without a reference, the README describes nothing that addresses it.

## How CloudCompare differs from MeshLab and PDAL

MeshLab is the closest comparison in day-to-day use: it is also an open source mesh and point cloud tool with a graphical interface. The difference is in what the two are organised around. CloudCompare's README frames the software around comparison between two clouds or a cloud and a mesh, with the octree as the structure that makes that comparison fast. MeshLab's emphasis is on mesh processing and editing operations. If your task is measuring deviation between two scans, CloudCompare's framing is the more direct match; if your task is cleaning and retopologising a mesh, it is not.

PDAL sits at a different layer entirely. It is a command line pipeline library for point cloud data, so it composes into scripts and services rather than into a desktop session. CloudCompare gives you an interactive application with a viewer and plugins; PDAL gives you something you can call from a build step. The two are not substitutes, and a workflow that needs reproducible batch processing will find CloudCompare's graphical model awkward where PDAL fits naturally.

## Maintenance, upgrades and what the GPL means in practice

The repository is not archived and the last push was on 2026-09-22, so the code base is being touched. That is separate from the release question: v2.13.2 from 2024-07-11 remains the newest tag. A team that tracks tags should plan to either backport fixes or move to master builds, and the README does not document a rollback procedure for either case.

Upgrade cost concentrates in the build. The README directs readers to BUILD.md for current dependency information, and optional dependencies drive format and plugin support. A version bump can therefore change which formats your build can read even when the core comparison behaviour is unchanged. The repository includes a CHANGELOG.md at the top level, which is where release level changes are recorded.

On licensing, the README is unusually direct: use as is for any purpose is fine, but distributing the software or reusing its code in something you distribute brings you under the GPL, and linked code must be published. Whether a specific integration triggers that depends on facts about your product that this article cannot assess.

## Conclusion

Adopt CloudCompare if your work is comparing scans against each other or against a reference mesh and you can accept GPL-3.0 obligations for anything you distribute. Do not adopt it if you need to link its code into closed source software, or if you expected a maintained release cadence: the last tagged release is v2.13.2 from 2024-07-11. Before committing, clone the repository, read BUILD.md for the dependency list, and confirm that the optional dependencies for your file formats are actually available on your platform.

## FAQ

### What is CloudCompare used for?

It is a 3D point cloud and triangular mesh processing application, originally designed to compare two point clouds, such as laser scanner captures, or a point cloud against a mesh. The README states it is meant to handle more than 10 million points, and up to 120 million with 2 GB of memory.

### Is CloudCompare free?

Yes. The README states the project is under the GPL, linked to version 3, and that you can use it as is for any purpose. Distributing it or reusing its code in something you distribute brings GPL obligations, including publishing code you link with it.

### How do I install CloudCompare on Ubuntu?

The README documents a Flathub install for Linux: flatpak install flathub org.cloudcompare.CloudCompare. It does not give a separate Ubuntu-specific package command, so on Linux the Flathub route is the one the project describes.

### What files can CloudCompare open?

The README does not list supported formats. It says optional dependencies exist mainly to support particular file formats or some plugins, which means format support depends on which dependencies were compiled into your build.

### Is CloudCompare legit?

The README identifies the project as CloudCompare, hosted at cloudcompare.org, under the GPL version 3, with releases published on GitHub and a build workflow running on the master branch. Those are the provenance facts the repository states.

### What is the octree in CloudCompare for?

The README states the software relies on an octree structure that is highly optimized for the comparison use case, and that this is what lets it deal with very large point clouds. It is the spatial index behind the comparison queries rather than a user-facing feature.

## Sources

- [CloudCompare/CloudCompare on GitHub](https://github.com/CloudCompare/CloudCompare)
- [Issues](https://github.com/CloudCompare/CloudCompare/issues)
- [Project website](https://cloudcompare.org)
- [README](https://github.com/CloudCompare/CloudCompare/blob/master/README.md)
- [Releases](https://github.com/CloudCompare/CloudCompare/releases)

---

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