Rustsim becomes Dimforge
Three years ago, I created Rustsim in order to group all the Rust projects I have been working on and maintaining since 2013. Creating this organization on GitHub was one step further towards securing the future existence and maintenance of these Rust crates, some of them being quite popular today like nalgebra or nphysics. Today, I am going one step further and create my company named Dimforge.
Dimforge

Dimforge is a French EURL (Entreprise Unipersonnelle à Responsabilité Limitée), which can be translated to "single-member limited liability company". It aims to be an open-source company which develops high-quality crates for linear algebra and physics simulation. The decision to create Dimforge comes from both personal and communal motivations:
- Creating this company is a way for me to further show my dedication to the Open-Source Rust community by strenghtening my involvement through a legal entity. I always desired to work on my Open-Source projects full-time. This company creation is one step further towards making this happen in about 3 months.
- I will be able to setup partnerships with other companies to fund the development of new features, as well as setup paid support plans.
- If this becomes financially possible in the future, I will hire other Rust developers to either work on my current projects, or on new projects if they are relevant to linear algebra, geometric algorithms, or physics simulation.
How is Dimforge funded?
Right now, Dimforge is entirely funded by me. In the short term I see the main sources of revenue for the company to be:
- Donation crowdfunding through GitHub sponsor. I will close my personal sponsoring account in favor of Dimforge's.
- Development of a partnership with one of the industrial users of Rapier (more about this new project in the next sections).
If you supported me, @sebcrozet directly through GitHub sponsor or Patreon, please consider switching to the Dimforge GitHub sponsor account. That would be extremely helpful, especially for the first couple of years after this creation.
Wait, why is nphysics "passively maintained"?
I you read Dimforge's landing page thoroughly, you may be surprised to see that nphysics, the 2D and 3D physics engine I have been developing for the past 6 years, is now in passive maintenance mode. And it is even more surprising considering I made a post last year showing how I intended to develop nphysics for several years to come.
Did I lie? I wouldn't say so. My desire to continue the development of nphysics was real, and still is but in a different form. nphysics has a fair share of virtues and problems. Some of them are plain unsolvable considering the current design of nphysics. Performance and lack of serialization for example are two recurring problems. This is why I am stopping the active development of nphysics in order to work on its much needed successor Rapier!
Rapier: the flag project of Dimforge
Rapier is the new physics engine I have been working on secretly during the past 5 months. Just like nphysics it is split into two crates: rapier2d and rapier3d for 2D and 3D physics respectively. It is designed to be fast and multithreaded right from the beginning. It is also designed to require less incremental compilation times because the data structures it defines are not generic.
Rapier runs 5 to 10 times faster than nphysics, making it close to the performances of (the CPU version of) NVidia PhysX and faster than Box2D. Benchmarks will be provided in my next blog post.
In addition, Rapier aims to be cross-platform, including web targets. That's why I am maintaining JavaScript bindings right from the beginning. NPM packages already exist: @dimforge/rapier3d and @dimforge/rapier2d.
I am still at the beginning of the implementation of Rapier though, so many features are still missing. However some long-requested features like serialization, (optional) cross-platform determinism, parallelism, and SIMD have already been integrated to ensure their existence and maintenance.
There already are a few key features that makes Rapier stand out. Since they may affect compilation times and/or performances, they are disabled by default and need to be enabled explicitly through cargo features. They are however both enabled on our official NPM packages.
- Serialization: every physics component is serializable using
serde, meaning you can take a deep snapshot of the physics state and restore it later. This snapshot can even be saved on disk or sent through network. - Cross-platform determinism: if the
enhanced_determinismfeature of Rapier is enabled, you it will behave in a bit-level cross-platform deterministic way in all platforms that comply with the IEEE 754-2008 floating point standard. This means that if you run the same simulation with the same initial states on two different machines (or on a browser) you will get the exact same results. Here "bit-level" determinism means that if you serialize the physics state after the same number of timesteps on two different machines, you will obtain the exact same byte array for both: you may compute a checksum of both snapshots and they will match. All this doesn't apply to platforms with pointer size smaller than 32-bit, and on platforms that don't comply to IEEE 754-2008 strictly.