Anvil Physics brings the Box3D solver to Unity as a first-class citizen: one native core, two APIs, and the same deterministic result on every run.
Use it the way your project is built. Drop AnvilBody onto a GameObject and it behaves like a rigid body you already know. Or go wide with DOTS and drive tens of thousands of bodies from Burst-compiled systems. Both paths share the same solver, the same settings asset and the same debugging tools, so a prototype built on GameObjects does not have to be rewritten when it grows into an ECS project.
WHY IT IS FAST
The solver is native C, stepped through Unity's job system with a worker count that matches your machine. Nothing is allocated on the managed heap during a step, so there is no garbage collection spike in the middle of gameplay. Bodies that stop moving go to sleep and stop costing anything at all.
Measured on a Ryzen 7 7700X (16 cores), Unity 6000.5.2f1, 600 steps after 60 warm-up steps, identical seed, identical 1/60 time step, 4 sub-steps, rendering disabled:
5,000 falling boxes, median step time
1,000 falling boxes, median step time
Managed allocations per step: 0 bytes for every engine above.
These are medians, and that choice matters. Anvil puts a settled pile to sleep, so a third of the samples in a 600-step run cost almost nothing; averaging them would flatter us. On the same runs the mean for Anvil is 1.22 ms where the median is 1.63 ms, while for Unity Physics the two barely differ. Quoting the mean would buy us a "4x faster" headline that your own measurement would not reproduce.
By the median, at 5,000 boxes the DOTS path is 2.9x faster than built-in PhysX and 2.8x faster than Unity Physics; the GameObject path is 2.5x and 2.3x. Sleeping is then a separate win on top of the raw speed: after 394 steps the Anvil pile costs nothing at all, while Unity Physics was still simulating every box and PhysX still had 4,823 of them awake.
At 20,000 boxes the same test gives 7.99 ms on the DOTS path and 9.73 ms on GameObjects, against 17.75 ms for Unity Physics and 23.40 ms for built-in PhysX.
The benchmark that produced these numbers ships with the package, so you can reproduce them on your own hardware instead of taking our word for it. Run Tools > Anvil > Benchmarks, pick the engines and body counts, and the results land in a CSV and a JSON file with your CPU, GPU and Unity version recorded in the header, alongside the seed, the fixed step and the sub-step count, so a run can be compared against another.
WHAT YOU GET
Rigid bodies with box, sphere, capsule, convex hull, mesh and height-field shapes. Joints. Sensors and trigger events. Ray, shape and overlap queries callable from Burst jobs. Contact events carrying impulse and normal, so hit reactions and audio can respond to how hard something actually landed. Debris helpers and explosion impulses for destruction. A collision layer matrix that reads like Unity's own. Wind: one wind velocity on the world, and only the bodies you opt in feel it, so leaves and debris move in a storm while crates and dropped loot stay exactly where they are.
COMING FROM PHYSX AND UNITY PHYSICS
Two converters, one for each engine you might be leaving. Window > Anvil > Convert PhysX to Anvil scans a scene or a selection, lists every body it can convert, and replaces it with an Anvil body in one undoable step. Motion type, mass, gravity, both damping values, constraints, interpolation, collision layer, trigger flag and physics material are carried over. Anything it cannot convert is listed with the reason instead of being silently skipped, so a compound collider or a joint never turns into a half-migrated body you find out about at runtime.
Window > Anvil > Convert Unity Physics to Anvil does the same for DOTS projects built on PhysicsBodyAuthoring and PhysicsShapeAuthoring, carrying over motion type, mass, gravity factor, both damping values, smoothing, friction and restitution (including values inherited from a material template), the collision-response flag and the belongs-to layer. Shapes it cannot represent, a capsule that does not run along Y, a compound, a body another joint depends on, are refused by name rather than half-converted.
Mass survives the trip exactly in both converters, boxes, spheres, capsules and convex hulls alike: density is fitted to the shape, and the resulting body mass is then pinned to the source value, so a 7.5 kg crate is still 7.5 kg after conversion. Density continues to drive how the inertia is distributed, which is what you want when the hull the solver cooks is not the mesh you handed it.
DETERMINISM
Same input, same result, on the same build and the same platform. The recording API captures a session and replays it, which turns a physics bug from an anecdote into something you can step through.
SUPPORT
Questions and bug reports go to our Discord, where fixes are discussed in the open and ship in the next version on the Asset Store. The package tells you in the editor when a newer version is available. Buyers who verify their invoice number on the Discord server get a channel where fixes are discussed and tested before they are published; the package itself never checks a licence, never phones home for permission to run, and works fully offline.
The manual and the twelve guides are in English, Simplified Chinese, Japanese and Korean, both inside the package and on the documentation site. The generated API reference, the editor UI and support are in English.
CREDITS
The solver is Box3D by Erin Catto, the author of Box2D, used under the MIT licence and redistributed in binary form inside the native plugin: https://github.com/erincatto/box3d
Anvil is the Unity side of it - the C# facade, the GameObject and DOTS APIs, baking, editor tooling, converters, tests and documentation. Full notices ship in THIRD PARTY NOTICES.md.