From c9916bcb4179be501f619306f6d1fbcc632a6524 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Tue, 11 Aug 2026 23:25:55 +0000 Subject: [PATCH] re: CORRECTION -- the e106 slab is a container-dependent mis-decode, not a stray volume One iteration ago I concluded assemble_ship was drawing a non-renderable collision volume. That named the wrong cause, and decoding the same resource from every container that holds it settles it: Stage_S01 172 verts 110 tris 49 x 23 x 42 <- a turret, correct Stage_S02 172 verts 110 tris 1600 x 2100 x 4800 <- wrong Stage_S08 same 1600 x 2100 x 4800 <- wrong Stage_S26 same 1600 x 2100 x 4800 <- wrong eleven others 49 x 23 x 42 <- correct Same resource, same vertex and triangle counts, correct in eleven containers and wrong in three. So the placement is legitimate (e303_wep_01 is a small shared turret cross-mounted on e101/e106), the original author's vbase-dedup explanation of the capture's silence stands, and my "dedup would show one, not zero" objection does not survive -- at its true size the turret is ordinary geometry. The defect is in the mesh decoder. The wider point: the decoder can produce wrong geometry WITHOUT declining. The XBG7 audit counted 814 honest refusals; this is the other kind, silently 100x too large. A screen for the signature (bounds exact multiples of 50, span > 1000) flags 22-32 models each in S02/S03/S08/S26/S27, but it also catches legitimate e_rou_* composite proxies, so that is a candidate list and not a bug count. Next: diff the anchor scan's chosen vb0 for this resource between Stage_S01 and Stage_S02 -- same resource, two outcomes -- and turn whatever distinguishes them into a post-decode sanity check so a silent mis-decode becomes a decline. Kept from the previous entry: the test can only fail one way, and cross-id placement is genuinely narrow (2 pairs across 335 ships). Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/BACKLOG.md | 61 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 54 insertions(+), 7 deletions(-) diff --git a/docs/re/BACKLOG.md b/docs/re/BACKLOG.md index f50fdcd..6f9a34e 100644 --- a/docs/re/BACKLOG.md +++ b/docs/re/BACKLOG.md @@ -153,7 +153,7 @@ report needs re-grounding against a specific ship and a specific expectation. --- -## ⚠️ The format layer is NOT exonerated — `assemble_ship` draws a non-renderable volume +## ⚠️ The format layer is NOT exonerated — but the cause is a MIS-DECODE, not a stray volume **Found 2026-08-11 by finally doing the visual**, which the notes above kept naming as the next step. It overturns their conclusion. @@ -177,9 +177,50 @@ e106_brg_01 202 verts, 202 tris 105 x 76 x 305 ``` **110 triangles, perfectly round axis-aligned bounds, and bigger than the ship it -is mounted on.** That is not a turret. 🟡 It reads as a collision / trigger -volume, and ✅ whatever it is, **the game does not draw it**: the runtime capture -of e106 contains no `e303_wep_01` at all. +is mounted on.** + +### CORRECTION (same day, one iteration later): it is not a volume — it is a bad decode + +The first reading of this was that `e303_wep_01` is a collision/trigger volume +the assembler wrongly draws. **That is wrong, and the evidence that settles it is +decoding the same resource from every container that holds it:** + +``` +Stage_S01 172 verts 110 tris X[-24.5, 24.5] Y[0.0, 23.4] Z[-20.8, 20.8] ← 49 × 23 × 42, a turret +Stage_S02 172 verts 110 tris X[-1000, 600] Y[±1050] Z[±2400] ← 1600 × 2100 × 4800 +Stage_S03… 172 verts 110 tris 49 × 23 × 42 (correct) +Stage_S08 … 1600 × 2100 × 4800 +Stage_S26 … 1600 × 2100 × 4800 +``` + +Same resource, same vertex and triangle count, **decoding correctly in eleven +containers and wrongly in exactly three** (`Stage_S02`, `S08`, `S26`). So: + +- the **placement is legitimate** — `e303_wep_01` is a small shared turret, + cross-mounted on `e101` and `e106`, and at its true size it is unremarkable; +- the original author's explanation of the capture's silence (**vbase dedup**) + stands, and my "dedup would show one, not zero" objection does not survive: + with the correct decode the turret is small, ordinary geometry; +- **the defect is in the mesh decoder**, which resolved this resource's vertex + data differently in three containers. + +The render and the symptom are real; the cause named in the first version of this +entry was not. + +### The part that matters more than this one resource + +**The decoder can produce wrong geometry without declining.** The +[XBG7 audit](structures/xbg7-mesh.md) counted 814 resources it *refuses* — a +visible, honest failure. This is the other kind: `e303_wep_01` decodes "fine" in +`Stage_S02` and is silently 100× too large. Screening for the signature (bounds +that are exact multiples of 50 with a span over 1000) flags 22–32 models in each +of `S02`, `S03`, `S08`, `S26`, `S27` — **but that screen also catches legitimate +`e_rou_*` composite proxies**, so it is a candidate list, not a count of bugs. + +**Next:** diff the anchor scan's chosen `vb0` for `e303_wep_01` between +`Stage_S01` (correct) and `Stage_S02` (wrong) — same resource, two outcomes, so +the divergence is directly observable — then use whatever distinguishes them to +add a post-decode sanity check, so a silent 100× mis-decode becomes a decline. ### Why this was missed @@ -205,6 +246,12 @@ Sweeping all 335 assembled ships for the signature *ship-scale span with under by capture absence, and by geometry. Some of the others may be legitimately large low-poly parts, and each needs the same three checks before being called a bug. -**Next:** decide the rule that separates drawable parts from volumes (candidates: -the node-name suffix, a descriptor flag, or the triangle-density heuristic), then -re-point `static_assembly_matches_runtime_capture` so it also fails on extras. +**Still true, and independent of the correction above:** +`static_assembly_matches_runtime_capture` walks the capture's parts and looks each +up in the static output, so **extra static placements can never fail it**. That is +worth fixing regardless — it is the same one-way-test shape as the earlier +`include_external` hypothesis. + +Also unchanged: only **two** cross-id placements exist fleet-wide (`e303_wep_01` +on `e101` ×24 and `e106` ×36, across 335 assembled ships), so cross-id mounting is +a narrow, real feature rather than a systemic guess.