
NPhysics: 2D and 3D Real-Time Physics Engine for Rust - ArtWomb
https://nphysics.org/
======
erichocean
Anyone know if there is a Rust equivalent to Intel's Embree[0] library (high
performance ray tracing kernels)?

[0] [https://www.embree.org/](https://www.embree.org/)

~~~
fuoqi
I think your best bet will be to use a wrapper around it:
[https://docs.rs/embree-rs](https://docs.rs/embree-rs)

------
onion2k
This looks great. I've used most of the popular JS physics libraries (matter,
p2, cannon, ammo, box2dJS, etc) and while they're all good they all have a few
JS-related drawbacks (mainly around garbage collection killing performance
occasionally.) Having something WASM based _could_ address some of that.

~~~
reitzensteinm
I remember releasing a game written in Haxe for the original iPad. It ran
quite slowly.

I had to hack up the Box2D port to pool short lived objects that would
normally exist on the stack.

Which was kind of frustrating, as it was all compiled back down to C++ again
anyway.

------
raxxorrax
Didn't look at rust too much, but I love this already. Will try it out.

Body deformation is mentioned as a feature. Is this equivalent to what other
renderer call soft body physics opposed to rigid body physics? And can I treat
such an object as a rigid object again if I wanted to and can I have compound
objects with soft and rigid parts? Had some problems with that in some
renderers.

Here is an example of what I would basically understand under that term:

[https://www.babylonjs-playground.com/#480ZBN#2](https://www.babylonjs-
playground.com/#480ZBN#2)

This is babylon.js with ammo.js (I think it is ammo.js for the physics part).

~~~
j-pb
I think so.

Check out the demos in your browser:
[https://nphysics.org/all_examples3/](https://nphysics.org/all_examples3/)

Also check out the fluid simulation engine that is a sister project of
nphysics: [https://salva.rs](https://salva.rs)

------
dotaheor
A silly question: how to build the examples? I haven't found a build tutorial
in the project.

As a rust newbie, I guess I should run in "cargo build" in the example
folders. But both output the error

error[E0463]: can't find crate for `std`

What I missed here?

~~~
DerSaidin
Stay in the main folder and run: cargo run --example foo

~~~
dotaheor
It looks the "install.sh" script must be executed by an admin to install the
tools in some system folders. Setting the bin folders in PATH doesn't work,
and error message is totally useless to explain why the way doesn't work.

------
Lichtso
Very cool, I was just reading about constraint solvers and position-,
velocity- / impulse-, forced-based dynamics etc the last few days and wondered
how hard it would be to do a physics engine from scratch.

As far as I can tell, this is single threaded CPU only, right? I wonder if it
wouldn't be more appealing to do it parallel on the GPU instead when starting
a new physics engine today, especially given how hard it is to change that
later on.

~~~
zelphirkalt
There was an article on HN not too long ago, where the title was something
like: "When in parallel pull, not push". It was about calculating sand pile
fractals and how pulling strategy removes the need of locking. I guess for a
physics engine the same principle applies. Instead of telling objects, that
they are being pushed, let objects themselves ask whether they are pushed,
pulling the information readonly from their environment. You would need really
light weight processes for situations with many bodies though.

~~~
Diggsey
It would be tricky: constraint solving is a single-threaded algorithm, so the
best option might be to run the broad-phase, and then break the scene down
into islands of disconnected bodies for parallel constraint solving.

The problems are that: 1) There may not be enough islands to make full use of
the available threads. 2) For many frames there might be a single island which
is particularly expensive to solve, so the benefit from parallelisation is
reduced.

The broad-phase itself might benefit significantly from parallelisation
though.

~~~
rossnordby
While island based parallelism is doable and works reasonably well for many
workloads, it's possible to dynamically batch constraints based on their
involved bodies such that no constraints in a given batch share the same
bodies. All constraints within each batch can be solved in parallel.

Of course, pathological cases can generate a ton of batches. Usually such
implementations will use a final 'catchall' batch of some kind after N normal
batches. That final batch can be handled sequentially or with a fully parallel
jacobi-ish solver (which typically has worse convergence than PGS/SI, but it's
usually not a problem in context).

------
ghusbands
Is anyone out there working on continuous physics engines? This, like most any
physics library I can find, uses the fix-after-intersecting fixed-time-step
model, which makes everything act like a stiff sponge, even if you greatly
increase the number of iterations per frame.

Carmageddon 2 (as the last example I can think of) instead found out when the
next intersection would happen, precisely, moved time forward exactly that far
and then resolved the collision using impulses and would then repeat until it
reached a frame's worth of time. In pathological cases, this resulted in a
frame taking nearly a second, but that was rare and the physics were much less
spongey and more realistic.

~~~
Lichtso
It does CCD:
[https://nphysics.org/continuous_collision_detection/](https://nphysics.org/continuous_collision_detection/)

Not sure if that is what you had in mind. Also, intersections / collisions
aren't the only dynamic in such a simulation.

~~~
ghusbands
> It does CCD

Intersection and post-correction still seems to be present (and the
sponge/spring behaviour) in demos even when you increase CCD steps and enable
sub-stepping. Look at how much the bottom cubes/spheres intersect when the
stack lands. (It's hard to tell what the demo called CCD is demonstrating.)

> intersections / collisions aren't the only dynamic in such a simulation.

Fair. (Contact points and friction also seemed more stable/realistic in
Carmageddon 2 than in most physics libraries.)

~~~
dfbrown
There are two separate things here, interpenetration due how
contacts/constraints are solved, and whether you do continuous collision sub-
stepping or not.

For stability and performance reasons physics engines usually have parameters
that soften or add compliance to contacts/constraints. A bit of compliance is
almost always better than infinitely stiff collisions/constraints. There are
cases where infinitely stiff systems either have no solution, are very
expensive to solve, or would produce very extreme impulses (causing things to
explode). Including some compliance fixes these issues. It is also often
required to produces more realistic looking results since objects in real life
aren't infinitely stiff, they either flex or break.

For performance reasons most physics engines also do not completely solve
their constraints. They either use a fixed number of iterations (most common,
including the demos here) or solve up to some specified error threshold. This
tends to add some additional compliance to complex scenes (stacks/piles of
objects for example).

With the right parameters a good rigid body physics engine should be able to
prevent noticeable interpenetration in most situations, though the performance
cost may not be worth it. In these demos if you max out Position iterations,
velocity iterations, and frequency you should see significantly less
interpenetration.

As for continuous collision detection/sub-stepping, this is a very common
feature to prevent fast moving objects from clipping into or tunneling through
other objects. However resting/continuous contact cannot be handled by
stepping to the next intersection time and so have to be handled differently.
Also multiple simultaneous or near simultaneous collisions can grind things to
a halt in degenerate cases (such as multiple stacked objects that are almost,
but not quite in resting contact). This is why physics engines that support
continuous collision usually let you set a maximum number of sub-steps.

------
cs702
Gosh, it seems every day I see a new shiny thing made with Rust that was
developed remarkably quickly, runs quite smoothly, and appears to be magically
bug-free.

I'm _sooo_ tempted to dive into Rust head-in. Have only dabbled a bit with it
so far. The main thing holding me back at this point is that Rust seems to
lack a decent ecosystem for data science and AI/DL/ML (in particular, a set of
crates that has proven useful and stable in real-world AI/DL/ML applications).

~~~
dabreegster
[http://www.arewelearningyet.com](http://www.arewelearningyet.com) is a good
overview. And if there's something missing, trying to create it yourself could
be a way to learn the language, even if the result doesn't actually do
everything you need.

~~~
cs702
Thank you for sharing that link. The tagline on that page summarizes my views
quite well: "...but the ecosystem isn't very complete yet." It's nice to see
that others are thinking the same. I'll take a look.

~~~
rckoepke
I truly wonder, what is it about this community that leads to such quality
software?

Your reaction to arewelearningyet is similar to how I feel about:

[https://areweguiyet.com/](https://areweguiyet.com/)

However, at least for GUI I know that Raph Levien is really pushing a focus on
GUI at the moment.
[https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020....](https://raphlinus.github.io/rust/druid/2019/10/31/rust-2020.html)

I wish I could contribute more. You really summed up how I feel about Rust:
"It seems every day I see a new shiny thing made with Rust that was developed
remarkably quickly, runs quite smoothly, and appears to be magically bug-
free."

Even the maligned actix web framework in Rust is still leading performance
benchmarks:
[https://www.techempower.com/benchmarks/#section=data-r19&hw=...](https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=db)

