Three Books That Shaped My Physics Simulations — The Knowledge Behind 203 Implementations

#Introduction

sakimytocom currently has 211 interactive demos. Over 100 of them use physical laws or mathematical algorithms. Particle systems, fluid simulations, flocking intelligence, collision detection, pendulums, wave equations -- to implement all of these through self-study, three books were particularly influential.

In this article, I'll write specifically about "which chapter of which book I read, and which component I built from it." This isn't a book review -- it's a reading log from an implementer's perspective. Rather than an abstract "recommended books list," I want to introduce these at the level of "this concept from this chapter was directly used in this part of this component."

I hope this serves as a reference for anyone looking to write physics simulations in code and wondering which book to pick up first.

#Book 1: The Nature of Code (Daniel Shiffman)

Without this book, half of sakimytocom's physics simulations wouldn't exist. It was that decisive.

Daniel Shiffman is known as a Processing educator, and this book systematically teaches how to simulate natural phenomena in Processing (Java). Vectors, forces, particle systems, autonomous agents, cellular automata, fractals, genetic algorithms -- it covers nearly all the fundamentals of physics simulation.

#Vector Class Design -> physics.ts Vec2 Type

Chapter 1 of The Nature of Code is about "Vectors." The design philosophy of PVector (Processing's Vector class) -- treating position, velocity, and acceleration all as vectors with operations like add, sub, mult, normalize -- became the direct prototype for the Vec2 type in physics.ts.

type Vec2 = { x: number; y: number }

Where Processing uses class-based PVector.add(), I implemented pure functions like addVec(a, b) in TypeScript. Stateless functions work better with React's rendering model. This "class-based -> functions + useRef" conversion pattern came up repeatedly when porting Processing code.

#Boids (Flocking Intelligence) -> Boids.tsx

Chapter 6, "Autonomous Agents," and the Boids algorithm was one of the most inspiring chapters. With just three rules -- separation, alignment, and cohesion -- complex bird-flock-like movement emerges.

In Boids.tsx, separation has an influence range of 25px, while alignment and cohesion use 50px. These values are based on the book's recommendations, adjusted for browser screen sizes. Without reading the book, I wouldn't have understood what these parameters mean.

Shiffman's explanation of calculating each rule's force as a "steering force" was particularly good. The difference between desired velocity and current velocity becomes the steering force. This approach is intuitive and easy to translate into code.

#Particle Systems -> ParticleField.tsx

Chapter 4, "Particle Systems," served as the direct blueprint for ParticleField.tsx. Particle generation, velocity decay, lifetime management, emitter concepts -- I used the structure learned from the book as-is.

In ParticleField.tsx, the mouse cursor applies a repulsive force to particles. Particles closer to the cursor are pushed away more strongly. This applies the inverse-square law from the book's "Attraction and Repulsion" chapter (Chapter 2). A force inversely proportional to the square of the distance, with the sign flipped to make it repulsive. Simple, but the resulting interaction feels incredibly satisfying.

#Reaction-Diffusion -> ReactionDiffusion.tsx

The Reaction-Diffusion covered in Chapter 7 provided implementation steps for the Gray-Scott model that were almost directly usable. Two chemical substances' diffusion and reaction are calculated using the Laplacian. The book implements it with Processing's pixel manipulation, and replacing it with Canvas API's getImageData / putImageData gets nearly identical code running.

Two parameters -- feed rate and kill rate -- produce spots, stripes, and maze-like patterns. I referenced the parameter space exploration table in the book.

#Tips for Processing -> TypeScript Conversion

Patterns I developed while porting code from The Nature of Code:

• setup() -> useEffect initialization
• draw() -> requestAnimationFrame loop
• Global variables -> useRef
• PVector class -> Pure functions (addVec, subVec, scaleVec)
• mouseX, mouseY -> PointerEvent coordinates stored in useRef

Once you learn this pattern, Processing sample code can be mechanically converted to TypeScript + Canvas.

#Book 2: Mathematics and Physics for Game Development

If The Nature of Code teaches "what to build," this book teaches "why it works that way." Its greatest strength is the careful derivation of mathematical formulas.

#Collision Detection Mathematics -> physics.ts

detectCollision and resolveCollision in physics.ts are almost direct implementations from this book's collision detection chapter. Circle-circle collision detection (comparing center distance with the sum of radii), collision normal calculation, and impulse-based collision response.

The impulse calculation for collision response in particular was something I couldn't have understood without following this book's derivations. "Why does the coefficient of restitution go in this position?" "Why do we partition by the inverse of mass?" -- these are carefully derived from conservation of momentum and conservation of energy. Because I understood the derivation rather than memorizing the formula, I could predict what would happen when changing parameters.

#Reflection Vectors -> Breakout, Pinball

The calculation for balls bouncing off walls and blocks in Breakout.tsx, and balls hitting bumpers in Pinball.tsx -- both use the reflection vector formula:

v' = v - 2(v · n)n

Reflecting incident vector v off normal vector n. The formula itself is short, but understanding "why the dot product appears" and "why we multiply by 2" geometrically required this book's diagrams. Decomposing the incident vector into normal and tangential components, then inverting only the normal component -- this intuitive understanding came from this book.

#Discretizing Equations of Motion -> Symplectic Euler

The integration function in physics.ts uses the Symplectic Euler method. Instead of regular Euler (updating position first), velocity is updated first, then position.

// Symplectic Euler
vel.x += acc.x * dt
vel.y += acc.y * dt
pos.x += vel.x * dt
pos.y += vel.y * dt

Just a two-line order difference, but energy conservation improves dramatically. The book visually explains "why regular Euler causes energy to diverge" using a 1D spring example. After reading this explanation, I unified all simulations in sakimytocom to Symplectic Euler.

#Rotation and Angular Velocity -> DoublePendulum

DoublePendulum.tsx uses Lagrangian mechanics, but understanding "what is angular velocity" and "what is torque" is a prerequisite. This book's chapter on rotational motion provided exactly that foundation.

Angular velocity omega, angular acceleration alpha, moment of inertia I, torque tau. These concepts and their correspondence with linear motion (v, a, m, F) are summarized in a table, making it possible to understand rotation as an "analogy to linear motion."

#A Book That Teaches "Why"

The greatest value of this book is presenting formulas as "process" rather than "results." Instead of textbook-style "use this formula," it guides you through "from these assumptions, applying these transformations, we arrive at this result."

As a result, I developed the ability to derive formulas rather than memorize them. This proves invaluable in situations where no existing formula exists -- for instance, when designing custom game mechanics.

#Book 3: Linear Algebra for Programming

This book isn't about physics simulation. It's about linear algebra. Yet it provided the most foundational understanding for writing physics simulations.

#Coordinate Transformations -> Canvas translate / rotate / scale

In the Canvas API, you combine ctx.translate(), ctx.rotate(), and ctx.scale() to transform the drawing coordinate system. I first understood through this book that these operations are "matrix products."

For example, "rotating around the origin then translating" and "translating then rotating" produce different results. This is because matrix multiplication is non-commutative (AB != BA). Having this understanding dramatically changes the debugging efficiency for complex coordinate transformations on Canvas.

In SolarSystem.tsx, planets orbit the sun, and moons orbit planets. This nested rotation is implemented as composition of coordinate transformations. When I realized that the ctx.save() / ctx.restore() operations for pushing transformation matrices onto a stack are literally a matrix stack, Canvas's API clicked completely.

#Eigenvalues and Eigenvectors -> Understanding Oscillatory Systems

Eigenvalues and eigenvectors are among the most abstract concepts in linear algebra. This book starts with the intuitive explanation of "vectors whose direction doesn't change under transformation."

In physics simulation, eigenvalues correspond to natural frequencies of oscillatory systems. In coupled oscillatory systems like the double pendulum, there are two eigenmodes, each with its own natural frequency. Understanding this concept allows qualitative judgment of whether simulation results are "correct."

Learning eigenvalues not for Principal Component Analysis (PCA) but to understand eigenmodes of physical phenomena -- this may be a somewhat unusual path.

#The Meaning of Matrices -> "Matrices Are Transformations"

The biggest change before and after reading this book was my intuition about "matrices."

Before: Matrices are tables of numbers. I know how to compute with them but don't know what they're for. After: Matrices are spatial transformations. Rotation, scaling, shearing, projection -- everything can be expressed as matrices.

With this intuition, I could write Canvas coordinate operations with the consciousness that I'm "multiplying matrices." When bugs appeared, I could isolate "which transformation matrix is wrong." Debugging speed improved by an estimated 3x or more.

#The Essence of Physics Simulation

The conclusion I reached through this book is that "physics simulation ultimately reduces to matrix multiplication and discretization of differential equations."

Coordinate transformations are matrix products. Equations of motion are Euler integration of differential equations. Collision response is projection onto normal and tangential directions (dot product). Everything reduces to basic linear algebra operations. This clarity made it obvious "where to start" when implementing new simulations.

#Supplement: Math Girls (Yuki Hiroshi)

This isn't a book I used directly for implementation. However, without it, I probably couldn't have read through the three books above.

Math Girls is a novel where high school protagonists solve mathematical problems through dialogue. Fibonacci sequences, prime numbers, Taylor series, Fourier series -- mathematical concepts are naturally introduced within the story.

When I built FourierSeries.tsx, the intuitive understanding of Fourier series -- "any periodic function can be expressed as a superposition of sine waves" -- came from this book's Fourier chapter. I confirmed the mathematical details later in textbooks, but I grasped the big picture of "what's happening" from this book.

The greatest value of Math Girls is that it transformed mathematics from "something to solve" into "something to enjoy." I became able to look at a formula and think "that looks interesting." This change in attitude was far more important than any technical skill. Once the fear of mathematics disappears, you can open any textbook.

#How to Use Books: "Read Only the Chapters You Need"

I didn't read these three books cover to cover, page by page. When I got stuck during implementation, I looked up the relevant chapter -- using them like dictionaries.

For example, when implementing the Navier-Stokes equations: I grasped the overall structure from The Nature of Code's fluid chapter, then confirmed the discretization method in the game physics book's differential equations chapter. Going back and forth between the two books, picking up only the knowledge I needed.

This approach works because the three books cover different domains:

• The Nature of Code: A recipe collection for "what to build." Best for grasping the overall picture of an implementation
• Mathematics and Physics for Game Development: A derivation collection for "why it works that way." Best for understanding the meaning of formulas
• Linear Algebra for Programming: "The foundation of everything." Best for understanding the relationship between coordinate transformations and matrices

"Textbooks are dictionaries. You don't need to read from page 1" -- this may be the most important mindset for self-studying physics simulation. Skip chapters you don't understand. Read only the chapters needed for your current implementation. Then implement. If it works, move on. If it doesn't, read again. This cycle was the most efficient.

#Summary: Physics Simulation Books

The knowledge behind 211 interactive demos ultimately boils down to three books.

1. The Nature of Code -- Natural phenomena simulation recipes. Particles, Boids, Reaction-Diffusion -- it teaches "what to build"
2. Mathematics and Physics for Game Development -- Mathematical foundations for collision detection, reflection, and integration methods. It teaches "why it works that way"
3. Linear Algebra for Programming -- Coordinate transformations, matrices, eigenvalues. It teaches the mathematics underlying all simulations

These three books cover 90% of physics simulation. The remaining 10% -- Lagrangian mechanics, detailed Gray-Scott model parameters, Navier-Stokes stabilization techniques, etc. -- can be supplemented with Wikipedia and papers.

For those who want to write physics simulations but lack confidence in mathematics, I'd recommend starting with Math Girls. Once you can enjoy mathematics, grasp the overall picture of implementation with The Nature of Code. When you want a deeper understanding of formulas, use the other two books as references. I believe this order is the path least likely to lead to frustration.