Syplheed-Reborn/docs/re/ship-placement-capture-generalisation.md

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 — "Capital ships assemble wrong in the viewer", reported 2026-07-30. The oracle and the correlator already exist (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 — 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.
• 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.