Ariki · Clothing lane · For humans

How we make clothes in Marvelous Designer

We build Ariki's garments as real sewn cloth — flat pattern pieces, stitched along seams, dropped onto Lena's actual game body and simulated until they hang. Nothing is sculpted by hand. This page explains what we've made, how the process runs, and the things that took us a long time to learn.

Lena in a red, black and white tāniko bodice with a flax-coloured piupiu skirt, arms out in T-pose.
The kapa haka outfit, v3 — a tāniko-patterned pari (bodice) over a piupiu (flax skirt), draped on the game body inside Marvelous Designer. Both the tāniko diamonds and the flax strand banding are textures we generated from reference photos, not painted by hand.

The short version

Clothing runs on a two-stage lane. Marvelous Designer is the upstream half — it answers "what is this garment, and what shape is it on our body?" A headless Blender pipeline is the downstream half — it answers "how does the game wear it?" They meet at a garment mesh.

reference photo ──▶ [ MARVELOUS DESIGNER ]  ──▶  garment mesh (FBX/OBJ)
   or concept        draft · drape · texture       1.2k–4.7k verts, already fitted
                     measure · screenshot          + .zprj editable source
                                                            │
                                                            ▼
                                   [ clothing/garment_pipeline.py — headless Blender ]
                                    census · prepare · fit · reduce · skin · export
                                                            │
                                                            ▼
                                   ariki-game/assets/quaternius/outfits/<set>/
                                   per-slot GLB on the shared 65-bone skeleton

The upstream half needs a human to start each session. The downstream half is fully automatic.

The same tāniko bodice and piupiu skirt on an animated character in the game's clothing test bed.
The same two garments after the downstream half, worn in-game in the Clothing Test Bed and playing an animation. Note the piupiu clipping through the left thigh — that is the kind of defect the downstream fit stage's clearance shell exists to prevent, and it is why we review in the test bed rather than trusting the MD render.

How a garment actually gets made

Six steps. Every one of them produces numbers that the next one is checked against.

1 · Take the reference apart

Before drafting anything, the reference image is deconstructed into a worksheet: which body slot each piece belongs to, where it's anchored, where its edges should sit in metres, and how much ease (slack) it needs. Every downstream number traces back to a row of that worksheet. Skipping this step is how early garments shipped 4–14 cm off target.

2 · Draft from Lena's measurements, not a size chart

Lena is stylized. Her card reads roughly 108 – 67 – 109 cm with 72 cm thighs on a 178 cm frame. Real-world size charts produce clothes that simply do not fit her. The measurements are extracted straight off the game mesh by a script that slices it at known heights (tools/tailor/measure_body.py), so they describe the body the game actually renders.

3 · Build from blocks, not freehand

We have parametric blocks — a fitted top, an A-line skirt, a strand/fringe skirt — that turn worksheet numbers into a runnable pattern. You give it the band height, hem height and ease; it emits the panel outlines, the seam pairing and the arrangement rules with the known fixes already baked in. Hand-typing point lists is how the early mistakes happened.

4 · Drape it on the body

The flat panels get arrangement points on the avatar (shoulders, waist, skirt front/back), then the cloth simulates onto her. The sequence matters more than the settings:

5 · Judge the fit by numbers, not by eye

This is the step that was missing at the start, and it matters most. Early drapes were accepted because they looked like clothing. They were bunched around the middle.

Now every drape is measured. A script (qc_placement.py) reads the render, separates background from skin from garment, calibrates pixels-to-metres off Lena's known 1.777 m height, and reports where each garment band's top and bottom actually sit — against a target table pulled from the reference photo. For the kapa haka outfit that table was: pari top at 1.31 m ±3 cm (above the bust), pari hem and piupiu waist at 1.05 m ±3 cm, piupiu hem at 0.45 m ±4 cm (below the knee). We iterate until it's inside tolerance.

Every shipped garment also gets a screenshot committed to tools/tailor/screenshots/, front and back. That's how the work gets reviewed without anyone opening Marvelous Designer.

6 · Export four ways

FileWhy we keep it
.zprjThe editable source of truth. Opens in MD normally. Regenerating a variant from this always beats re-authoring.
.fbxWhat the downstream Blender pipeline consumes.
.objPlain-text backup, and the only reliable way to measure the mesh (see below).
.zpacFor assembling multi-piece outfits later.

The unusual part: we drive MD with code

Marvelous Designer has an embedded Python API. We wrote a small plugin that opens a socket inside MD (TinqsMDBridge), so a script on the outside can send it commands — create these panels, sew this edge to that one, simulate 250 frames, render the viewport to a PNG.

The whole method is a vision loop: draft, drape, render, look at the image, measure it, adjust, repeat. That's what makes it possible to iterate a garment dozens of times in an afternoon.

Two things to know if you're sitting at the machine. MD's embedded Python can't run in the background, so the bridge takes over the main thread: a human has to click Plugin → TinqsMDBridge to start a session, and MD's window freezes for the whole session — "Not Responding" is normal, not a crash. Ending the session with python tools/md_bridge.py --stop gives the UI straight back. If you want to look at the model yourself, we stop the session first.

None of this locks the work up. The .zprj files are ordinary MD projects — open them, edit patterns, re-drape, re-export by hand any time. The bridge is just how the automation drives the same buttons.

What we've made so far

Authored on and after 2026-07-30. Vertex counts are the exported garment mesh.

GarmentWhat it isVersionsVerts
TeeFirst test — fitted top blockv12,335
SkirtFirst test — A-line block, the most forgiving garmentv11,988
PariKapa haka bodice, tāniko patternv1 → v41,406
PiupiuKapa haka flax skirt, strand blockv1 → v33,022
CapeShoulder garmentv1, v24,664
Kapa haka outfitPari + piupiu assembled togetherv1 → v3

Our own garments are far cheaper than downloaded ones. These export at 1.2k–4.7k verts. The downloaded MD dress the clothing pipeline was first piloted on was 2.49 million verts / 110 MB. So the brutal reduce stage downstream is mostly unnecessary for our work — and because they were draped on the real game body, they arrive already fitted.

Textiles do more work than tailoring

For traditional wear, garment identity lives in the pattern, not the cut. Kapa haka, Mexica and Pacific garments are largely rectangles and simple blocks. So we model the shape simply and spend the effort on the cloth: taniko.png (concentric woven diamonds) and piupiu.png (flax strands with geometric banding) are both generated procedurally from reference photos, and both are reusable.

One non-obvious control: in MD, a PNG's DPI sets its physical size on the cloth. 1024 px at 54.2 dpi is 480 mm of fabric. You tile a motif by changing the DPI, not by scaling the image.

Things that cost us hours

What happensWhy
The garment drapes upside-down over her head and tangles In MD's 2D pattern window, y+ is UP in 3D. Panels drafted y-down come out inverted. It looks exactly like a seam bug and isn't — seven iterations were lost to this once.
A strapless top slides down to the underbust Cloth falls to the narrowest catch. MD doesn't simulate putting a garment on — it materialises the cloth where you arranged it. Add straps; it fixes placement and coverage at once.
The garment slides off the shoulders or twists partly inside out Seam pairing. Panels drafted as identical copies offset sideways are not mirrored, and need the opposite flip setting from mirrored ones.
Everything in the scene changes colour at once Fabric slot 0 is the shared default. Colouring it dyes every garment. Always add a new fabric.
A defect ships because nobody saw the back MD's snapshot camera has no rear view at all — bottom, front, ¾, sides, top, and that's it. Four separate defects shipped through this blind spot before we started using turntable renders for the back.
A busy texture hides folds and inside-out panels Judge shape with the texture off: cloth renders white on its front face and grey on its back, so a grey patch seen from outside is inside out and a white streak is a fold.

The one diagnostic that unsticks everything: render the scene right after arranging the panels but with zero simulation frames. That shows where the cloth actually starts, before physics muddies the picture. Reach for it the moment a drape misbehaves.

What doesn't work yet

Where everything lives

PathWhat's there
tools/tailor/The garment workshop: per-garment recipes, the parametric blocks, Lena's measurement card, QC scripts, generated textures, and every shipped .zprj/.fbx/.obj
tools/tailor/screenshots/The review renders — start here to see what exists
tools/md_bridge.py + tools/md_bridge/The socket bridge into MD, and a dump of MD's real API surface (688 functions, introspected — the published docs are thin and several signatures in them are wrong)
clothing/The downstream half: garment mesh → game-ready skinned GLB
.claude/skills/marvelous-designer/The full operating playbook, written for whoever (or whatever) is driving
.agents/wiki/architecture/clothing-lane.mdHow the two halves fit together

Animation repo · .humans/marvelous-designer.html · written 2026-08-06.
Everything here was learned by doing it, and verified against Marvelous Designer 2026 Personal on the PC. If a detail here disagrees with the playbook in .claude/skills/marvelous-designer/, the playbook is the source of truth — this page is the explanation, not the spec.