bbfeb1c387
Working the BACKLOG item "capital ships assemble wrong in the viewer". - ship_audit over all 22 stage containers: only ONE outlier ship (f002_bdy_05, Stage_S03/S27, dist 6540 vs cluster spread 1071), so static assembly is not grossly broken class-wide. Recurring MULTIKEY joint tracks on f104/f105/f106/e102 are the standing hypothesis for class-specific error — e106, the one validated ship, has none. - new tools/re-capture/ship_capture_session.sh: one blocking session that boots Stage 02 and fires N F10 ship-captures with screenshots. Boot to in-flight was 24 s; 3 of 5 presses produced logs (2964/3111/3668 draws). - NEGATIVE, unexplained: correlate_capture matched ZERO parts for f101/f105/ f106/e105. Documented with the collected facts and the next step (invert the match: largest capture vcounts -> which decoded part has that count). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
101 lines
5.5 KiB
Markdown
101 lines
5.5 KiB
Markdown
# Capital-ship placement — does the `e106` result generalise? (WIP, 2026-07-31)
|
||
|
||
**Status:** 🚧 **WIP, time-boxed session.** Two results so far: a static audit across all
|
||
22 stage containers (done, below) and a first in-mission F10 capture run in Stage 02
|
||
(done — three capture logs, but **no capital-ship part correlated**; see "Open").
|
||
|
||
Context: [`BACKLOG.md`](BACKLOG.md) — "Capital ships assemble wrong in the viewer",
|
||
reported 2026-07-30. The oracle and the correlator already exist
|
||
([`ship-placement-runtime-capture.md`](ship-placement-runtime-capture.md)); the open
|
||
question is whether the rules derived from the one validated ship (`e106`, Stage_S01)
|
||
hold for other classes.
|
||
|
||
## 1. Static audit across all stages (offline, reproducible)
|
||
|
||
```
|
||
cargo run --release --example ship_audit -- ../sylph_extract/hidden/resource3d
|
||
```
|
||
|
||
87 lines of output, of which:
|
||
|
||
- **Only two OUTLIER lines, and they are the same ship twice**:
|
||
`Stage_S03`/`Stage_S27`, `f002_bdy_05` centroid `[-1398 6251 918]`, `dist=6540`
|
||
vs a cluster spread of `1071`. Every other assembled ship in every other stage
|
||
has all parts inside its own cluster.
|
||
→ **The user-visible breakage is NOT a gross static-placement outlier for most
|
||
classes.** Whatever is wrong in the viewer is either subtler than "part flung far
|
||
away" (wrong rotation, wrong mirror, missing part) or lives in the viewer, not in
|
||
`assemble_ship`. `f002_bdy_05` is a genuine, separate, reproducible static bug.
|
||
- **MULTIKEY**: joint tracks with more than one keyframe, which `read_trs9`'s
|
||
single-key read does not model. Recurring rigs: `e_rou_f104` (3), `e_rou_f105` (2),
|
||
`e_rou_f106` (2), `e_rou_e102` (6), `e_rou_e108_Missile_open` (2), `e_rou_e501` (1),
|
||
and the `e901` boss with 2–15 tracks per pose. Several of these (`Missile_open`, the
|
||
`e901_attack*` poses) are obviously *animation* and harmless for a static pose; the
|
||
plain hull rigs `f104`/`f105`/`f106`/`e102` are **not** obviously animation and are
|
||
the best hypothesis for a class-specific assembly error. ❔ **HYPOTHESIS — not
|
||
verified.** `e106`, the one validated ship, has **no** multikey tracks, which is
|
||
exactly how a rule that only works for single-key rigs could have passed unnoticed.
|
||
|
||
Raw audit output is reproducible with the command above (not checked in; it is
|
||
deterministic from the disc).
|
||
|
||
## 2. First in-mission capture run (Stage 02)
|
||
|
||
New tool: [`tools/re-capture/ship_capture_session.sh`](../../tools/re-capture/ship_capture_session.sh)
|
||
— one blocking session (per the session-lifetime rule): boot → Stage 02 in flight →
|
||
N× {screenshot, F10, small yaw}. Each F10 writes its own
|
||
`xenia_ship_capture_NN.log` next to the binary.
|
||
|
||
Run 2026-07-31, 5 presses requested:
|
||
|
||
- **Boot to in-flight took 24 s** (`skip_intro.sh` skipped the movie at 1 s and 6 s,
|
||
title at 11 s, HUD shield bar at 24 s) — much faster than the ~100 s in the notes.
|
||
- **3 of 5 F10 presses produced a log** (`_01`…`_03`, 2964 / 3111 / 3668 draws).
|
||
Logs (8–10 MB each) and the screenshots are at `/sylph-home/re/shipcap/`; not
|
||
committed for size. One screenshot is checked in as
|
||
[`captures/shipcap-stage02-launch.png`](captures/shipcap-stage02-launch.png).
|
||
- The screenshot confirms the capture frames are real in-mission combat frames
|
||
(HUD live, `REMAINING OB 004`, ACROPOLIS + a Destroyer labelled on screen, a
|
||
capital-ship hull filling the bottom of the frame).
|
||
|
||
### Result: no correlation yet ❌
|
||
|
||
```
|
||
correlate_capture xenia_ship_capture_03.log Stage_S02 <id> bdy_01
|
||
```
|
||
for `f101` (ACROPOLIS), `f105`, `f106`, `e105` reports *"no draw matches any LOD
|
||
(culled/off-screen?)"* for essentially every part — only two speculative LOD tries
|
||
(`f101_bdy_03` vcount 90 `[l]`, `e105_wep_01` vcount 60 `[l]`) and **zero accepted
|
||
matches**.
|
||
|
||
That is a **negative result, and it is not yet explained**. Facts collected:
|
||
|
||
- The capture is not empty or degenerate: 3668 draws in `_03`, top shaders
|
||
`0xDA51B0745ABF85D2` (1258), `0xE0BAFB4F520FE441` (1091), `0xEEA84C59D7F95371` (770).
|
||
None is the `e106` ship-shader hash from the 2026-07-26 capture; the F10 path does
|
||
not filter by hash, so this alone is not the cause.
|
||
- Large vertex counts *are* present (3024, 2772, 1736, 1612, 1240 …), so capital-ship-
|
||
sized geometry is being drawn.
|
||
|
||
Candidate explanations, **untested**:
|
||
1. the Stage-02 capital ships on screen are drawn from LOD/damage variants
|
||
(`_d00`, `_m`, `_l`) whose vcounts the correlator's variant list does not cover;
|
||
2. the position-validation step rejects otherwise-correct vcount hits (the capture
|
||
dumps ≤64 positions — a set-membership test against the wrong variant fails);
|
||
3. the ships in view at launch are drawn by a *different* draw path than `e106` in
|
||
Stage_S01 (e.g. instanced/batched), so no single draw equals one part.
|
||
|
||
**First step next session:** take the largest few vcounts in the capture and ask which
|
||
decoded part in `Stage_S02.xpr` has that count (invert the match), instead of asking
|
||
per-part whether a draw exists. That distinguishes (1)/(2) from (3) immediately.
|
||
|
||
## Honest summary
|
||
|
||
- ✅ Static assembly is **not** grossly broken across stages — 1 outlier ship
|
||
(`f002_bdy_05`), reproducible.
|
||
- 🟡 A concrete, testable hypothesis for class-specific breakage exists (multikey joint
|
||
tracks on `f104`/`f105`/`f106`/`e102`; `e106` has none).
|
||
- ❌ The runtime oracle did **not** reproduce on a second ship class yet. The capture
|
||
pipeline works end-to-end (boot → F10 → logs); the correlation step is where it
|
||
stops. **NEEDS-HUMAN / next session**, do not assume the `e106` rules generalise.
|