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

re: the descriptor does not address geometry, and consistency does not prove reuse

Browse Source 
Two follow-ups, both negative, both worth recording so the next attempt does not
repeat them.

The descriptor cannot replace the candidate scan. If entry.data_offset located
the geometry, anchoring would be direct addressing. Across e106's resources in
Stage_S01, anchored_vb - data_offset ranges from 1199052 to 4173988 with no
constant or stride; data_offset locates the DESCRIPTOR and none of the first six
descriptor words tracks the vertex pool.

And yesterday's "1241 of 1242 pairs identical in every container, so sharing is
legitimate reuse" is weaker than it read. A SYSTEMATIC error is invisible to a
consistency test, because it is consistent. The same dump shows e106_bdy_02 and
e106_bdy_03_m anchoring to the identical offset (1505556), and e106_bdy_01_l with
e106_brg_01_m (4251208) -- a hull half and a different body's medium LOD, a hull
half and a bridge LOD. Different parts; one of each pair is wrong.

Honest position: sharing is common (19%), some is certainly legitimate (a
mirrored twin pair genuinely shares one geometry) and some certainly is not, and
cross-container consistency cannot separate them. What can: comparing a shared
pair against a runtime capture.

Instrumentation reverted; only docs land here.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-12 01:32:34 +00:00
parent f655c90b0c
commit 6d96446735
1 changed files with 24 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -528,3 +528,27 @@ The change was reverted: it was untargeted, unproven, and added a scoring path
with no demonstrated benefit. (Its one reusable idea — that several `vb0`
candidates can clear the gate and first-in-scan-order is an arbitrary tiebreak —
still applies to whichever anchor turns out to be at fault.)
## Two follow-ups on the anchor (2026-08-12)
**The descriptor does not address the geometry.** If it did, the whole
candidate-scan could be replaced by direct addressing. It cannot: across `e106`'s
resources in `Stage_S01`, `anchored_vb − entry.data_offset` ranges from
**1 199 052 to 4 173 988** with no constant or stride. `data_offset` locates the
*descriptor*, and nothing in the first six descriptor words tracks the vertex
pool. The scan is necessary.
**Cross-container agreement does not prove legitimate reuse.** The earlier
measurement — 1 241 of 1 242 related pairs identical in every container — was
read as "sharing is normal". It is weaker than that: a **systematic** error is
invisible to a consistency test, because it is consistent. The same dump shows
`e106_bdy_02` and `e106_bdy_03_m` anchoring to the identical offset
(`1 505 556`), and `e106_bdy_01_l` with `e106_brg_01_m` (`4 251 208`) — a hull
half and a *different* body's medium LOD, or a hull half and a bridge LOD. Those
are different parts; one of each pair must be wrong.
So the honest position is: **sharing is common (19 %), some of it is certainly
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.