How I Turned a Spider Into a 3D Simulator You Can Take Apart https://x.com/i/article/2119520412606320640
How I Turned a Spider Into a 3D Simulator You Can Take Apart. Here's How to Build Your Own
Many orb-weaving spiders build a new web every day and eat the old one. Almost nobody has watched one go up step by step. So I built a spider you can take apart.
Every number on that screen is computed, not typed. The silk counter, the spoke and spiral counts, the glue droplets and the "gland in use" readout all come from one timeline: where the spider is on its path. Move the spider and everything moves with it. The fact people send to friends: its dragline silk is about as strong as high-grade alloy steel, and weight for weight about five times stronger.
I built it with Claude in one conversation. No Blender, no 3D artist, no stock footage. Just Three.js in a browser, rendered frame by frame.
This is the full process: the structure every simulator shares, the 7 prompts I use, the research on why this format holds attention, and the mistakes that cost me hours, with the exact numbers that fixed them.
A turbine, a snake, a heart, a T-rex and an engine
The method doesn't care what you point it at. Here are five more, each built the same way.
This one runs on a single equation: power = ½ × air density × swept area × wind³ × efficiency. Wind goes from 6 to 12 m/s and power goes from 0.67 to 5.4 MW. Double the wind, 8× the power. No rotor can beat 59.3% efficiency (the Betz limit), and the gauge on the left never crosses it.
This one is invented, so there was nothing to look up, and that changes the job. Without real numbers, the realism has to come from behaviour: the head leads, the body follows one travelling wave, and the panels show live telemetry for the parts on screen. Dark stage, glowing grid, one hot accent colour: the look I use when I want parts to pop.
Your heart closes four valves about 100,000 times a day. Here every value comes from one input, where it is in the beat: the pressure curve, the pressure–volume loop, the "LUB" and "DUB" labels and the litres-per-day counter. Change the heart rate and everything moves together.
Same structure as the snake, opposite look: white stage, orange accents, soft shadows. I made it to prove the style is a setting, not the method. The chapters barely changed; the colours, the materials and the ending did.
This is the one people check with a calculator, so I put the calculation on screen. Bore and stroke are both 86 mm, so one cylinder is π/4 × 86² × 86 = 499.6 cm³, and four of them make 1,998 cm³: the "2.0 L" on the badge. At 6,500 rpm each piston stops and reverses 217 times a second, and the spark fires 217 times a second, in order 1-3-4-2. The pressure curve is labelled as a model, because it is one.
Six subjects, six looks: a forest at night, a grey North Sea, a black robotics lab, a pale clinical studio, a white robotics lab and a black workshop. Same structure underneath.
The anatomy of a simulator
Every one of these is a single HTML page with six layers. Get the first one right and the other five almost write themselves.
1. One input, one function. The spider has one number: where it is on its building path. The heart has one: where it is in the beat. The turbine has one: wind speed. Spokes laid, glue droplets, valve state, power and rpm are all computed from that number. Nothing is animated by hand, so nothing can drift out of sync.
1. The object, in real units. The web is 30 cm across and the spider about 2 cm long. The engine's bore and stroke are 86 mm, because that's what makes 2.0 L. The turbine's tower is 100 units tall because it's 100 m. Real proportions are why it reads as real.
1. The instruments. 4 to 6 panels, each drawn from the same model: an ECG, a power curve, a vibration trace, a silk counter. A chart that moves with the object is what keeps people watching.
1. The story. 6 chapters of about 4 seconds, one reveal each: show it, cut it open, slow it down, look inside, take it apart, push it to the limit. Then end on one number.
1. The labels. Short callouts with thin leader lines that track the 3D part as the camera moves. They're the difference between a pretty render and an explanation.
1. The sound. Built from the same timeline. Every spoke the spider lays makes a tick, the "lub" lands exactly when the mitral valve shuts, and the engine's rumble follows its rpm.
Then it's rendered frame by frame. A screen recorder drops frames when the computer struggles. Asking the page for frame 1, 2, 3 and so on can't, because each frame is a pure function of time. Remotion and timecut are built on the same idea.
Why this format works (and two myths it doesn't need)
Animation beats a still picture most when the thing you're learning is the motion. That's exactly what a simulator shows.
The honest reading: the overall effect is small to medium, and it gets much bigger when motion and realism carry the content. That's why every label and every panel here explains something. Decorative visuals don't improve learning at all. Interactive simulations hold up too: physics students who learned circuits on a PhET simulation outperformed students who used real equipment, even at building a real circuit (Finkelstein et al., 2005).
Two things you'll see quoted everywhere that you shouldn't repeat:
- "People process visuals 60,000× faster than text." It traces back to a 3M brochure with no study behind it (CogDog's hunt for the source). The real, citable number is better anyway: MIT found the brain can identify an image seen for just 13 milliseconds.
- "Most people are visual learners." Matching teaching to a "learning style" has no experimental support (Pashler et al., 2008). Good visuals help almost everyone, not a special group.
One more thing about reach on X. In the ranking defaults X published in 2026, a video view by itself carries a weight of 0. Shares, replies and follows carry the weight. So I don't design these to be watched; I design them to be sent to someone. Each one ends on a single number you'd quote to a friend.
The 7 prompts
Paste these into Claude one at a time, in order. Replace everything in [brackets]. I use Claude Code because it can run the render itself, but the first five work in any chat.
1. Get the real numbers first.
I want to build a 3D simulator of [the human heart as a pump]. Before any code, research it and give me a fact sheet: the 10 numbers that matter most [rate, stroke volume, pressures, valve timing], each with a source link. Mark anything uncertain or disputed. Tell me which single input drives the whole system.
This step decides everything. I left one number out of the spider video: I couldn't pin down how long a web takes to build, so the screen says TIME-LAPSE instead of showing a made-up figure.
2. Write the model before the model.
Write the system as pure functions of [one input: position in the cardiac cycle, 0 to 1]. Return every value the scene and the panels will need [volume, pressure, which valves are open, ECG voltage]. Use the numbers from the fact sheet. Check 3 of them by hand and show me the arithmetic.
3. Build the object.
Build [the heart] in Three.js from primitives, in real units. Parts: [4 chambers, 4 valves with leaflets, aorta, pulmonary artery, vena cavae, coronary arteries]. Every moving part reads from the model in step 2. Style: [pale studio background, soft shadows, red for oxygenated, blue for deoxygenated]. The object should fill 60–70% of the frame.
4. Add the instruments.
Around the object, lay out a 1920×1080 console: a title and one huge live number top left; 4–6 panels that redraw from the model every frame [ECG, pressure–volume loop, valve states, output per day]; thin leader-line labels that follow the 3D parts. No number on screen is typed in.
5. Write the story.
Make a 24-second tour in 6 chapters, one reveal each: [at rest, cut open, slow motion through one beat, the electrical signal, exploded view, exercise to 150 bpm]. Give each chapter a camera position and a one-line caption. End on a title card with the single most surprising number.
6. Be your own critic.
Render a still at the middle of every chapter and look at each one. List anything that overlaps, floats, clips, is too small, too bright or unreadable. Fix it with a number, not by moving the camera away from the problem. Show me the stills before and after.
7. Render it and score it.
Make renderAt(t) a pure function of time. Render every frame at 30 fps in headless Chrome and pipe them to ffmpeg (H.264, yuv420p, faststart). Then generate the soundtrack in code on the same timeline: [a "lub" on every AV-valve closure, a "dub" on every outlet-valve closure, a soft pad, a click on each chapter change]. Mux it in and send me the file.
What went wrong, and the number that fixed it
Prompt 6 caught every one of these before the final render. Each fix was a single value.
The last row is from an earlier video, a virus attacking a cell. It's the mistake I see most: adding detail until nothing is readable. Fewer, clearer parts beat more parts.
One practical note. These rendered on a machine with no graphics card, at 2–8 seconds per frame. A 24-second video is 720 frames, so 25–40 minutes. Splitting it into two halves that render at the same time cut that roughly in half.
Build your own: 6 ideas with one input each
The trick is to pick something with one input and real numbers you can look up. If you can't name the input, the simulator will turn into a pile of separate animations. Here are six I haven't built yet:
1. The human eye focusing. Input: distance to the object. The lens changes shape, the image sharpens on the retina, and a panel shows the focal length.
1. A hummingbird hovering. Input: wing-beat phase. The wing traces a figure-eight, and a lift chart shows both strokes doing work.
1. A lung breathing. Input: diaphragm position. Air volume, pressure and oxygen in the blood all follow it.
1. A bicycle gear change. Input: derailleur position. The chain climbs a sprocket and a cadence-vs-speed chart redraws.
1. A tsunami crossing an ocean. Input: water depth along the path. Watch the wave slow down and grow taller as it reaches the shore.
1. A nuclear reactor control rod. Input: rod depth. Neutron count, power and temperature all respond, with a SCRAM button at the end.
If you build one, post it and tag me. I'll repost the best ones.
Want the full prompt?
The 7 prompts above will get you 80% of the way. The spider took one more page of detail: the build order, the silk layers, the vibration model and the camera path, written out as one prompt.
Comment WEB and I'll send it to you.
And tell me: what should I take apart next? The most-liked reply gets built.
Save this article for when you build your first one. Every prompt is here.
Sources
- Orb weaver: Wikipedia: orb-weaver spider (web building, daily rebuild) · Wikipedia: spider silk (strength, 7 gland types)
- Heart: Cardiac output (OpenStax-based textbook) · Cardiac cycle and pressure · StatPearls: Heart sounds · Cleveland Clinic: blood flow through the heart
- Engine: displacement and piston arithmetic are worked on screen from the 86 × 86 mm bore and stroke; the cylinder-pressure curve is an illustrative model
- Learning research: Höffler & Leutner, 2007 · Ploetzner et al., 2020 · PhET research · Pashler et al. on learning styles · The 60,000× myth
- X ranking: 2023 open-source ranker weights · xai-org/x-algorithm
- Rendering: Remotion on deterministic rendering · timecut