Yes, it uses a Newtonian formulation. Another physics engine (nphysics) I wrote before rapier, had a Lagrangian formulation of joints (using reduced-coordinates). This is something I intend to add to Rapier too at some points.
No C bindings so far. This is something I would like to consider doing at some point. Though when exactly it is done will depends on the demand since I have limited resources.
I would try this out tomorrow if it had a C FFI. I've been working more with Rust, but I have a lot of existing work in other languages, and a C FFI would make it so much easier to consider this as an alternative.
The main source of inconsistency for nphysics performances is its broad-phase algorithm. It is a tree-based approach which is admittedly not written very efficiently and has very unstable performances when most objects moves.
Author of Rapier here. The best way to get help would be to join our discord server [1]. There is a channel dedicated to rapier.js. So far most of us are Rust devs but we want to grow our JS community progressively.
You can also ask questions/post issues on the rapier.js repository [2].
You will also find a WIP user-guide on the rapier website: [3].
Right now the JS bindings are not complete, so a couple of months of work is still needed to expose all the capabilities of Rapier through JS.
Yeah, ray-casting and CCD are missing currently, mostly because I didn't have the time to implement them yet (though I did implement them on ncollide/nphysics (https://nphysics.org) so it is mostly a matter of adapting/rewriting them to fit in Rapier.)
Well most physics engine, including nphysics, bullet, box2d, are able to achieve much more realistic simulations: just increase the number of iterations for the constraints solvers, and reduce the timesteps length. Of course this will no longer be real-time but will be suitable for generating animations. In the end, it always boils down to a compromise between performances and realism unfortunately.
Yes, the physics demo shown in the user guide was a bit slow (less than 60fps for sure). This video was made one year before today, using a version of nphysics that was at least 5 times slower than the current one.
Also, unless the gravity is artificially boosted, things may still look a bit slow because of the scale issue described by aaronetz (in all the demos, most objects are around 1 meter tall, and the camera is far enough to see them all). AFAIK, it is not uncommon on e.g. video games, to artificially increase the gravity so that things look a bit more dynamic.
The one application I know for 4D collision detection is 3D continuous collision detection. If two 3D objects are moving, you can parameterize their movement through time to obtain a 4D shape. If those movements are only translational, and the two shapes are convex and have a support function, then testing for contact is easy (e.g. using GJK). However if those movements contain rotations, the resulting 4D shape will be concave so interference detection may be hard.
I do not think anybody actually uses this method though.
