@woosh/meep-engine 3.24.0 → 3.25.0

package/src/engine/physics/cloth/MEASUREMENTS.md

@@ -2237,3 +2237,1053 @@ it too, at seed, alongside the subtree walk and the graph colouring that seeding
 already does. Nothing pays it per step.
 
 ---
+
+## 38. What M5 proved wrong in PLAN.md
+
+Four things, and the first two are the same mistake read from two directions:
+§12 described the worker's memory as a property of the *world*, and it is a
+property of the *cloth*.
+
+| # | The design said | The measurement said |
+|---|---|---|
+| 0 | §12 — "**One `SharedArrayBuffer` for the whole cloth world**, not one per instance", with "each instance gets a region inside the buffer" | It is one per cloth, and the reseed contract is why. A `ClothState` is sized at seed from that cloth's particle and row counts, and `ClothSystem#reseed` — a chain gaining a link, a `ClothDynamics` change the row tables depend on — builds a new one of a different size while other cloths are mid-flight. A world buffer would need an allocator with relocation, and a relocation invalidates every view of every cloth in it. One buffer per cloth costs one cold-plane message per seed and makes a re-seed a re-registration. §39 |
+| 1 | §12 — the collider table is a region of the per-cloth layout; `ClothInstance` (M2) — it lives on the instance instead, "because its size is a property of the *world* … §12 puts it in the shared buffer when M5 needs it there" | §12 was right about *where* and M2 was right about *why*, and the two are not in conflict: the size is a property of the world, so the region has a capacity rather than a growth policy. A growable array is memory the worker would have to be told about again mid-run. What the capacity has to be sized against is not a garment but a **scene** — a cloth's table holds every collider on every character standing inside its query box: ten for one body, twenty for two, thirty for three. §41 |
+| 2 | §12 — "`ClothDynamics` reaches the worker through the command region, written every step" | Every step, yes; `ClothDynamics` , no. By the time the step can use them a cloth's dynamics have been through `cloth_dynamics_map.js` — a retention, a velocity limit, a self-collision radius, gravity rotated into the local frame — and sending the raw component would mean running that mapping a second time on the far side with no way to prove the two agreed. What crosses is the **step's own parameter block**, and `ClothSystem` fills the identical block in a private scratch array. §40 |
+| 3 | §18 — "**Open — the write-back has no interpolation.** §12 gives cloth `PhysicsSystem`'s producer / `__interp_restore` contract … It lands with M5" | It does not, and the contract named is not the one cloth needs. `Interpolated` is an **entity-keyed marker** — `InterpolationSystem` files snapshots under a key it assigns from the entity id — and a rigged garment's simulated things are `Node3D`s inside a skinned model, which are not entities. Cloth also needs only half of the contract it was pointed at: `__interp_restore` exists to undo render-time writes before the sim reads them, and cloth never reads back what it writes. §43 |
+
+**And one thing the implementation confirmed rather than corrected**, which is
+the milestone's own gate. §12: "`ClothSystem` and `WorkerClothSystem` must
+produce bit-identical results. Identical code over identical data in an
+identical order." They do, and the number is zero — not at the end of a run but
+at **every step of one**, over the whole `ClothState` buffer. §40.
+
+---
+
+## 39. One buffer for the whole cloth world is one buffer per cloth
+
+§12's opening sentence is the one M5 could not implement as written, and the
+obstacle is not the worker — it is `ClothSystem#reseed`, which M1 built and M5
+inherited.
+
+A `ClothState` is one allocation whose every region is sized from the cloth:
+particle count, stretch rows, bend rows, leash rows, backstops, colours. Seeding
+produces it. **Re-seeding produces a different one**, and re-seeding is an
+ordinary event rather than a teardown: `cloth_dynamics_change_needs_reseed`
+returns true whenever a field the row tables depend on moves, a chain that gains
+a link says so through `reseed(entity)`, and a rigged garment re-seeds when its
+model finishes loading. Each of those changes at least one region's length.
+
+Putting every cloth in one buffer therefore means an allocator with relocation —
+and a relocation is not a local event. Every view of every region of the moved
+cloth has to be re-cut, on both threads, while other cloths in the same buffer
+have steps in flight against their own regions. The engine has `OffsetAllocator`
+and it could do this; what it cannot do is make the *re-cut* free, and the
+re-cut is the part that has to be coordinated across a thread boundary.
+
+One buffer per cloth costs, instead, exactly one cold-plane message per seed:
+
+```
+  add_cloth    { id, state: {buffer, six counts}, self_exclusions }
+  remove_cloth { id }
+```
+
+and makes a re-seed a re-registration, which is the same code path as a first
+seed. The registration is what the worker is waiting for, so a cloth that
+re-seeds is simply not stepped for the few ticks the message takes — the same
+window a newly spawned garment already sits in.
+
+**The layout is not serialized anywhere.** The descriptor carries the buffer and
+the six counts, and the worker runs the *same* `allocate` the main thread ran, so
+there is no second description of the layout that could drift from the first.
+That is worth saying because the alternative — a table of byte offsets in the
+message — is the obvious implementation and it is the one that rots.
+
+### What it cost to move the collider table inside
+
+M2 left `collider_table` on the instance, growing by doubling. M5 moved it into
+the state at a fixed `CLOTH_COLLIDER_SLOTS`. The layout change is a `Float64`
+result region at the head of the buffer (three words, 8-byte aligned where the
+buffer's own alignment is free) and the table plus its key array inserted before
+the contact slots.
+
+Both are on the hot path's critical structure, so the question is whether the
+step got slower. It did not:
+
+```
+  interleaved A/B in one process, per-frame minimum over 1,200 frames
+
+  case                HEAD's layout   M5's layout   ratio   states agree
+  400p 2x4               1.100 ms       1.082 ms    0.983   bit-identical
+  400p 2x4 + self        1.454 ms       1.399 ms    0.962   bit-identical
+  576p 2x2               0.847 ms       0.803 ms    0.949   bit-identical
+  1024p 2x4              4.582 ms       4.487 ms    0.979   bit-identical
+```
+
+0.95 to 0.98 is not a speed-up; it is noise with a sign. The bit-identical
+column is the load-bearing one: the two states are built from the same rest pose
+and stepped with the same inputs, and they stay equal to the last bit for 1,600
+steps, so the layout change moved bytes and nothing else.
+
+### Two things about measuring it that cost an hour
+
+**The machine was not idle and could not be made idle.** Nineteen node processes
+and 30–38% background CPU throughout — other work in the same checkout. M4's own
+lesson says a timing run needs a quiet machine; what M4 did not have to answer is
+what to do when the machine will not go quiet. The answer is to stop measuring
+absolutes and measure a **ratio from interleaved samples**: whatever the rest of
+the machine is doing, it is doing it to both variants inside the same frame.
+
+**And an interleaved A/B has to alternate its order**, which the first version of
+this harness did not. Running A then B every frame charges A for everything the
+rest of the machine evicted between frames, and B reads the cache A just warmed.
+The bias is not small:
+
+```
+  ratio, M5 against HEAD     A always first     alternating
+  400p 2x4                       0.693             0.983
+  400p 2x4 + self                0.738             0.962
+  576p 2x2                       0.662             0.949
+  1024p 2x4                      0.882             0.979
+```
+
+A 30% "improvement" that is entirely an artifact of going second. Anyone
+re-running a paired measurement in this repo should alternate.
+
+---
+
+## 40. The parameter block is the protocol, and that is why the parity is structural
+
+§12 asks for bit-identical results between the two systems and calls the
+mechanism "identical code over identical data in an identical order". M3 met the
+same bar between the entity and rig paths (§25) by making the row builder and
+the pose reconstruction **one function each** rather than two that agreed. M5
+does the same thing one level down, and the shape it takes is a block of words.
+
+`cloth_step_instance(state, exclusions, params, offset)` reads every number it
+needs out of a `Float64Array`: `dt`, gravity already rotated into the cloth's
+local frame, the substep and iteration counts, the damping retention, the
+velocity clamp, the contact radius, the self-collision radius, the collider
+count, and whether self-collision is on at all. `ClothSystem` fills that block in
+a thirteen-word private scratch array and calls the function. `WorkerClothSystem`
+fills a thirteen-word slice of the shared command region and the worker calls the
+function. **Neither system computes a step parameter of its own**, so neither can
+compute one differently.
+
+`Float64` throughout the block is load-bearing rather than incidental. Every
+number in it is produced in double on the main thread and consumed in double by
+the step, so the round trip through shared memory is exact. An `f32` command
+region would round the velocity clamp, and a clamp that rounds is a velocity that
+rounds.
+
+The same argument decided where the *results* live. The step answers with three
+scalars — the largest speed left, which the sleep test reads, and two diagnostic
+counts — and a `ClothState` attached over shared memory in a worker is a
+different JavaScript object over the same bytes, so a plain field on it is
+invisible to the main thread. They go in the buffer, in `Float64`, at the head
+where the alignment is free. `Float32` would have been enough for a diagnostic
+count and not for the speed: it is compared against `CLOTH_SLEEP_SPEED_RATIO ·
+reach`, and an f32 round on one side of that comparison and not the other is a
+cloth that falls asleep one step earlier than its twin and diverges from there.
+
+### The number
+
+```
+  240 steps, a 10-link rope, anchor walking a sine with a turn in it
+  180 steps, three 10-link strands in cotton, two colliders, one of them moving
+
+  differing bytes in ClothState's buffer, per step:   0
+  differing bytes at the end of the run:              0
+```
+
+**Compared every step, not at the end.** A divergence that appears at step 200
+and one that appears at step 2 read the same from the end of a run and they are
+very different bugs — the first is drift, the second is a wrong parameter. The
+comparison is the whole buffer rather than selected fields: particle positions
+and velocities, every dual and penalty, the collider table, the contact slots and
+their warm-started multipliers, the self-collision pair list, and the step's own
+result words.
+
+The second run is there because the first never takes two of the branches:
+`cloth_contact_find` with records in the table, and `cloth_self_find` at all.
+Cotton is one of §33's three entries that set `ClothDynamicsFlags.SelfCollision`,
+and the run is self-checked — it asserts that the collider table filled, that
+contact rows were created, and that self-collision pairs were found — because a
+parity test over a branch that did not run is a parity test over nothing.
+
+### What the write-back does, which is not identical and is not meant to be
+
+The scene's poses lag by one tick. At tick `T` the worker system joins step
+`T − 1` and writes it back, then dispatches step `T`. The spec pins that exactly:
+the local transforms the worker system writes at tick `T` equal the ones
+`ClothSystem` wrote at tick `T − 1`, every tick, for the whole run.
+
+**The local transforms rather than the world ones**, and the reason is a sentence
+M1 already wrote. A node's world pose is a function of its local pose *and of the
+anchor's pose now*, so two scenes whose steps are one tick apart show the same
+shape in different places: "the cloth's *shape* is one fixed step stale; its
+*position* is not, because the attachment cascade carries the whole subtree
+rigidly with the anchor". §4.1 says that about running cloth before the poser.
+The worker's one-tick lag is the same statement with the same consequence, which
+is a reassuring place for it to land: the quality cost of the worker is a cost
+the design had already priced.
+
+---
+
+## 41. What the main thread stops paying for
+
+§17 asks M5 for "a measured main-thread cost reduction". The loopback is what
+makes it measurable: in production the worker's step and the main thread's tick
+overlap, but under `SystemWorkerLoopback` they are two calls on one thread, so
+`em.update()` is *exactly* what the main thread pays and `runPendingStep()` is
+*exactly* what moved.
+
+```
+  400 warm-up ticks then 900 measured, 3 rounds, minimum of the minima
+  a garment as an entity subtree, anchor walking; "+ body" is a ten-part
+  character collider set in the scene
+
+  workload              ClothSystem   WorkerClothSystem    the worker's   main thread
+                        main thread         main thread           step        saved
+
+  COTTON 1024p             3.623 ms            0.181 ms       4.084 ms       95.0%
+  COTTON 1024p + body      5.222 ms            0.206 ms       4.845 ms       96.1%
+  SILK 400p                1.666 ms            0.059 ms       1.488 ms       96.5%
+  SILK 400p + body         1.853 ms            0.066 ms       1.739 ms       96.4%
+  DENIM 576p               1.106 ms            0.081 ms       0.992 ms       92.7%
+  ROPE 40 links            0.130 ms            0.006 ms       0.129 ms       95.5%
+```
+
+**92% to 96%**, and the figure is not a surprise — `MEASUREMENTS.md` §7 put 69%
+of a frame in the stretch rows and 18% in the bend rows, and those are what
+crossed. What is worth stating is what is *left* on the main thread: the anchor's
+pose, the local-frame carry, the leash centres, the broadphase query and its
+rewrite into the cloth's frame, the sleep test, and the write-back. All of it
+reads components, walks hierarchies or queries an index, and all of it together
+is a fifth of a millisecond for a thousand-particle garment.
+
+The columns are minima taken from separate runs on a machine carrying other work,
+so they do not add up exactly — the 1024p inline minimum landed below the
+worker's own step minimum, which is impossible within one scene and ordinary
+across two. The ratio is the result; the absolute column is an upper bound.
+
+**Note what this does not do**, and §17 already says it: the worker moves the
+cost, it does not reduce it. "2 ms on the worker" with several characters in
+flight is a scheduling question, and `WorkerSystem` answers it with one step in
+flight at a time and a fixed-step gate — so the budget §17 sets is now a budget
+for *all the cloth in the scene together*, on one thread, per tick. What changed
+is that it no longer competes with the renderer for the same thread.
+
+### How full the per-cloth collider table gets
+
+This is the measurement that sized `CLOTH_COLLIDER_SLOTS`, and it moved the
+number, because it showed the table is bounded by the **scene** rather than by
+the garment:
+
+```
+  600 ticks, a garment walking through a scene of ten-part character bodies
+
+  garment   colliders in the scene    worst    mean    capacity
+  SILK              10                  10     10.0      64
+  COTTON            10                  10     10.0      64
+  DENIM             10                   8      7.7      64
+  ROPE              10                  10      9.0      64
+  COTTON            20                  20     19.1      64
+  COTTON            30                  30     24.9      64
+```
+
+A garment's query box is its own particle bounds fattened by a step's travel, and
+a garment is worn *on* a body — so what lands in the table is every collider that
+body carries, and every collider carried by anyone standing close enough to touch
+it. One character fills ten slots. Three fill thirty. There is no garment-shaped
+number here at all.
+
+Thirty-two was the first choice, against M2's twenty-collider scene, and three
+characters would have been inside 88% of it with an **arbitrary** drop past that
+— `ClothColliderIndex#query` answers in its own order, not in order of how much a
+collider matters, so an overflow discards colliders the cloth may be resting on.
+Sixty-four is six characters, nine kilobytes a cloth, and 1.4% of the §17
+workload's state — the same order as the 16% §33 already spends on
+self-collision storage that four of seven entries never read. The drop still
+warns once, because the capacity is a bound and not a rule.
+
+---
+
+## 42. The library, re-measured, and why no entry is re-sized
+
+§17 says to re-measure at M5 and re-size anything that drifted outside. The
+absolute table taken with `cloth_library_bench.mjs` reads 15% to 25% above M4's:
+
+```
+  M4's §33          M5's run          entry
+  1.427 → 1.802     1.641 → 2.069     SILK      2x4
+  1.478 → 1.802     1.547 → 2.002     COTTON    2x4
+  1.297 → 1.765     1.458 → 2.020     DENIM     2x2
+  1.315 → 1.828     1.435 → 2.039     LEATHER   2x2
+  0.116 → 0.129     0.126 → 0.133     ROPE      2x4
+  0.165 → 0.183     0.183 → 0.215     CHAIN     2x6
+  1.438 → 1.798     1.571 → 1.997     HAIR      2x4
+```
+
+**That is the machine, not the milestone**, and the paired measurement in §39 is
+what says so. `cloth_library_bench.mjs` does not go anywhere near
+`WorkerClothSystem` — it calls `cloth_self_find` and `cloth_step` directly over a
+`ClothState`, so the only thing M5 changed that it can see is the buffer layout,
+and that is 0.95 to 0.98 with the states staying bit-identical. Every one of
+these entries is 400 to 576 particles at 2×4 or 2×2, which are exactly the four
+shapes §39 paired.
+
+The run was taken with nineteen other node processes on the machine and 30–38%
+background CPU, which M4's own lesson predicts will cost 9% to 29%. It cost 15%
+to 25%. **No entry is re-sized**: re-sizing a library on numbers taken from a
+busy machine would bake someone else's test run into a shipped garment.
+
+What the measurement *is* good for is the shape, and the shape is unchanged: the
+three entries that set `ClothDynamicsFlags.SelfCollision` are still the tightest,
+the chains still find no pairs at all, and leather still pays the most for the
+fewest. §33's ordering stands entry for entry.
+
+**The thing to re-measure on a quiet machine** is the absolute column, and the
+question it answers is no longer "does a garment fit in a frame" but "does all
+the cloth in a scene fit in a worker tick" — §41's last paragraph. Whoever does
+it should check the process count first; this section exists so they know to.
+
+---
+
+## 43. Interpolation: the named contract cannot express a rigged garment
+
+§18 carried "the write-back has no interpolation" as open and said it lands with
+M5, "where the worker makes the fixed-step producer contract load-bearing for a
+second reason". The second reason is real and it points the other way: the worker
+is what makes the simple implementation impossible.
+
+**Three findings, in the order they change the answer.**
+
+**1. `Interpolated` is entity-keyed, and a garment's joints are not entities.**
+The contract §13's reuse ledger points at is `PhysicsSystem`'s: an `Interpolated`
+marker component per interpolated body, carrying a `key` the
+`InterpolationSystem` assigns from the entity id at link time, and a list of
+interpolands each naming a component class and its serialization adapter. That
+works for a rope, whose links are entities. It cannot express a **rigged**
+garment at all: M3's write-back drives `Node3D.transform_local` on the joints of
+a skinned model, and `shade_node_to_entity_composition` does not expand a skinned
+node into entities — "that is a boundary rather than an omission" (D47, quoted in
+§3). There is no entity to put the component on and no key to file the snapshot
+under. §13's ledger row is wrong for half the feature.
+
+**2. Cloth needs half the contract, and it is the half with no name.**
+`__interp_restore` exists because the render-time blend writes into the very
+components the simulation reads, so the sim has to be handed its authoritative
+pose back before it integrates. Cloth's simulation state is `ClothState.position`
+in the cloth's local frame, and `cloth_write_back` writes nodes `1` upward —
+never the anchor, which is the one transform it reads. **Cloth never reads back
+what it writes**, so there is nothing to restore. It needs the record/publish
+half and none of the restore half, and it gets the restore it *does* depend on
+for free: an anchor on a physics-driven character is restored by
+`PhysicsSystem.__interp_restore` before cloth reads it.
+
+**3. The worker takes the cheap implementation away.** Without it, a render-time
+pass could read `ClothState.position`, reconstruct the pose and blend. With it,
+that memory is owned by the worker from dispatch until the next tick's join —
+which is essentially all of the time outside the fixed pass. An interpolating
+cloth therefore needs a **published pose slot**: the last two steps' node poses,
+copied out on the main thread at join, blended at render time from the copy. That
+is the same double-buffered publish slot `WorkerFluidSystem` documents as the
+unbuilt prerequisite for its own render-time reads, and it is the honest cost of
+the feature rather than an implementation detail of it.
+
+### What it would cost, and what it would buy
+
+The slot is nearly free to *fill*, because `cloth_write_back` already computes
+every node's local TRS and would only have to keep it. What costs is the
+per-frame pass, which is a pose per node blended and written — strictly less work
+than the write-back, because it reads two stored poses instead of reconstructing
+one from particles, so the write-back's own cost is an upper bound on it:
+
+```
+  write-back, 401 nodes    0.0487 ms
+```
+
+The arithmetic, spelled out, because the first draft of this section guessed at
+it and was wrong by a factor of two. A blend pass runs **every frame**, where the
+write-back runs every tick, and the write-back keeps running either way. So on a
+165 Hz display against a 60 Hz fixed step:
+
+```
+                                     400 nodes     1,024 nodes (§17)
+  a blend pass, per frame             0.049 ms        0.124 ms
+  ... at 165 frames a second           8.1 ms/s        20.5 ms/s
+
+  what the main thread pays today      3.5 ms/s        10.9 ms/s   (§41, x60)
+  what it paid before M5             100.0 ms/s       217.4 ms/s   (§41, x60)
+```
+
+**Interpolating a cloth would roughly triple what the main thread pays for it**
+— and leave it at a seventh of what it paid before the worker. That is the shape
+of the trade: the feature is affordable *because* M5 happened, and it is not free.
+
+What it buys is the size of the hold, measured on M3's cape geometry — five
+strips of 8 cm links, 8.5 cm apart, which is the garment §37 measured:
+
+```
+  600 steps past settling; the largest world-space distance a node covers in one
+  fixed step
+
+  anchor     worst        mean       worst, in link lengths
+  still     46.74 mm    12.51 mm            0.58
+  walk      37.90 mm    27.98 mm            0.47
+  sprint   106.71 mm    67.42 mm            1.33
+```
+
+Half a link length a step at a walk, and a whole one at a sprint. That is
+visible, and it is the *size* of what a display running faster than the fixed
+step shows as a hold — 105 of every 165 frames repeating a pose in the general
+case.
+
+**The decision: it does not land with M5.** §17's M5 is four artifacts and three
+proofs and interpolation is none of them; the feature it turns out to need is a
+publish slot, a second system, an ordering contract with `InterpolationSystem`,
+and a way to name a `Node3D` that the engine's interpolation layer does not have.
+Landing a worker and a half-built interpolator together would have been the thing
+§17 asks milestones not to do. What has changed is that the open question is no
+longer "wire the existing contract": it is "build the cloth-shaped half of a
+contract whose entity-shaped half does not fit", and §18 now says so with the
+three findings above beside it.
+
+The one piece of good news is that the cloth-shaped version is *simpler* than the
+engine's, not harder: no restore pass, no serialization adapters, no log — two
+poses per node and a lerp, driven by the same `alpha` `EntityManager` already
+exposes for the purpose, and it covers the rigged path and the entity path
+identically because both of them end in a pose per node.
+
+---
+
+## 44. Two things M5 deliberately did not build
+
+**A playground page.** M0 through M4 each added one and M5 does not, for a
+reason that is about the dev server rather than about the cloth: a
+`SharedArrayBuffer` needs a cross-origin isolated page, and
+`packages/meep-engine/vite.config.mjs` sends no `Cross-Origin-Opener-Policy` or
+`Cross-Origin-Embedder-Policy`. Adding them is four lines and it is four lines
+that change how **every** playground page in the package loads its subresources,
+including the Sponza path-tracer pages under `src/shade/playground/`. That is a
+change to shared infrastructure to demonstrate a bridge that
+`SystemWorkerLoopback` already tests more precisely than a page could — the
+loopback makes message delivery and step execution separate events a spec can
+order, and a real worker makes them a race nobody can observe.
+
+**A second step in flight.** `WorkerSystem` allows exactly one, for reasons its
+own docblock gives, and cloth has no reason to want more: the fixed-step gate
+means a cloth's step must complete before the next tick begins regardless.
+
+---
+
+# Cloth — M6 measurements
+
+> Written 2026-09-12, against the M6 implementation in `wind/`, `solver/` and
+> `ecs/`. Everything above this line is M0's through M5's and is unchanged.
+>
+> Two scripts, both runnable directly under node — the M0 note applies unchanged:
+>
+> ```
+> node src/engine/physics/cloth/ecs/__fixtures__/cloth_m6_measure.mjs
+> node src/engine/physics/cloth/ecs/__fixtures__/cloth_library_bench.mjs
+> ```
+>
+> The second is M1's, extended here with a section that prices §10's aerodynamic
+> term against each entry's own size and budget beside the one M4 added for
+> self-collision.
+>
+> **The behavioural numbers come off the playground**, driven from its own
+> `globalThis.cloth_wind_playground` handle rather than clicked, because the
+> question is what a banner does over four hundred settled steps and a screenshot
+> cannot answer that.
+
+---
+
+## 45. What M6 proved wrong in PLAN.md
+
+Five things. The first is the one the milestone is *about* — §10 names a
+quantity that half the system cannot have — and the second is the one that would
+have shipped a garment blowing at a speed that depended on how finely someone
+had voxelised the room.
+
+| # | The design said | The measurement said |
+|---|---|---|
+| 0 | §10 — `a_drag = drag · (u_air − v) · \|n·û\|`, "the normal-facing factor making a sheet catch the wind broadside and slice through it edge-on — the difference between a flag and a rope" | The **rope has no `n`**. A chain's particles span a line and every direction perpendicular to it is equally a normal, so any one this code picked would be the history-free fabrication §7 P4(a) exists to keep out — and a rope wants the *opposite* dependence anyway, catching the flow across it and slicing along it. Both are one quantity: the part of the flow the particle's own incident rows cannot let past. Rank 2 gives §10's `\|û·n\|` exactly, rank 1 gives the cross-flow, rank 0 gives 1. §47 |
+| 1 | §10 — "a cloth overlapping a `FluidComponent` **samples its velocity field** per particle" | It samples it and then has to **convert it**. `FluidField#sampleVelocity` answers in *grid cells* per second and documents that it deliberately does not rescale, "on the assumption that callers (vegetation sway, dust drift) interpret the field as a direction × magnitude wind". Cloth's drag row is a relaxation toward a velocity, so without the multiply by `cell_size` the same wind voxelised at 0.25 m instead of 1 m blows a garment four times as hard. §46 |
+| 2 | §10 — the whole section, which never says **which thread** samples | It cannot be the worker's. A fluid field is a hundred thousand floats its own solver rewrites every step and may itself live on another worker; the *answer* is three floats a particle. So the sample runs on the main thread and lands in a region of the cloth's own `SharedArrayBuffer`, where the worker already reads — nothing is copied — and everything built from it runs in `cloth_step_instance` with the rest of the arithmetic, which is what keeps §40's parity argument intact. §46 |
+| 3 | §10 — `drag` multiplies the relative flow directly | What the step multiplies by cannot be a rate. One acceleration is held for the whole fixed step, so an explicit `rate·(u − v)` overshoots the air once `rate·dt > 1` and diverges past 2 — and §1's first commitment is "not at 5 fps", which is a `dt` of 0.2 s and a rate of 10. What crosses is the **per-step response** `(1 − e^(−rate·dt))/dt`, the exact solution of the same ODE, which closes a fraction of the gap that is strictly below one for every rate and every step. It is also the step `GlobalFluidEffector` takes for the air itself. §49 |
+| 4 | §12 — "thirteen words into memory the worker already shares"; §10 — "sleep wakes on a wind change" | Fourteen now, and the gust needs a clock that counts **steps rather than ticks**. A worker cloth is not advanced until its registration is acknowledged (§39), so the two systems reach a cloth's first step at different tick counts — and a clock that counted ticks would hand that cloth a different gust on the same step under the two systems. That is a divergence the parity gate reports, and it is the only thing in M6 that did. §50 |
+
+**And one thing the implementation found that the design had no line for at
+all.** §10's normal-facing factor is what makes a flag a flag, and it does —
+measured on the playground's banner, turning a *uniform* wind ninety degrees
+takes the mean facing factor from 0.221 to **0.000** and the mean aerodynamic
+acceleration from 43.2 m/s² to 0.08. Turning a **wake** ninety degrees does
+nothing of the kind: 0.216 to 0.280. A wake has velocity in every direction, so
+there is no orientation of a banner that is edge-on to one. §10's argument for
+reading a fluid simulation is therefore stronger than §10 knew — the simulation
+knows something the factor's own intuition does not — and the factor's headline
+claim is a statement about *laminar* air. §51.
+
+---
+
+## 46. Which side of the worker bridge, and the units nobody had converted
+
+§10 describes what cloth does with the air and never says where the reading
+happens, which was fine until M5 put the arithmetic on a thread. M6 has to
+answer it, and both answers cost something real: sampling on the main thread
+gives back part of what M5 bought, and sampling in the worker means the field
+has to get there.
+
+**The field cannot get there.** A `FluidComponent` is not a parameter, it is a
+simulation:
+
+```
+  a 32³ fluid field, the size a room-sized volume wants
+
+  velocity_x   33 x 32 x 32     33,792 floats
+  velocity_y   32 x 33 x 32     33,792
+  velocity_z   32 x 32 x 33     33,792
+                               101,376 floats = 396 KB
+
+  rewritten, every one of them, every fixed step, by a solver that may itself
+  already be on a different worker (`WorkerFluidSystem`)
+```
+
+Against a cloth step that is 1 to 4 ms and a main-thread share that M5 got down
+to 0.18 ms, shipping 396 KB a step to feed it is not a trade, it is the feature
+costing more than the thing it feeds. And there is a second objection that is
+structural rather than arithmetic: `ClothSystem` would have to sample the field
+too, so the field would have to be on **both** sides and the two copies would
+have to be proved equal — which is exactly the shape `MEASUREMENTS.md` §40 says
+breaks the parity gate.
+
+**So the field stays where it is and the answer crosses.** `cloth_sample_air`
+runs on the main thread in both systems, writes one air velocity per particle
+into `ClothState#air_velocity` — a region of the cloth's own buffer — and the
+step reads it there. Nothing is copied and nothing is marshalled: §39's "one
+buffer per cloth" already made that memory shared, and this is the first thing
+to use it in the main-thread-writes direction.
+
+The **drag arithmetic** is not on the main thread. It reads positions and
+velocities the state already holds, so it belongs with the rest of the
+arithmetic, and it is one more word of the parameter block rather than a second
+computation. §49 is what it costs; §48 is what the sample costs.
+
+### The field answers in cells, and cloth wants metres
+
+`FluidField#sampleVelocity` is trilinear over a MAC grid and answers in **grid
+cells per second**. Its docblock says so and says why: it "does NOT rescale
+them, on the assumption that callers (vegetation sway, dust drift) interpret the
+field as a direction × magnitude wind and want consistent strength regardless of
+the underlying cell size".
+
+Cloth is not such a caller. §10's row is a relaxation toward a *velocity*, and a
+velocity in cells is a garment that blows differently depending on how finely
+someone voxelised the room:
+
+```
+  the same 3-cells-per-second flow, sampled by ClothFluidWind
+
+  cell size    what the field says    what the cloth is handed
+  2.00 m         3 cells/s                6.0 m/s
+  0.50 m         3 cells/s                1.5 m/s
+```
+
+A factor of four between two authorings of the same room. `ClothFluidWind`
+multiplies by `cell_size`, `cloth_wind.spec.js` gates on it, and it is the one
+line of M6 that would have been silently wrong rather than loudly wrong.
+
+---
+
+## 47. The factor §10 wrote as `|n·û|`, and the rope that has no `n`
+
+§10 asks for `|n·û|`, and it is right about what it wants: a sheet should catch
+the wind broadside and slice it edge-on. What it is wrong about is that a normal
+exists to take the dot product with. Half of what this system simulates is
+chains — `CLOTH_ROPE`, `CLOTH_CHAIN`, `CLOTH_HAIR`, and every cape whose proxy
+is strips (§37) — and a chain's particles span a **line**. Every direction
+perpendicular to it is equally a normal. Picking one would be the same
+fabrication §7 P4(a) rules out for a contact normal, and it would be worse than
+arbitrary, because a rope's aerodynamics are the *complement* of a sheet's: it
+catches the flow across it and slices along it.
+
+Both are one quantity. Take the span `T` of the directions to the particle's
+stretch-row neighbours **in the current configuration** and the factor is the
+part of the flow that span cannot let past, `‖û − proj_T(û)‖`:
+
+```
+  rank of T   what the particle is      the factor                what §10 wanted
+  2           a point on a surface      |û·n|,  n = b1 x b2       exactly this
+  1           a link of a chain         sqrt(1 - (û·t)^2)         the complement
+  0           an isolated particle      1                         (no case)
+```
+
+One expression, three topologies, no stored normal, no orientation, no sign, and
+nothing carried between steps — recomputed from the configuration every step,
+which is what P4(a) asks of a normal and what a baked one could not offer.
+
+Measured on the topologies the two paths actually build
+(`cloth_wind_accelerate.spec.js`):
+
+```
+  a 5x5 triangulated sheet in the XZ plane, interior particle
+
+  flow direction        facing
+  along the normal      1.000
+  along the surface     0.000
+  45 degrees            0.707      (the cosine, as a sheet should)
+
+  boundary and corner particles, which carry three rows and two
+  along the normal      1.000
+  along the surface     0.000
+
+  a 5-link chain along X, middle particle and end particle
+
+  along the chain       0.000
+  across it             1.000
+  60 degrees off it     0.866      (the *sine*, which is the rope's answer
+                                    and not the sheet's)
+```
+
+**And the rows that would have faked a plane out of a line do not.** §11.1's
+chain bends through a skip row to its grandparent, which runs parallel to the
+two links it spans; §6's strain-limit row is a second row on an edge that
+already has one. Either would give a straight rope a surface, and a straight
+rope with a surface slices through a wind blowing across it — the exact opposite
+of the right answer. A second direction has to survive projection out of the
+first by a quarter of its length (about fourteen degrees) before it counts, and
+a six-link chain carrying both kinds of row still measures 0.000 along itself
+and 1.000 across.
+
+### What it does on a whole garment, which is not 1
+
+A flat sheet held rigid and broadside would read 1. A banner does not:
+
+```
+  the playground's 16x16 silk banner, 500 settled steps in a uniform 9 m/s wind
+
+  mean facing over the free particles    0.221
+```
+
+That is the correct answer and it is worth stating because it looks like a
+failure. A free flag **streams**: at equilibrium its surface lies along the
+flow, which is edge-on, and what is left facing the wind is the part near the
+pinned edge that cannot turn. A flag that stayed broadside would be a flag
+nailed to a board. The factor is what produces that shape rather than a number
+the shape should make large.
+
+---
+
+## 48. What the sample costs the main thread
+
+This is §17's question for M6 — "a measured cost showing the per-step sampling
+stays inside budget" — and the answer has two very different halves depending on
+whether a fluid field actually reaches the cloth.
+
+```
+  cloth_m6_measure.mjs section 1, paired and alternated, per-frame minima
+  a triangulated sheet at 2 cm, the §17 topology
+
+  particles   ambient      field      ratio    per particle (field)
+        144    0.50 us     9.00 us    18.0x        62 ns
+        400    0.90 us    23.40 us    26.0x        58 ns
+        576    1.30 us    34.00 us    26.2x        59 ns
+      1,024    2.20 us    59.70 us    27.1x        58 ns
+```
+
+**A trilinear sample costs 58 to 62 nanoseconds a particle**, flat in particle
+count, which is what a per-particle pass with no term in the neighbour count
+should look like. For the §17 workload that is 0.060 ms a step.
+
+**A uniform source costs a twenty-fifth of that**, and the reason is §10's own
+cost-control sentence read one step further. §10 says "a cloth outside every
+fluid field's bounds skips it entirely"; what makes that worth having is that
+the *skip* is a property the source can answer for a whole cloth at once.
+`AbstractClothWind#varies` is that question, `ClothAmbientWind` answers `false`
+for every box, and the sampler then takes one sample and fills the region —
+which is a bounds scan and a write, both linear with a handful of operations
+each. Weather is nearly free; air is not.
+
+### The whole main thread, which is what M5's number was
+
+§41 measured `em.update()` under a `SystemWorkerLoopback` and called it "exactly
+what the main thread pays, because the worker's step is a separate call". M6
+runs the same measurement with a wind source attached:
+
+```
+  cloth_m6_measure.mjs section 4
+  a garment as an entity subtree, anchor walking; the field reaches all of it
+
+  garment          no wind      ambient       field     ambient   field
+  COTTON 1,024p     0.269 ms     0.293 ms    0.334 ms      +6%    +24%
+  SILK 400p         0.059 ms     0.063 ms    0.092 ms      +6%    +55%
+  ROPE 40 links     0.006 ms     0.006 ms    0.009 ms      +5%    +54%
+```
+
+The absolute column is this machine's and this scene's — the garment is strands
+rather than §41's patch — so the ratios are what the pairing licenses. Read
+against §41's own figures, a thousand-particle garment standing in a simulated
+wake pays about **a third more main thread** than one that is not, and about a
+twentieth more if the air is only weather. Against the 3.62 ms the same garment
+cost before M5, the whole of M6's main-thread share is under two per cent of
+what the worker removed.
+
+The ambient column's +5% to +6% is the bounds scan and the fill, and it is worth
+naming what it is *not*: a source that answers `varies() === false` is not
+approximated, it is exact, because `false` is a promise rather than a hint.
+
+---
+
+## 49. What the aerodynamic term costs the step, and the trap in measuring it
+
+The first version of this section measured a cloth in a gale against a cloth
+hanging still and reported the difference as the cost of the code. It is not,
+and §7 already said so — "the variants sit in different physical states, and an
+isolated loop over one accumulate measures a converged mesh rather than a moving
+one". The size of that mistake here:
+
+```
+  the same 40-link rope, 2x4, stepped 3,300 times
+
+  hanging dead straight       0.029 ms per step
+  blown horizontal at 9 m/s   0.095 ms per step      3.24x
+```
+
+None of that 3.24× is arithmetic. A rope blown out to 1.79 m of its own 2 m is
+fighting its own hard rows at every iteration; a rope hanging straight down has
+converged and is barely working. The wind's own code, measured on the same rope
+with the physics held fixed, is **0.7%**.
+
+### Holding the physics fixed
+
+Fill the external-acceleration array with exactly gravity and the two paths
+simulate the same cloth, so the only difference left is which predict and
+integrate run. (Exactly the same cloth: the region is `Float32`, so the uniform
+side is handed `Math.fround(-9.81)` too, and the harness asserts the two
+position arrays are bit-identical after every round. Without that the two
+accelerations differ by 4e-7 and a hanging sheet — which is chaotic — is
+somewhere else entirely three thousand steps later, which is the confound above
+arriving by the back door.)
+
+```
+  cloth_m6_measure.mjs section 2, paired and alternated
+
+  entry        budget   uniform   varying    path     + term    total
+  SILK          2x4      0.930     0.934     +0.4%     0.2%     +0.6%
+  COTTON        2x4      0.933     0.931     -0.2%     0.2%     -0.1%
+  DENIM         2x2      0.649     0.648     -0.2%     0.3%     +0.2%
+  LEATHER       2x2      0.645     0.647     +0.3%     0.3%     +0.6%
+  ROPE          2x4      0.029     0.029     +0.3%     0.7%     +1.0%
+  CHAIN         2x6      0.050     0.050     -0.2%     0.4%     +0.2%
+  HAIR          2x4      0.918     0.927     +1.0%     0.2%     +1.2%
+  COTTON §17    2x4      3.232     3.196     -1.1%     0.1%     -1.0%
+```
+
+**The whole feature is one per cent of a step, and the sign of the path column
+is noise.** Two loops rather than a branch inside one is why the uniform path
+does not pay: a cloth with no wind runs the code M0 through M5 measured, byte
+for byte, and `cloth_wind.spec.js` holds a 120-step run to exactly that.
+
+`cloth_wind_accelerate` itself — the Gram-Schmidt walk over incident rows plus
+the arithmetic — is 0.1% to 0.7% of a step, larger as a fraction on a chain
+because a chain's step is small rather than because its walk is long.
+
+### What `drag` does
+
+```
+  a 20-link rope hanging under gravity in a steady 2 m/s cross-wind, 2x4
+  "lean" is the tip's downwind travel once settled; "half" the step at which it
+  first passes half of that; "settle" the step the fastest particle first falls
+  under 1 mm/s
+
+  drag   rate 1/s   response   lean m   half   settle   peak m/s
+  0.00        0.0       0.00    0.000      -       67      0.11
+  0.05        3.0       2.93    0.468     21      111      1.02
+  0.08        4.8       4.61    0.602     20      115      1.28
+  0.12        7.2       6.78    0.704     19      116      1.48
+  0.20       12.0      10.88    0.802     18      119      1.67
+  0.30       18.0      15.55    0.857     17      134      1.77
+  0.45       27.0      21.74    0.897     17      143      1.85
+  0.70       42.0      30.20    0.926     16      149      1.90
+  1.00       60.0      37.93    0.942     16      152      1.95
+```
+
+Monotone in every column and exactly zero at zero, which is what makes it a dial
+rather than a switch. The library's own spread — leather at 0.05 to silk at
+0.45 — is 0.47 m of lean against 0.90 m at the same wind, which is the
+difference between a skirt that moves and a banner that flies.
+
+Two things in that table are worth naming. **Settling gets slower, not faster**,
+as drag rises: 111 steps to 152. A livelier cloth is a cloth with more to
+dissipate, and §7 P5's sleep still arrives for every value — a banner in a
+steady wind settles into a displaced equilibrium and sleeps there, which
+`cloth_wind.spec.js` gates on. And **peak speed approaches the air speed**,
+1.02 m/s to 1.95 against 2 m/s of air, which is `drag = 1` meaning what
+`cloth_dynamics_map.js` says it means: a cloth with no aerodynamic memory.
+
+### The response cannot overshoot, at any step length
+
+```
+  a free particle, no rows, no gravity, air at 10 m/s, drag = 1
+
+    dt      rate*dt   closed/step   v after 1 step   v after 20
+  0.00417      0.25      0.221199        2.2120        9.9326
+  0.01667      1.00      0.632121        6.3212       10.0000
+  0.03333      2.00      0.864665        8.6466       10.0000
+  0.10000      6.00      0.997521        9.9752       10.0000
+  0.20000     12.00      0.999994        9.9999       10.0000
+```
+
+An explicit `rate·(u − v)` at the fourth row would move the particle to 60 m/s
+in one step and to 590 in two. The exact form closes 0.9975 of the gap and
+stops. §1's first design commitment is "it does not explode… not at 5 fps", and
+this is that commitment discharged by construction rather than by a clamp.
+
+### Memory
+
+```
+  particles    state bytes   the two regions    share
+        144         97,400            3,456     3.5%
+        400        262,776            9,600     3.7%
+        576        377,528           13,824     3.7%
+      1,024        671,160           24,576     3.7%
+```
+
+Twenty-four bytes a particle, unconditionally — the same shape as M4's
+self-collision regions, and for the same reason: `ClothState` is one allocation
+sized at seed, and making `drag` a reseed trigger would be a change to the
+reseed contract rather than a tidy-up. Against §33's 16% for three regions four
+of seven entries never read, 3.7% for two regions every cloth in a windy scene
+does is not the thing to fix first.
+
+---
+
+## 50. The clock counts steps, not ticks, and the parity gate is why
+
+§12 asks the two systems for bit-identical results and M5 made that structural:
+one `ClothWorld`, one `cloth_step_instance`, one parameter block. M6 adds the
+first thing in the system that is a function of **time**, and time is where the
+two systems genuinely differ.
+
+A worker cloth is not stepped until its registration is acknowledged, and §39's
+own argument is that it is not *advanced* either — "not stepped, not written
+back" — so `ClothSystem` reaches a cloth's first step on tick 1 and
+`WorkerClothSystem` reaches it on tick 2 or later. A gust that is a function of
+ticks would therefore be a different gust on the same step:
+
+```
+  step    ClothSystem's clock    WorkerClothSystem's clock, ticking
+     1              dt                       2dt
+     2             2dt                       3dt
+   ...
+```
+
+Measured, by putting the clock back on ticks and running the gate: the two
+buffers differ at **step 1, byte 0**. Byte 0 is the first word of
+`ClothState#result` — the largest particle speed the step produced — so the very
+first step of the run is already a different step. Not drift, a wrong parameter,
+which is exactly the distinction §40 built the per-step comparison to make: from
+the end of a run the two would look like any other divergence.
+
+**The fix is not a synchronisation.** It is that the clock advances at the first
+`advance` of a tick rather than at `begin`, so a tick in which no cloth is
+advanced does not move the weather. A cloth that has not started stepping has no
+weather yet, which is the right semantic on its own terms — a paused simulation
+should not have the wind move — and it makes the two systems agree by
+construction rather than by arrangement. It sits **above** the sleep tests
+deliberately: a world whose every cloth is asleep still has weather, and §10's
+"sleep wakes on a wind change" is the whole reason it needs to.
+
+### The number
+
+```
+  200 steps, two 9-link strands in silk, a real fluid volume with a sheared
+  flow in it, an ambient gust of 1.5 m/s on a 0.7 s period, and the anchor
+  walked out of the volume partway through
+
+  differing bytes in ClothState's buffer, per step:   0
+  steps sampled per particle:                       104
+  steps sampled once for the cloth:                  96
+```
+
+Both of the sampler's paths ran, and the run is self-checked on that, because
+§40's own lesson is that a parity test over a branch that did not run is a
+parity test over nothing. The run also asserts the banner actually moved — a
+rope that hangs straight down under a gale would make every byte agree for the
+wrong reason.
+
+---
+
+## 51. The banner in the wake, and what a wake turns out not to be
+
+§17 asks M6 for "a playground with a banner in a simulated wake". `wind.html` is
+that, and it is simulated in the strong sense: a `FluidField`, a
+`FluidSimulator`, a `GlobalFluidEffector` in its prevailing-wind regime, and a
+solid post written into `FluidField#solid`. The banner reads it through the same
+`ClothFluidWind` and `cloth_sample_air` a scene would.
+
+M5 skipped a playground for a reason about the dev server — a `SharedArrayBuffer`
+needs a cross-origin isolated page (§44) — and that reason does not reach M6:
+this page drives `cloth_step` in process, like the solver and collision pages,
+and needs no shared memory at all.
+
+### The post's deficit is a third of the free stream
+
+```
+  driven at 9 m/s, 18 x 18 x 29 cells at 8 cm, measured at the banner
+
+  post present     6.00 m/s
+  post absent      8.69 m/s
+```
+
+That 31% is the incompressible projection's answer to a solid standing in a
+flow, and there is no authored falloff anywhere in it. It is also the whole of
+§10's argument in one number: nothing cloth-specific was written to produce it.
+
+### Turning the flow: the factor works, and the wake does not care
+
+```
+  the 16x16 silk banner, 500 settled steps, gust off
+
+  source     flow    mean relative flow    mean drag accel    mean facing
+  ambient      0°           9.00 m/s          43.24 m/s²         0.221
+  ambient     90°           9.00 m/s           0.08 m/s²         0.000
+  field        0°           7.25 m/s          34.00 m/s²         0.216
+  field       90°           5.56 m/s          33.83 m/s²         0.280
+```
+
+**In uniform air the factor is everything.** Turn the wind ninety degrees at the
+same speed and the banner is not merely less driven, it is *undriven* — 0.08 m/s²
+of aerodynamic acceleration against 43.24, a factor of five hundred. That is
+§10's flag-versus-rope claim, and it is the sharpest single result in M6.
+
+**In a wake it does nothing.** The factor reads 0.216 broadside and 0.280
+edge-on — slightly *higher* edge-on, which is noise around "no dependence at
+all". The reason is not a failure of the factor: a wake has velocity in every
+direction, so no orientation of a surface is edge-on to it, and `‖û − proj_T(û)‖`
+is correctly reporting that there is nothing to slice through.
+
+This is a correction to §10's intuition rather than to its design. §10 offers
+the factor as the thing that makes reading the fluid worth doing; the
+measurement says the factor's headline behaviour is a statement about *laminar*
+air, and that what reading the fluid actually buys is the half §10 stated more
+quietly — a wake is a place where the air is slower and turned, and no
+orientation escapes it.
+
+### What the wake is not: a shedding street
+
+```
+  the air a banner's width downstream of the post, over 4 settled seconds
+  "wobble" is the largest deviation from its own mean, m/s
+
+  cells   damping   confinement   speed    wobble   ms/step
+     18       0          0         3.11     0.002      5.0
+     18     0.2        0.6         3.07     0.001      5.2
+     26       0          0         7.29     0.005     15.5
+     26     0.2        0.6         6.29     0.232     16.0
+     34       0          0         6.77     0.031     34.7
+     34     0.2        0.6         5.79     0.000     37.0
+```
+
+At every resolution the page can afford, and with the simulator's damping and
+vorticity confinement at both ends of their useful range, the wake is a
+**steady** velocity deficit rather than a von Kármán street. The banner's own
+free corner moves 1.44 µm a step with the post present and 0.12 µm without — a
+factor of twelve, and both of them settled rather than fluttering.
+
+That is the fluid solver's answer at this scale and not the cloth's: resolving a
+shedding shear layer needs a grid whose step is 15 ms at 26 cells and 35 ms at
+34, against the 5 ms an 18-cell volume costs. It is recorded here rather than
+tuned away because the page says "a banner in a simulated wake" and a reader is
+entitled to know that the wake is steady.
+
+---
+
+## 52. The library, re-measured, and why no entry is re-sized
+
+§17 says to re-measure with `cloth_library_bench.mjs` and re-size anything that
+drifted outside. The bench gains a section that runs §33's own scenario — the
+reversing gust that folds the sheet, each entry's own self-collision flag — with
+and without §10's aerodynamic term.
+
+**And the first thing it measured is §42's warning, three times.** Three runs of
+the same bench on the same machine inside an hour, same code, no wind in any of
+these columns:
+
+```
+  the §17 workload's baseline row, "M0 rows only", 1,024p at 2x4
+
+  run A    3.490 ms      12 node processes, nothing else of this session running
+  run B    3.826 ms       8 node processes, this session driving a browser
+  run C    4.257 ms       9 node processes, this session running the test suite
+```
+
+Run B had *fewer* processes than run A and was slower anyway, because the four
+that had gone were idle and what run B was actually sharing the machine with was
+a Vite dev server and a browser pane. §42 said "check the process count first";
+M6's amendment is that a process count is a proxy for load and not a measure of
+it, and that the only quantity worth reading off this bench is the **paired
+ratio** inside one run.
+
+The size of what that does to the library, before wind is anywhere near it:
+
+```
+  §33's scenario, self-collision on, no wind — the same measurement in four places
+
+  entry      M4 §33    M5 §42    M6 run A    M6 run C
+  SILK        1.802     2.069      1.730       2.042
+  COTTON      1.802     2.002      1.742       1.905
+  DENIM       1.765     2.020      1.693       1.967
+  LEATHER     1.828     2.039      1.676       1.814
+  ROPE        0.129     0.133      0.123       0.134
+  CHAIN       0.183     0.215      0.186       0.208
+  HAIR        1.798     1.997      1.722       1.930
+```
+
+**Silk reads 2.042 ms in run C with no wind in it at all** — the same code M4
+measured at 1.802 and M6 measured at 1.730 forty minutes earlier. Anything a
+re-sizing decision took from that column would be a reading of the machine.
+
+### What the wind term costs, paired
+
+```
+  cloth_library_bench.mjs, §33's scenario, with and without the wind term
+  three runs, each paired inside itself
+
+  entry      drag     run A     run B     run C
+  SILK       0.45     +4.5%     +3.4%     -2.3%
+  COTTON     0.20     -0.5%     -0.1%     +0.5%
+  DENIM      0.08     +6.2%     +6.9%     +5.5%
+  LEATHER    0.05     +0.7%     +2.1%     +8.5%
+  ROPE       0.12     +1.0%     +9.3%     -1.1%
+  CHAIN      0.05     -2.7%     -1.1%     +0.3%
+  HAIR       0.30     +6.1%     +8.1%     +4.4%
+```
+
+Between −2.7% and +9.3%, and **not monotone in `drag`** — the entry with the most
+of it comes back negative twice and the entry with the least comes back at
++8.5%. That is what a column carrying both a code cost of one per cent (§49) and
+a *different cloth* should look like, and the second is the larger term: a
+garment blown out of its drape is not the garment beside it, which is §7's
+warning in its fourth setting.
+
+**No entry is re-sized**, and M6 has a measured reason to add to M5's. M5's was
+that the absolute column came off a busy machine. M6's is §49: with the physics
+held fixed so both sides simulate the same cloth, the whole aerodynamic term is
+**one per cent of a step** — an order of magnitude below the run-to-run spread of
+the thing that would decide a re-sizing, and two below the levers §17 prices.
+Re-sizing on that would bake noise into a shipped garment.
+
+§33's ordering stands entry for entry: the three entries that set
+`ClothDynamicsFlags.SelfCollision` are still the tightest, the chains still find
+no pairs at all, and leather still pays the most for the fewest.
+
+**What is true, and is the thing to watch**, is that those three entries are now
+within a few per cent of 2 ms on this machine with wind live — and were already
+within a few per cent of it *without*. `MEASUREMENTS.md` §42's closing advice
+stands and M6 adds one clause to it: re-measure the absolute column on a quiet
+machine, take a paired reading even then, and if the answer is that the library
+is genuinely at its ceiling, the lever to spend is the one §17 prices rather than
+the feature that happened to be measured last.