From aa82d293a989ef88898bf9564fb98d398c125055 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Wed, 12 Aug 2026 01:40:56 +0000 Subject: [PATCH] re: the capture logs are the sharing oracle -- engine reuses a buffer only 3.4% of the time The raw Canary capture logs from the 2026-07 sessions are still on disc at /sylph-home/re/shipcap/xenia_ship_capture_*.log, and their DRAW lines carry vbase -- the GPU vertex base, i.e. ground truth for which buffer the engine draws a part from. That is precisely the oracle the shared-decode question needs, and it needs no new capture run. Restricted to the ship-geometry stride 24, across the three logs: 6093 draws from 2291 distinct vbases, and only 77 vbases (3.4%) drawn more than once. So one buffer serving several parts is the exception in the engine, while our decoder has 19% of resources sharing geometry. The measures differ (draws-per-buffer vs resources-per-geometry) so this is evidence not proof, but it points the same way as e106_bdy_02 == e106_bdy_03_m: much of that 19% is anchoring error rather than asset reuse. Per-part use is already available: correlate_capture matches a draw to a resource by vcount plus decoded positions, and the same match yields each part's vbase -- so two resources our decoder gives identical geometry can be checked directly, different vbase meaning our shared decode is wrong. Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/structures/xbg7-mesh.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/docs/re/structures/xbg7-mesh.md b/docs/re/structures/xbg7-mesh.md index 120144e..1218188 100644 --- a/docs/re/structures/xbg7-mesh.md +++ b/docs/re/structures/xbg7-mesh.md @@ -552,3 +552,34 @@ legitimate (a mirrored twin pair genuinely shares one geometry), and some is certainly not** — and cross-container consistency cannot tell them apart. A test that can: compare a shared pair against a runtime capture, which is ground truth for what the engine actually draws. + +### The capture answers it at population level — and the logs are still on disc + +`/sylph-home/re/shipcap/xenia_ship_capture_*.log` (kept from the 2026-07 capture +sessions) carry the raw per-draw lines the baked table was distilled from: + +``` +DRAW vbase=0x150CCAC0 stride=28 vcount=1 indices=1 prim=1 vs=0x… +DRAW vbase=0x150CCAC0 stride=24 vcount=10891 indices=18 prim=4 vs=0x… +``` + +`vbase` is the GPU vertex base — **ground truth for which buffer the engine draws +a part from**, which is exactly the oracle the sharing question needs. Over the +three logs, restricted to the ship-geometry stride 24: + +- **6 093 draws from 2 291 distinct vbases** +- **only 77 vbases (3.4 %) are drawn more than once** + +So in the engine, one buffer serving several parts is the **exception**. Our +decoder currently has **19 %** of resources sharing geometry with another. The +two figures are not the same measure — draws-per-buffer versus +resources-per-geometry — so this is evidence rather than proof, but it points the +same way as the `bdy_02` ≡ `bdy_03_m` case: **much of that 19 % is anchoring +error, not asset reuse.** + +**How to use it per-part:** `correlate_capture` already matches a draw to a +resource by `vcount` plus decoded positions. The same match yields, for each +part, the `vbase` the engine used — so two resources that our decoder gives the +same geometry can be checked directly: different `vbase` in the capture ⇒ our +shared decode is wrong. That is the per-part oracle any future anchor work should +be validated against, and it needs no new capture run. \ No newline at end of file