Skip to main content

The Rapier physics engine 2025 review and 2026 goals

· 13 min read
Sébastien Crozet
Sébastien Crozet

🎊🎊🎊 Happy new year 2026 everyone! 🎊🎊🎊

This article summarizes the most significant additions made in 2025 to our open-source crates for geometry and physics simulation that we develop for the Rust community. We also present our main objectives for 2026.

rapier logo

It has been way too long since our last communication! We were deep into experiments and reflexions on the future of Rapier and our upcoming technological choices. In this article, we will be reviewing what notable work has been done on Rapier in 2025 and our envisioned priorities for 2026:

  1. A focus on performance improvements
  2. An unexpected turn of events: the glam migration
  3. A new small crate: glamx
  4. WGSL and Slang: cross-platform GPU physics exploration
  5. Next steps for 2026: robotics and GPU computing

We are also finally resuming maintenance of the kiss3d graphics engine. Check out our dedicated blog post on kiss3d.

A focus on performance improvements​

Rapier’s main focus for 2025 was performance improvements. Especially on web browser through WASM and its JavaScript bindings rapier.js. The main highlights are:

  • A  new BVH implementation (parry#361). This new Dynamic BVH supports efficient automatic rebalancing and SIMD-accelerated tree traversals. It is used in Rapier for both scene queries (ray-casting, point projection, etc) and the broad-phase. This eliminates the need to maintain two separate acceleration structures as it also replaces the older broad-phase based on a Hierarchical Sweep-and-Prune algorithm.
  • A collider for sparse voxels (parry#336). To our knowledge, Rapier is the first general-purpose rigid-body physics engine to support voxels explicitly. A dedicated collider offers several advantages compared to alternatives like making a surface mesh or using compound colliders made of cubes: lower memory footprint (each voxel size is close to a single u8), no ghost collisions, and efficient collision detection through automatic blocks grouping.

2D voxels and primitives
3D voxels and primitives
  • Persistent islands (rapier#895). By persisting simulation islands across frames, we avoid re-extraction of all the collision graph’s connected components at each frame. While this reduces significantly the computational cost of handling islands, this will also help with future performance improvements on the constraints solver.
  • Manifold reduction (rapier#895). This ensures all contact manifolds handled by the constraint solver never have more than 4 contacts. This simplifies the solver code.
  • Simplified 3D friction model (rapier#876). This reduces the number of constraints the solver has to solve in 3D for contact manifold involving at least two contacts. This resulted in a 25% speedup on scenes involving many contacts (like large stacks).
  • New simd-accelerated NPM packages. Before, the only NPM packages we published for the WASM/JS version of Rapier didn’t have SIMD optimizations enabled. Since modern browser are starting to offer stable implementation of SIMD in wasm, we have built and published additional SIMD-accelerated packages for Rapier (for example @dimforge/rapier3d-simd).

With all these improvements combined, on the web, the fastest Rapier NPM package you can use today is now between 2x and 5x faster than the faster Rapier NPM package you could use in 2024 (v0.24.0). The performance gains on native is more moderate considering that SIMD-acceleration has always been available there. The graphs below illustrate some of the performance gain compared to the last version form 2024 (0.23.0, blue curve) compared to 0.32 (red curve), both running on native with the simd-stable feature enabled. The new version is up to 2x faster than a year before.


8000 balls
19.800 spherical joints
8000 revolute joints

Falling stacks of 3027 cubes
Single tower made of 5320 planks
40 pyramids with 210 cubes each

An unexpected turn of events: the glam migration​

Starting with rapier 0.32 and parry 0.26, most of their API and internals using the nalgebra linear algebra library have been modified to use glam instead. This is significant change motivated by two key factors:

  1. The gaming and graphics communities are increasingly adopting glam for linear algebra. Which makes sense due to its simpler API and lower leaning curve.
  2. The rust-gpu compiler backend has first-class support of glam. Unfortunately nalgebra internals are too complex for it to be compiled with rust-gpu (at least currently).

So our goal is to make Rapier easier to learn and use, and to allow us to reuse a substantial amount of code for a future GPU version of Rapier based on rust-gpu (we’ll detail the GPU story more in one of the next sections below). While parry 0.26 no longer has any dependency to nalgebra, rapier continues to use nalgebra internally in two situations where glam falls short:

  • For the multibody implementation that requires a unique combination dynamically-sized matrices and fixed-size vectors (varying between 1D and 6D) and slices. These are both strong features of nalgebra.
  • For the AoSoA (Array-of-Struct-of-Array) SIMD internal optimizations of the constraints solver. nalgebra’s generics wrt. the scalar type and abstractions based on simba make it an obvious choice.

Overall, this is not a "one crate is better than the other" situation. We simply aim to use what we feel is the best tool for each job: glam for its simplicity for 2D and 3D math and for its compatibility with rust-gpu (which just doesn’t work with nalgebra right now); and nalgebra for its genericity on matrix dimensions and scalar types when it’s needed.

Both usages of nalgebra are mostly internal, so 99% of the public API is glam-based.

Impact on performances​

One very interesting aspect of this migration is that you rarely see comparative benchmarks between linear-algebra libraries in large-scale projects. Usually, you only see micro-benchmarks like mathbench that might not be representative of the actual results you would get in a real-life project.

So we were naturally very curious on what performance impact this change would have! And it turned out that… nothing changed, at all (measured on a Macbook Pro M4 Max). All our stress-test scenes ended up with the same performances as before (within margin of error). The only measurable difference we observed was a ~10% slowdown when using glam’s Vec3A type instead of Vec3, so we picked Vec3.

This shows that despite its internal complexity, the compiler manages to optimize nalgebra just as well as glam in our codebase. However, in debug runs, the new glam version tends to be around 20% faster, likely due to fewer indirections when the compiler does not inline.

Impact on the community​

If you are currently using rapier or parry, you are likely in one of three situations:

  • You entire codebase already relies on glam. Then, good news, you no longer need to convert from glam no nalgebra when interacting with rapier/parry.
  • Your entire codebase relies on neither glam nor nalgebra. Then, not much is changing for you: just convert your types to glam instead of converting to nalgebra.
  • Your entire codebase relies on nalgebra. Then, keep in mind that glamx and nalgebra implement type conversions (with the Into/From traits) between nalgebra and glam. Simply enable the nalgebra feature of the glamx crate. This will allow you to convert types between both linear algebra libraries when interacting with the newest rapier/parry version. We have checked with high-profile users (like the fantastic Fyrox game engine) and got feedbacks that this is a generally acceptable approach.

If you are experiencing difficulties with this migration, please don’t hesitate to reach out!

A new small crate: glamx​

The glamx crate (meaning glam eXtensions), provides a few features that are absent from glam but essential for geometry and physics:

  • Pose2, Pose3 for 2D and 3D poses (rotations + translation). Also known as Isometry2 and Isometry3 in nalgebra.
  • Rot2 for 2D rotations. Glam already supports 3D rotations with Quat.
  • MatExt for additional operation of 2D and 3D matrices. In particular, this implements SVD and eigendecomposition of symmetric matrices.
  • An optional feature named nalgebra for converting between glam/glamx types and nalgebra types.

It aims to keep its API simple and with no generics, in the same spirit as glam. It also re-exports every types from glam so you can simply use, e.g., glamx::Vec3 instead of dealing with two crate names everywhere. It is being used by parry, rapier, and kiss3d.

WGSL and Slang: cross-platform GPU physics exploration​

Our second big focus for 2025 was experimenting with various approaches for cross-platform GPU scientific computing in Rust. We have explored (at varying depths) multiple options:

  • WGSL is the shading language behind WebGpu. This is shading the language most Rust graphics/game engines based on wgpu are using. The WESL initiative aims to provide extensions and tooling around WGSL to make it more developer-friendly (e.g. with a module system).
  • Slang is both a shading language and a compiler for that language. You write your Slang shader once, and its compiler transforms it into your platform-specific shader (HLSL, Metal, SpirV, PTX, etc). While this project has been around since 2017 under the Nvidia umbrella, it has been transferred to Khronos in November 2024.
  • CubeCL is a procedural-macro-based system for compiling Rust code to the GPU without needing a nightly compiler. This can be seen as writing shaders with a Rust-based DSL rather than regular Rust code as many of the idiomatic Rust language features are not available in CubeCL shaders.
  • rust-gpu is as compiler backend for compiling regular (no-std) Rust code to SpirV. A similar project, rust-cuda, does the same but targeting CUDA. Rust-gpu has a troubled past. Originally created by Embark Studio it has then been abandoned as Embark revisited their priorities. It has then been maintained by the community, some of the maintainers now involved with VectorWare which aims to build GPU-native applications in Rust.

Long story short, we started with WGSL, switched to Slang, and are now settling with rust-gpu! The experiments with CubeCL were short as we’ve hit very difficult-to-navigate limitations of the subset of Rust language features that actually compile.

We have built quite an ecosystem with WGSL. This ecosystem codename is wgmath. In particular, we have a fully working implementation of a subset of Rapier running on any GPU, even in the browser. wgrapier includes for example a BVH-based broad-phase and modern Soft-TGS constraint solver all running on the GPU. You can try it out at the links below (you will get different performance depending on your browser/platform. See more details on the wgrapier README):


93.000 bodies and 120.000 joints
stack of 34.000 planks

We have also built an MPM (Material Point Method) simulation library in WGSL named wgsparkl. You can try it there (the same performance notes from the wgrapier README are applicable too):

Unfortunately, WGSL is a verry annoying language to work with for advanced mathematics! It lacks a solid module system, and the supported language features are extremely basic. While naga-oil or WESL make it a bit easier, it remains too limited to reach a pleasing development experience like we are used to in Rust. Moreover, WGSL is tied to the WebGpu standard which significantly reduces chances of ever targeting native-only APIs like CUDA.

Next, we tried Slang. Much nicer to work with than WGSL, supports high-level constructs like generics, albeit with more C++ flavors than we would like. Its main pain points are the lack of ecosystem in Rust (aside for the shader-slang compiler bindings), poor IDE support (with RustRover), and the fact that the Slang compiler is written in C++, making it more difficult to integrate with Rust (dylib handling or static linking, bindings, etc). The slang-rhi library (think wgpu but for Slang) is also a C++ library so we made our own slang-hal which is both very limited and way too much work to maintain/improve. At the end of the day, we ported wgsparkl to Slang under the project name Slosh. The code is much nicer than the WGSL version, but still not quite there yet due to constant friction between Slang and Rust. We are still working actively on Slosh but are aiming to transition it to rust-gpu eventually.

Finally, there is rust-gpu. This should technically solve all the aforementioned limitations/friction: you can write your no-std GPU code directly in Rust with most of its high-level language features and Cargo package management, but you are not limited to WebGPU. With some extra indirections, CUDA could also be targeted through rust-cuda sharing most of the same code. Finally, you can imagine libraries like Parry and Rapier being refactored in such a way that both CPU and GPU versions can share a non-negligible amount of code, reducing risks of bugs and making maintenance much easier. The migration of Parry and Rapier to glam was the first, and necessary, step towards that goal.

Next steps for 2026: robotics and GPU physics with rust-gpu​

As far as Rapier and Parry are concerned, we have two major goals for 2026:

  1. Improving Rapier’s features and accuracy for robotics.
  2. Cross-platform GPU rigid-body physics based on rust-gpu.

While Rapier already has some features geared towards robotics like the support for multibody joints (using the reduced-coordinates formalism), URDF file import (with the rapier3d-urdf crate), and inverse kinematics, we still have a long road ahead of us:

  • The multibody implementation needs some love as there are several outstanding known bugs and limitations reported by the community. It could use some numerical stability and performance improvements as well.
  • A new, more accurate constraints solver needs to be implemented for robotics use-cases.
  • Overall, we will be taking heavy inspiration from Mujoco to identify the features we need for robotics simulation. Though we will ensure it doesn’t impact the performances of game applications that doesn’t require that much accuracy.

Regarding cross-platform GPU rigid-body physics, we will apply the knowledge we obtained from the wgrapier WGSL experiment for making a version based on rust-gpu, with a systematic attempt to share as much code as possible with rapier itself. In particular, we envision sharing type definitions and fundamental numeric and geometric operations.

Conclusion​

The year 2025 has been very exciting; full of experiments on GPU computing, while at the same time making significant improvements to Rapier’s performances. We are also glad to get back to writing a bit about what we are working on, considering that it’s been way too long since our last communication! Hopefully, now that the technological choices and path forward are clear, we will be in a good position to provide more regular updates.

We cannot thank enough:

  • Futurewei for sponsoring our work on cross-platform GPU scientific computing.
  • Hytopia for sponsoring most of the performance improvements on Rapier.
  • Foresight Spatial Labs for contributing to the development of Slosh.

Thanks to all the former, current and new sponsors! This helps us tremendously to sustain our Free and Open-Source work.
Finally, a huge thanks to the whole community and code contributors!

Help us sustain our open-source work by sponsoring us on GitHub sponsors or by reaching out ♥
Join us on discord!