nphysics 0.8.0 (full rewrite) is released!
I am thrilled to announce the release of nphysics2d/nphysics3d v0.8.0 as well as the release of two new crates: ncollide2d and ncollide3d that will replace the existing (large) set of crates prefixed by ncollide (ncollide_math, ncollide_geometry, etc.) I am sorry for the late arrival of those releases, especially since a couple of feature are still missing (see the third part of this post), and I have yet to start making a website for nphysics. The full rewrite of nphysics was such a massive task that it took me much longer than I expected in my initial planing there. Though here is a good news that will help me improve on that in the feature:

Great news: I decided to switch to a part-time (3/5) engineering job so that I have 2 days off dedicated to my rust developments. While this has a significant financial impact, this will allow me to produce a higher-quality works. I intend to do this as long as it remains financially possible. Of course, patreon is a great way to help me continue this since donations reduce the financial impact of having only a part-time salary. I've added goals and rewards to my patreon profile!

My objectives for those releases

At first, my objective was to completely rewrite nphysics. This was motivated by:

  1. A need to make the physics world Send+Sync in order to simplify its integration with several frameworks (including ECS-based applications).
  2. A need to clarify the internal structure of the library so that it becomes more easily maintainable and extensible in the future.
  3. A need to make the solver much more robust and realistic.

I also wanted to implement a feature that rarely exist on popular open-source physics engine: numerically stable multibodies using a reduced-coordinates approach. "Stable" here means that methods like the Feartherstone algorithm are not an option for serious applications as it will break down whenever velocities vary a bit too much.This also resulted in the deep modifications of collision detection algorithms, and in particular in the representation of contacts and how they are computed. This required lots of dimension-specific code, at a point where putting 2D collision detection and 3D collision detection into separate crates (ncollide2d and ncollide3d) became very practical. I also wanted ncollide:

  1. To have a smaller memory footprint for 2D applications by specializing data structures: this was not possible easily with my previous dimension-generic approach because of the lack of specialization on stable rust.
  2. To have simpler data types by removing most of the generic type parameters.
  3. To have a simpler crate structure by merging together all the ncollide_math, ncollide_geometry, ncollide_pipeline, etc.

Changes made on ncollide and why you should or shouldn't transition now.

ncollide now takes the form of two crates: ncollide2d and ncollide3d. Those crates keep the same structure of the previous ncollide crate except that:

  1. Time-of-impact computation has been removed for now (but will be re-added and the related bugs fixed soon).
  2. Persistent collision detection involving cylinders and cones is no longer supported.
  3. Most struct and traits now have only one type parameter: the scalar type (expected to be set to f32 or f64).

On the other hand this brings several significant improvements:

  1. More accurate collision detection involving convex polyhedron, including robust contact manifold computations.
  2. Persistent contact information are much more detailed by including which face/edge/vertex touch, as well as contact kinematic information.
  3. Lower memory footprint for 2D applications. The fact that ncollide2d is on its own crate allows specialization of various data structures to improve memory usage.

So if time-of-impact computation is a must for your current application, you should way a bit before upgrading to the ncollide2d and ncollide3 crate. Otherwise, you should upgrade. If your current application rely on persistent contact computation between cylinders and cones, you should use convex polyhedral approximations of them instead.Finally, I did not have the time to update the user-guide on yet. Fixing this is among my short-term objectives.

Changes made on nphysics and why you should or shouldn't transition now.

nphysics has been completely rewritten. So don't expect the API to be the same as its previous version. You may read the various examples provided on the examples2d and examples3d folders to get a taste of the new API. The major new features are:

  1. The World is now Send+Sync, meaning it can be used in a multi-threaded context. This was a widely requested by users of an ECS-based architecture.
  2. The stability of stacking has been significantly improved by the implementation of a non-linear constraints solver with position-based penetration correction. This approach is the one existing on Box2d which I also generalized for the 3D case.
  3. All well-known joints have been implemented using two methods: constraints-based approaches and reduced-coordinates approaches. The constraints-based joints are like the joints that already existed on the previous version of nphysics. The reduced-coordinate based joints (i.e. multibody links) are a novelty that provide joints that cannot be violated, i.e., no matter how hard you try, you won't be able to break the constraints imposed by the joint. This is great for highly accurate simulation but may be slower than constraint-based joint in some situations.
  4. Joint limits and joint motors have been implemented for most joints that use the reduced-coordinate approach.
  5. Regarding constraints-based joints, joint limits has been implemented for the UniversalConstraint (the constraints-based joint that allows only one relative translational motion). Motors and limits for other constraints-based joints should be implemented within a month or two after this release.

There are, however a few regressions you should be aware of before considering migrating your project to the new version of nphysics:

  1. Cylinders and cones are no longer supported by nphysics. And I don't intend to support them any time soon. Instead, you should use polyhedral approximations.
  2. Continuous-collision-detection (for very fast objects) is no longer available. This requires some more work to make it compatible with the new non-linear penetration correction algorithm introduced in this release. Fixing this is part of my short-time objectives.
  3. Performance  may be lower than before. That's because I mostly focused on features for this release. I intend to dedicate at least two full months to performance improvements. I expect this to happen in August/September.
  4. The public API still needs some polishing. This will be improved while I write the user-guide.

Finally, note that I did not have the time to create user-guide for nphysics yet. Sorry for that. Reading the examples is still your best way to learn about using nphysics. Working on this user-guide is among my short-time objectives.

What will happen during the next 2 to 3 months.

Here is my sorted list of priorities for the next few months:

  1. Rewrite the time of impact computation code on ncollide. Fix the related issues at the same time.
  2. Add joint motors and limits to the RevoluteConstraint and other constraints that are compositions of the RevoluteConstraint with the PrismaticConstraint.
  3. Update the online user guide for ncollide in order to reflect this release.
  4. Create a website with a user guide for nphysics.
  5. Re-add the continuous collision detection on nphysics.  

Once all this is done, I intend to dedicate at least 2 months to improving performance of nphysics. Support fort soft-bodies and fluid will get a higher priority only after all those are done.

Thank you for your support!