🤖 AI disclaimer: the text of this entire blog-post is hand-written. Only the schematics were created with AI assistance.

Rapier is a Free and Open Source physics engine for games, animation, robotics, written with the Rust programming language. For years, we focused on rigid-body physics only: objects that cannot deform in any way. Due to popular requests from the community, we finally integrated deformable bodies: cloth, jelly, ropes, etc. Rapier’s implementation of deformable objects is very versatile, and interacts with all the other engine features with little to no restrictions. For example, you can:

• Attach any type of ImpulseJoint (revolute, prismatic, fixed, generic 6-dofs, etc.) to soft-bodies. Meaning that you can attach two soft-bodies by joints, one soft-body and one rigid-body, as well as attach a soft-body to a multibody. It all works seamlessly and with the same API as you are used to.
• Attach deformable and non-deformable colliders to soft-bodies. Sensor colliders can be deformable too.
• Skinning: use a deformation lattice that is different (often lower-resolution) from the collision-detection or visual mesh while having the collision/visual mesh follow the deformations.
• Control parts of the soft-body kinematically.

In this article, we won’t dive into API details (refer to the user-guide for that). We will focus on the core modeling choices, challenges we faced, and literature we recommend looking at if you are interested in implementing your own soft-bodies system. Our technological choices were guided by the following priorities:

1. Ergonomics: the API should integrate nicely with what we already have.
2. Stability: the simulation should, as much as possible, never break down. Meaning that it should not suddenly explode, or start making objects fly away uncontrollably. This is actually surprisingly difficult to achieve with deformable physics.
3. Control: games need control over the objects they are working with to fit gameplay that does not necessarily agree with real-life physics.
4. Performance: the simulation should be fast, not perfect. Some very advanced algorithms and solvers can eliminate whole classes of difficulties we will discuss (e.g. penetrations of deformable meshes), but are too computationally expensive to be actually usable in games.

Definition of a soft-body​

Let’s start with the definition of a rigid-body: it is a moving point in space (x,y,z) and an orientation (rotation matrix/quaternion), totaling 6 Degrees Of Freedom (DOFs) in 3D and only 3 DOFs in 2D. No matter how complex a rigid-body shape (its colliders) is, from the dynamics perspective it can entirely be represented as a single oriented point in space. In other words, a rigid-body is a moving coordinate frame: the location and movement of any point of the rigid-body can be expressed implicitly from the location and movement of that frame. This is what makes it so cheap and easy to implement and control.

A soft-body is more complex because a single moving frame isn’t enough: deformations require parts of the body to be capable of moving (somewhat) independently of the other parts. Instead, a soft-body is made of several mass points (aka. particles) where each mass point is a point (x,y,z) in space without any orientation. Each particle has 3 DOFs in 3D (or 2 DOFs in 2D), so the more particles a soft-body is made of, the more degrees of freedom it has, the more detailed and smooth the deformations can be.

A soft-body also needs a way of keeping these particles together to form a single cohesive object. In Rapier, you can define a lattice made of points (the mass points), edges (connecting two points), and cells (connecting 3 or 4 points). The only mandatory elements are the mass points; the rest can be added optionally depending on how you want the deformations to behave.

Rapier supports three ways of modeling forces preserving the cohesion of the soft-body: shape-matching, constraints, and the Finite Elements Method (FEM).

Shape-matching​

Main reference: Meshless deformations based on shape matching (Müller, et al.)

Shape-matching is the simplest approach that only needs the soft-body mass points to work (no need for edges or cells). It is good for sets of unstructured points or if the ability of the point-cloud to always recover its original shape after absurdly massive deformations is important. It is cheap to calculate but deformations might feel too local since pressing on one particle will not necessarily affect its neighbors (but this can be improved by enabling both shape-matching and spring constraints simultaneously).

Shape-matching roughly works the following way:

1. Calculate the centers of the deformed and rest (undeformed) shape.
2. Align the rest shape on top of the deformed shape so both centers coincide.
3. Then calculate the best orientation that makes the deformed points the closest to their undeformed version.

Once the matched pose is found and applied to the undeformed soft-body so it aligns roughly with the current deformed version, a virtual spring is inserted between each deformed point and its undeformed twin. The constraints solver then calculates the spring forces on each deformed point individually, making it eventually recover its undeformed shape. As you can see, each point is considered individually, there is no constraint between two mass points of the same deformed soft-body.

Spring constraints​

Main reference: A Constraint-based Formulation of Stable Neo-Hookean Materials (Macklin & Müller)

Constraints-based deformations are likely the most common and versatile approach. It offers a good compromise between realism and performance. Its main limitation compared to FEM is that the apparent stiffness of the soft-body is dependent on the constraints solver convergence: low iteration count results in softer material even at high stiffness coefficient.

Spring constraints work with both edges and cells. For edges, springs are modeled as a simple spring-damper system. For cells, they can either use a constraints-based Neo-Hookean or Corotated linear elastic model (which you can interpret as Hooke’s law but on a volumetric element instead of a segment), or a volume constraint (the deformed cell aims to match the rest volume).

Finite Elements Method (FEM)​

Main reference: Large steps in cloth simulation

The FEM solver offers the most realism but is also significantly more computationally expensive. It will resolve deformations semi-implicitly, making it capable of simulating very stiff materials. The FEM solver requires cells to operate, meaning that you need some sort of triangulation (in 2D) or tetrahedrization (in 3D) of your model. Rapier provides some triangulation and tetrahedrization functions through SoftBodyBuilder::volumetric, which fills a closed boundary mesh with cells:

• In 2D, the interior of the boundary polyline is triangulated with Delaunay and refinement to insert internal mass points.
• In 3D, the shape is enclosed with tetrahedrons using the Isosurface Stuffing (Labelle & Shewchuk) method.

Handling penetrations and self-intersections​

Because deformable bodies will almost always end up having a non-convex shape, collision-detection and collision resolution immediately become an order of magnitude more difficult than with rigid-bodies. In fact, game physics engines generally try very hard to avoid non-convex colliders for dynamic rigid-bodies; this is why you will almost always see concave shapes approximated with convex primitives using Compound Shapes or (Approximate) Convex Decomposition. Some physics engines entirely forbid using meshes as the collision shapes for dynamic rigid-bodies.

But why do physics engines try to avoid non-convex colliders on dynamic bodies so much? Two main reasons:

1. Performance: for example detecting collisions between two cubes through the SAT algorithm is much cheaper than colliding their 12-triangle mesh representations.
2. Collision response: because meshes (polylines in 2D) do not have an explicit representation of their interiors, they are generally seen as triangle soups. And each triangle/triangle collision is seen individually. So if two meshes (or polylines) are penetrating, some contacts will actually actively try to keep them in this penetration state instead of resolving the penetration.

The performance issue isn’t a huge deal: as long as the game developer is aware of the cost, they can decide on when and how soft-bodies are relevant to their gameplay. The collision response issue on the other hand is out of the game developer’s hands since this is core physics engine behavior.

And of course, deformations make it even worse: not only can two meshes penetrate, but a single mesh can also deform and intersect itself, getting tangled with itself:

The mesh/mesh intersection and self-intersection problems are not new. While the collision-detection itself is a somewhat well-solved problem (as long as we keep it feature-local), the modeling and resolution of the contacts is a very difficult problem for physics simulation, resulting in decades of still-ongoing research. Here are the main families of approaches we identified from the literature:

1. Guarantee no penetrations/self-intersections: the idea is that if you can guarantee that the physics solver behaves in such a way that two meshes never penetrate or self-intersect no matter how hard you push on them or how folded they are, then you completely eliminate the penetration/self-intersection problem. This is arguably the most true-to-reality approach, but it comes at a heavy cost from the constraint solver. This generally involves mesh CCD (Continuous Collision Detection), barrier potentials (contact models that get infinitely strong as the distance gets close to zero), and an implicit solver iterated to convergence to satisfy the constraints. IPC and ABD are two major publications in that domain. Methods falling in that category often leverage the GPU to achieve interactive rates.
2. Let penetrations happen, and use global analysis to fix them. Since a simple triangle/triangle local collision response cannot work, the idea is to identify patches of penetrating mesh elements that need to be pushed globally. We recommend the paper Untangling Cloth (Baraff, et al.).
3. Consider penetrations as a normal occurrence and rely on the intersection volume for the contact model. We are thinking in particular of the paper Volume Contact Constraints at Arbitrary Resolution (Allard, et al.). The idea is to let the shapes penetrate and define a contact model that pushes the deformable objects in the direction opposite to the volume gradient (i.e. push them to minimize the volume overlap). This has the benefit of being independent of the actual triangle/triangle contact points/normals that are at the core of our collision-resolution issues.

For Rapier, we experimented with (2) and (3) as they both felt reasonable performance-wise on paper. (1) felt clearly out of our performance budget.

The approach (2) was reasonably good, but can suffer from occasional glitches due to floating-point inaccuracies during the global search/flooding. This can occasionally result in a suddenly incorrect movement when the simulation would otherwise remain peaceful. But we do think that (2) has good potential and might revisit it later (and encourage other engine writers to consider it so we can figure out how to make it work more robustly and efficiently).

The approach (3) was very promising as soon as we tried it. While we did not end up keeping an implementation that matches everything from the paper, our solution can be seen as a dumbed-down variant of that paper. It boils down to one observation: the "volume normal" obtained from the volume gradient (which the paper uses for defining the friction plane) turns out to be a fairly good approximation of the MTV (Minimum Translation Vector) direction.

Obtaining a good approximation of the MTV between two deformable meshes is very valuable, even if we don’t necessarily know its magnitude. This allows us to push the shapes toward that direction until they de-penetrate. And since we consider that direction as the "blessed" depenetration direction, we can use it to filter-out/fix incorrect local triangle/triangle contact directions that would otherwise make the pair of meshes stay in a penetrating/tangled configuration.

The concept of soft frames for joints and colliders​

Physics engines often limit the types of joints you can attach to soft-bodies, and the API for doing so is usually separate from the main rigid-body API. In Rapier, we introduce the concept of soft frames to solve this rather elegantly. A soft frame is a coordinate system (translation + rotation) associated to a piece of a soft-body. That coordinate system is represented as a RigidBody with a special RigidBodyType::SoftFrame type (recall that until now Rapier supported the RigidBodyType::Dynamic, ::Fixed, ::KinematicPositionBased and ::KinematicVelocityBased types. So ::SoftFrame is just an additional variant to that enum). This is useful for two reasons:

• Joints and non-deformable colliders need both a translation and a rotation to work. This is precisely what rigid-bodies provide.
• By representing soft-frames as regular rigid-bodies, all the pre-existing APIs work the same: if you want to attach a joint to a soft-body, just attach it to one of its soft-frames. Same for colliders. You define and manipulate them exactly the same way as you would with a regular rigid-body.

Essentially, the concept of soft-frame is to associate, and automatically update, a single translation and rotation to a soft-body. That single translation and rotation should hopefully behave continuously through time and should be representative of its location/orientation if it weren’t deformed. We already discussed a concept we can reuse precisely for that: shape-matching!

So, in essence, a RigidBody of type SoftFrame is a special type of RigidBody which has its translation and rotation automatically calculated with shape-matching on its associated soft-body at each step. When a SoftBody is created, Rapier automatically creates a companion RigidBody with type SoftFrame. That companion RigidBody (that we also call a "proxy") has a RigidBodyHandle that you can use for attaching impulse joints and rigid colliders to it, just like you would with any other rigid-body.

But that single soft-frame is often not expressive enough. If you want to attach two (or more) joints to a soft-body, or if you want the joint’s effect to be concentrated at a particular location other than around the center of mass, the whole-body soft-frame will not be enough.

This is why a soft-body can have multiple soft-frames associated to it. Each soft-frame can be associated to any subset of the soft-body’s mass points and the resulting shape-matching for translation and rotation calculations will be local to that subset of points. This allows joints to be attached to smaller clusters of mass points independently, each with their own independent orientation.

Therefore, Rapier allows you to create clusters on soft-bodies, each with an associated SoftFrame. Each of these is a RigidBody with positions and rotations synced automatically from the shape-matching on subsets of the soft-body mass points. Thus, you can also attach non-deformable colliders to them, meaning that two rigid-colliders attached to the same soft-body but through different soft-frames will move and orient themselves independently.

Cage simulation and skinning​

Unlike engineering, games don’t worry too much about mechanical correctness. Instead, they want the simulations to look good, stable, and to run fast. As a result, it is not uncommon for the simulation shapes to be significantly simpler than the visual shapes: meshes are approximated with coarser meshes or even with primitives, some details are ignored, etc. The same holds for soft-bodies: handling every single visual triangle as its own soft cell is often unnecessary and will often impact performance and even robustness badly (too large number of elements and/or badly shaped elements). This is why Rapier supports cage simulation and skinning.

Cage simulation means that your detailed deformable mesh (collision and/or visual) is trapped into a deformable "cage". That cage is a volumetric blob that often has a larger volume than the original mesh. Similarly, a deformable sheet would be modeled as a thicker set of deformable tetrahedrons (or triangles in 2D). That "cage" generally has a much lower geometric precision than the visual mesh, and has the benefit of being well-formed (e.g. regular tetrahedrons) and volumetric. The vertex positions of that detailed mesh are interpolated from the deformed cage: this is skinning. Note that you don’t need a volumetric cage for leveraging skinning: it would also work with any deformable mesh associated to your visual mesh.

tip

Rapier is capable of automatically calculating a cage for simulating any deformable mesh with SoftBodyBuilder::volumetric_skinned. In 3D, it is built using the Isosurface Stuffing algorithm, skipping the snapping step so that the input mesh remains fully enclosed. That automatic calculation is focused on performance rather than geometric fidelity.

A detailed screwdriver mesh and its automatically generated coarse deformation cage (blue)

The paper Skeleton based tetrahedralization of surface meshes is how we learned about the existence of cage simulation (but we didn’t end up implementing that paper’s skeleton-based technique).

Permanent deformations: tearing and plasticity​

Main reference: Interactive virtual materials (Müller & Gross)

Finally, two interesting features of soft-bodies are the ability to model permanent deformations. We distinguish two concepts:

• Plasticity: permanent change of rest position of the mass points (without any topology change). This models materials like a piece of metal that folds on impact, clay being molded, etc.
• Tearing (aka. "failure/fracture"): permanent change of the soft-body topology where pieces of it physically disconnect from other pieces. This models effects like breaking glass, a piece of fabric being torn in two, etc. Tearing is implemented with a mass-splitting approach. Instead of removing elements (edges or cells) when they are torn, we split their mass points in two. That way, the volume of the post-split shape matches the volume before the split. Each connected component after the split becomes its own independent soft-body.

Rapier supports tearing and plasticity with both solver types (SoftBodySolver::Fem and ::Constraints). When using the constraints-based solver, the quality of plastic deformations is strongly correlated to the solver’s convergence, meaning that more solver iterations result in more convincing permanent deformations.

Where can I use Rapier’s soft-bodies today?​

Soft-bodies are available starting with Rapier 0.36.0. They can currently be used from:

• Rust: using the rapier crates directly: rapier2d and rapier3d, user guide.
• Typescript: using our official Typescript bindings, available on NPM: @dimforge/rapier2d and @dimforge/rapier3d, user guide.
• Python: using our official Python bindings, available on PyPI (3D only): rapier3d, user guide.
• C: using our (new 🎉) official C bindings: sources, user guide.
• Bevy: with bevy_rapier for integration with the Bevy game engine: sources, user guide.

Support in Godot will likely be added once the third-party godot-rapier plugin gets updated.

The new C bindings will allow easier integration of Rapier into other popular game engines (Unity, Unreal, etc.) in the future.

Acknowledgements​

We cannot thank enough:

• Futurewei for sponsoring our physics work for robotics and AI.
• NGI Zero Commons Fund for accepting our grant proposal to further extend the solvers supported by our GPU physics engine Nexus.
• 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 contributors!

** Credit: the car model from the "Plastic car chassis (3D)" demo video is Dune Hunter (taanX).

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

If you haven’t seen it already please check out our Q1 technical report because our Q2 work is the continuation of that exciting work. As promised, this second quarter led to the release of one of our new flagship projects: Nexus, a cross-platform GPU multi-physics engine.

We also started making improvements to Rapier, our CPU-based rigid-body physics engine, for addressing issues and limitations related to multibodies for robotics use-cases.

Finally, we have further enhanced the feature set of Kiss3d, or simple 2D and 3D graphics engine by bring a wide range of more advanced rendering effects.

Nexus: cross-platform GPU physics​

https://github.com/dimforge/nexus

We are very excited to release the first version of our GPU multi-physics engine: Nexus. It started as a port of our former WGSL-based work wgrapier. While it shares similar algorithms, it differs in multiple major ways:

• All the shaders are written 100% in Rust, using rust-gpu, khal, and vortx.
• It implements more features including multibody joints, multiple colliders per bodies, and dynamic insertion of rigid-bodies.
• It implements batch simulation to run thousands of variants of the same scene in parallel. This is typically used for Machine Learning like Reinforcement Learning, and, more generally, training datasets generation.
• It is generally 2x faster than our WGSL implementation, and has a much smaller performance gap between running natively and on the browser.

Keva tower

Compound colliders

Trimesh & convex

Joints and bodies

MJCF robot

2D primitives

×

×

×

×

×

×

Using the wgpu backend, Nexus can run on all major hardware and browsers (tested on Edge, Chrome, Firefox on Windows, Linux, and MacOS). It is currently not compatible with Safari which has stronger restrictions on supported shaders. It supports both 2D and 3D.

Creating a Nexus scene is done by initializing rigid-bodies, colliders, joints, etc. using Rapier types. They are then converted to GPU resources internally. Nexus ships with a viewer built on top of kiss3d; it is capable of rendering the Nexus scene efficiently without any GPU→CPU synchronization when using its default (webgpu) backend.

use khal::backend::GpuTimestamps;
use nexus_viewer3d::NexusViewer;
use nexus3d::prelude::{NexusCapacities, NexusPipeline, NexusState, RbdCoupling};
use rapier3d::prelude::*;

pub async fn run(
    viewer: &mut NexusViewer,
    pipeline: &mut NexusPipeline,
) -> anyhow::Result<NexusState> {
    const NXZ: isize = 30;
    const NY: isize = 70;

    let capacities = NexusCapacities::default().rbd_collisions(500_000);
    let mut state = NexusState::new(capacities);
    let no_coupling = RbdCoupling::NONE;

    /*
     * Falling dynamic objects.
     */
    for j in 0..NY {
        let max_ik = NXZ / 2;
        for i in -max_ik..max_ik {
            for k in -max_ik..max_ik {
                let x = i as f32 * 1.1 + j as f32 * 0.01;
                let y = j as f32 * 1.1 + 0.6;
                let z = k as f32 * 1.1 + j as f32 * 0.01;
                let pos = Vec3::new(x, y, z);

                let body = RigidBodyBuilder::dynamic().translation(pos).build();
                let collider = ColliderBuilder::cuboid(0.5, 0.5, 0.5).build();
                let shape = collider.shared_shape().clone();
                let handle = state.insert_rigid_body(body, collider, no_coupling);
                viewer.insert_shape(handle, &shape, Pose::IDENTITY);
            }
        }
    }

    /*
     * Floor made of large cuboids.
     */
    {
        let thick = NXZ as f32 * 1.5;
        let height = 12.0;
        let walls_color = Vec4::new(0.6, 0.8, 1.0, 0.3);
        let walls = [
            (Vec3::new(0.0, -0.5, 0.0), Vec3::new(thick, 0.5, thick)),
            (Vec3::new(thick, height, 0.0), Vec3::new(0.5, height, thick)),
            (
                Vec3::new(-thick, height, 0.0),
                Vec3::new(0.5, height, thick),
            ),
            (Vec3::new(0.0, height, thick), Vec3::new(thick, height, 0.5)),
            (
                Vec3::new(0.0, height, -thick),
                Vec3::new(thick, height, 0.5),
            ),
        ];

        for (wall_pos, wall_sz) in walls {
            let body = RigidBodyBuilder::fixed().build();
            let collider = ColliderBuilder::cuboid(wall_sz.x, wall_sz.y, wall_sz.z)
                .translation(wall_pos)
                .build();
            let shape = collider.shared_shape().clone();
            let handle = state.insert_rigid_body(body, collider, no_coupling);
            viewer.insert_shape_with_color(handle, &shape, Pose::from_translation(wall_pos), walls_color);
        }
    }

    let mut timestamps = GpuTimestamps::new(viewer.backend(), 2048);
    viewer.scene3d_mut().add_directional_light(glamx::Vec3::new(1.0, -2.0, 3.0));

    // Optional finalize, useful so we can render even before starting the simulation.
    state.finalize(viewer.backend()).await?;

    while viewer.render_frame().await {
        if viewer.simulating() {
            pipeline
                .simulate(viewer.backend(), &mut state, Some(&mut timestamps))
                .await?;
        }
        viewer.sync(&mut state, Some(&mut timestamps)).await?;
    }

    Ok(state)
}

Why rust-gpu?​

You might be wondering why we decided to pick rust-gpu for such an ambitious project. Well, we tried many different alternatives for single-source cross-platform GPU compute: WGSL, WESL, Slang. Unfortunately none of these reached the quality of developper experience we were hopping for, either because of language limitations (with WGSL/WESL), or due to difficulties to interface with a C++ stack and a lack of IDE tooling and package manager for sharing shaders across projects (Slang).

Rust-gpu on the other hand lets us write shaders in Rust directly. It even allows us to reuse shader code across crates using our beloved cargo. Because it is Rust, we don’t need to learn yet another programming language: we can even reuse some of our (originally non-GPU) mathematics libraries (like glamx for advanced operations like the Singular Value Decomposition), and we can write complex procedural macros in khal to interface the GPU code with the CPU code and get compile-time type checking on kernel invocations! Moreover, the CPU code can depend on the GPU crate, so you can reuse the GPU structures directly, eliminating all difficulties wrt. data layout mismatch. Finally, you can run your GPU code on the CPU to debug easily like any other piece of regular Rust code. The productivity gain is massive, and writing GPU code that way is much more pleasurable as a Rust developer!

But, still, is Rust the right choice for writing high-performance compute shaders? We are confident that, yes, it is a strong option. We have actually observed a growing interest in writing compute shaders in Rust during the past few months with:

• cuda-oxide: recently announced by NVidia for compiling Rust code to Cuda. It is somewhat similar in goals to rust-cuda.
• cutile-rs: Rust-based DSL for tile-based kernel programing, also maintained by NVidia.
• cubecl: Rust-based DSL for cross-platform gpu compute maintained by Tracel-AI.

If NVidia themselves start to develop major interest into using Rust for CUDA, this suggests Rust on GPU isn’t a bad idea after all. And this urges us to build a solid cross-platform scientific computing ecosystem in Rust as early as possible, so the Rust community doesn’t get locked into the proprietary Cuda environments.

On a final note, it also feels encouraging that Khronos acknowledged the relevance of rust-gpu by listing it as one of the options on their recent Shader Compiler Survey: https://www.surveymonkey.com/r/LKWFQ3M (not sure how long that link will remain valid).

Python bindings​

Both the robotics and the machine learning communities strongly rely on Python. And since Nexus aims to also be beneficial to both, we automatically generated Python bindings. The general design of the Python bindings aims to match the Rust API as closely as possible in order to keep them as thin as possible (and make their maintainance easier). Bindings for the viewer are also provided in the same package.

"""Python port of `crates/examples3d/boxes3.rs`.

A grid of dynamic cuboids falls into a walled box. Run with:

    maturin develop -m crates/nexus_python3d/Cargo.toml --features metal
    python crates/nexus_python3d/examples/boxes3.py
"""

from nexus3d import (
    NexusViewer,
    NexusPipeline,
    NexusState,
    RbdCoupling,
    RigidBodyBuilder,
    ColliderBuilder,
    GpuTimestamps,
    Vec3,
    Vec4,
    Pose,
)

NXZ = 30
NY = 70

def run(viewer: NexusViewer, pipeline: NexusPipeline) -> NexusState:
    state = NexusState()
    no_coupling = RbdCoupling.NONE

    # Falling dynamic objects.
    for j in range(NY):
        max_ik = NXZ // 2
        for i in range(-max_ik, max_ik):
            for k in range(-max_ik, max_ik):
                x = i * 1.1 + j * 0.01
                y = j * 1.1 + 0.6
                z = k * 1.1 + j * 0.01
                pos = Vec3(x, y, z)

                body = RigidBodyBuilder.dynamic().translation(pos).build()
                collider = ColliderBuilder.cuboid(0.5, 0.5, 0.5).build()
                shape = collider.shared_shape()
                handle = state.insert_rigid_body(body, collider, no_coupling)
                viewer.insert_shape(handle, shape, Pose.IDENTITY)

    # Floor made of large cuboids.
    thick = NXZ * 1.5
    height = 12.0
    walls_color = Vec4(0.6, 0.8, 1.0, 0.3)
    walls = [
        (Vec3(0.0, -0.5, 0.0), Vec3(thick, 0.5, thick)),
        (Vec3(thick, height, 0.0), Vec3(0.5, height, thick)),
        (Vec3(-thick, height, 0.0), Vec3(0.5, height, thick)),
        (Vec3(0.0, height, thick), Vec3(thick, height, 0.5)),
        (Vec3(0.0, height, -thick), Vec3(thick, height, 0.5)),
    ]
    for wall_pos, wall_sz in walls:
        body = RigidBodyBuilder.fixed().build()
        collider = (
            ColliderBuilder.cuboid(wall_sz.x, wall_sz.y, wall_sz.z)
            .translation(wall_pos)
            .build()
        )
        shape = collider.shared_shape()
        handle = state.insert_rigid_body(body, collider, no_coupling)
        viewer.insert_shape_with_color(
            handle, shape, Pose.from_translation(wall_pos), walls_color
        )

    timestamps = GpuTimestamps(viewer, 2048)
    viewer.add_directional_light(Vec3(1.0, -2.0, 3.0))

    # Optional finalize, useful so we can render even before starting the simulation.
    state.finalize(viewer)

    while viewer.render_frame():
        if viewer.simulating():
            pipeline.simulate(viewer, state, timestamps)
        viewer.sync(state, timestamps)

    return state


def main() -> None:
    viewer = NexusViewer()
    viewer.init_backend()
    pipeline = NexusPipeline()
    pipeline.preload_pipelines(viewer)
    run(viewer, pipeline)


if __name__ == "__main__":
    main()
    import os

    os._exit(0)

Reinforcement learning​

We have been collaborating with Xavier Tao − @haixuantao − from 1ms.ai for feedbacks, optimizations, and contributions related to using the Nexus stack for Reinforcement Learning. While we are still early in the process, we are already able to train a simple robot to stand and walk, relying on Nexus’ batch simulation to accelerate the training loop. The entire project is in Rust.

Both videos below showcase a bipedal robot controlled by a neural network trained for standing (left) and walking (right) using Nexus multibody joints and batch simulations.

Next steps​

While we present Nexus as a multi-physics engine, this release only supports rigid-body physics. We intend to extend it further by supporting more models for non-rigid physics. One of our next main objectives is the addition of an MPM solver (Material Points Method) with coupling with Nexus’ rigid-body solver.

We also intend to further improve the stability of multibodies, performances, and the public API of Nexus to make it easier to interact with the scene while the simulation is running.

Rapier: improvements for robotics​

https://github.com/dimforge/rapier

One of our main focus for Rapier in 2026 is the improvement of its robotics-oriented features. During the past three months, we started by addressing some long-standing bug reports on multibodies (both regarding crashes in instabilities).

Multibodies and MJCF​

Since we wanted to test multibody simulations on more actual robot models, we implemented the support for MJCF files (i.e. the file format from the MuJoCo project). These resulted in the mjcf-rs crate as the low-level parser that is independent of Rapier, and rapier3d-mjcf for loading these MJCF files as rapier multibodies. We then added a new 3D example that lets you browse through a collection of MJCF models and simulate them. It is capable of loading most robots from the MoJoCo menagerie dataset (you will have to clone the dataset yourself), including actuator keyframes as showcased in the video below.

The PhysicsWorld object​

One common difficulty with using rapier as a beginner is the large number of different collections to create before being able to run a simulation. Rapier 0.34 introduces a new structure PhysicsWorld that wraps all these fields so you can create them all at once. Using PhysicsWorld is not mendatory so you are free to keep using the individual resounces and physics pipeline.

pub struct PhysicsWorld {
    /// Gravity applied to all dynamic bodies each step.
    pub gravity: Vector,
    /// Parameters controlling the simulation (timestep, solver iterations, etc.).
    pub integration_parameters: IntegrationParameters,
    /// The main simulation pipeline that orchestrates each physics step.
    pub physics_pipeline: PhysicsPipeline,
    /// Manages active/sleeping body groups (islands) for efficient simulation.
    pub islands: IslandManager,
    /// The broad-phase acceleration structure for fast spatial queries.
    pub broad_phase: BroadPhaseBvh,
    /// Precise contact and intersection detection between collider pairs.
    pub narrow_phase: NarrowPhase,
    /// All rigid bodies in this world.
    pub bodies: RigidBodySet,
    /// All colliders (collision shapes) in this world.
    pub colliders: ColliderSet,
    /// All impulse-based joints (hinges, springs, ropes, etc.).
    pub impulse_joints: ImpulseJointSet,
    /// All multibody joints (kinematic chains, articulations).
    pub multibody_joints: MultibodyJointSet,
    /// The continuous collision detection solver.
    pub ccd_solver: CCDSolver,
}

In addition, it exposes helper functions for inserting bodies, colliders, joints, etc. and stepping the simulation. All the fields are public if you need finer grained control or need to avoid some situations where borrowing the whole physics world instead of some of its components would be limiting.

Kiss3d: advanced rendering effects​

https://github.com/dimforge/kiss3d

Most popular physics engines from the robotics community ship with a nice viewer. This becomes especially relevant if we want the viewer exposed through python bindings while being able to interact with the Nexus GPU resources efficiently. Therefore, we have been enhancing the quality of the Kiss3d renderer significantly during the past quarter. We also added a hardware-accelerated path-tracer for high-fidelity rendering.

PBR material

Refraction

Order Independent Transparency

GLTF + animations

Depth of field

Offscreen rendering

Reflections

Bloom

Path tracing

×

×

×

×

×

×

×

×

×

Of course, all these rendering features are cross-platform, and compatible with the web (though the path-tracer won’t leverage GPU RT-specific hardware on the web). The kiss3d online examples have been updated for showcasing all the new features.

Kiss3d is used as the renderer for the Rapier and Nexus viewers. In particular, with Nexus, it enables rendering all the simulated objects without any GPU→CPU synchronization since all the data needed for rendering is already available on the GPU by making both use the same wgpu device.

Conclusion​

During this second quarter we reached a significant milestone on our cross-platform GPU physics journey by releasing the rigid-body solver of Nexus, written with rust-gpu. With the introduction of python bindings and the support of the popular MJCF format, we aim to reach a wider audience from the Robotics and ML communities. We intend to make of Nexus a major multi-physics engine for large-scale robotics, ML, animations, and engineering by adding more rigid and non-rigid solvers in the future like MPM.

We also started improving Rapier (our CPU-based rigid-body physics engine) for robotics by fixing long-standing bugs and stability issues on multibodies. We also reworked its testbed to make it easier to use, making examples more self-contained by avoiding internal callbacks.

Finally, the improvements of our Kiss3d renderer allowed us to easily integrate advanced rendering effects as well as a path tracer to our physics showcases, while at the same time making it available through the Python bindings too. By ensuring direct compatibility with the dependency versions shared with Nexus, we can guarantee the ability to render complex 3D physics simulations without any GPU→CPU synchronization, ensuring excellent performances in most browsers too.

Acknowledgements​

We cannot thank enough:

• Futurewei for sponsoring our physics work for robotics and AI.
• NGI Zero Commons Fund for accepting our grant proposal to further extend the solvers supported by Nexus.
• 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 contributors!

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

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.dimforge.com.

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: