How This Project Started — One Simulation in a Weekend

It was supposed to be a quick Three.js experiment for a weekend. A year and 40+ simulations later, here we are. The origin story of 3D Simulations — what started it, what almost stopped it, and what keeps it going.

It Started with a Question

I was watching a video about Boids — the flocking algorithm invented by Craig Reynolds in 1987. The visuals were beautiful: hundreds of virtual birds swooping and turning as one. The rules were deceptively simple: separation, alignment, cohesion. Three forces and you get emergent behaviour that looks alive.

I thought: could I build that in a browser over a weekend?

The answer, it turned out, was yes. In about twelve hours of coding, spread across a Saturday and Sunday, I had a working Boids simulation in Three.js with 500 agents running at a solid 60 FPS.

The Boids sim is still live today — you can find it at /boids/. It still uses roughly the same spatial hash I wrote that first weekend.

One Becomes Two Becomes Many

The problem with finishing one simulation is that it immediately suggests another. Boids made me think about the Game of Life — another "simple rules, complex output" system. Game of Life made me think about reaction-diffusion. Reaction-diffusion made me think about fluid dynamics.

Before I knew it, I had a folder called simulations/ with seven entries. Then fifteen. Then thirty.

Each one taught me something I didn't expect:

Why Pure HTML/JS — No Build Step

Early on I made a decision that shaped everything: no bundlers, no npm, no build pipeline. Every simulation loads directly from the filesystem via a <script> tag or works as a bare file:// URL.

The reasoning was partly laziness (I didn't want to configure Webpack) and partly philosophy. The web platform is powerful enough. Modern ES modules work natively. Three.js ships a browser-ready build. You can open an HTML file and it just runs.

This turned out to be the right choice. The project is trivially portable — zip it up, hand it to anyone, it works. No node_modules. No lock files. No "works on my machine."

What Keeps It Going

The honest answer? Curiosity. Every simulation answers a question and raises three more.

The slightly less honest answer: the feedback loop is extremely short. Edit a shader, refresh the page, see the result — no compilation, no hot reload to configure, no type errors to fix. It's the fastest possible iteration cycle, and that makes it addictive.

The project has grown into something I didn't originally plan: a kind of interactive textbook. Physics, biology, mathematics, machine learning — all rendered in real time in the browser, free and open, for anyone who's curious enough to look.

What's Next

The devlog series will cover individual simulations in more detail: the math behind them, the implementation decisions, the bugs that took three days to hunt down.

Next up: Devlog #2 — SPH Fluid: From Wikipedia to 60 FPS →