
Show HN: BepuPhysics – 3D real-time physics simulation library in C# - rossnordby
https://github.com/bepu/bepuphysics2
======
theprotocol
This is very impressive! But honestly I am here to comment about the humor in
the demo video. The section towards the end starting from the shrinkwrapped
newts genuinely made me laugh.

~~~
rossnordby
I'm glad someone respects newt rights.

~~~
mythz
Came to say the same thing, fun story, great demo!

Are there any other demos/games built with the library yet?

~~~
rossnordby
I know some people are fiddling with it, but I'm not aware of any public
projects using v2 yet. It's pretty darn early still- convex hulls got added
only a few weeks ago.

I did build it for a reason, though- over the coming weeks I'll be diving into
actually making stuff with it. That'll be a nice change of pace.

------
Vanit
V2 has been a looooong time coming, kudos to the bepu team. For those
wondering why C#, one word; monogame. (And previously, xna)

~~~
rossnordby
Thanks! XNA and its descendants have definitely had a big impact.

(I remember early on sketching out the development plan for v2 and coming up
with like 9 months of work... Things escalated.)

------
gitgud
Great (and humorous) video demo, Could this be made cross-platform using Mono
or .NET Core?

~~~
rossnordby
Yup! The library itself is .NET Standard 2.0, so it'll run anywhere with a
supporting runtime. The only issue is that some older JITs don't understand
the SIMD intrinsics and will either barf or run 100x slower.

------
lostmsu
Should not one use GPGPU for physics to get the best performance? Does not
seem like your library does that.

Also, do you have a performance comparison with other physics engines?

~~~
rossnordby
I feel a little gross about headlining aggressive benchmarks with other
engines, especially since most of them are free and open source just like
bepuphysics. Plus, I learned a lot from projects like bullet, box2d and
friends. I'd recommend potential users benchmark their use cases for
themselves- those are the most trustworthy benchmarks anyway.

Regarding GPGPU, you're correct that bepuphysics v2 is strictly CPU-side, and
also that I could likely make a GPGPU version faster. I wrote a blog post
about why I chose to go with CPU-only:
[https://www.bepuentertainment.com/blog/2019/1/16/-but-
gpus-a...](https://www.bepuentertainment.com/blog/2019/1/16/-but-gpus-arent-
always-the-right-choice)

The short version is comparative advantage. I have other things to use the GPU
on, and the GPU is even better at those things. And driver bugs.

Also, as I've mentioned elsewhere, while I have not done rigorous
benchmarking, a casual evaluation showed that bepuphysics v2 on the CPU
compares well with physX 4.1 running on a GPU of similar cost. Collision
detection heavy scenes tend to favor GPU physX, while solver-heavy scenes tend
to favor bepuphysics v2.

(Except for AMD's Threadripper CPUs unclear reasons. I suspect inter-CCX
communication kills effective memory bandwidth in the solver. A 1700x is about
as fast as a 2950x, and modern Intel cpus with full rate AVX2 can be much
faster. Zen 2 should change things significantly.)

~~~
Const-me
Agree with almost everything.

> if you want to run physics serverside, it’ll probably need to run on things
> that aren’t windows

On the other hand, you’re in control of hardware. For some kinds of projects,
CUDA saves lots of time compared to DirectCompute or OpenCL: better libraries
(these hand-optimized BLAS, FFT, etc.), better runtime i.e. simpler CPU-GPU
interop, and better language, CUDA is relatively modern C++, with templates
and constexpr. Unlike graphics, CUDA runs fine on Linux.

I’m not an expert in CUDA but I’ve completed a couple of projects where my
clients needed to compute some GPGPU stuff on their servers, or on other
people’s servers they’ve rented.

~~~
rossnordby
Yup- if you have control over the entire deployment, more reasonable options
open up.

For my purposes, CUDA isn't really an option due to needing to run simulations
on both servers and unknown clients (ideally with a single codebase), but for
other services that never leave the datacenter I'd definitely consider it.

------
tadeusz_wojcik
Well done! love the intro vid.

~~~
rossnordby
Thanks!

------
xchip
Good stuff, just a question, why c#?

~~~
electricslpnsld
Not op, but outside of C++, C# is probably the widest deployed language (on
the CPU) in the game industry by virtue of the Unity engine.

~~~
rossnordby
To make things a little stranger, it's worth mentioning that I'm not sure if
bepuphysics v2 works well with Unity right now. Attempts in the last several
months by users trying to upgrade from v1 to v2 had... less than ideal results
under that runtime.

The library is .NET Standard 2.0 compliant, though, so in theory it should
work. It may require some extra work on the runtime side of things. As time
goes on, I'd hope that mono/CoreRT or whatever the AOT story ends up
being/CoreCLR converge and Unity can embrace them for all their target
platforms. (Burst is also an option, but that would require a massive rework
in bepuphysics that I can't really afford to do given that my projects aren't
on Unity.)

------
ncmncm
What makes "pure" a notable or (presumably) desirable quality? If bits of it
were in C++, and that made it faster, how would that make it less useful?

~~~
rossnordby
I included that for a couple of reasons: 1) It's unusual. Historically, C# is
more of a businessy thing, with a bit of game stuff on the side, mainly in the
form of scripting. Extremely high performance C# code is even stranger. 2)
It's more easily portable than a mixed library. It's definitely not impossible
to make/use a cross platform mixed library (they're all over the place), but
depending only on one toolchain is just less complicated.

So not a big deal, just a notable quirk.

~~~
electricslpnsld
> 1) It's unusual. Historically, C# is more of a businessy thing, with a bit
> of game stuff on the side, mainly in the form of scripting. Extremely high
> performance C# code is even stranger.

Unity is C#, no? I remember reading that they are moving most of the
traditionally C++ 'backend' engine code to C# now, too.

Edit: Found the article:
[https://lucasmeijer.com/posts/cpp_unity/](https://lucasmeijer.com/posts/cpp_unity/)

~~~
rossnordby
Unity is in the process of moving more of their codebase into C#, backed by
some in-house compiler work, yes. And they did indeed use C# extensively
before then for game scripting, even if not exactly 'pure' or high performance
in the same sense.

The work in Unity's Burst/HPC# is very recent, though, and the
CoreCLR/language features I rely on in bepuphysics are still pretty obscure. I
wouldn't expect most people outside of the weird niche I live in to know about
the ecosystem's progress.

In other words, I was just trying to get an unaware visitor to raise an
eyebrow.

