fabi/Syplheed-Reborn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re: the break-composite alarm is false -- the container stores 3-6 copies of each buffer

Browse Source 
locate_draw counts copies of a captured buffer. The f105 parts _rou_f105_break
claims exist 3-6 times over (the 2336-vert one: 6 direct AND 6 mirrored), and
every live LOD checked is anchored on a direct, byte-identical copy -- so the
composite taking the drawn copy costs nothing. This also calibrates the oracle:
'exact' (anchored at the drawn offset) is stricter than correct, so 45/46 is a
lower bound. Open: a resource landing on a MIRRORED copy would be a real defect
invisible to every count-based metric.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-12 03:32:58 +00:00
parent 7f1ac41563
commit 55e1fe3783
2 changed files with 84 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
docs/re/structures/xbg7-mesh.md
View File

@@ -898,14 +898,37 @@ systematic mis-anchor is invisible to it because it is consistent. Where the two
disagree, the capture wins. Full suite green including the disc- and ISO-gated
ship tests.
❔ **Still open — grouped composites.** `_rou_f105_break` (the f105 destruction
model) claims **twelve consecutive** drawn buffers, each matching one of its
sub-mesh vertex counts exactly, while `f105_bdy_01_m`, `f105_bdy_03_m`,
`f105_eng_01_m` — resources of exactly those sizes — are anchored elsewhere.
Distinct assignment does not touch this: the grouped-pool path is excluded. The
question is the twins' question again — does the container hold two copies of
each of those buffers, or one that both names should share? The same
mirror/duplicate test would answer it.
✅ **Closed — the grouped composite is a false alarm.** `_rou_f105_break` (the
f105 destruction model) claims **twelve consecutive** drawn buffers while
`f105_bdy_01_m`, `f105_bdy_03_m` and `f105_eng_01_m` sit elsewhere, which looked
like the twins' bug in the grouped-pool path. It is not.
`examples/locate_draw.rs` counts how many copies of a captured buffer a container
holds, directly and X-mirrored:
| drawn buffer | vcount | direct copies | mirrored copies |
|---|---|---|---|
| `0x1bf596c` | 2446 | **3** | 0 |
| `0x1c0fe2c` | 2336 | **6** | **6** |
| `0x1c211cc` | 1402 | **4** | 0 |
| `0x1bf40f4` | 261 | 1 | 0 |
The container stores these parts several times over, and every live LOD checked
(`f105_bdy_01_m` at `0x1ecb4c0`, `f105_bdy_03_m` at `0x1f902a4`, `f105_eng_01_m`
at `0x1ffb884`) is anchored on a **direct** copy — byte-identical geometry to the
one the engine drew. So the composite taking "the drawn" copy costs nothing: the
decode is the same vertices either way. (The draws use the ordinary ship shader
`0xEEA84C59D7F95371`, the same one as the validated e106 hull draws, so these are
intact-ship draws, not debris.)
⚠️ **This also calibrates the oracle metric.** "Exact" in the tables above means
*anchored at the offset the engine drew from*, which is stricter than correct: a
resource anchored on an identical copy is equally right. The 45/46 figure stands
as a lower bound, and an "unclaimed" row is not automatically a defect.
❔ What the copy counts *do* leave open: with six direct and six mirrored copies
of one buffer, a resource landing on a **mirrored** copy would be a real defect
and would look identical to a correct decode in every count-based metric. Only a
capture (or the twin-pair invariant) can catch it.
Not settled: `e106_brg_01_b_02` ≡ `e106_brg_01_l` (51 verts). A second 51-vertex
`vbase` exists in the logs but is **not** from this container, and the container