How to make satisfying physics simulation videos with Claude

A thousand dominoes falling in a spiral. A marble dropping through a pegboard into exactly the right slot. A soft cube being sliced into neat layers. Satisfying simulation videos have no story and no narration, and they hold attention anyway, because physics that behaves exactly as you expect, at exactly the right speed, is pleasant to watch.

They are also natural territory for Claude. A physics engine does the hard part, Claude writes the scene and the camera, and code gives you the one property these videos depend on: you can tweak a single number and get the same perfect run again. This tutorial covers the method, from engine choice to the loop point.

What creators published and claimed

The format's reach is mostly reported second-hand. Ernesto Lopez posted about accounts publishing slicing simulations that he says were "100% simulated with claude opus 5.5", one with 33.2 million views across six videos. Those are third-party numbers as he relays them, and the post shares no method. The replies are more useful than the post: one creator confirmed his own series did millions of views but that "views don't convert that well into downloads", and another asked to see installs rather than views.

Dumble (@Y0urDumble) lists "domino spirals" and "clay planets" among faceless 3D Short formats and a stack to build them: Blender driven through an MCP server, a 3D model generator for props, a local voice, captions, generated music and HyperFrames for titles. The method details that matter most here come from creators who wrote about determinism in other formats: Finn's stickman prompt simulates physics once with a fixed timestep and samples the recording by time, and Elvar's teardown article insists collisions be fixed with a number in the parameter block, never hidden with the camera.

Step 1: choose the moment, then the setup

Every satisfying video has one moment: the last domino, the marble landing, the knife reaching the board, the tower settling. Design backwards from it. Decide what the viewer is waiting for, how long the anticipation lasts, and what happens in the second after, because the release after the moment is half the satisfaction.

• Chain reactions: dominoes, marble runs, Rube Goldberg sequences. The pleasure is inevitability.
• Precision: a ball through a gap, a stack that just balances. The pleasure is the near miss.
• Cutting and squashing: slices, presses, soft bodies. The pleasure is texture and sound.
• Mass: thousands of small objects pouring, sorting or filling. The pleasure is order emerging.

Step 2: pick the engine

For the browser, cannon-es (rigid bodies) and Rapier (rigid bodies, fast, deterministic builds available) both work with three.js, and Claude knows them well. For soft bodies, cloth, fluids and anything that needs high quality rendering, Blender's physics and Cycles or Eevee rendering are hard to beat, and Claude can drive Blender through an MCP server and look at its own renders. A simple 2D case (a pegboard, a falling stack) can be a hand-written Verlet integrator in a canvas, which Finn's stickman prompt uses for cloth.

Choose by what the moment needs. Hard objects colliding: a browser rigid body engine is enough and renders fast. Squash, slice and goo: Blender, or a custom 2D soft body.

Step 3: bake the simulation

This is the step that separates a reliable pipeline from a frustrating one. Physics engines step forward in time, but a code-made video must be able to draw any frame on its own, and must give the same frame every time. So simulate once, at load or in a separate script, with a fixed timestep and no randomness except from a seed, record every body's position and rotation at every step, and then have seek(t) look up the recording. Rendering frame 1,800 becomes a lookup, and the run is identical every time you render.

Bake with cannon-es, then sample by time

import * as CANNON from "cannon-es";
const world = new CANNON.World({ gravity: new CANNON.Vec3(0, -9.82, 0) });
world.allowSleep = false;                 // sleep can differ between runs
const DT = 1 / 240, STEPS = Math.ceil(DURATION / DT);
const rec = new Float32Array(STEPS * bodies.length * 7);

for (let s = 0; s < STEPS; s++) {
  world.step(DT);                         // fixed step, never variable
  bodies.forEach((b, i) => {
    const o = (s * bodies.length + i) * 7;
    rec.set([b.position.x, b.position.y, b.position.z,
             b.quaternion.x, b.quaternion.y, b.quaternion.z, b.quaternion.w], o);
  });
}

window.seek = (t) => {
  const s = Math.min(STEPS - 1, Math.round(t / DT));
  meshes.forEach((m, i) => {
    const o = (s * bodies.length + i) * 7;
    m.position.set(rec[o], rec[o + 1], rec[o + 2]);
    m.quaternion.set(rec[o + 3], rec[o + 4], rec[o + 5], rec[o + 6]);
  });
  renderer.render(scene, camera);
};

Save the recording to a file so renders do not re-simulate, and keep the parameters that produced it in a small JSON next to it. When a run is perfect, you want to be able to reproduce it exactly.

Step 4: tune with numbers, not luck

A chain reaction that fails at domino 412 is not bad luck; it is spacing, friction or mass. Have Claude expose every parameter (spacing, friction, restitution, mass, initial push, timestep) in one block, run the bake headless many times across a range, and report which runs complete and how long they take. Then pick the run whose timing suits the video. This is the same rule Elvar gives for mechanical simulators: fix problems with a number in the parameter block, never by hiding them with the camera.

A parameter sweep prompt (our wording)

Expose all physics parameters in params.json.
Sweep spacing 0.55-0.75 (step 0.02) and friction 0.3-0.6 (0.05).
For each run: did the last domino fall? time to the last fall?
any body leave the table? Write results.csv.
Pick the run that completes in 18-22 s with no escapes and
render 6 stills from it: start, 25%, 50%, 75%, the moment, +1 s.

Step 5: design for a phone

These videos are watched vertically, so design the setup for a tall frame: spirals viewed from above, runs that travel downward, towers that rise. Keep the important action in the middle of the frame, away from the platform's buttons at the bottom and side. Use a camera that moves slowly and with purpose; a slow push in during the build-up and a held frame at the moment is usually right. The camera should never chase the action so fast that the viewer loses it.

Step 6: materials and light

Satisfying videos look tactile. A few choices do most of the work: soft, large light sources so objects have gentle highlights; a slightly glossy material with roughness high enough that it never blows out to white (Elvar suggests keeping metal roughness at 0.45 or higher for the same reason); a clean, plain floor with a contact shadow under every object; and a restrained palette, often one colour family with a single accent for the object that matters. In three.js, physically based materials with an environment map get you most of the way; in Blender, an HDRI and an area light.

Step 7: contact sounds

Sound is half of a satisfying video. Every collision is an event you can hear, and the bake knows exactly when each one happens. Record contacts during the simulation (time, the two bodies, the impact speed), then generate a sound cue for each one with volume and pitch scaled by impact speed. Thin out cues that are too close together, or a thousand dominoes become noise; the ear wants a rhythm. Use real recorded click, clack and thud samples with slight random variation chosen by seed.

Collisions to sound cues

const cues = [];
world.addEventListener("postStep", () => {
  for (const c of world.contacts) {
    const v = Math.abs(c.getImpactVelocityAlongNormal());
    if (v > 0.4) cues.push({ t: world.time, v, a: c.bi.id, b: c.bj.id });
  }
});
// after baking: keep at most one cue per pair per 60 ms,
// gain = clamp(v / 4), pitch = 0.9 + 0.2 * seeded(a, b)

Then mix like any other code-made video: place each sample by its peak on the cue time and normalise the whole thing. Our post on beat sync and sound design has the mixing code.

Step 8: make it loop

Many of these videos loop: the last frame leads back into the first, and viewers watch twice without noticing. Design for it: end the run in a state that matches the start (the stack rebuilt, the board reset, the camera back at its first position), or cut on a moment of motion that hides the seam. Check the seam by playing the clip twice back to back and by comparing the last and first frames.

A worked example: a domino spiral Short

Put together, a 20 second vertical domino spiral looks like this. The moment is the last domino in the centre tipping a small ball into a cup. Claude lays out about 600 dominoes along an Archimedean spiral seen from above, with a slight colour gradient from the outside in so the viewer can see progress. The bake runs headless across a sweep of spacing and friction values, and the chosen run completes in just under 19 seconds with no escapes. The camera starts high and wide, pushes in slowly over the first 15 seconds, and holds still for the final three so the ball and cup read clearly.

Contact events from the bake drive the sound: one clack per domino, thinned so no two clacks fall within 40 milliseconds, rising slightly in pitch toward the centre, with a single heavier sample for the ball landing. Six stills check composition before the full render. The last frame is matched to the first by fading the fallen spiral into a standing one in the final half second, so the clip loops. Each variation after that (a heart shape, a spiral of 1,000, a different palette) is a parameter change and a new bake.

Pitfalls

• Rendering a live simulation instead of a baked one: different results each render.
• Variable timesteps or engine sleep settings that change between runs.
• Hiding a collision bug with the camera instead of fixing the parameter.
• Too fast. The satisfaction is in seeing it happen; slow the camera, not the physics, if you need more time.
• Sound for every contact, which turns into noise.
• Bodies escaping the frame or the table. Check stills at the extremes.
• Night-dark scenes that compress to mud. These videos want bright, soft light.
• Confusing views with results. Satisfying content can draw large audiences without bringing customers; decide what the video is for.

Cost and time

The engines and renderers are free. Browser simulations bake in seconds to minutes; Blender soft bodies and fluids can take much longer, and high quality 3D rendering is the most expensive part of this format in time. The Claude cost is the scene setup, parameter sweeps and review. Once one setup works, variations (new colours, a different count, a new arrangement) are cheap, which suits a series.

Doing it in about 3 minutes with WhatToUpload Video Studio

Physics simulation is not a Video Studio style; we are not going to pretend otherwise. What is live today is Kinetic type, Ink stickman and Diagram explainer, with more being added. If your simulation channel needs explainer videos alongside it (how dominoes transfer energy, why a marble chooses a slot), Diagram explainer turns one sentence into a voiced, captioned video drawn as code in about three minutes.

A 30 second video is 26 to 30 credits, and plans are $19, $49 and $99 a month.