PositionBasedDynamics: one C++ library for rods, soft solids, fluids and rigid bodies

Why position changes are solved instead of forces

The README's opening paragraph is the clearest statement of the method's bargain. Position based simulation methods compute position changes directly in each simulation step, based on solving a quasi-static problem, rather than integrating forces. The stated consequence is that these methods are fast, stable and controllable, which makes them well suited to interactive environments.

The README is equally direct about the cost. These methods are generally not as accurate as force based methods, but still provide visual plausibility. That sentence determines how you should read every result the library produces. If you need physically certified stiffness values, this is the wrong tool. If you need an object that deforms believably at sixty frames per second and does not explode when a solver iteration count is too low, it is the right one.

The application areas the README names follow directly from that trade: virtual reality, computer games, and special effects in movies and commercials. All three are domains where visual plausibility at interactive or offline playback rates matters more than strict accuracy. The library is credited to a single author, Jan Bender, at interactive-graphics.de, and carries an MIT license, with the features list noting the library is free even for commercial applications.

Four material types, one constraint vocabulary

The features list is long, but it divides into four families that the library treats uniformly. Elastic rods get a bend-twist constraint, a stretch-shear constraint and the Cosserat constraint. Deformable solids get the widest spread: point-point distance, point-edge, point-triangle and edge-edge distance constraints, a dihedral bending constraint, an isometric bending constraint, a volume constraint, shape matching, and FEM based PBD in both 2D and 3D, plus strain-based dynamics.

Fluids get a single entry, position-based fluids. Rigid bodies get the long mechanical list: contact constraints, ball, ball-on-line, hinge, universal and slider joints, target angle and target velocity motor variants for hinges and sliders, a ball joint between a rigid body and a particle, a distance joint, a damper joint and an implicit spring. Several of those exist in both plain PBD and XPBD form, which is the extended position based variant that adds compliance as a physical parameter.

The unification is not cosmetic. The changes list records a parallelised unified solver using graph colouring, and separately a unified solver for rigid bodies and deformable solids, meaning a simulation can mix cloth and metal in one step and let the solver colour the constraint graph so independent constraints solve in parallel. Substepping was added later for the same reason, giving you a knob between solver iterations and integration steps that rigid body work usually needs.

Cubic signed distance fields for collision on arbitrary meshes

The collision story is the most distinctive technical feature and the one worth reading the linked papers for. The library uses Discregrid, another project by the same group, to generate cubic signed distance fields for collision detection. The changes list names two milestones: collision detection based on distance functions, and later collision detection for arbitrary meshes based on cubic signed distance fields.

This matters because arbitrary triangle meshes are notoriously bad collision geometry. A field gives you a signed distance and a gradient, so you can pose a contact without special casing convexity or face adjacency, and the field is precomputed and cached rather than solved per query. The README also records automatic computation of the inertia tensor for arbitrary triangle meshes, which removes another piece of manual scene setup that rigid body code usually demands.

Two of the news items point at the research lineage. One is a paper on a direct position-based solver for stiff rods, implemented by Crispin Deul from Deul, Kugelstadt, Weiler and Bender, published in Computer Graphics Forum 2018, with a corresponding demo in the repository. Another is the Position and Orientation Based Cosserat Rods paper by Kugelstadt and Schoemer from SCA 2016. A third references a separate paper on hierarchical high performance adaptive signed distance fields. When a README lists papers that use its own code, that is a reasonable signal about how seriously the constraint implementations are grounded.

A Python wheel is the shortest path in

For Windows and Linux targets, prebuilt Python wheel files exist. Installing them is one command:

pip install pypbd

The wheels cover multiple Python versions and are published on PyPI as pyPBD. The package is built from the same CMake project as the C++ library, which the `setup.py` at the repository root makes plain: it is a setuptools extension class that shells out to CMake, locates the CMake binary, enforces a minimum CMake version on Windows, and passes the library output directory into the build. So the wheel is not a separate reimplementation, it is the C++ solver wrapped by pybind11.

If your platform is not covered by a wheel, the README points at the build instructions and at a dedicated Python getting started guide in the documentation. Two other Python-side conveniences show up in the changes list: a SceneGenerator.py that generates new scenarios by simple Python scripting, and a scene loader based on json.

The practical recommendation is to script scenes in Python first. It removes the C++ compile from the loop while you work out which constraints the scene needs, which is the expensive part to get wrong.

CMake builds, tested on two specific configurations

The native build is CMake, and the README gives two tested configurations rather than a compatibility matrix: Windows 10 64-bit with CMake 3.9.5 and Visual Studio 2019, and Debian 9 64-bit with CMake 3.12.3 and GCC 6.3.0. One instruction comes with the build notes and is easy to miss: use a 64-bit target on a 64-bit operating system, because 32-bit builds on a 64-bit system are not supported.

Dependencies are vendored rather than fetched. The README lists CMake, Eigen, nlohmann json, pybind11, glfw, hapPLY and imgui, the last only for the demos, and states that all external dependencies are included. The changes list records that the Boost dependency was removed, so an older checkout of this project will look structurally different from a current one.

The repository tree shows the shape of the codebase. `Simulation/` holds the simulation machinery, `PositionBasedDynamics/` the constraints, `Demos/` the demo programs, `Common/` shared code, `Utils/` helpers, `pyPBD/` the Python binding, `CMake/` build modules, `extern/` the bundled third party code, `data/` scene data, `doc/` documentation including the scene file format, and `bin/` for binaries. `version.txt` and `Changelog.txt` at the root are where the current version lives. The GUI is now imgui based, which replaced the AntTweakBar interface in the 2.2.0 release.

Releases stop in 2022 while the source keeps moving

Here is the discrepancy worth planning around. The last tagged release is 2.2.0, published on 2022-12-13, and before that 2.1.0 on 2022-09-16 and 2.0.1 on 2021-12-22. The last push to the repository is 2026-09-01. So the source tree is nearly four years newer than the newest tag, and the recent work is not captured in any release artefact.

The 2.2.0 release notes themselves show what a release contains: removal of the AntTweakBar GUI in favour of imgui, PLY support and PLY export, documentation of the scene file format, updated pybind11, macOS compilation fixes, a glfw frame rate limit, and assorted cleanup. That is a coherent small release. The releases also show the XPBD work landing incrementally, with the XPBD FEM constraint in 2.1.0 and the XPBD distance, isometric bending and volume constraints in 2.0.1.

So if you need a pinned, tagged version, take 2.2.0 and accept the constraint set of December 2022. If you need the signed distance field collision work or the recent Python interface, build from master and keep track of the API yourself. Documentation is hosted on Read the Docs with a latest badge in the README, and questions go to the GitHub discussions page.

Editorial conclusion

PositionBasedDynamics earns its place by refusing to specialise. The unified solver is the real asset here, since rope, cloth, flesh, sand and rigid contacts are expressed in one constraint vocabulary rather than three incompatible frameworks, and a deformable body with a high resolution render mesh attached is a supported case rather than a hack. The signed distance field collision work from Discregrid is the other half of the value, because it is what lets arbitrary meshes participate without hand built proxy shapes. The practical friction is packaging: releases stop at 2.2.0 from December 2022 even though the source tree was pushed in September 2026, so there is a real gap between what the README lists and what a tagged version contains. Start with the `pyPBD` wheel to script a scenario from Python, read the scene file format documentation in the `doc/` directory, and only build the C++ side once you know which constraints you actually need.

Frequently asked questions

Official sources

1. InteractiveComputerGraphics/PositionBasedDynamics on GitHub
2. Issues
3. License: MIT
4. README
5. Releases