Findings from the engine evaluation that led to this project, kept separate from
the table's own A/B results:
- Apple Silicon threading: Box3D gets SLOWER past the performance-core count on
the M3 Ultra (30 workers 5158ms -> 32 workers 5646ms, 24P+8E). A physics step
is a barrier, so a share of the work on a third-speed E-core makes the whole
step wait. Read hw.perflevel0.physicalcpu, never hw.ncpu. Applies to any
threaded physics on this fleet, not just Box3D.
- The benchmark harness: the CMake option is BOX3D_BENCHMARKS (plural), the
scene/flag list, upstream's M2 Air + AMD baselines, and a warning that a full
sweep runs over an hour on 32 cores — always pin -b and -w.
- What the binding does NOT implement (Generic6DOF, ConeTwist, SoftBody3D,
per-pair exceptions) plus the silent Area3D-vs-trimesh divergence.
- Why pinball and not the ragdoll game: ~/Documents/alright is the better fit but
is BLOCKED — its ragdoll is built from Generic6DOFJoint3D. Watch that upstream.
- Provenance: Box3D is serious (Catto, MIT, s&box + Esoterica adoption); the
binding is five weeks old with zero releases and self-declares experimental.
This is a testbed, not a bet.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Playable table (hinge-motor flippers, plunger, bumper, drain) plus a headless
probe harness that measured, per engine: tunneling of a fast ball through a
1 cm wall with CCD off/on, and hinge-motor drive. Findings in godot/README.md:
Box3D never tunnels even with CCD off, but its hinge motor sign is inverted
vs Jolt/GodotPhysics, and Jolt blows through angular limits that Box3D holds.
Ships a from-source macOS arm64 libgodot-box3d.dylib (upstream has no
releases). Also gitignore the remaining Microsoft media at repo root.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
