bepuphysics2: a pure C# 3D physics engine for .NET 8

What bepuphysics2 solves, and for whom

bepuphysics2 is a 3D rigid body physics engine written entirely in C#. It is the second version of the BEPUphysics line, described in the README as "a complete rewrite of the C# 3d rigid body physics engine BEPUphysics v1". The problem it addresses is straightforward: if you are writing a .NET application and need objects to collide, stack, roll and rest under gravity, you can add this library instead of writing a solver yourself or binding to a native engine.

The audience is .NET developers. The README states that the BepuPhysics and BepuUtilities libraries target .NET 8 and should work on any supported platform. That is a narrower claim than it sounds. It means the library ships as managed code with no native binary to match against your operating system, which is unusual for a 3D physics engine. Most engines in this space are C++ libraries with language bindings. bepuphysics2 is not.

It is not a game engine. There is no renderer, no scene graph and no editor in the library itself. The repository does contain a Demos application with DX11 and OpenGL variants, but the README presents those as demonstrations, not as part of the shipped library. If you want a full engine, this is one component you would assemble into it.

How the simulation pipeline is put together

The repository is split into two libraries: BepuPhysics and BepuUtilities. BepuUtilities holds shared types and math helpers; BepuPhysics holds the simulation. The README notes that the engine "heavily uses System.Numerics.Vectors types", which is the reason it asks for a compiler that can consume those types well, naming RyuJIT. That is a design decision with a consequence: performance depends on the runtime's handling of SIMD-friendly vector types, so an older or less capable runtime will not give the same results.

On the simulation side, the README lists spheres, capsules, boxes, triangles, cylinders and convex hulls, plus compounds of those shapes and meshes. Constraints are a first-class concept, with the README pointing to a whole directory of constraint types. There is linear and angular continuous collision detection, and a sleep state described as "extremely low cost" for bodies at rest.

The collision pipeline is described as "at least somewhat extensible", with an example custom voxel collidable in the demos. That phrasing is honest about the limit: extensibility exists, but it is not presented as a general plugin system. Scene-wide ray and sweep queries are also listed, and there is a character controller example.

One line in the feature list deserves attention: "Highly nonidiomatic APIs". The author puts this next to "Super speediness". The implication is that the API was shaped around data layout and throughput rather than around the conventions a C# developer would expect. Expect to read the documentation rather than guess method names.

Building bepuphysics2 from source and running the demos

The README does not give a NuGet install command, so this section covers the source build it does document. The README states that the easiest option is a recent version of Visual Studio with the .NET desktop development workload installed, and that Demos.sln references all relevant projects. More detail is in Documentation/Building.md. Because the BepuPhysics and BepuUtilities libraries target .NET 8, your toolchain needs .NET 8 support; the README adds that the engine heavily uses System.Numerics.Vectors types, so a compiler that consumes those types well (it names RyuJIT) is what gets good performance.

Once the repository is cloned, the README gives these commands to run the demos from the repository root:

dotnet run --project Demos/Demos.csproj -c Release
dotnet run --project Demos.GL/Demos.csproj -c Release

The first uses DX11 and is the default. The second uses OpenGL and, per the README, should run on other platforms. Running one of these gives you the demo scene, which is the fastest way to confirm that the library builds and runs in your environment. The README does not document a minimal code sample for creating a simulation, so the demos are the practical starting point for learning the API shape.

If you want the library without the source tree, the README does not describe a package install, so confirm on NuGet whether a package exists and which version it carries before you plan around it.

Where bepuphysics2 stops being the right tool

The most concrete limitation is the release status. The most recent releases listed are 2.5.0-beta.29, 2.5.0-beta.28 and 2.5.0-beta.27. The version line is beta. That does not mean the code is unused or unmaintained; the last push to the repository was on 2026-09-19, days before this writing. It does mean the project does not present a stable release channel, and an API you build against may move.

The second limitation is the API itself. The README calls the APIs "highly nonidiomatic". For a developer used to fluent, object-oriented C# interfaces, the learning cost is real. The documentation exists at docs.bepuphysics.com, and the README even notes fallbacks if that page or its redirect breaks, which tells you the docs are maintained but not treated as a guarantee.

Third, the library is a simulation, not a product. There is no editor, no serialization format described in the README, and no rollback or networking layer mentioned. If your project needs deterministic lockstep across machines, the README does not document that capability, and you should treat it as unverified rather than assume it.

Finally, if your target is a platform where .NET 8 is not available, the library is simply not an option. The README's platform claim is conditioned on .NET 8 support.

How bepuphysics2 differs from Jolt Physics and other engines

The related searches put bepuphysics2 next to Jolt Physics and Jitter Physics, and the comparison is worth making explicitly. Jolt Physics is a C++ engine. Its approach is native code with bindings for other languages, which typically means a native binary per platform and an interop layer in your .NET project. bepuphysics2 takes the opposite approach: managed C# all the way down, relying on System.Numerics.Vectors and a capable JIT for performance. The trade-off is that you avoid native build and deployment complexity, but you also give up the ability to use the engine from a non-.NET host without a bridge.

Jitter Physics is the closer comparison, since it is also a .NET physics engine. The README does not discuss Jitter, so any difference beyond language and platform is not something this material can establish. What can be said is that bepuphysics2 is a rewrite of an earlier engine rather than a first attempt, and the README states that directly.

For Unity users, the related searches suggest interest in Unity integration. The README says nothing about Unity. Unity has its own physics engines, and bepuphysics2 targets .NET 8, which is not the same runtime Unity uses. Anyone searching for a Unity path should treat that as an integration project they would have to build, not a supported configuration.

Maintenance, licensing and the upgrade question

The repository is not archived, and the last push was on 2026-09-19. That is recent activity. The release cadence, however, is uneven: 2.5.0-beta.29 landed on 2026-04-21, 2.5.0-beta.28 on 2026-03-01, and 2.5.0-beta.27 on 2025-09-07. There is a gap of roughly six months between beta.27 and beta.28. If you depend on tagged releases rather than the master branch, plan for stretches without a new version.

The licence is Apache-2.0. That is a permissive licence, which generally means you can use the library in commercial and closed-source projects, but the terms are the terms and this is not legal advice. Read LICENSE.md in the repository if the distinction matters to your organisation.

Upgrade cost is the open question. Because the current line is beta, moving between betas can involve API changes, and the README does not document a deprecation or migration policy. The practical approach is to pin the version you build against and read the release notes before moving. The README does not describe rollback procedures, so treat version pinning as your rollback mechanism.

Editorial conclusion

Adopt bepuphysics2 if you are building a .NET 8 application and want a 3D rigid body simulation without leaving C#. Do not adopt it if you need a documented, stable API surface for a production engine right now, because the current release line is still labeled beta. Before committing, verify the exact version you need on NuGet, check that your target platform can run the library, and read the Documentation folder and docs.bepuphysics.com for the API details the README does not cover.

Frequently asked questions

Official sources

1. bepu/bepuphysics2 on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases