Claude (auto-RE)
3d9f21f030
A capture at controlled range (ship_capture_close.sh: lock a capital ship, close on it, F10 per range band) finally draws capital-ship hulls at full detail. Two correctness fixes were needed before the numbers meant anything: * one F10 log is ~14 frames with no delimiter, and WV_ref^-1 . WV_p only cancels the camera within one frame — segment_frames splits on vertex-buffer recurrence, and correlate_frames cross-checks the blocks against each other instead of trusting a single shot; * aggregate by consensus, not median: a stage holds several ships of one class sharing vertex buffers, so a block can mix two instances. Result: f105, e105 and e106 reproduce assemble_ship to <=0.43 units in translation and 0.000 in rotation for every part that does not move. The e106 rules generalise, and the viewer bug report now points at the viewer. Narrow leftovers: e105_brg is missing from assemble_ship, e105_eng_01 rotation differs by 1.711. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
3.1 KiB
RE backlog
Open items that are not being worked right now. Each entry says what is wrong or
unknown, what evidence exists, and what the first step would be. Move an item into
INDEX.md (with a structures/…md or a parser + test) once it is actually settled.
Capital ships assemble wrong in the viewer
Reported: 2026-07-30, by the user. Status: 🔎 diagnosed 2026-08-10 — the
format layer is exonerated. Runtime captures of three classes (f105, e105,
e106) at controlled range reproduce assemble_ship to ≤0.43 units in translation
and to 0.000 in rotation for every part that does not move; see
ship-placement-capture-generalisation.md
§4. So look at the viewer: first that it passes include_external = true
(iso_loader.rs:4012 — with false an e106 loses its bridge and both nacelles,
5 parts instead of 11), then its own transform stack. Two narrow format-side leftovers
remain: e105_brg is never produced by assemble_ship, and e105_eng_01's rotation
differs by 1.711.
The original report and its reasoning follow.
The reborn viewer builds capital ships from the split XBG7 parts via
sylpheed-formats::ship::assemble_ship, and they come out wrong — parts in the
wrong place / wrong orientation.
Why this is a real finding and not a known limitation: the RE write-up
ship-placement-runtime-capture.md declares
static assembly ✅ exact as of 2026-07-26 — 9-channel joint tables
[TX TY TZ RY RX RZ SX SY SZ], Euler Ry·Rx·Rz, with
ship::tests::static_assembly_matches_runtime_capture asserting static == runtime
capture (T < 1.0, R < 0.02). So either the viewer is not using that path, or the
claim generalises worse than the test suggests.
The likely gap: that test is one ship — the e106 destroyer, 8 parts plus
two nacelles, two turrets and the hull mirror. Nothing pins the other classes.
Rules that were derived from e106 and could easily be e106-specific:
- the engine cluster rig mounted at
GN_Engine_01(two mirrored nacelles + centre); - "X-reflect the shared-geometry twin whose lateral offset opposes the geometry's dominant side" — a heuristic, not a decoded flag;
- cross-id turret instancing (×2).
First step (the oracle already exists): re-run the runtime capture on a different
capital ship and diff static vs captured, exactly as e106 was done — F10 in the
capture-ship-placement build of xenia-canary-native dumps the ship shader's
c0..c2 WorldViewProjection rows per part; WV_ref⁻¹ · WV_p is the ship-space rigid
transform, which is ground truth. Pick a class whose rig differs from e106
(different engine count, a ship with no sld, a carrier). Then extend
static_assembly_matches_runtime_capture into a per-ship table so a regression in one
class cannot hide behind e106 passing.
Also worth ruling out first, cheaply: that the viewer's own transform stack (scale,
handedness, node-instance recursion) is not re-breaking a correct assembly — compare
the viewer's placement against assemble_ship's output directly before blaming the
format layer.