return to table of content

Rapier is a set of 2D and 3D physics engines written in Rust

porphyra
13 replies
2d13h

Dimforge is really doing god's work. I would be so excited if nalgebra + Rust can replace Eigen + C++ for robotics stuff like localization and mapping.

accurrent
5 replies
2d13h

Yes! Ive been working mostly in rust recently for robotics projects. The amount of time our industry wastes on C++isms is ridiculous where rust just works. Unfortunately theres an old guard that refuses to let up and invest in rust.

Tbh there is a huge industry aroumd C++ robotics code so I can see why.

iExploder
3 replies
2d11h

Companies barely have enough time and money to keep developing their already existing 10+ yrs old tested and "working" codebases as is, how would anyone switch to a whole new language at this point?

abricq
2 replies
2d10h

Maybe not converting legacy code, but starting new projects in Rust !

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.

robertlagrant
0 replies
2d8h

That's great - I mostly work in Python now and I came from the Java world. My first paid Python project was from that time - a little data munging script I was allowed to write in Python.

accurrent
0 replies
2d4h

Im in a similar position to you. My manager loves rust, so Im fortunate... Weve been developing new tools in rust. Some greybeards actively oppose it though. Im not asking for rewrites but at least new stuff should be written with more modern tools. Rust aint perfect but its hell of a lot better than C++ and CMake magic. My experience has been we can build features far faster with rust than C++ and we deal with legitemate bugs not "which idiot forgot to check the bounds of this array?". I think the biggest pitfall for rust howver is its difficulty in interoping with C++ and the unstable ABI (given how much the robotics community love C++ plugins...).

throw10920
0 replies
1d14h

The amount of time our industry wastes on C++isms is ridiculous where rust just works.

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.

abricq
5 replies
2d10h

I want to make this happen ! Do you know of any good robotics framework in Rust, as of today ? I heard that ROS2 was slowly including Rust [1], not sure at how did it go. Ros would be a good entry door to sensor fusion, mapping and localization. Because all of the hardware integration / abstraction is already done (in C++). I'm curious to know if company are using this.

[1] https://github.com/ros2-rust/ros2_rust

fvncc
2 replies
2d4h

You can also check https://github.com/sequenceplanner/r2r for another example of ROS2 bindings (using in production at work for a couple of ROS nodes).

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.

porphyra
1 replies
2d

Yeah the ROS node architecture sucks. However, one reason for that design was so that you can run ROS on distributed systems where things communicate to each other over the network.

fvncc
0 replies
1d18h

Actually another reason people use the architecture is for process level isolation, i.e. limiting the blast radius of memory corruption. But in both cases, Im sure you could design an ergonomic RPC framework that takes care of offloading computation mostly transparently behind the scenes :)

singhrac
0 replies
2d10h

Maybe the folks at Rerun [1] know something about it? I imagine at least some of their customers are Rust robotics shops.

[1] https://github.com/rerun-io/rerun

porphyra
0 replies
2d

The only Rust robotics shop I know of is Tangram Vision so you might try asking them? https://www.tangramvision.com/

p4ul
0 replies
1d15h

Yes! I couldn't possibly agree more; this is truly my fondest wish!

infogulch
11 replies
2d12h

I got sucked down a Geometric Algebra rabbit hole a few months ago, which seems like a remarkably concise and intuitive way to work in a very wide variety of geometries, including 2D, 3D, 4D+, non-euclidean etc. I've wondered if GA would make a good foundation for a physics engine...

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

falcor84
1 replies
2d9h

Why "still"? Have you intentionally decided to move away from GA? If so, why?

xixixao
0 replies
1d13h

Because it was a while ago and I wouldn’t be surprised if someone ripped it out.

It’s a bit of an overkill for what it’s used for / the fact that it is not used widely in the app.

chrisjj
0 replies
2d4h

Interesting. What advantage did this gain?

meindnoch
2 replies
2d7h

A physics engine's least interesting part is the vector representation. Geometric Algebra is isomorphic to "classical" (i.e. Heaviside) vector algebra.

Collision handling, energy conservation, stability, etc. are the hard problems.

infogulch
1 replies
2d2h

Fair. I guess the promise of a GA-based physics engine is in the implementation as development velocity and how much work it takes to get decent performance, but that wouldn't necessarily translate to users.

meindnoch
0 replies
1d20h

Actually, performance of GA-based approaches tend to be worse than classical vector algebra. The general multivector in a geometric algebra over an n-dimensional space has 2^n components. The general geometric product is a 2^(2n) components!

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.

justincredible
0 replies
2d

My layman understanding would be that you're not gaining anything other than a more abstract model. If you want performance, the code is going to boil down to the equivalent linear algebra + quaternion operations.

jordibc
0 replies
2d

Well, I got sucked down the same Geometric Algebra rabbit hole, plus another "remarkably concise and intuitive way" one too, which is Clojure.

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/

amne
5 replies
2d9h

What is the main feature? I hope it's not "Rust".

lukan
2 replies
2d4h

Quite fast, because of a parallel algorithm. Many benchmarks said so, too.

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.

dncornholio
1 replies
2d3h

So maybe you could have listed all the reasons you opted to switch to Rapier? Or was it the benchmark results?

lukan
0 replies
2d3h

"Or was it the benchmark results?"

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.

timeon
0 replies
2d7h

That is important feature if you want to use it within Rust code-base.

gs17
0 replies
2d2h

It's effectively the only physics engine for Rust, so that's an important feature.

chrisjj
2 replies
2d

I am the only one feeling queasy at a system that treats slow-moving as non-moving?

) 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

rcxdude
1 replies
2d

It's a pretty common physics engine optimisation. Yes, it's inaccurate, but the performance gains are often too big to pass up.

chrisjj
0 replies
1d21h

It is not an optimisation, note.

manuel2258
0 replies
2d11h

I'm currently using xpbd to work on a physics driven 2d fighting game, and as of right now, I'm really enjoying it! Until now there was only one problem where some collisions would vanish for one frame. But stuff like that can be easily worked around and even better reported and fixed.

01HNNWZ0MV43FF
0 replies
2d11h

XPBD has caught my fascination. I've done a couple trial implementations and put AABB-only XPBD in my latest game jam.

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.

evrimoztamur
4 replies
2d11h

I built a game using Rapier! Using its deterministic mode, I built an online multiplayer game whereby players take turn slamming bugs against the other team and capture the hill.

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.

abricq
1 replies
2d11h

Looks real fun. Was it easy to deploy it on your website ? did you compile in web-assembly ? Or are you hosting all the logic onto a local server ?

evrimoztamur
0 replies
2d7h

For the deployment, I am running the server applications for both Maginet (https://evrimzone.itch.io/maginet) and Critter Showdown on the same $5 server, under a different subdomain. These subdomains are reverse-proxied by nginx behind Let's Encrypt certificates. Game servers host lobby and game logic, and are compiled to native Rust binaries. The client-side is compiled to WebAssembly (I don't use an engine, so it's all wasm-bindgen) and the Steam version (of Maginet) is just a thin Electron wrapper around the same thing that runs in the browser. In both games, the client and server share all the game related logic, with the server orchestrating synchronization of states, and client wrapping it all with the I/O.

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.

excsn
0 replies
2d5h

I've actually started using Rapier2D to write a multiplayer game on the server side, so I hope to see your post soon.

dnadler
0 replies
1d4h

Thanks for posting this project! I’ve been curious about wasm with rust and I found your code to be really easy to follow, and gave me a really good idea of how I could get started with a similar project. Kudos!

hnben
3 replies
2d7h

How good is it suited for neuro evolution? i.e.:

* 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?

lukan
2 replies
2d4h

Are you sure, you are in the right thread?

Nothing runs on GPU here, no NPCs, no game engine. This is a physic engine.

lostdog
1 replies
2d

NVidia has a physics engine that runs on the GPU. It is really useful if you're training neural nets, which also run in parallel on the GPU. That's probably what the other poster was thinking about when they asked.

lukan
0 replies
1d23h

I know about PhysX (have not tried it out, though) but it is news to me, that its hardware part is also really useful for training neural nets? More so than the ordinary GPU?

rollulus
2 replies
2d8h

From building a rigid body physics engine decades ago I remember that stacking was a very hard problem. The best solution at the time to avoid objects sinking into the ground was to create a directed acyclic graph, starting with the ground and pushing bodies outward. It required multiple iterations to converge and felt very hacky. Does anyone know if this problem has been solved nowadays? I couldn’t find any mention of stacking in this project.

TinkersW
0 replies
2d3h

Stacking works fine today.. you don't need a acyclic graph, just run the solver for enough iterations and it will converge, multiple iterations is to be expected given the number of contacts and friction constraints involved. If you track the max residual you can run until it reaches ~0.

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.

mtoner23
2 replies
2d2h

Rust keeps proving the stereotype true lol. 50 game engines written in rust but only 5 games made in rust.

gs17
0 replies
2d2h

I wish there were 50 physics engines. Rapier doesn't exactly meet my needs but there's no good alternative.

cyber_kinetist
0 replies
2d

I remember one recent game I've enjoyed was written in Rust: (the) Gnorp Apologue (https://gnorp.dev/).

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)

alex_suzuki
2 replies
2d13h

Anyone know how this compares to something like Box2D? (apart from also supporting 3D)

alex_suzuki
0 replies
2d11h

Thanks, that was informative – albeit a bit focused on performance.

xpe
1 replies
2d5h

Related to 3D but different from physics engines: for those interested in BREP (boundary representation) CAD kernels, you might be interested in the open source Rust project called Fornjot.

digdugdirk
0 replies
1d23h

Thank you! I clicked the link on this one hoping it'd be CAD applicable.

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

iercan
1 replies
2d7h

I tried to build a small web demo with Rapier too https://github.com/iErcann/NotRoblox (no rust)

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?)

gs17
0 replies
2d2h

What I like : - Good documentation compared to AmmoJS (you need to read pybullet)

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.

shdh
0 replies
2d12h

How does it compare to Jolt?

sebular
0 replies
2d

I made a simple web game using Rapier that takes advantage of the deterministic physics to prevent cheating by running physics and computing win/loss states on the server (though I stupidly haven’t implemented the high score board yet).

It’s an homage to the old Taito electric arcade game “Ice Cold Beer”

https://beerbubble.xyz

prashp
0 replies
2d3h

The demos don't work on Firefox 123.0 for me

coolvision
0 replies
1d5h

I tried to make a robot simulator with rapier, with a mixed sucess: https://grgv.xyz/blog/simulator4/ The performance is great but realism of joints and motors is lacking, and not suitable realistic simulation.

catapart
0 replies
1d22h

Oh awesome! I was just putting together some utilities for a barebones, no-bundler, vanilla javascript game library, and was wondering what kind of physics engine would work for demonstrating it. This looks perfect! I love that you already have the compatibility libraries available.

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!

anasrin
0 replies
2d10h

Using rapier along side three js, overall I really like it. But lack of documentation on wasm make me jump back and forth on rust version

WanderPanda
0 replies
2d3h

How does it compare to MuJoCo?

LoganDark
0 replies
2d5h

These guys (Dimforge) used to have a physics engine called nphysics that supported soft bodies and multibodies. It's now been deprecated in favor of Rapier, which doesn't support those or half the other things that nphysics did. As a result, nphysics is so old that it can't be used with the modern ecosystem, but Rapier is so new that it's far less capable.

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.