Rapier is a set of 2D and 3D physics engines written in Rust
rapier.rs
rapier.rs
It doesn't have a single-player mode yet (writing an AI for it is a bit more challenging than the chess-like I made) but check it out at https://evrimzone.itch.io/crittershowdown and the physics/game logic source code at https://github.com/evrimoztamur/crittershowdown/blob/e4d9a19....
I plan to write a post about how I wired it together and what I learned, but overall very solid library and well-thought of Rust-y API that enabled me to do everything I needed it to.
Was it easy? In the end, sure, it's a very simple system. However, a lot of gotchas including HTTP headers (connecting itch.io to my personal domain, or making sure that when the game updates the clients pick up the new binary).
I wrote about the client/server part of Maginet and its technical aspects over at https://evrim.zone/blog/projects/maginet/development_overvie.... However, I did not write much about the deployment. Both Critter Showdown and Maginet are essentially the same framework, I built the former in two weeks for a jam based on the stripped-down Maginet shell. If you follow the instructions on GitHub, you should be able to download and run both of them quite easily. Build client, build and run server, then head out to localhost:port to play!
PS: Maginet runs the shared game logic on the server side, but Critter Showdown (with Rapier2D physics) does not. Maginet has a stricter move validation logic (legal vs illegal turns for your mages) that Critter Showdown doesn't (force impulse vectors for your bugs). Turns are passed in Critter Showdown only when both players' turns are received, and it works pretty seamlessly.
There are a few small rust libraries that look interesting [1][2], but none with a lot of traction.
Has anyone looked into this?
[1]: https://crates.io/keywords/geometric-algebra
[2]: https://github.com/Lichtso/geometric_algebra
If you dare, a good place to jump in might be Freya Holmér's Why can't you multiply vectors? - https://www.youtube.com/watch?v=htYh-Tq7ZBI - Then https://bivector.net/index.html
It’s a bit of an overkill for what it’s used for / the fact that it is not used widely in the app.
Collision handling, energy conservation, stability, etc. are the hard problems.
In theory a sufficiently smart GA library can optimize away the zero components, but this is yet to be demonstrated in practice. And if you do it by hand, you'll end up with something very similar to classical vector algebra anyway...
What GA excels at is conciseness of notation. Although, once you consider all the different product types (inner product, exterior product, dot product, scalar product, left contraction, right contraction, regressive product - did I miss anything?), it can be a bit intimidating. Some of it feels a bit like APL to me.
So I wrote a library that can generate any GA and do all kind of fun operations (which could be used in particular as a basis for a physics engine). Just in case any of this is of your interest too: https://cljdoc.org/d/net.clojars.jordibc/geometric-algebra/
An interesting alternative in the Bevy space is Bevy XPBD which I also wrote about: https://taintedcoders.com/bevy/xpbd/
The only thing I haven't gotten to work is rotation. Everything else, the complexity just melts away. Linear algebra? Nope. Just Vec3. Matrix? Solver? You hit your head, it's 1998, just iterate over all the constraints and satisfy them. Collision margins? Skill issue. Broadphase? GJK? Don't over-think it. Throw a modern CPU at it, do the collect_pairs optimization, then realize you were actually malloc-bound and fix that, and it can handle 100 or so objects without blinking. Don't need Bullet.
The velocity fix-up step also threw me off, but having prototyped it for AABBs, I suspect I can translate it back to generic shapes. I skipped it at first and all my collisions were slightly elastic.
> ) Sleeping is a technique that reduces the cost of simulating objects that are not moving to improve performance. We can tweak it by adding a SleepingThreshold resource:
fn main() { App::new() .add_plugins(DefaultPlugins) .add_plugins(PhysicsPlugins::default()) // These are the default values .insert_resource(SleepingThreshold { linear: 0.1, angular: 0.2
Tbh there is a huge industry aroumd C++ robotics code so I can see why.
At my robotics company (where I lost so many hours compiling overly-templated code in C++), I was able to convince my boss to start a new small product in Rust (was an internal simulation tool) and it convinced him to let me work on another new product a few month later, also in Rust, on a much bigger scale. He had only ever worked in C++ before, and I guess he doesn't mind to loose hours compiling and fixing memory leaks. But regardless, it worked and now I can work (a bit) in Rust.
This implies that Rust doesn't have any problems, which is...crazy.
In addition to the problematic community, just rearchitecting your code to fit around the borrow checker can be a massive amount of work, which already makes it infeasible for use in some places where the primary work is not on greenfield projects but on legacy code.
> Unfortunately theres an old guard that refuses to let up and invest in rust.
...and this is just emotionally manipulative, in addition to incredibly dishonest about the problems that Rust actually has.
But TBH, in a Rust world, it’s worth revisiting the assumptions behind the ROS node architecture, since Rust is so strong at scaling to large monolithic applications (due to the strict hierarchical code patterns it encourages).
A transitional Rust approach, that doesn't try to reimplement everything from scratch, could do something like a strangler pattern: Take each ROS node, run them separately in “jails” with a Rust API around each one, then implement the plumbing/management logic in pure Rust.
https://box2d.org/posts/2024/02/solver2d/
The author's video linked at the bottom of the post shows how each solver handles various hard stacking problems https://youtu.be/sKHf_o_UCzI
The only kinda busted aspect is that collision & solver only runs at some limited update rate, so if you start with penetration it needs to resolve that, which is kinda "fake" since real world objects don't penetrate like that, so this can add extra motion and make the stack less stable, but there are various methods to work around this, all the popular physics engine have some solution or another.
So maybe feasible with smaller-scale 2D games that can be written without too much "engine" code (in this case the game used SDL for most of the stuff)
What I like : - Good documentation compared to AmmoJS (you need to read pybullet)
- Recent
- You can run it server side (Node) & client side (Browser), here I'm running it server side but it's possible to do both and implement client side prediction + reconciliation
- Small bundle (AmmoJS was like 2 MB?)
On the Rust side, the Rapier docs are out of date AFAIK. Fortunately I'm stuck on the previous version so it's not so bad.
This has happened before as well, they used to have a fluid simulation library called Salva that supported two-way coupling with nphysics, and ran on all GPUs/CPUs, but that's deprecated in favor of Sparkl which doesn't, and also only supports CUDA. As a result, Salva is about as old as nphysics, but Sparkl is so new that it's also far less capable, and it also has no cross-platform support. Seemingly intentionally! (Rewrite to make this code less cross-platform.)
Hopefully one day the constant rewrites will stop and they'll settle on something that actually supports everything it should. Until then though, I don't see the dimforge ecosystem working out for me if they keep losing features each rewrite. After all, how do I know that Rapier isn't going to get deprecated in favor of something even newer that doesn't support half the features Rapier does?
Sure, give them a break. It's new! It doesn't support all the features that the more mature nphysics does. And that's exactly why the more mature nphysics is completely deprecated and unmaintained in favor of... oh, wait.
These would be unrealistic concerns only if dimforge didn't already have a track record. :(
I get that one day Rapier might be up to feature parity with what nphysics already had five years ago, but that's a completely arbitrary five-year setback for developers who want to build on these features that are currently missing.
It’s an homage to the old Taito electric arcade game “Ice Cold Beer”
https://matthias-research.github.io/pages/tenMinutePhysics/i...
But I cannot directly compare, how it works out for real, as I did not finish yet migrating my engine from Box2D (also in wasm) to rapier and just did some small experiments with rapier otherwise.
Yes. More power means more options in the game.
But I did not decided to switch yet, I need to see how it performs. But for this I have to implement a basic version.
Actually, now that I take a look at the webpage, I really love everything this company is doing. Very interested in working with these libraries!
Just FYI for any random geniuses who happen to read this post - if you can create a modern open-source GPU accelerated CAD kernel (GPU computation, not graphics), mechanical engineers the world over will build shrines in your honour.
#HeresHoping
* Can it do multiple concurrent headless simulations on GPU?
* Can it handle many Mobs/NPCs interacting with each other? (1.000? 1.000.000?)
* Is there a limit on the frame rate?
Nothing runs on GPU here, no NPCs, no game engine. This is a physic engine.