Rapier: physics for games, animation and robotics, in Rust

Four crates covering two dimensions and two precisions

Rapier arrives as four crates, rapier2d, rapier3d, rapier2d-f64 and rapier3d-f64, covering the two dimensions and two floating-point precisions that games, animation and robotics respectively demand. Robotics is a stated audience, not a marketing afterthought, and the workspace carries dedicated support crates for robot description formats to prove it. Development sits with the Dimforge organization, the license is Apache-2.0 with the README promising it is forever free and open source, and the workspace version is 0.36.0. There are no GitHub releases; publishing happens to crates.io, which the crate badges at the top of the README link directly. The f64 variants matter for simulation work where accumulated float error is the difference between a robot that walks and one that slowly falls over.

SIMD always on, parallelism behind a feature flag

The performance design has two tiers. SIMD-batched constraint solving and contact processing are always on: the solver processes 4 contact manifolds per instruction, falling back to scalar code on targets without SIMD support, so no configuration is needed for the baseline. The second tier is opt-in through the parallel feature, which multithreads the whole physics step, broad phase, narrow phase and solver, through rayon:

rapier3d = { version = "*", features = ["parallel"] }

One detail is documented with unusual care: on CPUs with heterogeneous cores, Apple silicon and Intel hybrid parts, the README recommends calling PhysicsPipeline::set_dedicated_thread_pool(None), so the step runs on a pool sized to the performance cores only, because the solver's barrier-paced stages otherwise run at the speed of the slowest efficiency core. That is the kind of note that separates documentation written from production experience from documentation written from benchmarks.

cargo run all_examples2 before reading further

The documented on-ramp is refreshingly concrete: read the user guides at rapier.rs/docs, then play with the examples:

cargo run --release --bin all_examples2

cargo run --release --bin all_examples3

Running examples before reading API documentation is good advice for a physics engine specifically, because the feel of a solver, how stacks settle, how joints behave, communicates more in a minute of watching than a page of type signatures. The user guide itself is versioned in the same repository under website/, so the docs travel with the code, and help is a Discord message or a GitHub issue away per the README's third step. For teams evaluating engines, the examples double as acceptance tests: if what you see in all_examples3 resembles your use case, the engine fits.

Bindings for C, Python, JavaScript and Bevy

The bindings directory is where Rapier stops being a Rust library and becomes a cross-language one. The C and C++ story covers the C ABI, C++ ownership helpers, native build instructions and Unity and Unreal integration guidance, spanning 2D, 3D, f32 and f64, including soft bodies. The Python bindings ship as a single package, rapier3d, wrapping the 3D engine with 32-bit floats, and the README is candid about the gaps: no 2D and no f64 Python bindings yet. JavaScript and TypeScript reach Rapier through NPM packages under the dimforge scope, and a Bevy plugin, bevy_rapier in 2D and 3D variants, integrates the engine with the popular Rust game framework. Each binding has its own examples, and the user guide publishes language-specific snippets.

A workspace that quarantines its bindings

The root Cargo workspace lists the core crates, testbeds, examples and robotics helpers as members, but its default-members list deliberately excludes the Python binding crates, with a comment explaining why: they need a Python build environment for the pyo3 extension-module and are exercised by a dedicated python-bindings workflow using explicit -p rapier-py-* invocations. C ABI crates get the same treatment, tested separately by a c-bindings workflow that includes native C and C++ consumers. The TypeScript and Bevy bindings are excluded outright, keeping their own separate Cargo workspaces so root-level cargo commands never absorb them. An ARCHITECTURE.md at the top level documents the design, and run-ci-checks.sh plus publish.sh encode the release process. For a contributor, the lesson is that a bare cargo test here is intentionally only part of the story.

URDF and MJCF crates betray the robotics audience

Among the workspace members sit rapier3d-urdf, mjcf-rs and rapier3d-mjcf, and their names map directly onto the robotics world: URDF is the robot description format of the ROS ecosystem and MJCF is MuJoCo's model format, so Rapier can load robot definitions rather than requiring hand-built rigid bodies. A rapier3d-meshloader crate handles asset loading, and the testbeds provide a visual harness for scenes built from these formats. Combined with the f64 precision variants, the picture is of an engine that takes simulation accuracy seriously enough for engineering use, not only for game feel. The examples directories include dedicated 3D f64 examples, so the high-precision path is exercised visibly, not just compiled.

Compiled documentation snippets and a written AI policy

Two practices stand out in the project's hygiene. First, the user-guide snippets shown on rapier.rs are the actual code under website/docs-examples, compiled, and for C and Python also run, to keep the guide from drifting from reality, documentation-as-code applied for real. Second, the README carries an explicit AI coding policy: AI is extensively used for the mjcf-rs, rapier3d-mjcf and Python binding crates including their tests and docs, and actively used with human review for documentation, changelogs, tests and CI configuration. AI-assisted contributions are accepted under three conditions, human verification, human-quality code, and non-regression tests where applicable. Community runs through Discord with a code of conduct and contribution guidelines, the blog at Dimforge carries announcements, and the last push landed on 2026-09-27.

Editorial conclusion

Choose Rapier when your simulation is written in Rust or delivered through its bindings, and per-step cost matters enough that SIMD and a rayon thread pool are worth configuring. Choose a long-standing C++ engine such as Box2D or Bullet when your codebase is C++ already and the ecosystem gravity matters more than Rust's safety or the WASM path. Verify first which numeric precision and dimension your target needs, since the four crates and the bindings do not all expose f64 or 2D, and read the dedicated thread-pool note if you run on Apple silicon or Intel hybrid CPUs.

Frequently asked questions

Official sources

1. dimforge/rapier on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README