The first quarter of 2026 has been very exciting as we are laying out the foundations of our upcoming cross-platform GPU physics libraries. We are introducing new crates:

• Khal: abstraction layer for cross-platform compute on GPU and CPU.
• Vortx: cross-platform GPU tensor library for general linear algebra.
• Inferi: cross-platform GPU inference library.

All these libraries are also compatible with browsers running WebGpu. Physics simulation is still cooking and will be the main highlight of our next update for Q2 2026.

Khal: write once, run on WebGpu, Cuda, and CPU​

https://github.com/dimforge/khal

Khal (meaning "Kompute Hardware Abstraction Layer") facilitates writing Rust code once and have it run on Vulkan, Metal, DirectX, WebGPU, CUDA, and the CPU. It can be seen as a wrapper around very strong tooling developed by the community. For the Rust-to-GPU conversion it wraps:

• rust-gpu: for compiling Rust code to SpirV.
• naga: for transpiling SpirV to target Metal, DirectX, Vulkan, WebGpu.
• rust-cuda: for compiling Rust code to Ptx (Cuda’s IR).

On the host, it wraps:

• wgpu: for initializing resources and running shaders on all gpu platforms over than Cuda.
• cudarc: for initializing resources and running shaders on Cuda.
• rayon and corosensei: for running the shaders on the CPU directly. It uses parallel iterations to run workgroups in parallel, and coroutines for running threads from the same workgroup concurrently. The CPU target is currently very inefficient so it is mostly relevant for debugging.

The general idea is that you write two crates. A no-std crate holding your shader code that will get compiled by rust-gpu and rust-cuda. And a second crate for holding all your application logic, gpu resource allocations, and shader calls orchestration.

The key is that by abstracting all the elements mentioned above, khal allows you to write both crates only once independently of your target (and 100% in Rust). If it works on any target (and, in particular the CPU target which is the easiest to test and debug), you can be fairly confident it will work everywhere unless you hit some unexpected platform-specific edge cases. Khal only focuses on compute shaders. Any rendering-specific shaders (vertex shader, fragment shader, etc.) are out of scope.

Let’s have a quick look at the khal-example and khal-example-shaders example pair. The shader crate for calculating the sum of two vectors is fairly straightforward:

#![cfg_attr(target_arch = "spirv", no_std)]

use khal_std::glamx::UVec3;
use khal_std::macros::{spirv_bindgen, spirv};

#[spirv_bindgen]
#[spirv(compute(threads(64)))]
pub fn gpu_add_assign(
    #[spirv(global_invocation_id)] invocation_id: UVec3,
    #[spirv(storage_buffer, descriptor_set = 0, binding = 0)] a: &mut [f32],
    #[spirv(storage_buffer, descriptor_set = 0, binding = 1)] b: &[f32],
) {
    let thread_id = invocation_id.x as usize;
    if thread_id < a.len() {
        a[thread_id] += b[thread_id];
    }
}

If you are already familiar with rust-gpu, this should look like what you are used to, except for two details:

• We are importing the spirv macro and UVec3 through khal_std instead of spirv_std. This is because khal_std hides the details of conditional compilation between spirv_std and cuda_std depending on the target platform.
• We are calling the #[spirv_bindgen] proc-macro. This is a new macro introduced by khal_std that runs compile-time reflection for generating strongly typed interfaces between the device kernel and rust on the host. In particular, it generates a GpuAddAssign structure (same name as the entrypoint but in PascalCase) with a ::call method that expects strongly typed gpu buffers for launching the kernel.

Now let’s look at the host-side code:

use khal::backend::{Backend, Buffer, Encoder, GpuBackend, GpuBackendError, WebGpu};
use khal::re_exports::include_dir::{Dir, include_dir};
use khal::{BufferUsages, Shader};
use khal_example_shaders::AddAssign;

static SPIRV_DIR: Dir<'static> = include_dir!("$CARGO_MANIFEST_DIR/shaders-spirv");

#[derive(Shader)]
pub struct GpuKernels {
    add_assign: GpuAddAssign,
}

#[async_std::main]
async fn main() {
    let webgpu = WebGpu::default().await.unwrap();
    let backend = GpuBackend::WebGpu(webgpu);

    // Run the operation and display the result.
    let a = (0..10000).map(|i| i as f32).collect::<Vec<_>>();
    let b = (0..10000).map(|i| i as f32 * 10.0).collect::<Vec<_>>();
    let result = compute_sum(&backend, &a, &b).await.unwrap();
    println!("Computed sum: {result:?}");
}

async fn compute_sum(
    backend: &GpuBackend,
    a: &[f32],
    b: &[f32],
) -> Result<Vec<f32>, GpuBackendError> {
    // Generate the GPU buffers.
    let mut a = backend.init_buffer(a, BufferUsages::STORAGE | BufferUsages::COPY_SRC)?;
    let b = backend.init_buffer(b, BufferUsages::STORAGE)?;

    // Dispatch the operation on the gpu.
    let kernels = GpuKernels::from_backend(backend)?;
    let mut encoder = backend.begin_encoding();
    let mut pass = encoder.begin_pass("add_assign", None);
    kernels.add_assign.call(&mut pass, a.len(), &mut a, &b)?;
    drop(pass);
    backend.submit(encoder)?;

    // Read the result (slower but convenient version).
    backend.slow_read_vec(&a).await
}

A few elements are worth noting here:

• Depending on the selected backend GpuBackend::WebGpu, ::Cuda, or ::Cpu, the created buffer’s underlying type will be respectively a wgpu::Buffer, a CudaBuffer, or a simple Vec.
• The kernels.add_assign.call function is strongly typed. For example if you changed the type of a: &mut [f32] to a: &mut [u32] on the entrypoint definition, you will get a compilation error (type mismatch) at the .call site. Same with const-correctness, if the shader expects &mut [T], you must provide a &mut reference to your gpu buffer to the .call function.
• The SPIRV_DIR static constant embeds all the compiled spirv/ptx shaders in your executable. This makes it standalone, and, in particular, simplifies serving it on the web as a single wasm file. It is also used by default by the #[derive(Shader)] macro for finding and instantiating the compute pipelines.

The strong typing eliminates extremely hard-to-debug bugs that would arise if there was any silent mismatch between the gpu kernel’s inputs and your gpu buffers. This would typically arise after some refactoring or changes to the shader entrypoint signature. Here, the compiler will prevent you from forgetting to update the .call function arguments.

The host crate also has a build.rs file for triggering the compilation of the shaders whenever you are compiling your rust crate. The compilation is done by calling the cargo gpu CLI (when targeting spirv/wgpu), or the cargo cuda CLI when targeting PTX/Cuda. Note that we have only tested cargo cuda on a Windows machine for the moment. So your experience may vary on Linux. Both executables are responsible for handling the toolchains specific to rust-gpu and rust-cuda. You need to install them prior to compiling your shaders:

# Install the cargo subcommands
cargo install cargo-gpu --version 0.10.0-alpha.1
cargo install cargo-cuda

# Install the toolchains used by both commands
cargo gpu install
cargo cuda install

The build.rs is fairly straightforward but lacks configurability at the moment. It is responsible for running cargo gpu and cargo cuda automatically for you:

use khal_builder::KhalBuilder;

fn main() {
    // Relative path to the shader crate’s directory.
    let shader_crate = "../khal-example-shaders";
    // Relative path where the compiled spirv and ptx files will be generated.
    let output_dir = "shaders-spirv";

    KhalBuilder::new(shader_crate, true)
        .build(output_dir);
}

Finally, note that the GPU resources created through khal aim to remain as transparent as possible: they are merely enums containing the underlying GPU resource from the backend’s API. So you are always able to break free of khal’s thin abstractions if you need more control, for example to reuse your buffers for a separate rendering library based on wgpu, or to use your CUDA buffers as inputs to third-party libraries like cublas.

Vortx: cross-platform GPU tensors​

https://github.com/dimforge/vortx

Vortx is a tensor library where each tensor can have rank up to 4 under the NCHW format (Batch/Batch/Rows/Columns). The rank is bounded to keep the GPU-side code simpler while covering most scientific computing use-cases. It provides simple ways to initialize tensors and manipulate their shapes. Some common general-purpose tensor operations are provided. Keep in mind that some of these operations are not optimized as much as they could be yet.

• componentwise operations: add, mul, sub, div, copy, inv.
• reductions: sum, product, min, max, squared norm.
• matrix multiplication: naive and tiled gemm.

Inferi: cross-platform GPU inference​

https://github.com/dimforge/inferi

It turns out that implementing LLM inference is an excellent way to stress-test and benchmark linear-algebra operators, and, in particular, all the libraries described above. Moreover, because inference operates mostly on primitive types, it is an easy starting point without having to worry too much about GPU/CPU data layouts (as opposed to physics that relies on a ton of more complex custom types).

Inferi is an inference library that implements a modest number of common operators and a couple of models (namely Llama, Qwen, and Whisper). The main objective is to explore writing inference kernels once and run them on all platforms, as opposed to popular frameworks like llama.cpp and candle that rely on rewriting every operator again and again for each different possible target (Metal, Cuda, Vulkan, etc.) The implementation has not been optimized too much yet, so we are not in par with llama.cpp or candle performance-wise yet.

Inferi comes with a web-compatible GUI application and CLI inferi-chat that runs inference locally after loading a GGUF file. The inferi-whisper-chat CLI does the same but uses voice transcription for the user prompt. Note that the application is mainly here for testing and demoing. Inferi is more about implementing the gpu operators rather than creating an end-user application.

How about physics?​

As promised in our 2026 newsletter, we are working on porting to Rust-GPU the GPU physics work we started in WGSL (see wgrapier). Our current plan for Q2 is to open-source a migration of our WGSL codebase to Khal in May and then continue improving the implementation by sharing more code with the no-std part of the Rapier and Parry codebases.

But our long-term objective doesn’t stop there: we intend to create a full GPU multiphysics system, somewhat similar to Genesis or Newton; all 100% in Rust thanks to Khal, Rust-GPU, and Rust-CUDA.

Conclusion​

This first quarter has been a very exciting opportunity to strengthen the foundations of our philosophy of writing GPU code once, and have it run on most platforms (including the web). Despite just being at the beginning of this journey, the developer-experience massively improved compared to our former experiments with WGSL and Slang. We are looking forward to release a first version of our GPU physics engine within the next couple of months.

We cannot thank enough:

• Futurewei for sponsoring our work on cross-platform GPU scientific computing.
• The maintainers of all the fantastic libraries we build on top of.

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!

The kiss3d crate was one of my very first projects in Rust in 2013! It is an easy-to-use 2D and 3D graphics engine for writing small demos (or even small games if you feel like it). Back in the days, there wasn’t any other easy-to-use graphics library, especially for 3D, and I needed one for showcasing my work on physics simulation; that’s why I created Kiss3d!

I paused its maintenance around 2020 when I switched to Bevy for the testbed of the Rapier physics engine. Some amazing community members helped to maintain Kiss3d since then (huge thanks to @Alex Maiorella and @ alvinhochun among others) but no significant activity happened since 2023.

Fast-forward today, the progressive complexification and frequent breaking of Bevy’s API has made it difficult to keep up and update the testbed every few months. Moreover, I needed an easier access to async functions and latest wgpu versions for experiments involving GPU computing. So it was time to switch back to kiss3d but with a deep refresh:

• It is now based of glam (or rather glamx which is built on top of glam) instead of nalgebra to simplify its API.
• It is based on wgpu (WebGpu) instead glow (OpenGL) for rendering to align with community standards and for easier compatibility with advanced compute shaders.
• It now has a unified interface when targeting native and the web (you control the main loop in both cases) thanks to an async main function, inspired from a similar approach in macroquad.
• Many of the functions for manipulating scene nodes have been renamed to something simpler. (For example append_local_translation is renamed translate).
• Addition of a few convenience and performance-oriented features like support for egui, instancing and polylines rendering. (Disclaimer: you might notice that the polyline demo is strongly inspired from a similar demo in bevy_polyline)
• Added support for multiple lights.

3D primitives	Multiple lights	Meshes, lines, points
Obj and textures	Post-processing effects	Instancing 10.000 2D rectangles
Instancing 1.000.000 3D cubes	3D Polylines	egui support

×

×

×

×

×

×

×

×

×

The kiss3d graphics engine is cross-platform (including the web) and aims to remain simple to use. It does not support Android/iOS yet, but we are planning on it. It is based on a scene tree to describe the rendering scene. You keep total control over main and the render loop and ou don’t need to fit everything into a new paradigm like ECS: you organize your data however you want, arrange your function calls yourself (no complex system scheduling declarations). Rendering simple primitives and meshes only takes a few of lines of code to get you started quickly. The following shows how you render a 3D cube and get an interactive camera supporting mouse controls:

use kiss3d::prelude::*;

#[kiss3d::main]
async fn main() {
    let mut window = Window::new("Kiss3d: cube").await;
    let mut camera = OrbitCamera3d::default();
    let mut scene = SceneNode3d::empty();
    scene
        .add_light(Light::point(100.0))
        .set_position(Vec3::new(0.0, 2.0, -2.0));

    let mut cube = scene.add_cube(1.0, 1.0, 1.0).set_color(RED);

    let rot = Quat::from_axis_angle(Vec3::Y, 0.014); // axis-angle in radians

    while window.render_3d(&mut scene, &mut camera).await {
        cube.rotate(rot);
    }
}

The 2D equivalent follows the same logic:

use kiss3d::prelude::*;

#[kiss3d::main]
async fn main() {
    let mut window = Window::new("Kiss3d: rectangle").await;
    let mut camera = PanZoomCamera2d::new(Vec2::ZERO, 5.0);
    let mut scene = SceneNode2d::empty();
    let mut cube = scene.add_rectangle(100.0, 150.0).set_color(RED);

    let rot = 0.014; // radians

    while window.render_2d(&mut scene, &mut camera).await {
        cube.rotate(rot);
    }
}

Check out the source-code of all the examples on github. You may also interact with some of them with the online demos compiled to WASM (your browser needs to support WebGpu). Refer to kiss3d’s CHANGELOG for detailed information about these breaking changes.

Unfortunately, I have since then lost control over the kiss3d.org domain name. The (new!) website is now hosted at https://kiss3d.rs.

Acknowledgements​

We hope that reviving Kiss3d will help fill a gap in the Rust community for users needing a simple graphics engine with a lower learning curve.

Thanks to all the former, current and new supporters through GitHub 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!

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.

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):

• https://wgmath.rs/demos/wgrapier2d/index.html
• https://wgmath.rs/demos/wgrapier3d/index.html

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):

• https://wgmath.rs/demos/wgsparkl2d/index.html
• https://wgmath.rs/demos/wgsparkl3d/index.html

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!

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

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

Rapier is a 2D and 3D physics engine for games, robotics, and animation written in Rust. Our goal for 2022 was to work on the missing high-level features of Rapier. This month we released the version 0.17 of Rapier with significant feature additions since the version 0.12 released in January 2022:

• The addition of a kinematic character controller.
• The addition of a dynamic vehicle controller.
• The addition of a generic debug-renderer.
• The exploration of destructible voxel-based physics.
• The significant improvement of the ergonomics of bevy-rapier.
• The fix of the internal edges problem in 3D: flat meshes no longer cause unexpected bumps when something slides or rolls on it.

We were also amazed to see Rapier being used by Resolution Games for one of their latest VR multiplayer game: Ultimechs.

Kinematic character controller​

We added a kinematic character controller to Rapier (as well as bevy-rapier and the JS bindings for rapier). The character controller was designed mostly with platformers in mind, supporting the following operations:

• Slide on uneven terrains.
• Interaction with dynamic bodies.
• Climb stairs automatically.
• Automatically snap the body to the floor when going downstairs.
• Prevent sliding up slopes that are too steep.
• Prevent sliding down slopes that are not steep enough.
• Interactions with moving platforms.
• Report information about the obstacles it hit on its path.

Dynamic vehicle controller​

A dynamic vehicle controller was also a very popular feature request. We ported to Rust the vehicle controller from the Bullet physics engine, and integrated it to Rapier. This vehicle controller is based on ray-casting (one ray per wheel) to detect the ground. It simulates wheel friction, suspension, and braking.

Debug renderer​

We added a debug-renderer to let the user see the scene as is actually seen by the physics engine, in order to easily spot common mistakes on objects dimentions and placements relative to their game assets.

Despite its name, Rapier’s debug-renderer doesn’t actually draw anything to the screen directly (except for the RapierDebugRenderPlugin of bevy-rapier which actually draws lines using Bevy’s rendering capabilities). Instead, the user is responsible for providing a method to draw lines using their favorite graphics engine. The DebugRenderPipeline simply returns the lines that need to be rendered. This makes it very easy to integrate to any game engine for quick physics debugging!

In JS, the lines to draw can be obtained with World.debugRender() which returns the vertex buffer and color buffer to render. See rapier.js#119 for integration examples with THREE.js, PIXI, and PlayCanvas.

Exploring destructible voxel-based physics​

We explored the feasibility of destructible voxel physics with Rapier. This requires three parts:

• A new Voxels shape in parry. This Voxels shape is composed of several grid-aligned voxels, where each voxel is represented as a pseudo-sphere (a sphere with cube-like corners along faces were the adjacent voxel exists). Using pseudo-spheres makes the collision-detection more efficient than using actual cubes.
• Collision-detection (also implemented in parry) with these new Voxels shape, and, in particular, between two Voxels shapes.
• The definition of a VoxelFracturePipeline in rapier responsible for calculating approximate stress values within a single Voxels shape in order to detected potential fracture locations.

This first exploration resulted in the following proof-of-concept: a room collapsing under its own weight. Each new colored body appearing is a fractured piece that separates from the main body:

Bevy-rapier: ergonomics improvements​

The bevy-rapier2d and bevy-rapier3d crates provide plugins to use rapier easily with the bevy game engine. In April 2022 we released a complete rewrite of this plugin to make the API significantly more "bevy-friendly":

• Colliders and rigid-bodies can be configured through multiple components.
• Collider and rigid-body positioning operates through the familiar Transform/GlobalTransform components directly.
• Mesh colliders can be created automatically after a Mesh asset is done loading, using the AsyncCollider or AsyncSceneCollider components.
• All the components and query functions now rely on glam types instead of nalgebra. nalgebra types are only needed when calling into the raw Rapier objects (which can be used for niche operations that are not exposed explicitly by the plugin yet).
• A wireframe debug-renderer can be enabled with the new RapierDebugRenderPlugin.

These changes were strongly inspired by the heron crate which had a way nicer API than bevy-rapier before this rewrite

Game highlight: Ultimechs​

In September 2022, our sponsor Resolution Games launched the exciting free-to-play multiplayer VR game: Ultimechs. Based on Unity, Ultimechs relies on our Rapier physics engine for physics. You can read more about Resolution Games’ use of Rust alongside Unity in their May 20 Insight.

Sparkl: exploring MPM physics simulation

The Sparkl project is entirely sponsored by Foresight Mining Software Corporation which currently leverages it in production for industrial applications.

We silently released in December 2022 our open-source MPM (Material Point Method) physics simulation libraries: sparkl2d, sparkl3d. In their current form, they supports 2D and 3D particle-based deformable physics simulation with various materials, including sand, snow, elasticity and fracture. They do not support two-way coupling with rapier yet, meaning that Rapier colliders can be used to define the ground using boxes or heightfields, but interaction with dynamic bodies isn’t implemented yet.

Sparkl runs on CUDA-enabled GPUs only (running on multiple GPUs is supported). All the CUDA kernels are written 100% in Rust thanks to the Rust CUDA Project.

nalgebra: linear-algebra

nalgebra is a general-purpose linear-algebra library for Rust. It supports low-dimensional, high-dimensional, sparse matrices, as well as geometric transformations (rotations, isometries, etc.)

In 2022, most of our efforts went in Rapier rather than nalgebra itself. Most new features were added by the community, including:

• Matrix slices were renamed as matrix views to avoid confusion with rust slices (by Andlon #1178).
• Enabling the rayon feature of nalgebra will enable theMatrix::par_column_iter and Matrix::par_column_iter_mut methods. As their names suggest, these are rayon-based parallel iterators on the matrix’s columns (by geo-ant #1165).
• Generalized eigenvalues problem resolution, generalized eigenvalues/eigenvector calculations, and QZ decomposition have been added to nalgebra-lapack (by metric-space #1067 and geoeo #1106).
• Performance of the product of two sparse matrices in nalgebra-sparse has been improved significantly (by smr97 #1081).

Check out the Changelog for details on the other additions.

What’s next in 2023

Because we focused on features during the past two years, we will take a different route for 2023. In its current form, Rapier looks complete enough feature-wise to fit most game use-cases. So our main objective will be to work on bug fixes, user-experience improvements, and documentation. This quality improvement effort will be focused mainly on Rapier, and include for example:

• Addressing most bugs reported on GitHub in 2022 and before, as well as complaints that are frequently reported on Discord (for example, related to some limitations of the character-controller when it hits vertical walls).
• Reduce risks of internal panics in Rapier (for example when a rigid-body has a NaN position).
• Make the debugging experience nicer with the JS bindings by detecting potential problems (and raising an exception) before reaching the WASM module.

In order to get a better awareness of Rapier’s ergonomics issues and bugs, we will be working on a small physics sandbox app. It is currently closed-source, but will be open-sourced once it is more fleshed-out and usable. Think of something similar Phun/Algodoo but written in Rust, based on Rapier, compatible with WASM (i.e. runs on the browser), and handling both 2D and 3D (in two different apps. sharing the same codebase).

Writing this physics sandbox will also be the opportunity to explore the scaling large-scale distributed physics simulation. This exploratory work is sponsored by Futurewei.

Thanks

We can’t thank enough:

• Foresight Mining Software Corporation for sponsoring Sparkl, all our CUDA-related efforts on nalgebra and parry, many of the new geometric primitives in Parry.
• Futurewei for sponsoring the ongoing exploration of distributed physics simulation.
• Fragcolor and Resolution Games for being our Gold sponsors for a whole year.

Thanks to all the former, current and new supporters through GitHub sponsors! This helps us tremendously to sustain our Free and Open-Source work.

This help is greatly appreciated and allows us to continue working on our open-source projects. Finally, a huge thanks to the whole community and code contributors!

The year 2021 has been a very exciting for Dimforge and the Rust community at a whole! This blog post summarizes the most significant additions made in 2021 to the open-source crates for linear-algebra and physics simulation we develop for the Rust community. We also present our main objectives for 2022.

Help us sustain this work by sponsoring us on GitHub sponsors ♥
Join us on discord!

Rapier is a 2D and 3D physics engine for games, robotics, and animation written in Rust. Our goal for 2021 was to work on the missing low-level features of Rapier: shape-casting, CCD, joint limits and motors, custom collider shapes, dominance, multibodies. We also significantly improved Rapier’s documentation by writing complete user-guides for the Rust version of Rapier, it’s Typescript bindings, as well as its Bevy plugin.

Today we released the version 0.12-alpha.0 of Rapier. This release features three significant changes:

1. The addition of multibody joints (part of our 2021 objectives).
2. The change of our constraint solver.
3. A complete redesign of our joints.

Please note that this is an alpha release which still has a few known limitations we would like to address before making a proper release.

Multibody joints​

The main focus of this release was to add the support for joints based on the reduced-coordinates formalism. There are basically two main ways of modeling joints:

• The full-coordinates approach, aka. impulse-based joints, that applies forces/impulses to enforce the joint’s positional constraints.
• The reduced-coordinates approach, aka. multibody joints, that encodes the positional constraints directly into the parametrization of the rigid-bodies positions when developing the equations of motions.

Both approaches have advantages and drawbacks. The impulse-based joints are more computationally efficient, and can sustain higher relative velocities without completely diverging. However, the constraint solver may not always be able to compute the exact forces needed to fulfill the joints requirements. This can result in a wobbly behavior, where the attached objects appear to oscillate. For example, you can observe this "wobbly" behavior here with fixed joints (top-left), limited prismatic-joints (bottom), and motorized revolute joints (top-right):

The multibody joints however can be less computationally efficient and do not allow joint assemblies with loops (it must form a tree). However, these joints will never be violated, avoiding any wobbly behavior. The assembly looks perfectly stiff:

Constraint solver change​

The addition of multibody joints proved to be quite difficult considering the design of our former constraint solver. Before the version 0.12-alpha.0, Rapier used a linear velocity-based solver (with warm-starting) to solve velocity (contact and joint) constraints, followed by a non-linear position-based post-projection to correct any penetration or joint drift at the position level. This scheme proved to be quite difficult to extend (because of the non-linear nature of the position-based solver) and computationally expensive when multibodies were involved. Therefore, we changed our solver to only contain two linear velocity-based phases:

1. A biased velocity constraint resolution, which solves for the contact and joint constraints and tries to correct penetrations and joint drifts at the same time. This will potentially add artificial energy to the mechanical system, resulting in potential jitters, and "popping" effects due to penetration.
2. A non-biased stabilization velocity resolution, which removes most of the excessive energy introduced into the mechanical system by the previous phase.

With both phases combined, typical simulations won’t show any large "popping" effect or jitter, while feeling stiffer overall. In addition, this solver doesn't require any warm-starting, meaning that the force computation no longer rely on the complete history of the simulation to converge. In the future this should allow the implementation of rollback systems with less state needed to keep the simulation stable.

Joints redesign​

One of our objectives with the introduction of multibody joints was to keep the multibody joints API as close as possible as the impulse-based joints API, despite the fact that their mathematical modeling are completely different. Before the release 0.12-alpha.0, we had different types for each impulse-based joint (RevoluteJoint, PrismaticJoint, FixedJoint and BallJoint). In the version 0.12-alpha.0, all the impulse-based joints are replaced by a single generic joint ImpulseJoint similar to "6-dofs joints" in other 3D physics engines. Similarly, the multibody joints have all been grouped into a single generic joint MultibodyJoint which can be configured to represent any combination of free/limited/motorized degrees-of-freedoms.

The structures FixedJoint, BallJoint, PrismaticJoint and SphericalJoint (formerly named BallJoint) still exist, but are only used as a simple way to build an ImpulseJoint or a MultibodyJoint. Impulse joints are added to the ImpulseJointSet (formerly named JointSet) and multibody joints are added to the MultibodyJointSet.

Why an alpha release?​

For the first time in the history of rapier, we are making an alpha release. This release introduces significant changes, and still has a few bugs we are aware of:

• Multibody joints created from a JointData directly instead of through a RevoluteJoint, PrismaticJoint, FixedJoint, SphericalJoint structure may behave oddly. We will soon make sure that the general case works properly (we finished the mathematical modeling but not the implementation yet).
• Joint motors affecting multiple free angular degrees of freedom may behave in an unexpected way because of a few numerical issues due that we need to address.
• We haven’t updated the user-guide yet (however all our examples have been updated).
• The parallel version of Rapier should not be used with this alpha version.

These issues will be our first priority for 2022. We didn't want to postpone the alpha release any further so that users that don’t rely on these specific features can already start switching to, testing, and providing feedbacks on this new version (especially regarding the new constraint solver). This also allows us to keep rapier in sync with the newer version of nalgebra we released today.

nalgebra: linear-algebra

nalgebra is a general-purpose linear-algebra library for Rust. It supports low-dimensional, high-dimensional, sparse matrices, as well as geometric transformations (rotations, isometries, etc.)

The main features added in 2021 were:

• The release of the new nalgebra-sparse crate entirely contributed by Andreas Longva. This is a complete rewrite of our former nalgebra::sparse module.
• The integration of const-generics, improving the ergonomics, debuggability, and generic programming, for code involving statically-sized matrices.
• The addition of the matrix!, vector!, point!, etc. macros to construct matrices from their components more easily. They allow the easy construction of const matrices and vectors too.
• The fix of several soundness issues, in particular by properly using MaybeUninit instead of the deprecated, unsound, mem::uninitialized().

Finally, today we released the version 0.30 of nalgebra which adds the compatibility with the recently announced rust-cuda project. This allows the usage of every no-std features of nalgebra (which are, everything, including matrix decompositions, excluding sparse matrices and dynamically-sized matrices) inside CUDA kernels written in Rust. The transfer of nalgebra structures between the RAM and VRAM is also possible.

Parry: collision-detection

In 2021, we released our new collision-detection library parry which replaces our former crate ncollide. The parry crate is more efficient than ncollide and is easier to use thanks to a much smaller amount of generics. Some notable features supported by parry that were not included in ncollide are:

• An implementation of the VHACD algorithm for approximate convex decomposition of concave 2D and 3D shapes.
• An implementation of an SIMD-accelerated quaternary BVH structure, much more efficient than ncollide’s BVT and DBVT structures.
• A more versatile non-linear shape casting.
• An implementation of the Hertel-Mehlhorn algorithm for 2D convex decomposition, fully contributed by Sven Niederberger.

Finally, today we released the version 0.8 of parry. This version allows a subset of parry to work in a no-std context. This was required to add the compatibility of this subset of parry with rust-cuda, allowing various geometric operations (including ray-casting, distance computation, intersection tests, etc.) to be used inside of a CUDA kernel written in Rust.

Salva: fluids simulation

In our roadmap for 2021, we mentioned that we would work on improving the performances of Salva with SIMD optimizations. We are sorry to announce that none of it has been done. Instead, we focused more of Rapier, and started experimenting with the Material Point Method. This experiment is important because:

• MPM has shown to be quite promising lately, for example with the recent presentation of the blub project.
• MPM is extremely versatile to simulate models sustaining large deformations, and a wide range of various materials, from sponges to fluids.
• MPM is very friendly for aggressive optimizations based on multithreading, SIMD, and GPU computing.
• MPM may end up replacing completely the SPH implemented in Salva if we get good results.

We currently have promising preliminary results using a CPU-based implementation multithreaded with rayon, or a GPU-based CUDA implementation based on rust-cuda (all our CUDA kernels are written in Rust, using nalgebra and parry). As always, we are targeting both 2D and 3D simulations. The development of this new crate is currently closed-source, with a plan to open-source it in April 2022. Here are a couple of small simulations featuring deformations, sand, fluids and fractures:

What’s next in 2022

For 2022, we have two main objectives:

1. Work on high-level features for Rapier.
2. Continue our exploration of MPM for fluids and deformable bodies simulation.

By high-level features for Rapier, we mean all these features that make the user’s life easier and that have been frequently requested in 2021. This includes:

• A more efficient handling of voxel-based worlds. We also consider experimenting with destruction on voxel-based games, similar to what can be seen in the Teardown game.
• A sample character controller.
• Utilities like Godot’s move_and_slide for easier control of kinematic rigid-bodies.
• Inverse kinematics.
• Solutions for the internal edge problem that may cause "bumps" when an object slides on a flat surface represented by multiple triangles or cubes.

These additions will bring Rapier to a very usable place for both physics beginners and experts.

Thanks

We would like to thank Croquet for sponsoring our work right from the beginning of Dimforge, as well as Fragcolor for being our new Gold sponsor for 2022! This helps us tremendously to sustain our Free and Open-Source work.

Thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on our open-source projects. Finally, a huge thanks to the whole community and code contributors!

Help us sustain this work by sponsoring us on GitHub sponsors ♥
Join us on discord!

New, user-guide for Rapier’s JS bindings 📖​

During April and May, we completely rewrote the user-guides for the Rust version Rapier and bevy_rapier. During the past two months, we continued this documentation work by completely rewriting the user-guide for the JS/TypeScript bindings for Rapier too. It is now much more complete as it covers all the available features.

Check it out on rapier.rs.

nalgebra v0.29: soundness and better non-Copy types support 🎊​

The development of nalgebra started even before the 1.0 release of the Rust compiler. Needless to say this was long before the MaybeUninit type was stabilized in Rust 1.36. Before the introduction of MaybeUninit, the use of mem:uninitialized() was the de-facto way of creating an uninitialized variable, and was therefore used extensively throughout the codebase of nalgebra. Switching to MaybeUninit instead of mem::uninitialized() was a major undertaking that never happened completely. We did replace all the mem::uninitialized() by MaybeUninit::new().uninit() a while ago but that was still technically unsound, even if it didn’t cause any actual problem in practice because nalgebra was mostly used with primitive Copy types.

With nalgebra 0.29, we completely reworked our trait system in order to use MaybeUninit properly. This has two benefits:

• The parts of nalgebra using uninitialized matrices is no longer unsound.
• It is now possible to use non-Copy types safely as matrix components (for example, BigUint from the num_bigint crate).

This work was the result of a significant group effort, for which we thank in particular

• Violeta Hernández who made a fantastic work exploring all the possible design solutions we could think of.
• Andreas Longva, Benjamin Saunders, and others on our discord server for providing valuable comments and ideas.

Announcing Rapier 0.11 ⚔️​

With the release 0.11 of Rapier, we implemented all the joint limits that were missing, this includes joint limits for revolute joints and ball joints.

During the past two months, we also started working on joints modeled using reduced coordinates. These joints have the benefit of being unbreakable, at the cost of being slightly less versatile (joint forces can’t be read, the chain of articulations can’t form a loop) and more computationally expensive

As mentioned in our 2021 roadmap for Rapier, we initially planned to release reduced-coordinates joints in August. However, it will take more time because we spent the last few months improving the documentation of Rapier (which we initially planned on doing at the end of this year instead) instead of working on these joints.

This work is happening in the multibody branch and will be our focus for the next couple of months.

Thanks

We would like to thank the whole community and code contributors. In particular, thanks to the code contributors from the past two months¹:

• @Andlon

• @atouchet

• @CAD97

• @CattleProdigy

• @Cryptjar

• @Demindiro

• @extrawurst

• @grimko

• @hoiast

• @jpetkau

• @jsmith628

• @MalteT

• @mariusknaust

• @n3vu0r

• @Nateckert

• @OfficialURL

• @oli-obk

• @Ralith

• @remilauzier

• @rezural

• @skairunner

• @ssbr

• @SuperSamus

• @vadixidav

• @viridia

• @Waridley

• @wwwtyro

• @zedseven

• @zicklag

• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.

• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on our open-source projects.

Help us sustain this work by sponsoring us on GitHub sponsors ♥
Join us on discord!

Announcing Rapier 0.9 + bevy_rapier 0.10 ⚔️​

The release 0.9 was mostly focussed on improving the ergonomics of the crate by:

• Allowing user-defined storages containing rigid-bodies and colliders in place of the default ColliderSet, RigidBodySet (which are still available). Actually the RigidBody and Collider structs can also be optionally replaced by a set of individual components (RigidBodyVelocity, RigidBodyPosition, ColliderShape, etc.) This can make the integration of Rapier into another framework much more ergonomic (bevy_rapier 0.10 is an example of improved integration).
• Allowing colliders not attached to any rigid-body.
• Adding a few simple methods to get/set the translation and rotation of a rigid-body or collider (instead of setting the whole isometry at once).
• Adding an easy way to enable collision-detection between a collider attached to a kinematic rigid-body and a collider attached to a static rigid-body. More generally, we can now easily enable collision detection between two colliders attached to non-dynamic rigid-bodies by configuring their active collision types.
• Adding velocity-based kinematic bodies. They are rigid-bodies controlled by setting their velocity instead of their next position.
• Making collision events and physics hooks enabled for each individual collider explicitly instead of being enabled for all the colliders automatically. See the collider's active events and active hooks.

Check out the v0.9.0 changelog for an exhaustive list of the changes.

Completely rewritten bevy_rapier 0.10 🐦​

Thanks to the support of user-defined storages in Rapier 0.9, we were able to rewrite our Rapier plugin for Bevy bevy_rapier 0.10 to make it significantly more ergonomic (giving it a more bevy-native feeling) than bevy_rapier 0.9.

As a result, Bevy's QuerySet are now used as rigid-body/collider storages instead of the RigidBodySet/ColliderSet. Rigid-bodies and collider are now defined as bundles (instead of the monolithic structs RigidBody and Collider):

#[derive(Bundle)]
pub struct RigidBodyBundle {
    pub body_type: RigidBodyType,
    pub position: RigidBodyPosition,
    pub velocity: RigidBodyVelocity,
    pub mass_properties: RigidBodyMassProps,
    pub forces: RigidBodyForces,
    pub activation: RigidBodyActivation,
    pub damping: RigidBodyDamping,
    pub dominance: RigidBodyDominance,
    pub ccd: RigidBodyCcd,
    pub changes: RigidBodyChanges,
    pub ids: RigidBodyIds,
    pub colliders: RigidBodyColliders,
}

#[derive(Bundle)]
pub struct ColliderBundle {
    pub collider_type: ColliderType,
    pub shape: ColliderShape,
    pub position: ColliderPosition,
    pub material: ColliderMaterial,
    pub flags: ColliderFlags,
    pub mass_properties: ColliderMassProps,
    pub changes: ColliderChanges,
    pub bf_data: ColliderBroadPhaseData,
}

The components in these bundles can be queried like any other components of Bevy.

New, complete, user-guides 📖​

During the past two months we have also been working at making the documentation of Rapier and bevy-rapier much more complete! We now have user-guides that cover all the available features of Rapier, excepted details about implementing your own custom storage for colliders and rigid-bodies.

Check out the new Rapier user-guide and the new bevy-rapier user-guide. We haven't improved the JavaScript user-guide but we will work on it in June.

Rapier JavaScript bindings v0.6.0 🌐​

The JavaScript bindings for Rapier have been updated to use Rapier 0.9.0. In addition, we added the ability to:

• Create velocity-based kinematic bodies.
• Read contact information (contact points, contact normals, etc.) and intersection statuses from the narrow-phase
• Write custom filters (as JS objects implementing a specific interface) for applying any rule to select what pair of colliders can or cannot collide.

Check out the 0.6.0 changelog for a list of all the changes.

nalgebra v0.26 and v0.27: const-generics 🎊​

In April, we released the version 0.26 of nalgebra with one major changed: we integrated const-generics. Check out our dedicated announcement if you missed it.

In nalgebra v0.27, we added (thanks to the contribution from Andreas Longva) the macros matrix!, dmatrix!, vector!, dvector!, point! for constructing matrices/vectors/points in a convenient way. The length of the matrix/vector/point is deduced automatically from the number of elements given to the macros:

use nalgebra::{vector, matrix};

let vec3 = vector![1.0, 2.0, 3.0]; // Constructs a `Vector3`.
let pt2 = point![1.0, 2.0]; // Constructs a `Point2`.
let mat2x3 = matrix![
    11.0, 12.0, 13.0; // The ; delimits each row of the matrix.
    21.0, 22.0, 23.0
]; // Constructs a `Matrix2x3`
let dvec = dvector![1.0, 2.0, 3.0, 4.0]; // Constructs a `DVector` with four elements.

The vector!, matrix! and point! macros can also be used in a const context:

const MY_VECTOR: Vector2<f32> = vector![1.0, 2.0];

What's next​

At the beginning of this year, we announced our 2021 roadmap for Rapier. During the past two months, we slightly diverged from that roadmap because we figured it was time to make the library more accessible to the community by improving its API (especially for bevy_rapier) and by providing comprehensive docs. Hopefully, this will make game-development in Rust even more appealing to newcomers, and will allow everybody to use the more advanced features of Rapier (that were not documented at all before).

In May, we will continue on that path by rewriting/completing the user-guide for the JavaScript bindings of Rapier. If we have time after that, we will implement the joint limits we initially planned for last month (currently, only joint limits for prismatic bodies are implemented).

Thanks

We would like to thank the whole community and code contributors. In particular, thanks to the code contributors from the past two months¹:

• alec-deason
• Andlon
• chammika-become
• DasEtwas
• Dave Farnham
• djkoloski
• dstaatz
• illis
• jturner314
• MJohnson459
• OfficialURL
• rezural
• sdfgeoff
• vks
• zakarumych

• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on our open-source projects.

The version 1.51.0 of Rust has been released three weeks ago. That version stabilized an MVP for one of the feature we wanted the most: const-generics. Const-generics allow you to define types parametrized by const integers, chars, or booleans. One iconic example is writing a structure wrapping an array of any size:

// Example taken from the 1.51 Rust announcement.
struct Array<T, const LENGTH: usize> {
    list: [T; LENGTH]
}

nalgebra supports matrices (and vectors) with dimensions known at runtime or at compile-time. The components of matrices/vectors with dimensions known at runtime are stored in a Vec<T>. Before nalgebra 0.26, matrices/vectors with dimensions known at compile-time were stored in a GenericArray, from the excellent generic-array crate. Thanks to const-generics, we were able to replace GenericArray by standard arrays: [[T; R]; C] (where R is the number of rows, and C the number of columns) in nalgebra 0.26.

This change results in significant ergonomics improvements when using statically-sized matrices or vectors:

• Simpler generic programming.
• Simpler debugging.
• Constructors using const-fn.
• New aliases.

1. Simpler generic programming with statically-sized entities​

Using nalgebra for generic programming with statically-sized matrices/vectors/points was quite challenging before. Let's take a simple example of a generic structure that wraps a point, a vector, and a matrix and performs some kind integration using 64-bit precision. In previous version of nalgebra this would look like this:

use nalgebra::{DimName, MatrixMN, VectorN, Point, DefaultAllocator, allocator::Allocator};

struct Integrator<D: DimName>
  where DefaultAllocator: Allocator<f32, D, D> + Allocator<f32, D> {
  m: MatrixMN<f32, D, D>,
  v: VectorN<f32, D>,
  p: Point<f32, D>
}

impl<D: DimName> Integrator<D>
  where DefaultAllocator: Allocator<f32, D, D> + Allocator<f32, D> {
  // A method that performs some kind of integration
  // using `f64` intermediate results.
  pub fn integrate_highp(&self, dt: f32) -> Point<f32, D>
    where
            MatrixMN<f32, D, D>: Copy,
            VectorN<f32, D>: Copy,
            Point<f32, D>: Copy,
            DefaultAllocator: Allocator<f64, D, D> + Allocator<f64, D> {
    // First cast all the operants to `f64`:
    let (m, v, p) = (self.m.cast::<f64>(), self.v.cast::<f64>(), self.p.cast::<f64>());
    // Perform the computation with f64 precision, then
    // cast the result to f32.
    (p + m * v * dt as f64).cast()
  }
}

See all the DefaultAllocator: Allocator<...> trait bounds? They are here to help the compiler deduce the proper storage types for the matrix/vector/points (i.e. to deduce the GenericArray with the right dimensions).

Now that const-generics have been integrated to nalgebra this code becomes as simple as one would expect:

use nalgebra::{Point, SMatrix, SVector};

struct Integrator<const D: usize> {
  m: SMatrix<f32, D, D>,
  v: SVector<f32, D>,
  p: Point<f32, D>,
}

impl<const D: usize> Integrator<D> {
  // A method that performs some kind of integration
  // using `f64` intermediate results.
  fn integrate_highp(&self, dt: f32) -> Point<f32, D> {
    // First cast all the operants to `f64`:
    let (m, v, p) = (
      self.m.cast::<f64>(),
      self.v.cast::<f64>(),
      self.p.cast::<f64>(),
    );
    // Perform the computation with f64 precision, then
    // cast the result to f32.
    (p + m * v * dt as f64).cast()
  }
}

See that there isn't any DefaultAllocator: Allocator trait bounds whatsoever.

Now, keep in mind that these simplifications will only work if you stick with entities with dimensions known at compile-time. If your code needs to work generically for both statically-sized matrices and dynamically-sized matrices, then the DefaultAllocator: Allocator bounds are still necessary (we should be able to get rid of them too once specialization is stabilized).

2. Simpler debugging of small matrices and vectors​

This one is a life-changer for those relying extensively on debuggers. Until now, inspecting with a debugger the content of statically-sized matrices or vectors (or points, quaternions, etc.) was extremely difficult. This was caused by the smart, but complicated, recursive definition of GenericArray. Here is what inspecting the content of let matrix = Matrix2::new(1, 2, 3, 4) looked like (in CLion's debugger, using the Rust plugin):

Here is what it looks like now that we replaced GenericArray by standard arrays:

This is much clearer now. Keep in mind that nalgebra stores its matrices in column-major format. That's why the components appear in the order [[1, 3], [2, 4]] (column by column).

3. Building small, constant, matrices and vectors​

Now that small matrices are using standard arrays under the hood, it is now possible to define constant vectors, matrices, points, quaternions, and translations by using their const fn new(...) constructors:

use nalgebra::{Vector3, Point4, Matrix2, Quaternion, Translation3};

const VECTOR: Vector3<u32> = Vector3::new(1, 2, 3);
const POINT: Point4<f32>  = Point4::new(1.0, 2.0, 3.0, 4.0);
const MATRIX: Matrix2<i32> = Matrix2::new(-1, 2, 
                                          -3, 4);
const QUATERNION: Quaternion<f64> = Quaternion::new(1.0, 2.0, 3.0, 4.0);
const TRANSLATION: Translation3<f32> = Translation3::new(1.0, 2.0, 3.0);

4. New aliases​

Everything in nalgebra ends up being expressed as a matrix, in one way or another. Even a vector is just the Matrix type setup to have only one column. This is why we have so many type aliasses like Vector3 which is an alias for a matrix with 3 rows and one column.

In nalgebra 0.26 we have the following dimension-generic type aliases:

• OMatrix<T, R: Dim, C: Dim>: for owned matrices (formerly called MatrixMN), i.e., matrices that own their components (as opposed to matrix slices that borrow them).
• SMatrix<T, const R: usize, const C: usize>: for statically-allocated matrices.
• DMatrix<T>: for dynamically-allocated matrices.

All the aliases for specific dimensions (e.g. Vector3 for 3D vectors) remain unchanged.

The same applies to vectors: OVector, SVector, DVector. For example a statically-sized vector with 528 components can be written SVector<f32, 528>.

Limitations: why typenum is still needed​

We no longer use the generic-array crate, but you will notice that nalgebra continues to depend on the typenum crate. This is needed because const-generics support on Rust 1.51 isn't complete yet, and doesn't allow operations on the const-parameters like in the following push method that adds an element to an array:

impl<T, const LENGTH: usize> Vector<T, LENGTH> {
    // The { LENGTH + 1 } isn't allowed yet in this context.
    fn push(self) -> Vector<T, { LENGTH + 1 }>
    { unimplemented!() }
}

In order to overcome this limitation, we have to rely on typenum by converting the integer to a type-level-integer, performing the operation with typenum's type-level operators, and then extracting the result as a const value. This roughly looks like this:

struct Const<const D: usize>;
trait ToTypenum {
    type Output;
}

trait ToConst {
    type Output;
}

impl ToTypenum for Const<1> { type Output = typenum::U1; }
impl ToConst for typenum::U1 { type Output = Const<1>; }

impl ToTypenum for Const<2> { type Output = typenum::U2; }
impl ToConst for typenum::U2 { type Output = Const<2>; }

// ... make the same impl. for all values until some arbitrary
//     limit (currently 127 in nalgebra).

impl<const R: usize> Vector<N, Const<R>> {
    fn push(&self) -> Vector<N, <Sum<<Const<R> as ToTypenum>::Output, typenum::U1> as ToConst>::Output>
    where Const<R>: ToTypenum,
          <Const<R> as ToTypenum>::Output: Add<typenum::U1>,
          Sum<<Const<R> as ToTypenum>::Output, typenum::U1>: ToConst {
        unimplemented!()
    }
}

It's actually less verbose in nalgebra because we have some additional traits to hide some of the complexity going on here. But the fact remains that without more advanced const-generics support from the compiler, methods like this push will be more verbose to define, and will be limited to the values of D (currently the values in [0, 127]) such that Const<D>: TyTypenum is implemented.

What's next?​

The const-generics MVP allowed us to significantly improve the ergonomics of statically-sized matrices and vectors. However, we are still waiting for two features to land to make nalgebra much nicer:

• Specialization: with specialization in place, we could get rid of all the DefaultAllocator: Allocator<...> bounds. This means writing generic code that accepts both statically-sized matrices and dynamically-sized matrices would become much easier.
• Const-generics (the complete version): being able to write something like [T; { LENGTH + 1 }] would allow us to remove the typenum dependency completely.
• Const-fn (the complete version): being able to have trait bounds other than Sized in generic const-functions would allow us to mark most of nalgebra's methods as const. Right now, only some constructors are possible.

Help us sustain this work by sponsoring us on GitHub sponsors ♥
Join us on discord!

Announcing nalgebra-sparse 0.1 🎊​

In February, we silently released a new crate: nalgebra-sparse. This new crate is a complete rewrite of sparse-matrix computations with nalgebra. It aims to completely replace the sparse module from the nalgebra crate. Here are the most significant features of that new crate:

• CSR, CSC and COO formats, and conversions between them.
• Common arithmetic operations are implemented: sparse addition, multiplication, and triangular solve.
• Sparse Cholesky decomposition for CDC sparse matrices.

We thank Andreas Longva for his amazing work in this crate!

Announcing Rapier 0.7 ⚔️​

The versions 0.6 (which we didn't communicate about) and 0.7 of Rapier come with very exciting new features! Here is a summary:

• Joint motors: control the position and/or velocity of a joint.
• Dominance groups: make one dynamic rigid-body immune to the forces generated by some other dynamic rigid-bodies.
• Contact modification: simulate conveyor belts, one-way platforms and other special effects.
• Collider modification: modify a collider after it has been added to the ColliderSet.
• Continuous collision detection: don't miss any collision because of fast-moving bodies.
• Large colliders support: colliders with very large shapes can be used efficiently now.

Joint motors​

Joint motors allow you to make a joint move the rigid-bodies it is attached to by:

• Choosing the relative velocity of the rigid-bodies along the joint's free degrees of freedoms.
• Or choosing a desired relative position of the rigid-bodies, along the joints's free degrees of freedoms.

For example, you can set the target angular velocity, or the target angle of a RevoluteJoint. One typical use-case is to make a simulated car move by making the joint rotate its wheels.

The following illustrates examples of motorized ball joints, revolute joints, and prismatic joints:

Dominance groups​

Dominance groups is a non-physical feature that allows you to ignore Newton's third law of motion (force reciprocity) for chosen pairs of rigid-bodies.

Each dynamic rigid-body can be given a dominance group number in [-127; 127] (the default is 0). If two dynamic rigid-bodies are in contact, the one with the highest dominance group number will act as if it has an infinite mass, making it immune to the forces the other body would apply on it. If both bodies are have the same dominance group number, then their contacts will work in the usual way (both are affected by opposite forces with equal magnitude).

Dominance is a completely unrealistic feature. But it can be used to simulate specific effects in games. An example is the simulation of a player represented as a dynamic rigid-body that cannot be "pushed back" by some other dynamic rigid-bodies part of the environment.

Contact modification​

Contact modification allows you to modify the properties of a contact (or completely delete a contact) after it has been computed by the narrow-phase, but before it reaches the constraints solver. Typical use-cases of contact modification are:

• The simulation of conveyor belts by modifying the tangent_velocity field of a contact.
• The simulation of one-way platforms by removing some contacts depending on their contact normal.
• The simulation of materials with smooth friction/restitution coefficient variations by modifying the friction and/or restitution coefficient of a contact, bypassing the CoefficientCombineRule of the colliders involved in the contact.

The one-way platforms example illustrates the first two use-cases enumerated above. Both platforms act as conveyor belts (i.e. they move objects towards predefined directions), and both platforms are one-way platforms:

(Note that the gravity is set to opposite directions on both sides of the simulation to make it more interesting).

These contact modifications are possible thanks to the introduction of a new PhysicsHooks trait that defines methods called during a timestep to filter contact pairs, filter intersection pairs, and modify the contacts to be processed by the constraints solver.

Collider modification​

Before Rapier 0.7, it wasn't possible to modify a collider after it was added to the ColliderSet. Therefore, changing a collider's shape, its position relative to the rigid-body it is attached to, or even changing its collision groups, was only possible by removing the collider and inserting a new one. That was both inconvenient and inefficient.

With Rapier 0.7, these modifications are now possible, and will automatically be taken into account by the physics engine.

Continuous collision detection​

Fast moving bodies are generally difficult to simulate because the physics engine may not be able to detect some collisions. Indeed, the physics simulation operates by discretizing the motion of rigid-bodies at fixed time intervals (equal to the timestep length dt). Therefore, a fast-moving rigid-body may end up ignoring some contacts that would have happened in-between two discrete positions along this motion. This is known as the tunnelling problem.

The following example illustrates this problem. The blue and green balls are colliders attached to fast-moving rigid-bodies. The simulation is run step-by-step for clarity. It is clear that the blue ball is missing a lot of collisions, resulting in the pyramids not being hit at all! The green ball is a sensor configured in such a way that all the cubes it traverses are recolored in dark-blue. As you can see, only the pyramid at middle of the top row has some of its cubes recolored to dark-blue:

Continuous collision detection (CCD) is a technique that aims to eliminate this tunnelling problem. CCD will take into account the actual continuous motion of the rigid-bodies (and their colliders) in order to detect every single contact that must happen in their continuous trajectory. With CCD enabled, the example above behaves as we would expect: the blue collider destroys the pyramids, the green sensor recolors in dark-blue all the cubes it encounters on its continuous path:

The CCD implementation in Rapier:

• Is non-linear because it takes into account both the translational and the rotational movements of the rigid-bodies/colliders with CCD enabled. Most other physics engines use linear CCD which is slightly more efficient but yields less realistic results (because rotation are ignored).
• Works for colliders and sensor colliders (many other physics engines don't support CCD for sensors).
• Relies on motion clamping. It means that CCD will find the first time of impact between a fast-moving collider and all the other colliders. The fast-moving rigid-body will be advanced to that time of impact, and all the remaining time will be dropped for that rigid-body. In other words, its motion is "clamped" to the first time it hits something.

It is possible to let the CCD resolution run multiple simulation substeps (implying an increased computational cost) in order to reduce the amount of time removed by the clamping procedure.

Currently, our CCD implementation will work with all collider shapes except heightfields and halfspaces. Support for these two shape types will be added soon.

Large colliders support​

Before Rapier 0.7, using a collider with a very large shape (for example a 1000x100x1000 3D heightfield) would result in extremely poor performances. This would make Rapier unusable in situations where large terrains were involved.

This is now fixed in Rapier 0.7 thanks to a massive improvement of the way our Broad-Phase algorithm (a variant of Sweep-And-Prune) handles these large shapes. This also means that shapes with virtually infinite bounds (like half-spaces, aka., planes) can now be used as collider shapes without any performance issue.

What's next​

At the beginning of this year, we announced our 2021 roadmap for Rapier. So far we implemented and released all the features that were announced to be available in April, with the addition of joint motors. We have two main goals for next month:

• Const generics (min_const_generics) is now stabilized. Therefore we intend to integrate it to nalgebra. This will allow us to use regular Rust arrays [T; DIM] parametrized by integers instead of GenericArrays parametrized by type-level integers from typenum.
• Implement joint limits for the revolute joints and ball joints, allowing the user to restrict the range of possible relative orientation of the rigid-bodies attached by these joints. Joint limits are already implemented for prismatic joints.

In addition to this, we would like to:

• Improve the JS bindings of Rapier by making it possible to read contact information in JS, and by allowing the use of JS closures as PhysicsHooks.
• Start the implementation of an Inverse Kinematics algorithm (probably the FABRIK method).

We are aware that the user-guides for Rapier really need to be improved now that it has a lot of new advanced features like CCD, dominance, contact modification, etc. Unfortunately we didn't have the time to improve the docs during the past two months. We intend to start addressing this in details in May.

Thanks

We would like to thank the whole community and code contributors. In particular, thanks to the code contributors from the past two months¹:

• alec-deason
• Andlon
• aweinstock314
• bastikr
• ChristopherRabotin
• Cupnfish
• dependabot[bot]
• emilk
• extrawurst
• guissalustiano
• iMplode-nZ
• joseluis
• mookerji
• paq
• Ralith
• Recmo
• rezural
• russellb23
• taiki-e
• Waridley

• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on open-source exclusively.

Join us on discord!
You can support us on GitHub sponsors ♥

Announcing Parry 0.1.0​

During the past two months we have been working on a new crate. Say hello to Parry:

Parry is a complete remake of our ncollide crate. It is declined in four crates: parry2d, parry3d, parry2d-f64, parry3d-f64, depending on whether you want, 2D or 3D geometry, and f32 or f64 accuracy. Parry is born from the merge of most of the geometry code we had in Rapier, and some of the geometric code we ported from ncollide.

As of today, Parry is the geometric library used by our Rapier physics engine (and Rapier itself includes much less geometry code than before). It is the crate we will continue to improve in the long-term. The ncollide crate is now in passive maintenance mode.

Parry doesn't have any user-guide right now, but we intend to write one in February. Here is a table comparing the features of ncollide to the features of Parry:

In addition, Parry implements much more efficient algorithms for contact manifold generation, and a more robust 3D convex-hull implementation.

The pipelining features of ncollide like the CollisionWorld have not been included in Parry because we are still unsure where we want this to go. We don't want it to just be an inferior version of the pipelining we already have in Rapier, so we need more time to think about it.

Rapier 0.5.0​

Similar to Parry, we released two new creates for Rapier: rapier2d-f64 and rapier3d-f64. These crates are for 2D and 3D physics simulation using 64-bit floats.

Thanks to the switch to Parry, the version of 0.5.0 of Rapier comes with a fair amount of new features. Here are some of the most important ones:

• The QueryPipeline is now able to perform scene-wide shape-casts (aka. sweep tests), point projections, and shape intersection tests. Note that shape-casting is essential for writing a character controller based on kinematic bodies.
• It is now possible to use custom shapes with Rapier.
• It is now possible to use a convex polygon (in 2D) or convex polyhedron (in 3D) as a collider shape.
• It is now possible to use concave shapes after they have been decomposed into convex parts. A convenient ColliderBuilder::convex_decomposition is provided to perform an approximate convex decomposition automatically.
• It is now possible to use different rules (average, min, max, multiply) for combining two friction and restitution coefficients.
• It is now possible to scale the gravity applied to each rigid-body. Setting this scale factor to zero will effectively make the rigid-body unaffected by gravity.

You may see the CHANGELOG of Rapier for more details on other changes we made in 0.5.0.

JS bindings 0.3 for Rapier 0.5​

Because Rapier 0.5.0 contained so many new features, we updated our JS bindings to expose most of these new features. You may see the CHANGELOG of rapier.js for the details on all changes we made in 0.3.0 to expose these new features.

In addition, we released two new NPM packages for the JS bindings of rapier: @dimforge/rapier2d-compat and @dimforge/rapier3d-compat. Thanks to Manuel Adameit for making this possible. These two packages are designed to be easier to integrate into any build system (with or without bundler). Instead of containing a .js and a .wasm file, these -compat packages only contain one .js which itself contains the WASM encoded in Base64.

What's next​

At the beginning of this year, we announced our 2021 roadmap for Rapier. So far we implemented and released all the features that were announced to be available in February. So we will continue to follow this roadmap with the following objectives for next month:

• Add the support of contact modification in Rapier. This will allow you to easily simulate, e.g., conveyor belts and one-way platforms.
• Add the support for dominance in Rapier. This will make some object (typically the player modeled as a dynamic body) immune to forces applied by a selection of other objects.

These two features should actually be fairly quick to implement considering we already made some modifications to prepare for this future work. Therefore, we have a few more objective for next month:

• Improve the user-guides of Rapier and make a user-guide for Parry.
• Start the SIMD optimization work on Salva.
• Review, and publish a new crate: nalgebra-sparse for sparse matrix computation. Currently, nalgebra has a limited support of sparse matrices when its sparse feature is enabled. Thanks to the huge contribution of Andreas Longva, our sparse matrix support will be completely rewritten and extracted into a new crate.

Thanks

We would like to thank Embark Studio for being our new donor on GitHub sponsors! This helps us tremendously to sustain our 100% free and open-source work.

We would like to thank the whole community and code contributors. In particular, thanks to the code contributors from the past two months¹:

• Bobox214
• chinedufn
• Fedcomp
• maun
• rezural
• SimonWoodburyForget
• smokku
• tomitheninja
• Troels Peter Jessen

• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on open-source exclusively.

The year 2020 is over, so it is time to see what we did so far on our Rapier physics engine, and what are our plans for 2021!

Rapier in 2020​

Rapier is a free and open-source physics engine for games, animation and robotics, written entirely with the Rust programming language. It focuses on performance, portability, and (optional) cross-platform determinism. We currently provide four Rust crates for Rapier and two NPM packages:

• rapier2d is optimized for 2D physics.
• rapier3d is optimized for 3D physics.
• bevy_rapier2d for using rapier2d with the Bevy game engine.
• bevy_rapier3d for using rapier3d with the Bevy game engine.
• @dimforge/rapier2d for using the WASM version of rapier2d in your browser with JavaScript.
• @dimforge/rapier3d for using the WASM version of rapier3d in your browser with JavaScript.

We announced Rapier for the first time at the end of August 2020. Since then, we implemented some essential features like ray-casting, collision filters, access to contact information, rotation locking, and the support of shapes like cylinders and cones. We made sure our cross-platform determinism feature works properly on the new Apple M1 ARM processor. And we set up continuous benchmarking visible on the Rapier website to make sure incremental changes don't destroy performances.

During December 2020 we started working on a large refactoring of the geometry-related code existing partly inside of ncollide and partly inside of Rapier itself. This refactoring is still work-in-progress, as part of the cdl repository (the name isn't definitive, don't hesitate to share your opinion on that issue). This work will be ready for the beginning of February 2021, and will allow us to proceed with our 2021 goals.

Rapier roadmap for 2021​

We have very exciting goals for Rapier in 2021! Basically, at the end of 2021 we want Rapier to have all the features one would expect from a physics engine for games. This implies achieving feature-parity with popular C++ physics engines like Box2d, Bullet Physics, and PhysX. There is one exception though: we don't plan to support running physics simulations on the GPU yet. Though this may become a focus at some point in the next years.

Here is a list of some of the most important features we are missing today. This includes when they should become available (ETA):

Note that the contact modification feature is what will allow you to simulate one-way platforms, conveyor belts, as well as colliders with non-uniform restitution and friction coefficients.

We also intend to implement some higher-level features like a character controller and a vehicle controller. Both should be available starting October. Most games will need controllers obeying their specific custom rules, so it is impossible to design a universal solution. Our goal is to provide something useful to start with, to serve as a basis to more specific character and vehicle controllers.

Finally, the last months of 2021 should be mostly dedicated to improving documentations and fixing bugs. Our bevy plugins and JS bindings will be updated progressively through the year in order to always use the latest version of Rapier.

What about fluids simulation?​

We also develop Salva, a 2D and 3D fluids simulation engine written in Rust. Salva implements two-ways coupling with Rapier. This means that fluids from Salva can be affected by contact forces originating from Rapier, and rigid-bodies from Rapier can be affected by forces originating from fluids. Our three 2021 objectives for Salva are:

1. Cross-platform determinism: just like Rapier, we want to make Salva optionally cross-platform deterministic (under the same assumption of IEEE 754-2008 compliance).
2. Performance improvements: we need to apply to Salva what we leaned from Rapier with explicit SIMD optimizations.
3. Stability improvements: to improve the quality of the fluids simulation itself and of the two-ways coupling with Rapier.

We intend to work on the first two objectives from February to May 2021. The stability improvements will be a progressive work during the rest of the year.

As of today we don't plan to create JavaScript bindings for Salva. However, this can happen if there is enough demand from the community.

Conclusion​

The Rust game-development community is growing every days and the ecosystem is maturing steadily with major crates like the Amethyst and Bevy game engine, rust-gpu project, and many other incredible projects. By working on Rapier (and some of its dependencies) full-time we aim to provide a high-quality free, open-source, community-friendly, cross-platform game physics simulation library. The year 2021 will allow us to make Rapier reach a level of feature-completeness comparable to its main C++ alternatives.

If you would like to support us with the development of Rapier, please consider sponsoring us on GitHub sponsor. Thank again to all our existing, past, and future sponsors for making all of this possible.

Have a great year 2021! 🥳

Join us on discord and on our user forum!
You can support us on GitHub sponsors!

Rapier 0.4.0​

The version of Rapier 0.4.0 includes a few important new features:

• The ability to read contact and proximity information from the NarrowPhase. In particular, it is possible to retrieve one specific contact pair (given two collider handles), or to retrieve all the contact pairs involving one specific collider.
• The ability to lock translations and/or rotations caused by forces on a rigid-body. For example, it is possible to lock all the rotations of a rigid-body except along one or two coordinate axes, without using joints. Locking rotations has been a common feature request from our community, for games with a player modeled as a dynamic rigid-body which should not rotate.

In the following demo, you can see a blue cuboid with all its translations locked, and all its rotations locked except along the x coordinate axis. The capsule (initialized in a tilted position) on the other hand has all its rotations locked. All this is achieved without any joints:

Finally, we tested Rapier on the new Apple M1 chip. It worked very well except for some cases where the cross-platform determinism of Rapier broke. We fixed this problem, which means that enabling the enhanced-determinism of Rapier will allow you to get the exact same results for the same simulations running on, e.g., MacOs with an Apple M1 ARM processor, and Ubuntu with an AMD Ryzen 9 X86 processor!

You may see the CHANGELOG of Rapier for more details on other changes we made in Rapier 0.4.

Bevy rapier plugin 0.6.0​

We released the version 0.6.0 of our Bevy plugin for Rapier bevy_rapier. This includes:

• The automatic removal of rigid-bodies, colliders, and joints from the Rapier structures when the entity they are attached to are removed from the Bevy ECS. Thanks to Robert Swain for this contribution!
• The ability to attach multiple colliders to a single rigid-body using Bevy hierarchy: one just has to spawn an entity with a RigidBodyBuilder component, and multiple children entities with one ColliderBuild component each. Thanks to @blamelessgames for this contribution!
• The adaptive change of number of timesteps executed by the Rapier plugin at each render loop iteration is now disabled by default: you can re-enable it by setting RapierConfiguration.time_dependent_number_of_timesteps to true.

Salva 0.5.0​

The integration of Rapier with our particle-based fluids simulation engine Salva has been completed and released in Salva v0.5.0. With this release, Salva no longer supports nphysics. In the following demo, you can see three fluids from Salva: two with a high elasticity (acting like jelly), and one with no elasticity (acting like water). These fluids interact with four rigid-bodies: the ground with a Polyline shape, and three dynamic bodies with Ball, Cuboid, and Capsule shapes.

We also added to Salva the ability to retrieve all the fluid particles located inside an AABB or a shape defined in our ncollide crate. This can be useful for, e.g., spawning new particles ensuring there isn't anything there already.

Rapier.js 0.2.13​

Our Typescript/JS bindings for Rapier have been significantly improved. They have as many features as the Rust version of Rapier now! In particular, we added bindings to support:

• Heightfield and triangle-mesh colliders.
• Collision groups and solver groups.
• Rotation and/or translation locking for rigid-bodies.
• Linear and angular damping for dynamic rigid-bodies.
• The ability to remove joints.
• Prismatic and fixed joints.
• The ability to set the velocity of a rigid-body after its creation.

You may see the CHANGELOG of rapier.js for more details on other changes we made since its version 0.2.6.

What's next​

Last month, we said we would add the support of arbitrary convex polyhedron shapes during November. This has been postponed to make it part to a larger piece of work: during December (and possibly January 2021), we will work on a significant refactoring of all the geometry-related code used by Rapier.

Right now, the geometry-related code (including collision detection and ray-casting) used by Rapier is partially located inside of the Rapier crate itself, and partially inside of our ncollide crate. We intend to move all the geometry code out of Rapier completely for better separation of concerns. We are not sure yet if all this will be moved inside of ncollide, or if we will create a new crate that will be the successor of ncollide (similarly to when we created Rapier as a successor of nphysics.

This refactoring is the first step before adding some essential features, like CCD (continuous collision-detection) and the support of custom collider shapes.

Thanks

We would like to thank the whole community and code contributors. In particular, thanks to the code contributors from the past month¹:

• alec-deason
• Andlon
• AutomatonSystems
• filnet
• heinousjay
• mark-schultz
• mvlabat
• robert-hrusecky
• ryo33
• sebcrozet
• superdump
• yutannihilation
• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on open-source exclusively.

Join us on discord and on our user forum!
You can support us on GitHub sponsors!

Rapier: new shapes, collision filtering, and user-defined data​

The new version of Rapier 0.3.0 includes a few important new features:

• The support of cylinders and cones as collider shapes.
• The support of collision groups (i.e. bit masks) for deciding what pair of colliders can collide based on some hard-coded rules combining bit masks. These collision groups can also be used for deciding what collider a ray should or shouldn't hit during a ray-cast.

• The support of collision filters (i.e. custom callbacks) for deciding what pair of colliders can collide based on user-defined trait-objects. This can also be used to allow the computation of contacts between two colliders attached to non-dynamic rigid-bodies.
• The ability to set the mass, center-of-mass, and angular inertia, of a rigid-body at creation time.
• The support of linear and angular damping for progressively slowing down a rigid-body. This is often used to simulate some sort of air friction.
• The addition of user-defined data stored into each rigid-bodies and each collider. This user-defined data is specified as a u128 which value can be freely set by the user. This can for example be used to store an Entity identifier from and ECS.

Another notable change is that shapes are no longer represented as an enum. Instead, they are represented as trait-objects. This is a first change towards making it possible to support user-defined shapes for colliders.

You may see the CHANGELOG of Rapier for more details on other changes we made in Rapier 0.3.

bevy_rapier: version 0.4.0​

We released the version 0.4.0 of our Bevy plugin for Rapier bevy_rapier. This includes:

• The use of the latest version of Rapier 0.3 with the addition of an InteractionPairFilters resource that may be modified in order to register user-defined collision pair filters and proximity pair filters.
• The implementation of rigid-body position interpolation for rendering, thanks to the contribution from Robert Swain. This follows the advices of the popular blog post by Glenn Fiedler: https://www.gafferongames.com/post/fix_your_timestep/

Salva: work-in-progress integration with Rapier​

We started the integration of Rapier with Salva. With the rapier branch of the Salva repository, it is possible to have two-way coupling between Rapier rigid-bodies and Salva fluids. This means that Rapier rigid-bodies with colliders attached will apply forces to fluids they interact with, and fluids with also be able to apply forces to rigid-bodies from Rapier.

This integration will likely be released at the end of November.

What's next​

During November, we will mostly focus on:

1. Adding the support of arbitrary convex polyhedra colliders.
2. Improving the JavaScript bindings so that they can cover most of the features of the Rust version. Currently, the JavaScript bindings are lacking access to a lot of recently introduced features.
3. Completing the Rapier/Salva integration.

Thanks

We would like to thank the whole community and contributors. In particular, thanks to the contributors from the past month¹:

• avl
• Bobox214
• filnet
• msmorgan
• neachdainn
• sdleffler
• sebcrozet
• superdump
• Terence
• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on open-source exclusively.

Join us on discord and on our user forum!
Support us on GitHub sponsors.

Rapier: continuous benchmarking​

Here are two facts:

1. Rapier is still in early development and lacks lots of features.
2. By adding new features to Rapier, we take the risk of making it slower.

But we want to make sure the addition of new features don't degrade performances of Rapier. This is why we stated working on a continous-benchmarking setup that will allow us to see performance impact of each pull-request targeting the master branch and each commit landing on the master branch.

Each relevant CI pipeline triggers the execution of a set of stress-test we used to compare Rapier to other physics engine when we first announced Rapier. Because CI runners can have unreliable performances, we are running these benchmarks on a dedicated server that does nothing but compile the code, run the benchmarks, and upload the result to a database. Once these benchmarks finished, they can be seen in the Rapier website there. In that page, we can select what commit we want to compare with what other commit. We can also include other physics engines (PhysX and nphysics) for comparison.

Right now, only the 3D version of Rapier is included on these benchmarks. We will add the 2D version in the future. The 3D version alone already allows us to spot any performance regression between two versions of Rapier because the 2D version of Rapier uses mostly the same code. The code of our benchmark setup can be found in our dimforge-bench repository.

Rapier: ray-casting support​

One of the most important features Rapier was missing is ray-casting, which can be essential for, e.g., writing character controllers.

Ray-casting is now supported by Rapier, but in a very different way than what we did in nphysics. Here we have a new stucture called QueryPipeline which will be responsible for executing all scene-wide queries. Only ray-cast is implemented right now, but it will also support queries like convex-casting, point-projection, or volume-interferences in the future.

The QueryPipeline can be used alongside the PhysicsPipeline, or even without the PhysicsPipeline if you don't care about physics simulation and just want to run some geometic queries. Just like the physics pipeline .step() method, the query pipeline has an .update() method that updates its internal state. This update method may not necessarily be executed at each iteration of the game loop. So you are not forced to update it if you don't do queries for some times.

The QueryPipeline uses its own acceleration structure internally, completely independently from the BroadPhase and NarrowPhase. Right now this structure is re-built from scratch each time the quey pipeline is updated. In the future, it will be updated incrementally for better performances.

You may see the CHANGELOG of Rapier for more details on other changes we made in Rapier 0.2.

Rapier.js: new bindings, less memory management​

We worked on brand new JavaScript bindings for Rapier. In the version 0.1, the bindings were automatically generated by wasm-bindgen. This is useful but has its limitations including:

• The necessity for the end-user to do manual memory management (by calling .free() on objects returned by the bindings).
• Places where the API does not feel quite idiomatic. In particular, we couldn't really apply the builder pattern because this would have resulted in wasm-bindgen generating a new JS objects each time a property of the builder is changed.

The new version 0.2 add a layer of Typescript wrappers on top of the bindings generated by wasm-bindgen. This extra layer takes care of the memory management for all transient objects (vectors, rotations, rigid-bodies, colliders, etc.) This means that the end-user only has to call .free() on:

• World and EventQueue.
• Or, if the World is not used directly, on RigidBodySet, ColliderSet, JointSet, IntegrationParameters, PhysicsPipeline, QueryPipeline, SerializationPipeline, and EventQueue.

This version 0.2 of @dimforge/rapier2d and @dimforge/rapier3d also makes the API closer to Rapier's by defining each part of the physics world individually.

Finally, the ColliderDesc and RigidBodyDesc used for creating colliders and rigid-bodies now use the builder-pattern because they are now completely implemented in Typescript.

See the CHANGELOG of rapier.js of the version 0.2.1 for details on all the changes we made.

bevy_rapier: version 0.3.1​

We released the version 0.3.1 of our Bevy plugin for Rapier bevy_rapier. This includes:

• The use of the latest version of Rapier 0.2 with the automatic addition (and update) of the QueryPipeline as a Bevy component.
• The update to Bevy 0.2 thanks to the great contributions from CleanCut.
• The replacement of the Gravity and RapierPhysicsScale resources by a RapierConfiguration resource. This new resource will also allow you to temporarily pause the physics simulation by setting its physics_pipeline_active flag to false. We thank Bobox214 for these great contributions.

salva: a progressive rewrite​

We started working on Salva, our fluids simulation library, in order to:

• Remove the generics wrt. the scalar type. This will allow faster incremental compilation times of end-user code, and allow the compilation of Salva with optimizations while keeping the end-user binary in debug mode.
• Add SIMD optimizations, applying what we learned with Rapier.
• Add coupling between fluids from Salva and rigid-bodies/colliders from Rapier.

Right now we only worked the first step, which is removing the generics wrt. the scalar type. We will work on the rest progressively, though it is not our top priority right now.

What's next​

There are at least two important Rapier features we intend to work on during October:

1. The support for cylinder colliders. Not all physics engines support cylinders: nphysics and PhysX don't! But they can be extremely valuable for simulating objects like, e.g., wheels. The typical workaround is to represent them as polyhedron, but this can make the simulation less accurate because of the approximation introducing "bumps".
2. The support for collision filtering. We want to make it possible for the user to prevent collisions between some pair of shapes. The typical way of handling this is through collision groups (with bit masks) and this is the first approach we will work on. We will consider other approaches as well based on community feedbacks on issues #2, #3, #15, and #24.

Thanks

We would like to thank the whole community and contributors. In particular, thanks to the contributors from the past two months¹:

• Bobox214
• CleanCut
• ColonelThirtyTwo
• farnoy
• FenQiDian
• neachdainn
• sebcrozet
• skairunner
• toasteater
• zalo
• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on open-source exclusively.

This post will be quite long, so here are all the different sections:

• Presenting Rapier
• Reaching out to other communities: Bevy and JavaScript
• Feature comparison with nphysics
• Benchmarks
  • 3D Benchmark: Rapier vs. PhysX vs. nphysics
  • 3D Benchmark: Conclusion
  • 2D Benchmark: Rapier vs. Box2D vs. nphysics
  • 2D Benchmark: Conclusion
  • Running the benchmarks yourself
• Conclusion

Presenting Rapier​

Rapier is the successor of nphysics and focuses on performance first. Just like nphysics it is split into two crates: rapier2d and rapier3d for 2D and 3D physics respectively. It is designed to be fast and multithreaded right from the beginning. It is also designed to require less incremental compilation times because the data structures it defines are not generic.

In release mode, Rapier runs 5 to 8 times faster than nphysics , making it close to the performance of (the CPU version of) NVidia PhysX and slightly faster than Box2D as you will see in the benchmark sections. Rapier is only at its beginning, so many features are still missing. However some performance optimizations like parallelism, and SIMD have been integrated right from the start.

There already are a few key features that makes Rapier stand out. Since they may affect compilation times and/or performance, they are disabled by default and need to be enabled explicitly through cargo features:

1. Serialization: if the serde-serialize feature of Rapier is enabled, every physics component will be serializable using serde. This means that you can take a deep snapshot of the physics state and restore it later. This snapshot can even be saved on disk or sent through network.
2. Cross-platform determinism: if the enhanced-determinism feature of Rapier is enabled, it will behave in a bit-level cross-platform deterministic way in all platforms that comply with the IEEE 754-2008 floating point standard. This means that if you run the same simulation with the same initial states on two different machines (or browsers) you will get the exact same results. Here "bit-level" determinism means that if you serialize the physics state after the same number of timesteps on two different machines, you will obtain the exact same byte array for both: you may compute a checksum of both snapshots and they will be identical. All this doesn't apply to platforms with pointer size smaller than 32-bit, and on platforms that don't comply to IEEE 754-2008 strictly.

See that section for a comparison between Rapier and nphysics features.

Reaching out to other communities: Bevy and JavaScript​

Writing a physics engine is hard. There are not a lot of choices out there and most of them are written in C++. With nphysics we wanted to provide an open-source 100% rust physics solution for the Rust community. With Rapier we want to go one step further by contributing to as many communities in need of a physics engine as we can. This is why we are starting, right at the beginning of the Rapier story, by providing:

• Official JavaScript bindings for the WASM version of Rapier. These binding are generated using wasm_bindgen and are published to NPM as the packages @dimforge/rapier3d and @dimforge/rapier2d. While multiple physics solutions already exist for JavaScript they are either slow (because they are manually written in JS like cannon.js or oimo.js), or not officially maintained by their original developers (because they are ported from C++ using Emscripten, like box2d.wasm, ammo.wasm, or physx.wasm). By providing official wasm builds and JS bindings, we are making sure to provide the best support, documentation, and continuous updates to the JS community.
• Official plugins for the Bevy game engine. They are available as the bevy_rapier2d and bevy_rapier3d crates. The Bevy game engine has recently been released as an efficient, fast-to-compile, and easy to use, data-oriented game engine. It is still at its early state and is lacking any physics feature. We believe physics support is a very high-value feature to have in a game engine. By providing official plugins we want to make sure the Bevy community can benefit from the Rapier physics engines quickly and easily.

There are so many more communities we would like to contribute to but don't have manpower to support all of them just now. Other integrations and languages will come in the future.

We also plan to create official plugins for the Amethyst game engine but have not started yet. We are waiting for the migration of Amethyst to the legion ECS solution before starting to work on this.

Feature comparison with nphysics​

Rapier does not have as many features as nphysics yet, but it also has a few features nphysics does not have. Here are comparative tables of both physics engines:

Today nphysics is more mature than Rapier. Our first goal during the next few months is to bring Rapier at the same level as nphysics featurewise, while keeping the significant performance improvements and better accuracy.

Benchmarks​

Alright, we claimed that Rapier is nearly as fast as the CPU version of PhysX, 5 to 10 times faster than nphysics, and slightly faster than Box2D. It is now time to prove these claims using benchmarks.

In the subsequent benchmarks we ran a set of stress tests using four different physics engines:

1. Rapier using our rapier3d crate for 3D and rapier2d for 2D.
2. PhysX 4 using the physx crate.
3. Box2d using the wrapped2d crate.
4. nphysics using our nphysics3d crate for 3D and nphysics2d for 2D

Independently of the chosen physics engine, all scenes are always initialized in the exact same way (same bodies, same colliders at the same initial positions) and with the following parameters:

• Rust compiler and flags: rustc 1.46.0-nightly, --release, --features simd-nightly, codegen-units = 1.
• Timestep length: 0.016 (i.e. 16 milliseconds).
• Number of velocity iterations: 4 for Rapier, nphysics, and Box2D. 1 for PhysX.
• Number of position iterations: 1 from Rapier, nphysics, and Box2D. 4 for PhysX.
• Targets: native CPU (WebAssembly versions and PhysX on GPU have not been benchmarked.)
• Solvers: variations of PGS. (The PhysX 4.0 TGS solver has not been benchmarked. We used the default ePGS solver.)
• Number of threads: 1.

Each 3D benchmark is run on two different machines because we observed performance differences between PhysX and Rapier depending on the processor:

1. A desktop computer, running Ubuntu, equipped with an AMD Ryzen 9 3900X CPU, 3.8GHz.
2. A MacBook Pro (plugged to a power outlet), running Mac OS, equipped with an Intel Core i7 7920HQ, 3.1GHz.

The 2D benchmarks are run only on the AMD Ryzen 9 3900X CPU (the relative performance remain the same with the Inter Core i7 CPU).

3D Benchmark: Rapier vs. PhysX vs. nphysics​

A few notes are in order regarding PhysX in this benchmark. First, we don't use the same number of iterations for Rapier and PhysX. For Rapier and nphysics we use 4 velocity iterations and 1 position iteration. It is the other way round for PhysX: 1 velocity iteration and 4 position iterations. This is the most sensible configuration because:

• PhysX developers advise to increase the number of position iterations for better stability, and leave to 1 the number of velocity iterations.
• PhysX itself (independently from this benchmark) uses 1 velocity iteration and 4 position iterations by default. It yields more stable simulations than using 4 velocity and 1 position without performance difference.
• Rapier and nphysics use a solver different from PhysX's. With our solver, it is recommended to increase the number of velocity iterations instead of position iterations, and leave the number of position iterations to 1.

The PhysX benchmarks will include two performance curves:

1. One performance curve using their default ePATH friction model. This is a simplified friction model, faster to compute, but less realistic. Rapier and nphysics don't implement a similar model yet.
2. One performance curve using their eTWO_DIRECTIONAL friction model. This is similar to the friction model used by Rapier and nphysics.

8.000 stacked balls​

In this benchmark there are 8000 balls falling on a ground also composed of balls. In the end, they form 400 independent small stacks of balls.

3.000 falling boxes​

In this benchmark, there are about 3000 small cubes falling on a large cube floor in a completely unordered way.

Pyramid of 4.900 boxes​

In this benchmark, there is a set of 4900 boxes falling in such a way that they form a single large pyramid in the end.

Triangle mesh with 1.500 falling boxes and balls​

In this benchmark, the floor is modelled as a triangle mesh composed of 800 triangles. There are 1500 small boxes and 1500 small balls falling on this mesh.

KEVA planks tower with 5.320 planks​

In this benchmark, 5230 rectangular rigid bodies are used to form a tower, much like what can be achieved with real-world KEVA wood planks. During the simulation, the tower breaks down to end up with a large pile. Note that the tower breaks down because only 4 velocity iterations are used for this simulation. With about 15 velocity iterations, the tower would remain stable when using Rapier.

19.800 interconnected ball joints​

In this benchmark, we have little less than 20.000 ball joints (aka. spherical joints). These joint connect rigid bodies in such a way that we end up with a single large fabric-like sheet.

20.000 fixed joints​

In this benchmark, we have 20.000 fixed joints keeping all balls from moving wrt. each other.

8.000 revolute joints​

In this benchmark, we have 8.000 revolute joints attached in a way that forms several independent chains.

3D Benchmark: Conclusion​

From these benchmark we can see that:

• PhysX and Rapier are both 4 to 8 times faster than nphysics. The gap would be greater (5 to 10 times faster) with multithreading enabled.
• Rapier and PhysX have close performance. When targeting the Ryzen 9 CPU, Rapier ends up being slightly faster in several cases. However, when targeting the Intel CPU PhysX ends up being slightly faster than Rapier.
• In terms of simulation quality, PhysX and Rapier are quite similar. Joints from PhysX look slightly stiffer because convergence for fixed joints are more quickly achieved. Joints from Rapier and PhysX are both much more stable than joint constraints from nphysics.

2D Benchmark: Rapier vs. Box2D vs. nphysics​

12.500 stacked balls​

In this benchmark there are 12.500 balls falling on a ground composed of balls. The Box2D times are very noisy here. We suspect this is caused by their broad-phase implementation.

3.380 falling boxes​

In this benchmark, there are about 3.380 small cubes falling on a large cubic "cup" in a completely unordered way.

Pyramid of 5.050 boxes​

In this benchmark, there is a set of 5.050 boxes falling in such a way that they form a single large pyramid in the end.

19.800 interconnected ball joints​

In this benchmark, we have little less than 20.000 ball joints (which are the same as revolute joints in 2D). These joint connect rigid bodies in such a way that we end up with a single large fabric-like sheet. The performance of Box2D go really crazy on this benchmark because its simulation breaks down (lack of numerical stability).

28.840 fixed joints​

In this benchmark, we have 28.840 fixed joints keeping all balls from moving wrt. each other.

12.500 prismatic joints​

In this benchmark, we have 12.500 prismatic joints attached in a way that forms several independent chains. Lower joint limits have been enabled.

2D Benchmark: Conclusion​

From these benchmarks we can see that.

• Rapier is generally slightly faster than Box2d in these benchmarks, especially when joints are involved.
• Joint constraints from Rapier are much more stable than Box2d. In particular, prismatic joints from Box2d are subject to lots of jitter, and the ball joints scenario completely exploded.

Running the benchmarks yourself​

If you would like to see how these benchmarks perform on your own computer, you may run them manually:

• For 2D benchmarks, execute the command cargo run --release --features simd-nightly --features other-backends -- --bench on the examples2d directory of the rapier repository.
• For 3D benchmarks, execute the command cargo run --release --features simd-nightly --features other-backends -- --bench on the examples3d directory of the rapier repository.

If you are using a stable version of the Rust compiler, you will have to replace --features simd-nightly by --features simd-stable so it compiles properly.

The benchmark will run and the outputs will be writen as CSV files created on the current directory. There will be one CSV file per simulated scenario. A CSV file will contain multiple columns, one per running physics engine.

Conclusion​

The development of Rapier started only five months ago and already shows very promising results. Its performance make it a great 100% Rust alternative to PhysX as long as you don't need a GPU-based solution. For 2D it is often slightly better than Box2D performance-wise, but it still lacks some features to be able to completely replace it. Compared to nphysics, Rapier is at a whole different level both in terms of performance and joint constraint stability. Finally, thanks to its JavaScript bindings, Rapier is both the most efficient and numerically stable Web physics engine available on NPM.

Optional features like snapshotting and bit-level cross-platform determinism make Rapier appealing for multiplayer and collaborative uses.

During the next ~8 months, our goal will be to implement in Rapier all the features that currently exist on nphysics, including CCD, reduced-coordinates joints, and soft-bodies. If you need some specific features (even that did not exist on nphysics), please feel free to contact us.

If you would like to support us with the development of Rapier, please consider sponsoring us on GitHub sponsor.

Thank you for your support!

Dimforge is a French EURL (Entreprise Unipersonnelle à Responsabilité Limitée), which can be translated to "single-member limited liability company". It aims to be an open-source company which develops high-quality crates for linear algebra and physics simulation. The decision to create Dimforge comes from both personal and communitarial motivations:

• Creating this company is a way for me to further show my dedication to the Open-Source Rust community by strengthening my involvement through a legal entity. I always desired to work on my Open-Source projects full-time. This company creation is one step further towards making this happen in a near future.
• I will be able to setup partnerships with other companies to fund the development of new features, and perhaps setup paid support plans.
• If this becomes financially possible in the future, I will hire other Rust developers to either work on my current projects, or on new projects they like if they are relevant to our objectives.

How is Dimforge funded?​

Right now, Dimforge is entirely funded by me. In the short term I see the main sources of revenue for the company to be:

• Donation crowdfunding through GitHub sponsor.
• Development of a partnership with one of the industrial users of Rapier (more about this new project in the last section).

If you supported me, @sebcrozet directly through GitHub sponsor or Patreon, thank you again! None of this would be possible without your help! Please consider switching to the Dimforge GitHub sponsor account. That would be extremely helpful, especially for the first few years after this creation.

I will close my personal Patreon and GitHub Sponsor account at the end of this month.

What does this change?​

From your point of view, as a end-user, this does not change anything. You can still use our crates freely. This should actually reassure you that I am deeply committed to these crates, and will continue to maintain and improve them for a long time in the future. There is however one exception: nphysics.

I you read Dimforge's landing page thoroughly, you may be surprised to see that nphysics, the 2D and 3D physics engine I have been developing for the past 6 years, is now in passive maintenance mode. And it is even more surprising considering I made a post last year showing how I intended to develop nphysics for several years to come.

Did I lie? No. My desire to continue the development of nphysics was real, and still is but in a different form. nphysics has a fair share of virtues and problems. Some of them are plain unsolvable considering the current design of nphysics. Performance and lack of serialization for example are two recurring problems. This is why I am stopping the active development of nphysics in order to work on its much needed successor Rapier!

Rapier: the flagship project of Dimforge​

Rapier is the new physics engine I have been working on secretly during the past 5 months. You can see its work-in-progress website there: https://rapier.rs.

Just like nphysics it is split into two crates: rapier2d and rapier3d for 2D and 3D physics respectively. It is designed to be fast and multithreaded right from the beginning. It is also designed to require less incremental compilation times because the data structures it defines are not generic.

Rapier runs 5 to 10 times faster than nphysics, making it close to the performance of (the CPU version of) NVidia PhysX and slightly faster than Box2D.

In addition, Rapier aims to be cross-platform, including web targets. That's why I am maintaining JavaScript bindings right from the beginning. NPM packages already exist: @dimforge/rapier3d and @dimforge/rapier2d.

I am still at the beginning of the implementation of Rapier though, so many features are still missing. However some long-requested features like (optional) parallelism, and (optional) SIMD have already been integrated to ensure their long-term maintenance and improvement.

There already are a few key features that makes Rapier stand out. Since they may affect compilation times and/or performance, they are disabled by default and need to be enabled explicitly through cargo features. They are however both enabled on our official NPM packages.

1. Serialization: every physics component is serializable using serde, meaning you can take a deep snapshot of the physics state and restore it later. This snapshot can even be saved on disk or sent through network.
2. Cross-platform determinism: if the enhanced-determinism feature of Rapier is enabled, you it will behave in a bit-level cross-platform deterministic way in all platforms that comply with the IEEE 754-2008 floating point standard. This means that if you run the same simulation with the same initial states on two different machines (or on a browser) you will get the exact same results. Here "bit-level" determinism means that if you serialize the physics state after the same number of timesteps on two different machines, you will obtain the exact same byte array for both: you may compute a checksum of both snapshots and they will match. All this doesn't apply to 8- and 16-bits platforms, and on platforms that don't comply to IEEE 754-2008 strictly.

The start of a new adventure​

This creation marks a milestone in my personal life, and it strengthens my dedication to Rust Open-Source development. This new adventure is not without risks but also has its fair share of opportunities. I am convinced that Rust, the language, is doomed to succeed, and that it has one of the best community one can hope for. So it is a privilege to be part of this community and do my best to provide high-quality FOSS crates.

Thank you for your support!

Join us on discord and on our user forum!

Starting with the version 0.16, nphysics2d and nphysics3d can be used with fixed-point numbers as their scalar type. This allows you to use fixed-point numbers from the simba crate (which wraps fixed-points numbers from the fixed crate) as the scalar type N of all the nphysics entities. This will result in cross-platform determinism of the simulation.

This work was made possible by a GitHub sponsorship dedicated to the implementation of this feature.

Cross-platform determinism means that two scenes initialized in the exact same ways (including the same insertion order of bodies/colliders) on two different machines/platforms will result in the exact same simulation result. This is generally not possible with conventional hardware-accelerated floating point numbers like f32 or f64 because different processors may process float operations with different levels of internal accuracy. This problem is avoided by using fixed-point numbers. In order to make the simulation work with fixed-point numbers it is necessary to:

1. Enable the improved_fixed_point_support cargo feature of nphysics. This will enable some numerical stability improvements that can have a slight negative performance impact when enabled. They are necessary for fixed-point numbers to work.
2. Enable the partial_fixed_point_support cargo feature of simba, otherwise you won't have access to the simba fixed-point types.
3. Use at least 24 bits for the decimal part of the number. I tested mostly with simba::scalar::FixedI40F24 and simba::scalar::FixedI32F32.
4. Be careful with the size of the colliders and the mass of the bodies. These should not be too large or too small to avoid overflow or underflow of the fixed-point numbers. The exact valid range depends on the actual fixed-point numbers you use. See the nphysics demos on the examples2d and examples3d directories to get an idea of what dimensions work. It is possible to experiment with various scalar types on the nphysics demos by changing the type alias type Real = ...; on the all_examples2.rs and all_examples3.rs demo files.

The support of fixed-point numbers is considered experimental because it needs more testing in real-world applications. So far most of the testing was done with the nphysics demos. Any non-deterministic behavior (even cross-platform) will be considered a bug when using fixed-point numbers.

About the new cordic crate​

In order to make nphysics work with fixed-points numbers, it was necessary to implement various special function, namely sin, cos, tan, asin, acos, atan, atan2, exp, sqrt for fixed-point numbers. They have been implemented using algorithms based on the CORDIC method, available on the new cordic crate.

Fixed-point compatibility of simba, ncollide, and nalgebra​

• The simba crate has the partial_fixed_point_support cargo feature. This will allow you to use all the simba::scalar::Fixed* types. These aliases follow the naming convention of the type the wrap on the fixed crate. Note however that this fixed-point number support is only partial. Even though the simba::scalar::RealField trait is implemented for these numbers, most of their special functions are just filled with undefined!(). The methods that are not undefined!() are these needed by nphysics itself and implemented in the new cordic crate.
• The ncollide2d/ncollide3 crates now have an improved_fixed_point_support cargo feature is well. This will also enable some numerical stability improvements for fixed-point numbers.

Note that this also means that nalgebra itself is now compatible with fixed-point numbers. Most transformation types, as well as matrix decompositions will work too (as long as your input do not cause any overflow/underflow).

Other changes unrelated to deterministic physics

Changes in nalgebra​

A few features were added to nalgebra v0.21.1:

• It is now possible to build a Cholesky decomposition without checking that its input is positive-definite using Choleksy::new_unchecked. Not having these checks also remove all branching from the Cholesky decomposition, making it suitable to the use with SIMD types for, e.g., building the Cholesky decompositions of four matrices at once using a Matrix4<simba::simd::f32x4>.
• Thanks to the contribution of m-ou-se, the Default trait is now implemented for matrices, and quaternions. They are all filled with zeros, except for UnitQuaternion which is initialized with the identity.
• Thanks to the contribution of fredrik-jansson-se, it is now posible to compute the matrix exponential with matrix.exp().

Changes in the nphysics​

• It is now possible to retrieve the number of BodyPart that compose a Body using body.num_parts(). This allows you to iterate through all the parts on a loop like for i in 0..body.num_parts() { let part = body.part(i); ... }.
• Thanks to the contribution of m-ou-se the testbeds of nphysics nphysics_testbed2d and nphysics_testbed3d can now be used with scalar types other than f32.

Thanks

I would like to thank the whole community and contributors. In particular, thanks to the contributors from the past two months¹:

• chiache-msft
• fredrik-jansson-se
• Hodapp87
• jannickj
• LiquidityC
• m-ou-se
• mxxo
• Nateckert
• oisincar
• philippeitis
• ProfFan
• sebcrozet

• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new patrons supporting me, sebcrozet, the lead developer of the current crates part of this organization on patreon or GitHub sponsors! This help is greatly appreciated and allows me do spend a significant amount of time developing those crates.

Join us on discord and on our user forum!

I am thrilled to announce the release of the new simba crate! Simba is a crate that defines a set of traits for writing code that can be generic with regard to the number of lanes of the input numeric value. Those traits are implemented by f32, u32, i16, bool as well as SIMD types like f32x4, u32x8, i16x2, etc. Here is a diagram showing most of the traits of Simba:

Each solid arrow illustrates trait inheritance, e.g., SimdRealField is a subtrait of SimdSigned. Dashed arrows illustrate blanket impls, e.g., any type implementing RealField also automatically implements SimdRealField. All the Simd* traits (as well as Field) are implemented for SIMD types like f32x8, f64x4 as well as scalar types like f32 and f64. Non-Simd traits on the other hand (except Field) are only implemented for scalar types. by scalar types like f32 and f64 (and the blanket impls make them implement the Simd* traits too). Simba is both much simpler and more easily extensible than our alga crate which has a much deeper and complex trait hierarchy.

One example of use-case applied by the nalgebra crate is to define generic methods like vector normalization that will work for Vector3<f32> as well as Vector3<f32x4>. This makes it easier leverage the power of SIMD Array-of-Struct-of-Array (AoSoA) with less code duplication.

Two optional cargo features can be enabled:​

• With the packed_simd feature enabled, the simba::simd module will export several SIMD types like f32x2, f64x4, i32i8, u16i16, etc. There types are wrappers around the SIMD types from the packed_simd crate. This requires a nightly compiler.
• With the wide feature enabled, the simba::simd module will export the WideF32x4 and WideBoolF32x4 types. These types are wrapper around the wide::f32x4 type from the wide crate. This will work with both stable and nightly compilers.

If none of those features are enabled, simba will define all the scalar and SIMD traits (and will be compatible with both stable an nightly compilers). However, the SIMD traits won't be implemented for any SIMD types. Therefore library developers writing generic code are not required to enable those features. However, users who will pick concrete SIMD numeric types are recommended to:

• Enable the packed_simd feature and use the types like simba::simd::{f32x4, i32x2, ...} if they want the most complete platform/numeric type coverage, and can afford to use a nightly compiler.
• Enable the wide feature and use the simba::simd::{WideF32x4, WideBoolF32x4} if they only need 4-lanes 32-bits floats, and can't afford to use a nightly compiler.

Use of the Simba crate by nalgebra 0.21

The use of Simba in the new version of nalgebra is what makes it possible to leverage the strengths of SIMD AoSoA to obtain great performance boosts:

Refer to the full benchmark for details about those numbers and comparison with other linear algebra crates.

• Before the version 0.21, nalgebra relied on the traits from the alga crate (e.g. RealField, ComplexField, etc). Those traits have now been replaced by the traits from the simba crate which have similar names. For example the equivalent of alga::general::{RealField, ComplexField} is simba::scalar::{RealField, ComplexField}.
• In many places, you will see the SimdRealField or SimdComplexField traits which are slightly more general than RealField and ComplexField because they are also implemented for SIMD types like f32x4, f64x2, etc.
• The dependency to alga is now completely optional. All the implementations of alga traits are still present, though the alga cargo feature must be enabled to get them.

The linalg and sparse modules don't use the SimdRealField and SimdComplexField traits at all. This is because the algorithms they implement are full of branching, and thus are difficult to rewrite in an SIMD AoSoA friendly manner. Finally, note that:

1. If you are not using any generics with nalgebra, chances are that your code will still compile as-is.
2. If you are using some generics, chances are that simply replacing all occurrences of alga::general::{RealField, ComplexField} by simba::scalar::{RealField, ComplexField} will likely do the trick.

The status of alga

Starting today, the alga crate switches to passive maintenance mode. Unfortunately, the traits structure of alga is very complicated, and makes it hardly accessible to users without strong knowledge about set theory. Moreover it does not seem to be much used within the community. Thoses are other reasons why nalgebra is now relies on traits from simba instead of alga.

Thanks

We would like to thank the whole community and contributors. In particular, thanks to the contributors from the past month¹:

• Aaron1011
• Andlon
• DasEtwas
• ProfFan
• SBrandeis
• alexbool
• aweinstock314
• azriel91
• cuviper
• daingun
• eclipseo
• hmunozb
• ignatenkobrain
• ilya-epifanov
• Kristof Lünenschloß
• kubkon
• m-ou-se
• nestordemeure
• nnmm
• sebcrozet
• waywardmonkeys

• Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
• Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!

Finally, thanks to all the former, current and new patrons supporting me, sebcrozet, the lead developer of the current crates part of this organization on patreon or GitHub sponsors! This help is greatly appreciated and allows me do spend a significant amount of time developing those crates.

In this post I'd like to introduce the next major change that will be released in nalgebra at the end of this month (March 2020). This change is about adding the support for SIMD AoSoA to nalgebra. I'll explain what I mean by SIMD AoSoA (Array-of-Structures-of-Arrays with explicit SIMD) and how it relates to SoA (Structure-of-Arrays) and AoS (Array-of-Structures). To give you an idea, SIMD AoSoA is actually what the recent ultraviolet crate has been using to achieve its amazing performance.

Here is a benchmark including the next (to-be-released) version of nalgebra. The best times within a 2.5% range of the minimum of each row are highlighted. Here, the ultraviolet column uses the non-wide types of ultraviolet (Vec2, Mat2, Isometry3, etc.) while the column ultraviolet_f32x4 uses its wide types (Wec2, Wat2, WIsometry3, etc.):

Please see the last section of this post for a more comprehensive benchmark (including the use of f32x8 and f32x16 with nalgebra) and details about the benchmark conditions.

What is AoSoA with explicit SIMD?​

The data layout I call here AoSoA with explicit SIMD (or SIMD AoSoA for short) is a straightforward variant of the AoSoA (Array-of-Structures-of-Arrays) layout which is itself a combination of two more common layouts: SoA (Structure-of-Arrays) and AoS (Array-of-Structures). So let's see what is the difference of all those layouts with the simple example using 3D vectors (vectors with three components x, y, z): given two arrays of 1024 3D vectors, we want to compute the sum of each pairs of vectors with the same index.

Note: The explanations here are merely a superficial introduction of the AoS vs SoA vs AoSoA concepts. I just want to explain some of the differences and some of their advantages/disadvantages. I won't give any detailed analysis of the generated assembly code after compiling the examples provided. The benchmarks at the end of this post will show the performance difference between AoS and SIMD AoSoA. You may be interested by that article too.

Note 2: For iterating through the arrays, I'll be using explicit indices for i in 0..1024 instead of iterators. This is on purpose to make the number of iterations explicit and to make the code easier to understand for readers that are not used to Rust iterators.

Array-of-Structures (AoS)​

The Array-of-Structures layout is the most common and intuitive layout. You define a structure as the aggregation of all its fields. And multiple structures of the same type are simply stored one after the other inside of an array. Here is what our 3D vector would look like:

struct Vector3 {
    x: f32,
    y: f32,
    z: f32
}

/// An array containing 1024 vectors.
type SetOfVector3 = [Vector3; 1024];

fn add_arrays_of_vectors(a: &mut SetOfVector3, b: &SetOfVector3) {
    for i in 0..1024 {
        va.x += vb.x;
        va.y += vb.y;
        va.z += vb.z;
    }
}

Here, we need to iterate through each pair of vectors, one from each set, and execute our sum. This is arguably the most intuitive way of doing this, but not necessarily the most efficient. All Rust linear algebra crates from this benchmark can work with this layout.

Pros of AoS​

• It is easy to read/write/modify each vector individually.
• AoS are generally easier to reason with when designing algorithms.

Cons of AoS​

• Not as efficient as other layouts when working on a large number of elements of the same type.

Structure-of-Arrays (SoA)​

The Structure-of-Arrays layout is less intuitive to work with because it will store each field of a struct into its own array. Thus, our set of vector set would look like that:

struct SetOfVector3 {
    x: [f32; 1024],
    y: [f32; 1024],
    z: [f32; 1024],
}

These is no explicit Vector3 structure here because they are all packed into the array. Accessing the components of the i-th vector of the set means we access set.x[i], set.y[i] and set.z[i]. With this structure, our vector sum becomes the following:

fn add_arrays_of_vectors(a: &mut SetOfVector3, b: &SetOfVector3) {
    for i in 0..1024 {
        a.x[i] += b.x[i];
    }

    for i in 0..1024 {
        a.y[i] += b.y[i];
    }

    for i in 0..1024 {
        a.z[i] += b.z[i];
    }
}

There is more code here than in our AoS example because we need to iterate on each components individually. However this will be much more efficient than our AoS approach because this is extremely vectorization-friendly: the compiler will be able to group consecutive vector entries for each component, and use SIMD instructions to perform the 2, 4, 8, or even 16 additions at a time instead of a single one.

Pros of SoA​

• Extremely fast.

Cons of SoA​

• Algorithms need to be explicitly designed with SoA in mind to be efficient.
• Manipulating vectors individually is more difficult and can be less efficient than AoS.
• It is more difficult to think in terms of SoA than in terms of AoS.

Array-of-Structures-of-Arrays (AoSoA)​

Now let's combine both SoA and AoS to obtain: Array-of-Structures-of-Arrays (AoSoA). The idea is to first define a wide 3D vector, i.e., we pack several vectors into a single struct:

struct WideVector3 {
    x: [f32; 4],
    y: [f32; 4],
    z: [f32; 4],
}

The term wide 3D vector is inspired from the terminology used in the ultraviolet crate's documentation. Here, our WideVector3 actually represents 4 vectors laid out in a SoA fashion. If we want our set of vector to contain more than just 4 vectors, we can define an array of WideVector3 (so we end up with an array of structure of array) with only 1024 / 4 elements because each element already represent 4 vectors:

type SetOfWideVector3 = [WideVector3; 1024 / 4];

Our vector sum then becomes quite similar to the AoS approach, except that we have to add each 4 components in the inner loop in an SoA fashion:

fn add_arrays_of_vectors(a: &mut SetOfWideVector3, b: &SetOfWideVector3) {
    for i in 0..1024 / 4 {
        // NOTE: each of those groups of four sums can be executed as
        // a single SIMD instruction.
        va[i].x[0] += vb[i].x[0];
        va[i].x[1] += vb[i].x[1];
        va[i].x[2] += vb[i].x[2];
        va[i].x[3] += vb[i].x[3];

        va[i].y[0] += vb[i].y[0];
        va[i].y[1] += vb[i].y[1];
        va[i].y[2] += vb[i].y[2];
        va[i].y[3] += vb[i].y[3];

        va[i].z[0] += vb[i].z[0];
        va[i].z[1] += vb[i].z[1];
        va[i].z[2] += vb[i].z[2];
        va[i].z[3] += vb[i].z[3];
    }
}