Riglab

I’m building an outfit for Burning Man: a wearable articulated creature on a pack frame. In a little over a day around July 4, I vibe-coded a design tool for it because the tools I had were fighting me. It’s Riglab, live at riglab.joemattie.com.

Where this came from

Years ago I saw a video of Esmee Kramer’s Project Raptor: a giant walking raptor costume built from heat-formed PVC pipe, rope-braced trusses, and a seesaw spine on a backpack frame, with a bowden cable running the jaw. It’s lived rent-free in my head ever since and defines the mechanism vocabulary I want: cheap pipe, rope, and cable that moves like it’s alive. I want to build my own creature in that style, which ran me straight into a tooling problem.

I believe Esmee originally drew inspiration from this earlier dinosaur costume. Both versions leave out the details I need most: actual measurements for the individual parts and good closeups of the linkages and mechanisms. I plan to release all of that once my creature is finished. I’m working on the head now, and the physical build is about 65 percent complete.

Why not just sketch it?

My sketching skills have atrophied to where SketchUp is easier than paper. Fine for form, but this is a mechanism problem, and SketchUp isn’t suited to kinematics. I want to drag the tail through its range of motion and see whether the neck linkage binds before I cut any pipe, and get a bill of materials at the end that tells me whether the thing balances on my shoulders or faceplants me into the playa. That’s simulation and accounting, not sketching, and I didn’t want to learn a real CAD package to get it.

What Riglab is

Riglab is a browser tool for prototyping PVC linkage mechanisms for wearable creatures. Play first, engineer second: sketch pipes on a wearer silhouette, snap them together, drag the wireframe to feel how it moves. Materials, joint types, forces, and the BOM are progressive refinement, never a prerequisite for playing.

The editor is a Rhino-style quad workspace: Top, Front, and Side orthographic panels plus a perspective view. Drawing in a panel sketches into its plane, pivots default to hinges, and the whole creature is one compound 3D mechanism solved together, so a neck that pans carries the head that pitches.

Riglab’s full Project Raptor example in the Top, Front, Side, and 3D views, with live mass, center-of-gravity, and seesaw-balance analysis

As of July 5, the sketch-and-drag loop had grown into:

Forces. Ropes, elastics, bowden cables, and torsion elements, with equilibrium readouts, so you can check tension before trusting a jaw mechanism to it.
Balance. Mass inventory, center of gravity, and seesaw balance over the pack frame, computed live from the solved pose.
The design face. A materials database, a joint resolution checklist, a nesting matrix for which pipe telescopes into which, a bend schedule for the heat-formed joints (including out-of-plane twist angles), and a BOM with CSV export and a printable view.
Movement. A wearer mannequin with movement clips, plus control bindings, so you can watch the creature ride a walk cycle.
Examples. Fifteen bundled, from single mechanisms out of the Project Raptor vocabulary (seesaw spine, bowden jaw, neck truss, tail gimbal, splayed gait legs) up to five complete costume concepts.

Everything runs client-side: no backend, no accounts, works offline once loaded. Projects persist in the browser and export as JSON.

The nerdy bit I’m most pleased with

The physics. I had Claude run a bake-off before committing to a solver: Rapier, planck (a Box2D port), and a hand-rolled XPBD solver, all behind one adapter interface. Each ran against the same scenarios with analytic expected answers: a four-bar linkage against the closed-form solution, a hanging mass on a tension-only rope (taut and slack), a rope through a frictionless eyelet, a bowden coupling.

The off-the-shelf engines passed, but each needed real workarounds (Rapier’s substepping silently biased tension readouts by nearly 50 percent until gravity got injected manually), and neither has routed ropes or displacement couplings. Those needed custom constraint code either way, so “use an engine” meant a mini custom solver plus an engine integration on top.

The custom XPBD solver won on every axis: native force readouts for every constraint, 0.16 ms to step a 100-node truss versus 2.65 ms for Rapier, and roughly zero bundle cost versus 636 KB of WASM. Measurements and reasoning are in the repo’s DECISIONS.md.

On vibe-coding this

About 129 commits across a bit over a day, written almost entirely by Claude (Fable) with me steering. I ran it like a real project: a spec planfile first, every architectural decision logged, solver and BOM math gated behind acceptance tests, CI green on every commit, automatic deploys to Cloudflare Pages.

It wasn’t cheap. In two days I burned half of my 20x Max plan’s two-week token budget, plus $250 and change in usage credits, then another hundred in API credits, because I screwed up: I told Claude to keep going until it’s done or you run out of tokens, flipped on dangerously-skip-permissions, and left for a Fourth of July rave. It kept going.

Midway through I decided the original 2D per-plane design wasn’t good enough and had it converted to fully 3D, the kind of refactor that would have killed a solo weekend project dead. It took an afternoon.

What was next on July 5

Actually designing the creature. I’m fleshing out ideas in Riglab, though right now I’m in an RLHF loop of my own: use the thing I built, find some UX that needs to change, hand it off to the agent, repeat.

That’s the point: prove the mechanism in software, then hand myself a parts list when it’s time to build. Burning Man is a few months away, so hopefully I’ll get this done in time. If it survives contact with a real build this summer, I’ll write that up too.