Mythic Masters: open-world frame budget (95th under 16.7 ms, no hitch, a party of six), hill climb to 8/10, rounds 6+ (from #3709) #3796

Score: 3.4/10 (target 8, on the owner's scale: agent judges halve their number, per the 2026-11-05 reset)

The owner's brief (2026-11-05): Mythic Masters' open world must be performant, especially once friends walk it together (#3663). Rounds 1 to 4 in #3664, #3686, #3701, #3705 (PR #3685), round 5 in #3709 (PR #3794).

Round 5 (PR #3794): the recipe walks alone and with a party of six (bun scripts/walk-budget.ts --party 1,6), and --profile <dir> writes CPU and heap flame graphs of each walk (scripts/profile.ts) and prints the hottest functions. The flame graph showed closed-chain-ik's solver at about 60% of a party frame, roughly 2 ms per beast, so a friend's line-up now poses every other frame with 3 iterations (Walker3d.lod). With six, p50 went from 33 to 16.7 ms and frames over 50 ms from 95 to 0 on desktop. The table is in the PR.

Next, in order:

1. Draw calls per beast. A beast is about 7 calls (several skinned parts and materials, pupils, the contact pool), so a party of six adds about 110 against the +12 allowed. Merge a beast's parts into one skinned mesh with one material where the art allows, put the pupils into the eye mesh, and draw the contact pools as one instanced mesh. Turning off friends' sun shadows didn't move the count (tried in round 5).
2. Desktop p95 with six is still 33 ms. Profile it (--profile) after 1.
3. IK off the frame. The solver is still the top of the flame graph. The bigger moves: run each beast's solve in a worker pool (pose one frame late, spread over cores), or port the solver to Rust/WASM next to sim-rs. Measure one beast's solve in each before picking.
4. A quiet-machine run of MM_BUDGET=1 bun test test/budget.test.ts. Round 5's single run failed on one 66.6 ms frame on the walk alone, on a Mac at load 6 to 30. Run it on the builder (Bob) when it's on.

Goalpost: 8/10 from the owner

Scored on numbers, not taste, so each round prints the same table from the same recipe (bun run probe mythic-masters --js with the mythicMasters handle; a fixed walk of 90 seconds across a region border at a fixed hour, with a party of one and of six shown):

1. Frame time. 95th percentile under 16.7 ms on this Mac's headless Chrome through the whole walk, and no single frame over 50 ms (the patch hitch gone: builds split over frames or moved to a worker).
2. Draw calls and memory. Draw calls per frame and JS heap printed and flat across the walk; a party of six adds at most 12 draw calls and 60 MB.
3. Load. Time to first walkable frame under 3 s on a cold cache locally, and the bytes it took, printed.
4. Phones. The same walk at a phone viewport with the quality knob (@rustybuns/util/quality) on low stays under 16.7 ms at the 95th; no feature only works at high.
5. A budget that holds. The numbers live in one test (test/budget.test.ts) that fails when a round regresses them, so the next climb can't spend them.

The loop

Each round is one PR against main that says "Part of #N" with the before/after table in the body. A fresh judge scores the five points, halves it, and the comment starts Score: x/10 (target 8) and ends Next: ...; then open "rounds N+ (from #N)", close this one with "Moved up to #new". Keep effect out of the per-frame code. At the target, a MANUAL RUN: for the owner's own walk on their phone.