# The Ball Looked Right. The Physics Still Wasn't Calibrated.
*A browser simulation can survive rebound tests, timestep changes, high-speed impacts, and 60 automated checks—and still fall short of a defensible “realistic physics” claim. The missing distinction is calibration.*
Three balls leave three launch points. The football carries farther, the basketball rebounds sharply from hardwood, and the tennis ball loses speed differently through the air. Nothing explodes. Nothing tunnels through a wall. To the eye, the scene works.
That is exactly when physics work becomes dangerous.
A plausible animation invites a conclusion the evidence has not earned: *the model must be realistic*. In the live Box3D Sports Ball Lab, football, basketball, and tennis run through the same configurable browser system. The lab earned an engineering pass in its evaluation. The same report labels its lift calibration partial.
Both labels are true. Understanding why is more useful than another physics-engine benchmark.
“Looks right” is the first gate, not the last
Visual plausibility answers a narrow question: does the motion violate what a person expects badly enough to break the experience?
That gate matters. A basketball that barely rebounds, a football that accelerates in still air, or a tennis ball that passes through a wall is unusable. Human perception catches failures that a unit test may never encode.
But the eye is also forgiving. Camera angle hides distance error. Slow motion hides unstable timesteps. A carefully selected launch can make the wrong drag curve look convincing. Several incorrect parameters can even cancel each other for one shot.
The practical mistake is treating one successful scene as evidence about the model. It is only evidence about that scene.
A stronger evaluation asks whether the behavior survives changes that should not change the answer: frame cadence, serialization, surface selection, launch direction, spin direction, and impact speed. Only after those invariants hold does it make sense to ask whether the numbers match the real world.
A three-level validation ladder
The Ball Lab uses a distinction that applies to any game-physics stack:
- Visual plausibility: The motion reads correctly to a person in representative scenes.
- Engineering validation: The system behaves consistently across numerical and gameplay stresses.
- Measured calibration: Outputs match external observations within declared conditions and tolerances.
Each level prevents a different kind of failure.
Visual review catches experiential failures. Engineering gates catch software and numerical failures. Calibration catches model error.
Passing a higher-looking test in one category does not erase a missing test in another. A deterministic simulation can be consistently wrong. A calibrated rebound can coexist with an invented aerodynamic lift curve. A beautiful trajectory can depend on the display frame rate.
That is why release language should name the level actually reached.
What an engineering pass can prove
On July 12, 2026, a fresh run of the Ball Lab physics suite passed 60 of 60 tests. The result is time-bounded evidence for that evaluated revision, not a claim that every possible ball interaction is solved.
The useful part is the shape of the test set.
Rebound anchors
A drop test gives the simulation a controlled input and a measurable output: release height in, rebound apex out. It is a better tuning surface than repeatedly adjusting restitution until a gameplay shot feels good.
Run it separately for each ball and surface. A basketball on hardwood should not inherit the same contact response as a football on grass merely because both are spheres.
Timestep convergence
A simulation may appear stable at one render cadence while producing different outcomes at another. The Ball Lab separates display updates from a fixed physics protocol; the evaluated configuration uses a 240 Hz physics step with two solver substeps.
That number is not a universal recommendation. The lesson is to choose a declared protocol, then test whether callers running at different cadences converge on acceptably similar results. If changing the display frame rate changes the rebound or range materially, tuning coefficients will not rescue the architecture.
Determinism and serialization
A saved ball profile should reproduce the same behavior when loaded again. Repeated controlled runs should not drift without an identified source of randomness.
These checks sound mundane until a tuning UI, network handoff, or replay system depends on them. A physically impressive demo that cannot reproduce its own parameters is not a dependable tool.
Continuous collision detection
High-speed balls create a classic failure: the body moves from one side of a thin wall to the other between discrete collision checks. The Ball Lab includes a wall-impact protocol specifically for continuous collision detection rather than assuming ordinary contact tests cover it.
The visual question is “did the ball go through?” The engineering question is broader: does contact remain reliable across ball sizes, speeds, and caller timesteps?
Aerodynamic symmetry and evidence
Spin should bend trajectories in the expected direction. Reversing spin should reverse the lateral tendency instead of exposing a coordinate or sign error. Drag should remove energy rather than add it.
Those are powerful invariants. They can prove that an aerodynamic implementation is coherent. They still cannot prove that its coefficients accurately describe a particular manufactured football or tennis ball.
That boundary leads to the most important result in the lab.
The partial-calibration result is the honest result
The evaluation marks the system as engineering-pass and partially calibrated because its evidence is uneven by design.
Drag uses ball-specific measured anchors. Lift uses a research-shaped sphere proxy. The proxy gives the model a defensible structure for exploring spin effects, but it is not the same as ball-specific wind-tunnel or trajectory calibration.
Calling both “realistic aerodynamics” would flatten a meaningful difference:
- Measured anchor: an external observation constrains the model for declared conditions.
- Research-shaped proxy: published physical behavior informs the curve, but the exact object has not been measured sufficiently.
- Gameplay tuning: a parameter is intentionally adjusted for experience rather than physical fidelity.
All three can be legitimate. The problem is not using a proxy or tuning for play. The problem is publishing one category under another category’s label.
For a developer, “partial” is actionable. It identifies the next experiment. Here, the next step is not another round of aesthetic tuning. It is ball-specific lift evidence across spin and speed ranges, followed by comparison against held-out trajectories.
A release label developers can actually use
Instead of “realistic physics,” attach one of four labels to a simulation:
Visual prototype
Representative scenes look plausible, but numerical invariants and external measurements are incomplete.
Use it for interaction design, camera work, and early gameplay decisions.
Engineering-validated simulation
The system passes declared stability, determinism, collision, serialization, and scenario gates.
Use it when the software behavior must be dependable, while stating that physical coefficients may still be approximate.
Partially calibrated model
Some important behaviors match measured anchors, while named components still rely on proxies or gameplay tuning.
Use it when readers need to know exactly which conclusions the evidence supports.
Measured calibration
Outputs match external measurements across declared conditions, tolerances, and held-out cases.
Use it only with the dataset, window, protocol, and error bounds attached.
This vocabulary improves engineering decisions because it turns vague confidence into a list of missing evidence.
How to evaluate your own simulation
Start with one scene that matters to the product, then refuse to stop there.
- Define the observable finish line: rebound apex, travel range, roll distance, impact containment, or lateral deflection.
- Separate the fixed conditions from the variables.
- Run the same scenario across caller timesteps and repeated trials.
- Reverse axes and spin directions to expose sign and coordinate errors.
- Stress thin obstacles and high velocities.
- Save and reload the exact profile.
- Compare against an external measurement where one exists.
- Label every remaining coefficient as measured, proxy, inferred, or tuned.
- Publish the strongest honest release label, not the most flattering one.
The engine choice still matters. Integration quality, documentation, WASM behavior, performance, and constraints matter too. But engine comparison cannot answer whether *your configured model* is trustworthy. That requires a protocol tied to the decisions your product will make.
The next experiment should target uncertainty
The Ball Lab’s next useful milestone is not making the trajectories look more dramatic. It is reducing the largest named uncertainty: lift calibration.
That means collecting or finding ball-specific trajectory evidence across controlled launch speeds and spin rates, fitting without consuming the evaluation cases, and then testing on held-out conditions. Surface calibration deserves the same treatment across materials and environmental conditions.
Until then, the current label is precise: engineering-validated, partially calibrated.
That phrase may sound less exciting than “realistic.” It is far more useful. It tells a developer what can be trusted today, what cannot, and exactly what evidence should come next.
Try the live Ball Lab, inspect the released source, and ask a harder question than “does it look right?” Ask which layer of confidence the evidence has actually earned.