rapier VS box2d-wasm

Ok, so this uses https://rapier.rs/ which is very cool

Rapier, alongside https://nalgebra.org/ (which it uses underneath) has seriously good documentation and some advanced features like cross-platform determinism (something made hard by the way floating point differs between platforms)

Code examples: see examples2d, examples3d-f64 and examples3d directories

What are the pros and cons compared to something like Rapier? When should one use Bevy XPBD instead of Rapier, or vice versa?

Still using Rust in a browser-based multiplayer party game I'm working on! I'm using Actix Web for the backend and rapier2d to handle my game's physics. I'm looking to make some more connections amongst the developer / gaming community through my game down the line.

I have noticed that Rapier 0.17 contains a RopeJoint struct, which constrains maximum distance between two dynamic bodies. It doesn't seem to have found its way into bevy_rapier3d yet so I haven't understood whether it supports (half of) my use case, and looking at the code (https://github.com/dimforge/rapier/blob/master/src/dynamics/joint/rope_joint.rs) I really cannot see how it is actually implemented and how I could extend it to also set a minimum distance, but this may be a place to start.

I was also frustrated with the kcc, so I opened a PR that fixes most of my issues: https://github.com/dimforge/rapier/pull/446

Likewise, see the js bindings of Rapier.

Maybe check out how Rapier does it. Rapier is likely the most advanced physics engine in Rust. (Though Embark Studios is doing some crazy stuff with ML physics.)

rapier

https://github.com/Birch-san/box2d-wasm.) Godot uses box2d, too, so that would be convenient, if I switch to godot, but only if it is worth the performance improvement, which it currently does not seem to be. Maybe next year.

Following the article, you build a simple 2D physic simulation (only for balls). Did by chance anyone expand on that to include boxes, or know of a different approach to build a physic engine in WebGPU?

I experiemented a bit with it and imolemented raycasting, but it is really not trivial getting the data in and out. (Limiting it to boxes and circles would satisfy my use case and seems doable, but getting polygons would be very hard, as then you have a dynamic size of their edges to account for and that gives me headache)

3D physic engine on the GPU would be the obvious dream goal to get maximum performance, but that is really not an easy thing to do.

Right now I am using a Box2D for wasm and it has good performance, but it could be better.

https://github.com/Birch-san/box2d-wasm

The main problem with all this is the overhead of getting data into the gpu and back. Once it is on the gpu it is amazingly fast. But the back and forth can really make your framerates drop - so to make it worth it, most of the simulation data has to remain on the gpu and you only put small chanks of data that have changed in and out. And ideally render it all on the gpu in the next step.

(The performance bottleneck of this simulation is exactly that, it gets simulated on the gpu, then retrieved and drawn with the normal canvasAPI which is slow)

box2dwasm - an old, still maintained C++ library compiled to WASM. The documentation is lacking and developer experience seems poor.

network inspector says 2.1MB. but that's dominated by a 1.3MB image.

the main assets of the library are:

- Box2D.simd.js (422kB)

- Box2D.simd.wasm (266 kB)

a minimal demo that uses the library can be created in just a few kB:

https://github.com/Birch-san/box2d-wasm/tree/master/demo/mod...

A couple weeks ago I ported liquidfun to TypeScript + WebAssembly: https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-liquidfun.0