Welcome to the first edition of This month in dimforge! This is the first edition of this newsletter that replaces the This month in rustsim we published before Dimforge was created. This will provide you with a summary of important update that occurred within the dimforge community. This includes in particular updates about the rapier (physics engine), salva (fluid simulation), ncollide (for collision-detection), nalgebra (for linear algebra), and simba (for abstract algebra) crates. This first edition will contain updates for the month of September 2020.

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

Rapier: continuous benchmarking#

Here are two facts:

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

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

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

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

Rapier: ray-casting support#

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

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

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

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

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

Rapier.js: new bindings, less memory management#

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

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

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

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

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

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

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

bevy_rapier: version 0.3.1#

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

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

salva: a progressive rewrite#

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

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

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

What's next#

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

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

Thanks#

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

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

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