fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: independently confirm the REGN face decode -- 133573/133573 against a 0.69% control

Browse Source 
Re-derived the other branch's central check with my own code, my own reading of
the record and my own control, rather than accepting the number.

At base chunk+0x10, with the plane at intra-record +0 and three u16 vertex
indices at +32: every one of 133573 faces has all three named vertices
satisfying its own plane equation. Random-vertex control 2782/400719 = 0.69%.
100% against 0.69% is not a fit.

That also settles the record boundary from my side: the u16s describing a plane
sit after it in the same 48-byte record, so my earlier 'four zeros at the start
of each record' was those integers seen 16 bytes out of position, one record
late.

Two implementations, two independent guesses at the intra-record layout, the
same 100%.
This commit is contained in:
Sylpheed RE agent
2026-08-26 08:06:30 +00:00
parent a2acd56407
commit 6c47f8231c
1 changed files with 29 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/re/structures/regn-map-grid.md
View File

@@ -461,4 +461,32 @@ gave for it was not evidence.
*boundary* moves, and the four integer words I described as "four zeros" move
with it into the record they describe — which is where the face adjacency, and
the answer to the cell→geometry question, was hiding. See branch
`auto/regn-reader` for the tetrahedral decode.
`auto/regn-reader` for the tetrahedral decode.
## ✅ Independent confirmation of the face decode
**2026-08-26.** I re-derived the other branch's central check with my own code,
my own reading of the record, and my own control — rather than accepting the
number.
Reading at base `chunk + 0x10`, taking the plane at intra-record `+0` and the
**three `u16` vertex indices at `+32`**, and asking whether each named vertex
satisfies its own face's plane equation:
| | |
|---|---|
| faces where **all three** named vertices lie on the plane | **133 573 / 133 573 (100.00 %)** |
| a **random** vertex lying on that plane (control) | 2 782 / 400 719 = **0.69 %** |
A 100 % against a 0.69 % baseline is not a fit — the face record genuinely names
the vertices of its own plane, and the `+0x10` base together with this layout is
right.
That also settles the record-boundary question from my side: the `u16`s that
describe a plane sit **after** it in the same 48-byte record. My earlier reading
of "four zeros at the start of each record" was those integers seen 16 bytes out
of position, one record late.
This is worth having in the corpus independently of the other branch: two
different implementations, two different guesses at the intra-record layout, the
same 100 %.