# PMP Library for C++ polygon mesh processing

> PMP is a C++ library for representing, processing, and viewing polygon surface meshes. It suits geometry-processing applications that need mesh I/O, algorithms such as decimation and remeshing, parameterization, and built-in viewers.

**pmp-library/pmp-library** — The Polygon Mesh Processing Library

- Repository: https://github.com/pmp-library/pmp-library
- Website: https://www.pmp-library.org
- Stars: 1,510 · Forks: 215
- Language: C++
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/pmp-library-pmp-library

## PMP's mesh-processing boundary

PMP addresses the problem of storing and transforming polygon surface meshes in C++ applications. The README describes it as a library for processing and visualizing polygon surface meshes, rather than as a general graphics engine or a mesh format converter. Its listed capabilities cover core geometry-processing tasks that commonly arise after a mesh has been loaded: decimation, remeshing, subdivision, smoothing, curvature, geodesic distances, hole filling, and parameterization.

The intended users are C++ developers working on geometry processing, research tools, visualization, and applications that need a reusable mesh data structure. The project also provides ready-to-use viewers, including `mpview`, and the repository contains focused examples for many of the advertised operations. That combination makes PMP useful both as a foundation for a custom application and as a way to inspect mesh-processing results.

The repository layout supports this interpretation. Source code is under `src/`, sample programs are under `examples/`, data files are under `data/`, tests are under `tests/`, and documentation is under `docs/`. Available example names include `curvature.cpp`, `decimation.cpp`, `fairing.cpp`, `hole_filling.cpp`, `parameterization.cpp`, `remeshing.cpp`, `smoothing.cpp`, and `subdivision.cpp`. Based on those files, PMP is organized around common mesh operations rather than one specialized pipeline.

PMP does not document a command for every algorithmic setting or guarantee a particular result for every input mesh. That matters when choosing it for production processing. The README identifies the available operations, but it does not provide a general performance matrix, supported-format table, or universal quality criterion for their outputs. Those omissions require checking the relevant examples and documentation before an application depends on a specific behavior.

## SurfaceMesh as the C++ entry point

The README's library example uses `pmp::SurfaceMesh` as the central mesh object and the I/O functions in `<pmp/io/io.h>` to read and write geometry:

```cpp
#include <pmp/surface_mesh.h>
#include <pmp/io/io.h>

int main()
{
    pmp::SurfaceMesh mesh;
    pmp::read(mesh,"input.obj");
    // .. do awesome things with your mesh
    pmp::write(mesh,"output.obj");
}
```

This establishes a simple data flow. A program creates a `SurfaceMesh`, asks PMP to read a file into it, performs application-specific mesh work, and writes the result to another file. The example uses `input.obj` and `output.obj`, so the public I/O path is demonstrated with OBJ. The repository also has `examples/io.cpp`, but the README does not specify the complete set of formats accepted or emitted by that example.

The surface-mesh header is named `<pmp/surface_mesh.h>`, while I/O is separated into `<pmp/io/io.h>`. That separation gives an application a direct place to begin when it needs a mesh container and file access. The exact constructors, iterators, property interfaces, and algorithm APIs are not reproduced in the README, so their details should be checked in the headers and corresponding examples before code is written.

The available examples also indicate that PMP exposes more than file loading. `iterators.cpp`, `properties.cpp`, and `basics.cpp` cover basic library concepts, while the algorithm examples place individual operations in separate programs. This is a useful design for learning because a developer can inspect one operation at a time instead of starting with an undocumented all-in-one processing framework. It also leaves integration choices with the application developer, which is convenient for a C++ codebase but requires more than the README example alone.

## Building mpview from a fresh checkout

The README gives a direct CMake build path. It assumes the repository has been cloned and that the usual `cmake` and `make` commands are available in the development environment. The documented sequence is:

```sh
git clone https://github.com/pmp-library/pmp-library.git
```

This command retrieves the repository from its GitHub origin. It does not select a particular release. The README then instructs the developer to configure and build the project in a `build` directory:

```sh
cd pmp-library && mkdir build && cd build && cmake .. && make
```

After a successful build, the documented viewer invocation loads the bundled bunny mesh from the `data/off` directory:

```sh
./mpview ../data/off/bunny.off
```

The expected first result is the `mpview` application opening with `../data/off/bunny.off` as its input. If the executable is not found at that path, the build configuration or current build directory should be checked against the repository's CMake files. The README does not document a package-manager installation, a prebuilt binary download, or platform-specific prerequisites.

For a first real use, a developer can follow this sequence and then inspect `examples/` for the operation that matches the task. The build uses the top-level `CMakeLists.txt`, while `examples/CMakeLists.txt` participates in the example build configuration. The README does not state which optional dependencies are enabled by default, so the first configure step is where those settings should be inspected. A project using a generator other than the one selected by CMake may also need to adjust the documented build sequence.

## Algorithm examples and viewer feedback

PMP's examples provide a practical map of its processing surface. `curvature.cpp` is relevant when geometric quantities associated with a mesh are needed, although the README does not define the curvature estimator or its parameters. `decimation.cpp` addresses reduction of mesh complexity, `remeshing.cpp` covers redistribution or regeneration of mesh samples, and `subdivision.cpp` covers a surface refinement operation. These are separate sources rather than one documented command with all options exposed in the README.

Other examples map to more specialized workflows. `hole_filling.cpp` targets missing regions, `parameterization.cpp` targets surface parameterization, `smoothing.cpp` targets smoothing, and `fairing.cpp` targets fairing operations. The repository topics additionally list geodesic distances, triangulation, and mesh simplification. Topic metadata indicates project scope, but it does not specify an API contract or guarantee that every listed feature has the same interface or level of documentation.

`mpview.cpp` and `mesh_processing_viewer.cpp` provide the visual side of the project. The README calls the supplied viewers ready to use and states that PMP can be cross-compiled to JavaScript through a demo. That makes visual inspection relevant to an evaluation workflow, especially for algorithms whose output is difficult to judge from source code alone. The README does not document viewer controls, whether one executable exposes every processing example, or how the JavaScript build is configured, so those points require inspection of the repository files.

The practical distinction is that PMP presents algorithms as library functionality while examples expose each operation as a starting point. The repository is therefore more useful for integrating a chosen operation into an existing C++ program than for assuming a single documented command-line pipeline. This arrangement favors code reuse, although it gives less information about runtime settings than a product with a unified GUI or fully documented application interface.

## Cross-compilation, dependencies, and upgrade boundaries

The README states that PMP supports cross-compilation to JavaScript and links to a demo. That is a documented distribution capability, but it does not provide the JavaScript build commands, toolchain requirements, browser support, or packaging format. A team evaluating deployment to the web must therefore verify those details in the repository before treating the web target as production-ready.

The project is not archived, and its last push was on 2026-08-28. The available release history lists `3.0.0` from 2023-08-24, `2.0.1` from 2022-08-26, and `2.0.0` from 2022-08-14. These dates show the published release sequence, but they do not establish compatibility or upgrade guidance by themselves. For upgrade planning, the most relevant project-specific files are `CHANGELOG.md`, the release tags, and the differences between the headers and examples used by an application. The README does not document a migration procedure or a compatibility matrix.

PMP is provided under the MIT license. The README says this allows open-source and commercial usage, but `LICENSE.txt` should still be reviewed for its exact terms. The repository contains an `external/` directory, so an adoption decision may also need to account for dependencies included or referenced there. The README does not identify those dependencies or state whether they carry separate licenses, making dependency review a specific part of the license check rather than a generic concern.

The main operational constraint is uncertainty around the build environment, optional dependencies, web target configuration, and behavior on particular input files. PMP is not described as archived, and the recent last-push date indicates repository activity after the latest listed release. That distinction matters when weighing the older release cadence against current repository changes, but it does not tell an adopter whether a specific unreleased change is stable.

## PMP compared with a format-specific implementation

A real alternative is to write processing logic directly against a format-specific mesh representation or build a small application around another geometry-processing library with a narrower API. The difference is architectural. PMP provides a shared `SurfaceMesh` abstraction plus a collection of general mesh-processing examples, while a direct format-specific path can avoid adopting a general library when the application reads one fixed format and performs one fixed operation. That alternative may reduce integration work, but it does not provide PMP's listed collection of algorithms or viewers without additional implementation.

PMP can also be compared with a library built around a different mesh representation or application workflow. The README does not describe interoperability, API compatibility, output guarantees, or performance against another library. An engineer should therefore compare actual input formats, required algorithms, output representation, build system, and licensing terms. PMP's documented advantage is the breadth of processing operations and the straightforward C++ entry point, not a measured performance advantage or a claim that it supersedes format-specific code.

PMP is the wrong choice when the requirement is exclusively JavaScript without a cross-compiled C++ target, or when the application must rely on an operation whose settings and failure behavior are not documented. It may also be unnecessary for a small tool whose only job is loading and writing one mesh file. In that case, the two-function README example provides the relevant model, while adopting the complete library adds a build dependency without a clearly documented benefit.

## Conclusion

PMP fits C++ developers who need polygon mesh processing and can build a native desktop or cross-compiled application around its documented API. It is less suitable for projects that require a language other than C++, an unmentioned platform, or guarantees for algorithms and formats that the README does not document. Verify the supported compiler and dependency requirements in CMakeLists.txt, test the needed mesh formats with your own files, and review the relevant example before adopting version 3.0.0.

## FAQ

### What is PMP Library used for?

PMP Library is used for representing, processing, and visualizing polygon surface meshes in C++. Its documented feature set includes decimation, remeshing, subdivision, smoothing, parameterization, and related geometry-processing operations.

### How do I build and run PMP Library?

Clone the repository, create a `build` directory, configure it with `cmake ..`, and build with `make`. The README then runs `./mpview ../data/off/bunny.off` to open the bundled mesh in the viewer.

### Can I read and write OBJ files with PMP Library?

The README example includes `<pmp/io/io.h>` and calls `pmp::read(mesh,"input.obj")` followed by `pmp::write(mesh,"output.obj")`. The README does not document every format supported by those functions.

### Does PMP Library support JavaScript?

The README states that PMP supports cross-compilation to JavaScript and links to a demo. It does not provide the JavaScript build commands, toolchain requirements, browser support, or packaging instructions.

### What license does PMP Library use?

PMP is provided under the MIT license. The README says it allows open-source and commercial usage, while `LICENSE.txt` and any dependencies should be checked for their exact terms.

## Sources

- [License: MIT](https://github.com/pmp-library/pmp-library/blob/main/LICENSE)
- [pmp-library/pmp-library on GitHub](https://github.com/pmp-library/pmp-library)
- [Project website](https://www.pmp-library.org)
- [README](https://github.com/pmp-library/pmp-library/blob/main/README.md)
- [Releases](https://github.com/pmp-library/pmp-library/releases)

---

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