Parry: four crates for 2D and 3D collision detection in Rust

Four crates, two dimensions, two precisions

Parry is described in the README as a set of 2D and 3D geometric and collision detection libraries, and the naming makes the structure obvious. There are four published crates, parry2d, parry3d, parry2d-f64 and parry3d-f64, so the dimension and the floating point precision are separate choices rather than a feature you toggle. The Cargo manifest lists exactly those four as the workspace members. The library is written in Rust by the Dimforge organisation, which also publishes the crates on crates.io, hosts the API documentation for each of them on docs.rs, and maintains a user guide at parry.rs whose documentation link is also recorded in the manifest. The keywords the manifest declares are collision, geometry, distance, ray and convex, and the categories include game development, mathematics and wasm, which is a good summary of the intended uses. The licence is Apache-2.0, and the workspace version is 0.31.1 on edition 2021.

The manifest is where the real documentation is

The README of this project is short, so the manifest has to do the work, and it is unusually complete. The shared package metadata is compact and tells you most of what you need before you read a single line of code:

[workspace.package]
version = "0.31.1"
authors = ["Sébastien Crozet <[email protected]>"]
documentation = "https://parry.rs/docs"
homepage = "https://parry.rs"
repository = "https://github.com/dimforge/parry"
license = "Apache-2.0"
edition = "2021"

Two entries there are worth pausing on. The documentation field points at parry.rs/docs rather than at docs.rs, so the narrative documentation and the generated API reference live in different places, and the README notes that the user guide is work in progress. The repository also carries an ARCHITECTURE.md and a CHANGELOG.md at the top level, alongside a CONTRIBUTING.md, a CODE_OF_CONDUCT.md and a licence file, so the detail exists in the repository even where the front page does not link to it. The top level also holds the shell scripts used to publish the crates and to generate the visual and written samples, plus a src directory and a crates directory, which is the usual split between the shared internal code and the four published crates.

Feature flags that are checked at compile time

The manifest configures rustc to warn on unexpected configuration values, and it lists exactly which feature names and target architectures the code is allowed to test. That list is the most precise documentation of what the crates can be built as, and it is worth reading before you add a dependency:

[workspace.lints]
rust.unexpected_cfgs = { level = "warn", check-cfg = [
    'cfg(feature, values("dim2", "dim3", "f32", "f64"))',

The dimensions and the precisions are therefore real features, dim2, dim3, f32 and f64, and the same block carries two more entries with explanatory comments. The wavefront feature is used only by the 3D crates, which makes sense for importing geometry from that file format, and the encase feature is used only in the f32 crates. The block also allows a spirv target architecture, which is a signal that the crates are expected to build for a shader compilation path as well as for a normal CPU target. The practical effect of declaring these is that a typo in a feature name produces a warning at build time rather than a silently disabled code path, which is a small thing that saves a long afternoon when a feature silently does nothing.

Lints that push the code away from the standard library

The clippy configuration in the workspace is short and says something specific about the design:

[workspace.lints.clippy]
alloc_instead_of_core = "warn"
std_instead_of_alloc = "warn"
std_instead_of_core = "warn"

Those three lints are the ones that complain when code reaches for the standard library where the core or the alloc crate would do, which is the standard way of keeping a crate compilable without the standard library. The dependency list points the same way, since most of the workspace dependencies are declared with default-features = false, and the vector and matrix library is pulled in with the nostd-libm feature, which replaces the platform maths functions with a bundled implementation. The README does not make a no_std claim in as many words, so if you are targeting a platform without an operating system, that promise is implied by the configuration rather than stated in the documentation, and it is worth confirming for your own target before you commit to it. The category list including wasm is a further hint about the range of environments the code is meant to survive in.

Dependencies point at serialisation and generic maths

The dependency list is a good map of what the library actually does. For numerics there is num-traits and num-derive, with no default features, plus either for the sum type used across APIs, and approx for approximate comparisons, which is what you need when comparing floating point results in a geometry library. The container choices are deliberate, with slab, arrayvec, simba and bitflags covering the small stack allocated structures that a collision routine wants to avoid allocating for. glamx provides the vector and matrix maths with a nostd-libm feature. For serialisation there are two separate paths, serde with the derive feature and serde_arrays for fixed size arrays, and rkyv with the bytecheck and alloc features, which is the archiving library in the list and points at a zero copy style of encoding. indexmap and hashbrown handle the map types, and downcast-rs with the sync feature covers the type erasure the API needs when shapes and queries are heterogeneous. The AWS and networking libraries are absent, which confirms the scope is geometry rather than anything to do with the network.

Where a physics engine would be the wrong expectation

The most common misunderstanding about a library like Parry is that it simulates anything. It does not. The keywords say collision, geometry, distance, ray and convex, and the project describes itself as geometric and collision detection libraries, so what you get is shape representations, overlap and contact queries, distance computations, ray casts and convex decomposition style primitives. If you need rigid bodies that fall, stack and settle, you need a dynamics layer on top, and the usual choice is a physics engine that ships its own collision detection. The difference in approach is the point. An engine couples its broad phase, its narrow phase and its solver, and you take the whole package with its own shapes and its own conventions. Parry is the narrower layer, so you can pair it with a solver of your own choosing, or with a different broad phase, and you can use the same geometry code in a 2D and a 3D build because the two crates are maintained in the same workspace with the same conventions. The cost of that choice is that you assemble more of the stack yourself.

Releases live on crates.io, not on GitHub

Maintenance is steady but it is expressed in a way that can catch you out. The repository is not archived and the last push was on 2026-10-06, so the code is being worked on. The repository has no GitHub releases, however, so there is no tag history on the project page to consult, and the version you depend on is the one published to crates.io, currently 0.31.1 according to the manifest. The CHANGELOG.md at the top level is the file to read to find out what changed between versions. The number itself is worth reading as a signal, since a zero major version on a long lived library usually means the public API is still allowed to move, and a version line that has passed thirty releases is well past the point where it is merely a young project. The README also points at the Dimforge blog for progress updates, and at a Discord server for questions and feature discussion, and the tree includes a Claude.md file, which is the convention for instructions aimed at coding agents working in the repository, alongside the publish script that pushes the crates.

Editorial conclusion

Parry fits a team writing a physics engine, a robotics stack or a game that needs precise shape queries, ray casts and distance computations without adopting someone else's solver, and the f64 variants are there for the cases where single precision is not enough. It is the wrong choice if you want rigid body dynamics out of the box, because Parry is geometry and collision detection only, and it is a poor fit if you need a documented public API guarantee, since the repository publishes no GitHub releases and the user guide is marked work in progress. Before you depend on it, read the feature flags in the manifest, decide whether you want the f32 or f64 crate for your target platform, and check the CHANGELOG.md, since the crates.io version is the only release channel you can pin against.

Frequently asked questions

Official sources

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