Building OnePhysics: deterministic 2D and 3D physics with agents

Short version →

Abstract

Agents built OnePhysics to 1.0.0, its first stable release. It is a C# library for deterministic 2D and 3D physics: the same starting world and inputs are intended to produce exactly the same simulation across supported platforms and thread counts. The release includes rigid bodies, characters, vehicles, ragdolls, cloth and soft bodies, ropes, destruction, fluids and rollback tools for saving and replaying a simulation.

The repository begins on October 26, 2026; the stable release is dated November 10. Engineering and coordination agents ran on Claude Opus 5.5, Claude Sonnet 5.5 and GPT-6.1 Sol through Alera. This report stops at the stable tag, rather than treating later development as part of the release.

The release does not establish a universal speed lead. Its README names slower 3D scenes and distinguishes sleeping cloth from cloth still moving. Those limits matter when choosing an engine.

The problem: deterministic simulation without a second engine

OnePhysics is written from first principles, not a wrapper around another physics engine. Its runtime depends on OneMath for deterministic math and on .NET’s built-in library. Separate 2D and 3D engines share infrastructure for scheduling, object references, sleeping, saving worlds and checking whether worlds match.

This matters for games that keep simulations in sync or rewind and replay them. A saved world must not merely look right when loaded: continuing from it must produce the same results. The public API offers snapshots (saved worlds), restoration, delta snapshots (files containing only changes to a saved world), replay, world copies and a tool for finding where simulations diverge.

Determinism belongs in the work order. The documented design fixes the order of dependent calculations and uses deterministic math. That is an implementation strategy, not proof that every possible world has been tested.

How the library is organized

The repository separates the physics runtime from authoring tools and file importers. That separation is also visible in the stable packages.

The stable release is broader than the earlier preview. Ropes, fracture and carving, fluids, articulations, fields, importers and rollback tools are now described in the released source, not credited as future plans. The raw interface to low-level engine storage and work batches remains experimental; the rest of the public surface is supported.

Verification: what “cross-platform deterministic” means here

The release promises identical results across operating systems, processors, vector widths, WebAssembly modes and thread counts. Its test method advances named simulations and compares fingerprints—compact summaries of their state—after each step across configurations. This report checked the tagged method and release documentation; it did not independently rerun the full cross-platform suite.

Result compatibility and file compatibility are different promises. The README’s 1.x contract says:

• Patch releases never change a simulation result: the same inputs give the same world, bit for bit.
• A minor release may change results, with the change recorded in the changelog. Peers in a synchronized or rollback session must use the same minor version.
• Snapshots, delta snapshots, replays and scene files written by any 1.x release load in every later 1.x release.
• The public API follows semantic versioning.

The previews did not promise result compatibility with one another or with 1.0. Loading an older saved file in a later minor version is not a promise that its future simulation will remain unchanged.

Speed: the released comparisons

The release README reports median simulation-step time on the same scene files, with the compared managed .NET engines at their defaults and tiered compilation off, so the runtime uses optimized code from the start. The reference versions are BepuPhysics 2.5.0-beta.33, Jitter2 2.13.0 and Box2D.NET 3.1.654. The machines are an AMD Ryzen 9 7950X3D (x64, 32 logical CPUs; the 8-thread measurements stay on one core complex) and an Apple M2 (arm64, 8 cores).

“2D: at or ahead of Box2D.NET on every scene at every thread count (large pile 0.11× its step time at 1 thread on x64, 0.17× on arm64).”

“3D: within 15% of the fastest stable managed engine, or faster, on large piles, mesh and height-field terrain, joint grids and queries at 1 thread; joint chains and tall pyramids, where no managed engine is stable at its defaults, are gated on stability only.”

These are the README’s claims for its measured scenes, not a comparison across all workloads. A ratio below 1 means less time per step; above 1 means more time. The following is the README’s table of scenes with slower measurements, including its passing rows for context.

The ratios compare OnePhysics with the fastest stable managed engine for each measurement. The README reports every other measured row within 15% or faster. Its cloth comparison needs a separate qualification:

“Soft bodies: ahead of Jitter2 on cloth. Our cloth sleeps once it settles, so the median step is a sleeping one; while awake, an 8-thread step is about 0.46 ms against Jitter2’s 0.13–0.19 ms.”

Do not use sleeping cloth to predict moving-cloth performance. The awake measurement is slower. Nor do these comparisons establish a speed lead over native engines or measure improvement between OnePhysics development runs.

What went wrong and what remains limited

The release changelog records a restored-world defect: a 2D collision shortcut could skip a touching pair in a running world but find it after restoration. The stable commit fixes the bound used by that shortcut. The distinction is important: repeatable runs alone do not prove that restoring a saved world resumes identically.

The slower rows remain relevant at the stable release. So does the experimental status of direct access to low-level engine storage. Neither the supported API nor a passing scene test removes the need to test an application’s own worlds.

Evidence limits

The release tag and package version declarations establish a finished stable milestone. They do not mean development has stopped. This case study checks the published source and release documentation; it does not independently reproduce the benchmarks.

Results and recommendations

OnePhysics reached a supported 1.0.0 release with runtime simulation, authoring tools and interchange packages. The material change from the preview is not just more features: users now have an explicit contract for patch results, minor-version changes and saved-file loading within 1.x.

Choose against your workload and compatibility needs. Start with the tagged source, reproduce the scenes closest to your application, and test saving and restoration as well as ordinary simulation. The evidence supports a substantial agent-built release with specific performance boundaries, not a claim that one engine is fastest everywhere.

Sources and reproduction

• Frozen source at v1.0.0 and stable-release changelog.
• Release README: compatibility, speed and packages.
• Benchmark method and scenes and stability limits.
• Cross-platform comparison method and shared-core architecture.

Use the frozen tag when reproducing the release. A current-branch run tests a different source version.