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 with 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.
Rapier: continuous benchmarking
Here are two facts:
- Rapier is still in early development and lacks lots of features.
- 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
master branch and each commit landing on the
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.
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
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.
QueryPipeline uses its own acceleration structure internally, completely independently from the
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
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-bindgengenerating 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
- Or, if the
Worldis not used directly, on
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
QueryPipelineas a Bevy component.
- The update to Bevy 0.2 thanks to the great contributions from CleanCut.
- The replacement of the
RapierPhysicsScaleresources by a
RapierConfigurationresource. This new resource will also allow you to temporarily pause the physics simulation by setting its
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.
There are at least two important Rapier features we intend to work on during October:
- 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".
- 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.
We would like to thank the whole community and contributors. In particular, thanks to the contributors from the past two months1:
- Thanks to users reporting spelling mistakes on the documentation. This is always appreciated.
- Thanks to users joining us on our discord server to provide feedbacks, discuss features, and get assistance!
Finally, thanks to all the former, current and new supporters through GitHub sponsors! This help is greatly appreciated and allows us to continue working on open-source exclusively.
- The list of contributors is automatically generated from the past two months' github commit history. Don't hesitate to let us know if your name should have been mentioned here.↩