Saved
Software · Systems

Physics engine

Physics engines don’t simulate reality—they choose which errors to tolerate.

Worth your time?4/5Yes.Study the whole thing.What works, what does not, who it is for ↓
8:56in productionCh. 1 · What it approximates/ 8:56 · ceiling 15 min
4 chapters · 8:56Ceiling 15:00

The brief is written and checked. The video joins this page when it is cut.4 chapters · 1 min read · 8:56 planned

Read the brief

A physics engine is software that approximates classical mechanical systems—rigid, soft, and fluid—using computational models. It solves the problem of predicting motion and interaction where analytical solutions are intractable. Real-time engines simplify calculations to meet frame-rate deadlines. High-precision engines use more processing power for accuracy, targeting science and film. ENIAC applied basic physics modelling to ballistics, assigning mass, angle, charge, and wind drift to compute trajectories. Since the 1980s, supercomputer-based engines have modelled fluid dynamics by assigning force vectors to particles. It does not simulate quantum or relativistic effects. It does not eliminate approximation: all outputs are estimates, not measurements. ENIAC produced one-time printed tables—not live feedback. Real-time engines sacrifice accuracy by design; high-precision engines cannot run interactively. It replaces manual calculation and physical experimentation with repeatable, scalable computation. It shifts ballistics from artillery field tables to real-time targeting systems. It enables visual effects pipelines that decouple simulation from rendering. It makes fluid behaviour programmable—but only as particle aggregates, not continuous media. Rigid-body collision detection works reliably in games. Ballistics table generation worked on ENIAC for fixed artillery conditions. Particle-based force vector modelling works for large-scale fluid circulation on supercomputers. Real-time response works when accuracy is secondary to latency.

Chapters & takeaways4
  1. 0:58
    What it approximates

    It approximates classical dynamics—not reality, not quantum effects, not relativity.

  2. 2:14
    Two classes, one trade-off

    Real-time engines cut corners to hit frame rates. High-precision engines burn cycles for fidelity.

  3. 3:40
    The first output was paper

    ENIAC was a one-shot physics engine: no iteration, no feedback, just printed tables.

  4. 5:29
    Fluids as particles, not flow

    Since the 1980s, supercomputers have modelled fluids as force-driven particles—not continuous fields.

1 more chapterFewer chapters
Worth your time?

Yes. Study the whole thing.

4/ 5
What works
  • rigid-body collision detection in games
  • ballistics table generation on ENIAC
  • particle-based fluid circulation on supercomputers
  • real-time response under timing constraints
What does not
  • simulate quantum effects
  • eliminate approximation
  • produce live feedback (ENIAC)
  • run high-precision simulations in real time
Study it if
  • game developers needing responsive collision
  • scientists requiring particle-level fluid resolution
  • historians studying early computational ballistics
Skip it if
  • physicists requiring exact differential solutions
  • real-time control engineers needing deterministic latency
Who should study it, and who should skipHide who it is for
The written brief1 min read

What it is and the problem it solves

A physics engine is software that approximates classical mechanical systems. It solves the problem of predicting motion and interaction where analytical solutions are intractable—like shell trajectories or airflow around a wing.

How it works

A physics engine approximates classical dynamics—rigid, soft, and fluid systems—using computational models. Real-time engines simplify calculations to meet frame-rate deadlines. High-precision engines use more processing power for accuracy, targeting science and film. ENIAC applied basic physics modelling to ballistics, assigning mass, angle, charge, and wind drift to compute trajectories. Since the 1980s, supercomputer-based engines have modelled fluid dynamics by assigning force vectors to particles.

What works

Rigid-body collision detection works reliably in games. Ballistics table generation worked on ENIAC for fixed artillery conditions. Particle-based force vector modelling works for large-scale fluid circulation on supercomputers. Real-time response works when accuracy is secondary to latency.

What does not

It does not simulate quantum or relativistic effects. It does not eliminate approximation: all outputs are estimates, not measurements. ENIAC produced one-time printed tables—not live feedback. Real-time engines sacrifice accuracy by design; high-precision engines cannot run interactively.

What it changes

It replaces manual calculation and physical experimentation with repeatable, scalable computation. It shifts ballistics from artillery field tables to real-time targeting systems. It enables visual effects pipelines that decouple simulation from rendering. It makes fluid behaviour programmable—but only as particle aggregates, not continuous media.

Is it worth your time

Yes—if your work demands either real-time interactivity or high-fidelity simulation. No—if you need exact physical prediction without approximation, or if you expect a single engine to serve both domains well. The trade-off between speed and precision is structural, not temporary.

Same field · Software4 of 114
9:45
ChromeOS2011ChromeOS (2011) is a proprietary operating system designed and developed by Google, derived from ChromiumOS (itself derived from Gentoo Linux), using the Chrome browser as its principal user interface. Announced in July 2009 as cloud-centric, it first shipped on Chromebooks in 2011. It supports progressive web apps, Android apps via Google Play, and Linux apps. In 2025, Google announced a merger with Android, replacing the Gentoo-based kernel with an Android-based system. The concept originated in 2006 as 'Google OS', a speed-focused Linux distribution.
9:07
Kubernetes2014Kubernetes is a container orchestration system announced by Google in June 2014 and released as version 1.0 on July 21, 2015. It was conceived by Joe Beda, Brendan Burns, and Craig McLuckie. Inspired by Google's Borg system but written in Go instead of C++, it uses Promise Theory to define infrastructure as declarative objects. It assembles virtual or bare-metal machines into clusters and automates deployment, scaling, and management of containerised workloads based on CPU, memory, or custom metrics.
9:52
NeXTSTEP1989NeXTSTEP was a tightly integrated, object-oriented OS built on Mach and BSD, released commercially in 1989 for NeXT’s Motorola 68000 workstations. It introduced the Dock and Shelf, bundled Display PostScript, Objective-C, and application kits, and served as the foundation for macOS and all Apple operating systems after 1996. It failed in the market but succeeded as infrastructure.
11:15
UTF-8Ken Thompson and Rob Pike · 1992UTF-8 is a variable-width Unicode encoding co-designed by Ken Thompson and Rob Pike in 1992. It guarantees ASCII compatibility, supports all 1,112,064 Unicode code points, and became the dominant web encoding — over 90% of pages in 2019. Its strength is pragmatic interoperability; its weakness is zero tolerance for malformed input and no compression benefit.
Up next in Technology

PostgreSQL

University of California Berkeley · 1996 · 10:18

PostgreSQL isn’t open-source by accident—it’s the deliberate, decades-long rejection of SQL as a marketing veneer.

10:18