▲ 164 points
back
83 comments
Why do the readmes for physics engines rarely specify how they solve contact constraints? This is one of the most difficult parts of writing a physics engine. It might be less important if you're just interested in visuals and making it "look OK" in a videogame, but it has an impact on the dynamics, so especially if you're interested in robotics or accurate simulation of real-world physics, this is really important to specify.
I would add that the way the contact constraints are solved decides what kind of artifacts you will be getting and you need to understand that to be able to understand precision of your simulation.
Even for a videogame this would be important. You may want to know if it is possible for fast moving objects to pass each other or not. You might then want to limit the velocity of objects (a cheap trick to solve the issue, but very effective), or you might want to choose an engine specifically for this (for example if you make a billiards game or a shooter).
Cross Platform determinism and great serialization capabilities makes this a networked physics programmer's dream!
I kinda wish this was in cpp, so that I could integrate it with Godot and have it be considered for upstreaming.
Edit:
Wait, no ray cast? I'm confused why that wouldn't be implemented. That's a very simple operation, is it not?
No continuous collision detection is not so great either, but is okay if the performance is good enough to tick at a high rate.
There is another Rust crate[0] from the same author that does ray casting. Also, nothing prevents this from being used in Godot[1].
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.)
I'm making a game in Godot and Rust, so I appreciate this physics engine. You can make Godot modules in Rust, so it could be an add-in (even in the Godot Asset library?) using a Godot Module.
The Rust library to bind to Godot can be found here: https://github.com/godot-rust/godot-rust
A few months back I tried - and failed - to write a basic 2d physics engine for my JS canvas library. Before then, I tried to use existing JS physics engines with the library ... but none of them integrated nicely; the closest I got to making something useful was with Matter.js (see Codepen demo[1]).
Rapier has a WASM version, and JS bindings. I'm already looking forward to see if I can get the engine working with my code. Is there a JS-focussed community around Rapier where I can ask questions if I get stuck?
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.
[1]: https://discord.gg/vt9DJSW
[2]: https://github.com/dimforge/rapier.js
[3]: https://www.rapier.rs/docs/user_guides/javascript/getting_st...
Many thanks! I've joined the discord and will have a go at setting up a Rapier-driven demo in a canvas element this weekend.
They have a discord, the link is on their github: https://github.com/dimforge/rapier
I've used Matter.js in a project with custom canvas renderer and it performed great. The only issue that I've had to patch up was tunnelling at high speeds. But this is a common problem with many engines.
- cross platform bit level determinism
- fully serializable state
Wow! Sounds like a boon for Javascript game engines like Bevy. I wonder if they'll support PlayCanvas as well.
Bevy is a a Rust game engine https://bevyengine.org/, although potentially it could be used with js when targeting WASM.
The benchmarks are pretty interesting. Why is it that nphysics has such apparent inconsistency in its frame times?
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.
> Cross-platform determinism: if the enhanced-determinism feature of Rapier is enabled, it will behave in a bit-level cross-platform deterministic way in all platforms that comply with the IEEE 754-2008 floating point standard.
Impressive! I've understood this to be a hard problem. Unity has promised this for years but still hasn't delivered, last time I looked.
Is there anywhere we could read more about the tradeoffs and challenges involved?
Also, how widely has this been tested?
Perhaps most importantly: how can I extend this determinism to my own code?
Do these type of physics engine use Newtonian F=MA at their hearts or do they rely on Lagrangian mechanics?
My instinct tells me the first as it seems more straightforward, but then I realized I just have no idea.
Anyone knowledgeable care to enlighten?
The former, because in order to formulate a physics engine in Lagrangian mechanics you need analytic differentiation (or you can just precalculate the partial derivatives with your own hands, but then it will be precisely the same as coding it in F=ma.)
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.
On a side note, does anyone know what happened to Bullet3D? It seemed like this was a really good candidate for driving game physics a few years ago, but it's been rebranded as "PyBullet", the wiki's no longer available, and it seems to have pivoted towards simulation. Also it seems like Bullet3 never got a proper release.
Is this a dead project?
It is still going strong and being actively developed : https://github.com/bulletphysics/bullet3 & https://pybullet.org/wordpress/
I think one of its main author was hired by Google AI when they (Google) realized that getting a big fat neural network to model the inverse problem of a physics engine (should call it a mechanics engine, really) had lots of very practical applications.
In other news, bullet is alive and kicking. e.g. It's integration into blender lets you do amazing thing, especially wrt modeling natural environments fast.
They mention wasm bindings. Are there c bindings as well?
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.
Bookmarking this comment section in case I ever need a prime example of bikeshedding.
It’s really out of hand. HN seemingly can’t help itself bikeshedding the naming of things, but you’d hope people would check to see all the other similar comments before posting their own not-so-unique take as a top-level comment...
Easy, albeit predictable, fodder for n-gate, if they can be bothered.
You spoke to soon, it's all buried now. The system works?
Regarding inane comments about the name, take a look at this:
https://en.wikipedia.org/wiki/Windows_Mobile#Pocket_PC_2000
Pocket PC 2000, originally codenamed "Rapier", was released on April 19, 2000, and was based on the Windows CE 3.0 kernel.