Price history
Recorded standalone sale prices and the latest available store price, in USD. Historical dots use the sale start date and its recorded offer price. Prices can change during a sale; this is not a daily price log. Bundle prices and upcoming offers are excluded. History covers up to the 100 most recent recorded offers.
Lowest recorded standalone price in this history: $34.99. The latest store price is $49.99.
View 4 recorded prices
| Sale start / price check | Price | Observation |
|---|---|---|
| $49.99 | Latest store price | |
| $49.99 | Unity First Price 2026-09-22 2026-09-22 | |
| $34.99 | Unity New Release Discount 2026-09-22 2026-10-06 | |
| $34.99 | Unity New Release Discount 2026-09-22 2026-10-06 |
Sale and bundle history
The 3 most recent recorded offers including this asset. Past offers may no longer be available. Bundle prices cover a package, not this asset alone.
About Anvil Physics - Box3D for Unity
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
• Anvil (DOTS): 1.63 ms
• Anvil (GameObjects): 1.97 ms
• Unity Physics: 4.59 ms
• Built-in PhysX: 4.82 ms
1,000 falling boxes, median step time
• Anvil (DOTS): 0.53 ms
• Anvil (GameObjects): 0.60 ms
• Built-in PhysX: 0.78 ms
• Unity Physics: 1.22 ms
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.
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
• Anvil (DOTS): 1.63 ms
• Anvil (GameObjects): 1.97 ms
• Unity Physics: 4.59 ms
• Built-in PhysX: 4.82 ms
1,000 falling boxes, median step time
• Anvil (DOTS): 0.53 ms
• Anvil (GameObjects): 0.60 ms
• Built-in PhysX: 0.78 ms
• Unity Physics: 1.22 ms
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.