From dde52c02e7630691fce6a8659e3f632fc5d96552 Mon Sep 17 00:00:00 2001 From: "Claude (auto-RE)" Date: Wed, 12 Aug 2026 02:24:44 +0000 Subject: [PATCH] re: correct the 3.4% reuse figure -- the capture dedups by (vbase, transform) Read off the emulator patch rather than inferred: CaptureShipDrawForRE dedups by (vbase, WVP hash), so a buffer drawn repeatedly at one transform appears once. The 3.4% counts multi-instance placement, not buffers serving several parts, and is not the population evidence about sharing it was written up as. Also pins vcount = buffer capacity and indices = that draw's num_indices. Co-Authored-By: Claude Opus 5 (1M context) --- docs/re/structures/xbg7-mesh.md | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/docs/re/structures/xbg7-mesh.md b/docs/re/structures/xbg7-mesh.md index ab32ecb..d0bb720 100644 --- a/docs/re/structures/xbg7-mesh.md +++ b/docs/re/structures/xbg7-mesh.md @@ -570,12 +570,22 @@ 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.** +⚠️ **That 3.4 % measures less than it first appears — corrected 2026-08-12.** +The capture code (`command_processor.cc`, `CaptureShipDrawForRE`) de-duplicates +by **(vbase, WVP-transform hash)**, so a buffer drawn many times *at one +transform* — which is what a mesh split into per-material sub-draws looks like — +appears **once**. The figure therefore counts buffers drawn at *several +placements* (multi-instance parts), not buffers serving several parts. It is not +the population-level evidence about sharing it was first written up as; the +`bdy_01_l`/`bdy_02_l` result below is direct evidence and stands on its own. + +Two more field semantics, read off the same patch rather than guessed: +`vcount = fetch.size × 4 / stride` is the **buffer's capacity**, not the draw's +vertex usage (which is why it matches a decoded resource's vertex count so +exactly), and `indices` is `VGT_DRAW_INITIATOR.num_indices`, **that draw's** +index count. So the 119-vertex twin logging `indices=21` against our 246-index +marker most likely means the engine issues the mesh as several sub-range draws +and the log keeps the first — likely, not proven. **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