[HN Gopher] Rapier is a set of 2D and 3D physics engines written...
___________________________________________________________________
Rapier is a set of 2D and 3D physics engines written in Rust
Author : excsn
Score : 306 points
Date : 2024-02-27 03:39 UTC (19 hours ago)
(HTM) web link (rapier.rs)
(TXT) w3m dump (rapier.rs)
| calebpeterson wrote:
| Really good JS interoperability too:
| https://www.rapier.rs/docs/user_guides/javascript/getting_st...
| Sateeshm wrote:
| And Threlte (ThreeJS in Svelte) has great rapier integration
|
| https://threlte.xyz/docs/reference/rapier/getting-started
| GenericCanadian wrote:
| I wrote a guide on the Bevy plugin for Rust which you can read
| here: https://taintedcoders.com/bevy/rapier/
|
| An interesting alternative in the Bevy space is Bevy XPBD which I
| also wrote about: https://taintedcoders.com/bevy/xpbd/
| 01HNNWZ0MV43FF wrote:
| 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.
| manuel2258 wrote:
| 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.
| chrisjj wrote:
| 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 wrote:
| It's a pretty common physics engine optimisation. Yes, it's
| inaccurate, but the performance gains are often too big to
| pass up.
| chrisjj wrote:
| It is not an optimisation, note.
| porphyra wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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...).
| abricq wrote:
| 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
| singhrac wrote:
| 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
| fvncc wrote:
| 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 wrote:
| 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.
| porphyra wrote:
| The only Rust robotics shop I know of is Tangram Vision so
| you might try asking them? https://www.tangramvision.com/
| alex_suzuki wrote:
| Anyone know how this compares to something like Box2D? (apart
| from also supporting 3D)
| excsn wrote:
| Might be interested in
| https://www.youtube.com/watch?v=wgUiZ7E19eM
| alex_suzuki wrote:
| Thanks, that was informative - albeit a bit focused on
| performance.
| infogulch wrote:
| 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 Holmer's Why
| can't you multiply vectors? -
| https://www.youtube.com/watch?v=htYh-Tq7ZBI - Then
| https://bivector.net/index.html
| xixixao wrote:
| Fun fact: I used GA in Excalidraw, and it's still powering some
| of the interactions!
| https://github.com/excalidraw/excalidraw/blob/master/package...
| falcor84 wrote:
| Why "still"? Have you intentionally decided to move away from
| GA? If so, why?
| chrisjj wrote:
| Interesting. What advantage did this gain?
| msvan wrote:
| This one has some more traction:
| https://github.com/fu5ha/ultraviolet
| meindnoch wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kame3d wrote:
| Relevant tutorial: https://www.youtube.com/watch?v=5R2sv9GCwz0
| jordibc wrote:
| 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/
| shdh wrote:
| How does it compare to Jolt?
| evrimoztamur wrote:
| 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 wrote:
| 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 wrote:
| 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/ma
| ginet/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 wrote:
| I've actually started using Rapier2D to write a multiplayer
| game on the server side, so I hope to see your post soon.
| sillysaurusx wrote:
| I'll never be able to read "rapier" and not think of
| https://youtu.be/K_rZ27Jdc00?si=rqibtrXl-Wpa49gr
| anasrin wrote:
| 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
| amne wrote:
| What is the main feature? I hope it's not "Rust".
| timeon wrote:
| That is important feature if you want to use it within Rust
| code-base.
| lukan wrote:
| 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 wrote:
| So maybe you could have listed all the reasons you opted to
| switch to Rapier? Or was it the benchmark results?
| lukan wrote:
| "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.
| gs17 wrote:
| It's effectively the only physics engine for Rust, so that's an
| important feature.
| rollulus wrote:
| 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.
| QuadmasterXLII wrote:
| The author of Box2D just put out a fantastic blog post on
| exactly that subject:
|
| 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
| TinkersW wrote:
| 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.
| hnben wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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?
| bambax wrote:
| On the same topic I really like Matthias Muller's lectures and
| simple and readable JS code "Ten Minute Physics"
|
| https://matthias-research.github.io/pages/tenMinutePhysics/i...
| iercan wrote:
| 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 wrote:
| > 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.
| xpe wrote:
| 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 wrote:
| 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
| LoganDark wrote:
| 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.
| WanderPanda wrote:
| How does it compare to MuJoCo?
| prashp wrote:
| The demos don't work on Firefox 123.0 for me
| mtoner23 wrote:
| Rust keeps proving the stereotype true lol. 50 game engines
| written in rust but only 5 games made in rust.
| gs17 wrote:
| I wish there were 50 physics engines. Rapier doesn't exactly
| meet my needs but there's no good alternative.
| cyber_kinetist wrote:
| 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)
| sebular wrote:
| 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
| ixxie wrote:
| If you are into Svelte we have a nice API for you:
| https://threlte.xyz/docs/reference/rapier/getting-started
| catapart wrote:
| 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!
___________________________________________________________________
(page generated 2024-02-27 23:01 UTC)