This repository contains low-level bindings for JoltPhysics (via JoltPhysicsC) used in Evergine.
JoltPhysics is a high-performance, multi-core friendly rigid body physics engine written in C++. JoltPhysicsC provides a pure C API layer, and this repository auto-generates .NET P/Invoke bindings from those C headers using CppAst.
- Full JoltPhysics C API — Covers the complete JoltPhysicsC surface: physics system, body management, shapes, constraints, queries, character controllers, vehicles, skeletons, and ragdolls
- Auto-generated bindings — Generated from JoltPhysicsC headers using CppAst; easily regenerated when the upstream API evolves
- Blittable structs — Math types (Vec3, Quat, Mat44, etc.) and settings structs are blittable, allowing zero-copy interop
- Unsafe raw pointers — Native pointer semantics preserved for maximum performance
- Pre-built native libraries — Ships with JoltPhysicsC binaries for all supported platforms
- Windows x64
- Windows ARM64
- Linux x64
- Linux ARM64
- macOS ARM64
- Android ARM
- Android ARM64
- iOS ARM64
- iOS Simulator ARM64
- Browser WASM
Ten runtime identifiers ship. Nine of them are checked against the real .nupkg before a
release is published, and a failure stops the publish. What that check is worth differs, and the
difference is worth knowing rather than glossing:
| how it is checked | |
|---|---|
| the five desktop identifiers | the package is installed and a sphere is dropped onto a floor through the native library, which has to fall, settle, and settle on the floor |
browser-wasm |
the same, under node, against the archive linked into the application at publish time |
iossimulator-arm64 |
an application is linked against the package and its executable has to define the entry points, not merely reference them |
ios-arm64 |
not verified directly. A device build needs a signing identity CI does not have. It links the same archive through the same targets file as the simulator, so the evidence is indirect |
android-arm, android-arm64 |
an APK is built against the package and opened, and both libJoltC.so have to be inside it, over a megabyte each, with no other ABI alongside. The libraries themselves are not executed |
iOS works differently from every other identifier and you do not have to do anything about it:
Apple only lets an application load dynamic libraries that ship inside its own bundle, so the
package carries a static archive and a buildTransitive targets file links it into your
application at build time.
dotnet run --project JoltPhysicsGen/JoltPhysicsGen.csprojdotnet build Evergine.Bindings.JoltPhysics/Evergine.Bindings.JoltPhysics.csprojdotnet pack Evergine.Bindings.JoltPhysics/Evergine.Bindings.JoltPhysics.csproj -c Releasedotnet test Tests/JoltPhysics.APITests/JoltPhysics.APITests.csproj -c Debug -r win-x64| Workflow | Trigger | Description |
|---|---|---|
| CI | push/PR to main |
Build and validate bindings |
| CD | manual | Regenerate bindings and publish NuGet |
| Sync standards | monthly / manual | Sync shared scripts from evergine-standards |
See LICENSE.