Sylpheed/docs/re/structures/regn-map-grid.md

REGN — a stage's tetrahedral navigation mesh (and MCOL beside it)

Status: ✅ CONFIRMED. A REGN object is a tetrahedral navigation mesh of the whole play volume — vertices, tetrahedra, faces with full adjacency, per-tetrahedron portal costs — plus a uniform grid for point location. The decode is complete except for two small fields; see the 2026-08-26 section, which supersedes the offsets in the older sections below (they were read 16 bytes early — the loader's fixup base is chunk + 0x10). The older sections are kept because their refutations are still instructive.

New to this corpus — no document mentioned REGN, MCOL or hidden/MiscBin.pak before 2026-08-24.

Where it is

hidden/MiscBin.pak — 40 entries, none name-resolved, in three groups:

magic	count	sizes
REGN	11	49 KB … 3.1 MB
MCOL	11	37 KB … 81 KB
(other)	18	—

Eleven of each, which pairs them: one REGN and one MCOL per map. MCOL is untouched here; the name and the size range read like mesh collision.

The header, and why it is believable

0x00  char[4]  'REGN'
0x04  u32      size of the data area  (the POF0 table starts at 0x04-value + 16)
0x10  f32[4]   bbox min   (x, y, z, 1.0)
0x20  f32[4]   bbox max   (x, y, z, 1.0)
0x30  f32[4]   extent     (max - min)
0x40  f32[4]   cell size
0x50  u32[4]   grid dimensions
0x60  u16[6]   six counts
0x70  u32[4]   four section offsets (the first is always 0x80)

The check that makes this a decode rather than a guess — over all 11 objects:

• extent == cell × dims holds 11 of 11, exactly;
• counts[3] equals the cell count: 1000 on every 10×10×10 map and 125 on every 5×5×5 one.

Two independent fields reproducing the grid is what rules out coincidence.

The three map sizes on the disc

half-extent	cell	dims	objects
250 000	50 000	10×10×10	2
50 000	10 000	10×10×10	6
25 000	10 000	5×5×5	3

So every map is a cube partitioned into 125 or 1 000 uniform cells — 10 km cells in a 100 km cube for the common case, and one pair of maps five times larger.

✅ Section 3 is the cell index — and it self-checks 11/11

The fourth section is a one entry per cell table of 8-byte records (count, offset), immediately followed by the records those offsets point at:

index      = offsets[3] .. offsets[3] + cells*8
payload    = align16(index end) ..
record     = 32 bytes (offsets step by 0x20)

Checked over all 11 objects: the lowest offset any cell refers to equals align16(offsets[3] + cells × 8) — 11 of 11. On the six 10×10×10 maps cells × 8 is already 16-aligned and the payload butts straight up against the index; on the three 5×5×5 maps 125 × 8 = 1000 is not, and the payload starts 8 bytes later, which is what makes the alignment rule visible rather than assumed.

Two more invariants from the same sweep:

• every occupied cell has count exactly 1 — total items equals occupied cells on all 11 objects, so this is "one record per cell", not a bucket list;
• counts[4] = occupied cells + 2, exactly, on all 11 (e.g. 997/995, 880/878, 125/123). The +2 is unexplained — two sentinels, or two cells counted differently.

Most cells are occupied: 878–998 of 1 000, 123 of 125.

✅ It is a serialised object graph with a POF0 fixup table

Every one of the 11 objects contains the tag POF0, always near the tail, and its position is exactly header[0x04] + 16 — on 11 of 11:

e993b93e  header +0x04 = 0x0b100   POF0 at 45328 = 45312 + 16
e4155d94  header +0x04 = 0x235d70  POF0 at 2317696 = 2317680 + 16
… 11 of 11 identical relation

POF0 is a pointer-offset (fixup) table: the file is a serialised C++ object graph, and the loader patches the recorded slots into real pointers. That explains a detail that would otherwise be odd — the "offsets" inside the cell index are absolute file offsets, because that is what a fixup table rewrites.

So header[0x04] is the size of the data area, and everything past header[0x04] + 16 is relocation bookkeeping rather than content.

🔴 Two readings of the cell payload, both refuted by generalising

Both came from the smallest object and both died the moment they were checked against the other ten — recorded because the temptation to keep them was real:

• "the f32 at record +0x1c is the grid's bounding-sphere radius." On e993b93e it is 86 689 against √3 × 50 000 = 86 603, a ratio of 1.001. On the other ten the ratio runs 0.13 – 0.27. Fitted to one sample.
• "a record's (count, offset) pairs point at leaf arrays of count × 4 bytes." True for the first record of e993b93e; across the objects the offset deltas fail that rule on every object checked (0 of 11 clean).

What survives is only descriptive: the payload area is dominated by float data — the "strings" a printable-run scan finds are all byte patterns like 0x46/0x47 high bytes, i.e. medium-magnitude floats, not text.

❔ The other three sections

Their offsets scale with the object, and counts[0..2] scale with them — (318, 1172, 2584) for the 350 KB map against (2936, 14967, 31155) for the 3.1 MB one, a roughly 1 : 4.5 : 10 ratio that holds across all eleven. The smallest object (49 KB) is nearly empty by comparison — (8, 6, 18) — which makes it the cheapest one to decode first.

Why this matters, stated without overclaiming

A mission's enemy count rises and falls as waves arrive and are destroyed, so somewhere there is a scheduler with parameters — what spawns, where, and on what trigger. A per-map uniform grid indexed by cell is exactly the structure such a thing is indexed by.

🔴 But nothing here shows spawn parameters yet. The header is a spatial partition and no more; the sections are unread. Treat this as the location of the world's spatial data, not as the wave table.

✅ Update: REGN is a stage's MapPath

The per-stage definition record (see stage-definition-table.md) has a field MapPath = test.rgn, and name_hash("test.rgn") = 0x3506e972, which is one of the REGN objects in MiscBin.pak. The sibling field MapMesh = test.col hashes to 0x2cf7eb47, an MCOL object in the same pak.

So .rgn/REGN is stage navigation/path data referenced by the stage record, and .col/MCOL is the stage collision mesh. This does not by itself validate either of the two refuted cell-payload readings recorded above, but it does explain why the payload looks like a grid of route data.

✅ Sections 0, 1 and 2 have record strides — and section 2 is a PLANE list

2026-08-26. The three sections the page called undecoded are fixed-stride record arrays, and counts[0..2] are their record counts. Dividing each section's byte span by its count over all 11 objects:

section	stride	evidence
0	12 bytes	count × 12 fits with a remainder of 0–12 in 11 / 11
1	96 bytes	count × 96 fits with a remainder of exactly 0 in 11 / 11
2	48 bytes	count × 48 fits with a remainder of exactly 96 in 11 / 11

Section 1 landing on a zero remainder in every object, and section 2 on the same 96-byte tail in every object, is what makes these strides rather than a coincidence of division.

✅ Section 0 is a point list

12 bytes is three f32. Over 13 467 records across all 11 objects, every one lies inside that object's own header bounding box — 13 467 / 13 467 (100 %). Values land on the box corners (±250 000) and inside.

✅ Section 2 is a plane list — 48 bytes, and the plane equation closes

Read as twelve f32:

[0..3]   zero
[4..6]   unit normal          |n| = 1 ± 0.02 in 133 573 / 133 573 (100 %)
[7]      signed distance d
[8..10]  a point on the plane, inside the bbox in 133 573 / 133 573 (100 %)
[11]     1.0 exactly           in 133 573 / 133 573 (100 %)

The check that makes this a decode: for a genuine plane, n·p + d must be zero. Over all 133 573 records:

|n·p + d| / scale :  median 2.29e-08   p90 6.78e-08   max 2.15e-07

That is float round-off, not a fit — the relation holds to the last bits of a 32-bit float in every record on the disc. Three independent 100 % properties (unit normal, point in bbox, trailing 1.0) and an exact algebraic identity are well past what a wrong reading survives.

So a REGN object carries, alongside its uniform grid, a point list and a plane list — which is the shape of collision or region-boundary geometry, and consistent with MCOL sitting beside it.

❔ Still open

• Section 1 (96 bytes/record, 63 410 records disc-wide) — a per-slot census is below, but what the record means is still ❔.
• What the planes are for. "Collision or region boundary" is a reading of the shape; nothing here shows what queries them.
• The zeros at [0..3] of every plane record, and the constant 96-byte tail after section 2, are unexplained.

🟡 Section 1, slot by slot — measured, but not read

2026-08-26. 96 bytes is 24 slots. Censusing every one of the 63 410 records across all 11 objects gives a clear regional structure, even though the record's purpose is not settled:

slots	what the values are	reading
0–3	slots 2 and 3 are zero in ~100 %; 0 and 1 mostly small	❔
4–6	96 % have |v| > 1 000, range ±250 000 — the header bbox range	🟡 a position
7	99.9 % > 1 000, always positive, 519 … 107 600	🟡 a radius or extent
8–11	as f32 these are denormals (1.4 × 10⁻⁴⁵ upward) — i.e. they are integers, not floats	✅ integer fields
12–23	six pairs: the even slot 200 … 67 000 and never zero, the odd 0 … 212 000 and zero in 7–13 %	❔

The denormal signature in slots 8–11 is worth stating plainly: a float field never holds 1.4e-45, so those four words are integers that a float reader would silently turn into near-zero garbage.

A position plus a positive scalar plus integer links is the shape of a bounding-volume hierarchy node, which would fit a file that also carries a point list and a plane list. That is a reading of the shape and nothing more.

❌ The index test has no discriminating power

I tried to confirm the integer slots are indices by splitting each into two u16s and checking them against each section's record count. The result is useless, and the reason is worth recording:

slot	halves valid for section 0	section 1	section 2
8	100.00 %	100.00 %	100.00 %
9	100.00 %	99.99 %	100.00 %
10	8.78 %	44.19 %	100.00 %
11	8.76 %	44.16 %	100.00 %

A test that accepts every hypothesis rejects none. Section 2 has tens of thousands of records, so "is this u16 below the plane count" is satisfied by almost any small number — it measures the size of the section, not the meaning of the field. Only slots 10 and 11 discriminate at all, and they merely rule out section 0.

slot 11's halves are consecutive (n, n+1) in 54 % of records and slot 10's in 12 % — suggestive of paired links, but 54 % is not a rule and I am not promoting it.

❔ So section 1 stays open. What would settle it is a test with power: pick a record, follow a candidate index, and check that the thing it lands on is spatially consistent with that record's own position and radius. That needs the tree walked, not the fields counted.

❌ The BVH reading is refuted — and slot 7 is a local scale

2026-08-26. Last iteration I wrote that "position + positive scalar + integer links is the shape of a bounding-volume hierarchy node", explicitly as a reading of the shape. Tested with a design that has power, it fails.

The containment test. If slots 8–11 hold child indices, a child's sphere should sit inside its parent's. Following every u16 half of every integer slot and checking |C_child − C_parent| + R_child ≤ R_parent (2 % slack):

RANDOM control                   0 of 126 787  =  0.00 %
slot 8 half 0    63 389 tried    0.00 %
slot 8 half 1    63 395 tried    0.00 %
…every candidate…                0.00 %

The random control is the informative row. It is also 0.00 %, which means no node's sphere contains any other node's sphere anywhere in the file — so there is no nesting for an index to point at, whatever the indices mean. The hypothesis fails before the indices are even in question.

Why: slot 7 is far too small to bound neighbours.

	median	p10	p90
slot 7	3 139	1 965	9 275
pairwise centre distance	45 457	19 071	126 295

Slot 7 is 14× smaller than the typical distance between nodes, and a random other centre falls within it only 0.40 % of the time. It is also smaller than the smallest grid cell on any map (10 000).

So ✅ slot 7 is a local scale, not a hierarchy radius — sub-cell sized, with a narrow spread. Together with 63 410 scattered centres across a 500 km cube, that is the shape of many small independent volumes, not a tree.

🟡 That fits per-object collision volumes — a map's asteroids and debris, which the mission Route tables independently show as Frame_S<NN>_Asteroid records. Stated as a reading, not a measurement; nothing here counts objects.

❔ Still open: what slots 8–11 index, and what the six pairs in 12–23 are. What this iteration removed is a wrong frame — the file is not a tree, so tree-shaped tests will keep returning nothing.

❌ The cell index does not reference section 1 — two powered tests, both negative

2026-08-26. The obvious coupling in a file with a uniform grid and a list of small volumes is that the grid indexes the volumes. It does not, by the only test that could show it: spatial agreement.

Test 1 — the cell payload as indices. For every occupied cell, read its 32-byte payload record and try each u16 in it as a section-1 index, then check whether that node's centre lies inside the cell that referenced it:

RANDOM control            0.138 %
+0    0.08 %      +2    0.18 %      +4    0.11 %      +8    0.08 %
+10   0.10 %      +12   0.08 %      +14   0.08 %      … 

Every field sits at the chance rate. Nothing points at section 1.

Test 2 — the cell payload as coordinates. 32 bytes is eight floats, so a position could be in there. Trying every float triple and asking whether it lies inside its own cell:

+0  0.81 %   +4  0.81 %   +8  0.15 %   +12  0.16 %   +16  0.26 %   +20  0.78 %

Also chance.

⚠️ And the tempting number in that table is worthless

The same run reported those triples lie inside the object's bounding box in 100.00 % of cases, at five different offsets. That looks like a decode and is not: the bbox spans the entire 500 km map, so any mid-range float triple passes, and overlapping windows starting at +0 and +4 both scoring 100 % is the tell — a real field would not survive being read at a four-byte shift. It measures the size of the box, not the meaning of the bytes. This is the third time in this file's investigation that a containment test against something large has produced a meaningless 100 %, so it is recorded rather than quietly dropped.

❔ So the grid and section 1 have no demonstrated link, and how a cell reaches its geometry is unknown. What is now excluded: the cell payload holding section-1 indices, and holding cell-local coordinates.

✅ Incidental, from the same sweep: u32 slots at +0, +8 and +12 of the payload record are below 0x10000 in 100 % of records, while +4, +16, +20 and +24 are in only 11 % and +28 never — so the record has three index-shaped fields and four wide ones, whatever they refer to.

❌ …nor the point list, nor the plane list — the static coupling search is exhausted

2026-08-26. The previous test only tried section-1 targets, which left the obvious gap: the payload's three index-shaped u32s might address the points or the planes instead. Tested the same way — follow the index, ask whether the target lies inside the cell that referenced it:

RANDOM control                    0.203 %
+0  -> points 0.17 %   planes 0.16 %
+8  -> points 0.81 %   planes 0.09 %
+12 -> points 0.81 %   planes 0.09 %

All at the control rate. The two 0.81 % cells are 4× the baseline, and I am not treating that as a signal: across this and the previous iteration I have now run on the order of twenty of these tests (three index fields × three sections × two readings × several offsets), and at that count a single 4× enrichment on ~8 000 trials is what noise looks like. Reporting it as a lead would be exactly the multiple-comparisons error that a long hypothesis sweep invites.

Where this leaves REGN

✅ Decoded: the header and grid, section 0 (points), section 2 (planes), section 3 (the cell index), and the strides and field regions of section 1.

❌ Not decoded, and not reachable by the tests available statically: any link between the grid and the geometry. Every index-shaped field has been followed into every section and checked for spatial agreement, against controls, and nothing rises above chance.

❔ What would actually settle it is the code — find what reads a REGN object in the executable and watch which fields it dereferences. That is static PE work (/work/*.pe, offset = VA − 0x82000000) of the same kind that cracked the .slb packing phase, and it is the honest next step rather than a twenty-first correlation.

✅ 2026-08-26 — the reader found: REGN is a tetrahedral navigation mesh

The previous section closed with "find what reads a REGN object in the executable and watch which fields it dereferences". That worked, and it did not need the consumer: the deserialiser answers the question, because the file carries its own pointer map and the deserialiser tells you how to read it.

✅ The reader — sub_82465110 / sub_82465138 / sub_82465200

Three functions, all in the resource module around 0x82460000:

sub_82465110   find_pof0(chunk)
  82465110  lwz  r11, 4(r3)        ; datasize
  82465118  add  r11, r11, r3
  82465120  addi r3,  r11, 16      ; -> chunk + 16 + datasize
  82465124  lwz  r11, 0(r3)
  82465114  lis  r10, 0x504F  /  8246511c  ori r10, r10, 0x4630   ; 'POF0'
  82465128  cmplw cr6, r11, r10
  8246512c  beqlr cr6                                ; else return 0

sub_82465138   relocate_chunk_chain(chunk)
  82465164  lbz  r11, 8(r31)  /  clrlwi r11,r11,31   ; already-relocated bit
  82465178  bl   0x82465110                          ; find the POF0 chunk
  82465194  addi r4,  r11, 16                        ; POF0 payload
  82465198  lwz  r5,  4(r11)                         ; POF0 payload size
  8246519c  addi r3,  r31, 16      ; ← THE FIXUP BASE = chunk + 0x10
  824651a0  bl   0x82465200
  824651a8  ori  r11, r11, 0x1  /  stb r11, 8(r31)   ; set the bit

sub_82465200   apply_pof0(base=r3, table=r4, size=r5)
  82465224  clrrwi r8, r10, 6      ; top two bits of the lead byte select
  82465228  cmplwi cr6, r8, 0x40   ;   0x40 →  6-bit delta, 1 byte
  82465230  cmplwi cr6, r8, 0x80   ;   0x80 → 14-bit delta, 2 bytes
  82465238  cmplwi cr6, r8, 0xC0   ;   0xC0 → 22-bit delta, 3 bytes
  82465258  add    r11, r10, r11   ; running WORD index, never reset
  8246525c  slwi   r8,  r11, 2
  82465260  lwzx   r10, r8, r3     ; slot = base[word]
  82465264  cmplwi cr6, r10, 0x0
  8246526c  add    r10, r10, r3    ; *slot += base   (skipped when *slot == 0)
  82465270  stwx   r10, r8, r3

Two things follow, and both are load-bearing:

1. The fixup base is chunk + 0x10, not chunk + 0 (82465198: addi r3, r31, 16). Every stored "offset" in a REGN file is relative to file offset 0x10. Everything on this page above was read 16 bytes early. That single error is why twenty correlation tests returned chance.
2. The POF0 table is an exact list of which words are pointers. It is not a heuristic — it is the data the retail loader itself walks. Decoding it gives the pointer graph directly, with no guessing.

sub_82465138 is reached from exactly two callers, sub_82461018 (vtable slot 9 of the class at 0x820af8bc, the pak/resource file class) and sub_82461DE8; both store chunk + 16 as the object's data pointer, which confirms the same +0x10 base from the other side.

🔴 …and the magic is never compared

Worth recording because it is what sent the search to the fixup table: 'REGN' and 'MCOL' are not constructed anywhere in the executable. The title builds its four-character tags as lis/ori pairs, and a sweep of every such pair recovers 156 tags — RATC, T8aD, XBG7, IPFB, IDXD, LSTA, POF0, PRMD, TBMD, WMV3 … — but neither of these. Nor does either half appear as an immediate anywhere: 0x474E ('GN') occurs zero times in 1 865 751 instructions, and the flat PE image contains the byte string REGN zero times. So no magic-dispatch site exists to find; .rgn objects are handed to the map code by the stage record, not identified by their tag.

✅ The header is 0x70 bytes at chunk + 0x10, with six sections

Corrected, and re-derived from the POF0 table, which relocates exactly six header words (0x70, 0x74, 0x78, 0x7c, 0x80, 0x84) on 11 of 11:

chunk +0x00  char[4]  'REGN'
      +0x04  u32      data size          (POF0 chunk at +0x04-value + 0x10)
      +0x08  u8       flags; bit0 = "already relocated" (set by sub_82465138)
data = chunk + 0x10:
      +0x00  f32[4]   bbox min           (w = 1.0)
      +0x10  f32[4]   bbox max
      +0x20  f32[4]   extent
      +0x30  f32[4]   cell size
      +0x40  u32[4]   grid dims
      +0x50  u16[6]   record counts, one per section
      +0x60  ptr[6]   section pointers

The old page had four sections because it read the last two pointers as data. There are six, their strides are 12, 96, 48, 8, 32, 4, and each section's span divided by its stride is its counts[] entry exactly — 11 of 11, with the only slack being 16-byte alignment padding and, for the face list, two all-zero sentinel records (which is the unexplained "constant 96-byte tail" from the section above: 2 × 48).

#	contents	stride	count
0	vertices	12	counts[0]
1	tetrahedra	96	counts[1]
2	faces (plane + adjacency)	48	counts[2]
3	cell index, one per cell	8	counts[3] = cells
4	cell items, one per occupied cell	32	counts[4]
5	tetrahedron references	4	counts[5]

✅ How a cell reaches its geometry — the question, answered

The POF0 table places every pointer in the file, and there are only four kinds. Verified on all 11 objects by tools/re-capture/regn_decode.py verify:

• the six header words, and nothing else in the header;
• one pointer per occupied cell, at section-3 record offset +4 — so a cell is { u32 count; item* } and the count word is not a pointer;
• exactly one pointer per section-4 record, at offset +0x14 — the 32-byte cell item is { …, u32 n @+0x10, tetref* @+0x14, … };
• every word of section 5, all counts[5] of them.

So the chain is:

position ─▶ cell (x,y,z)  index = (z·dimY + y)·dimX + x
         ─▶ sec3[index]              {count, item*}
         ─▶ item                     {…, n @+0x10, refs* @+0x14, …}
         ─▶ refs[0 .. n)             each a pointer into section 1
         ─▶ tetrahedron

Four independent checks, all 11 of 11 objects:

• section-5 targets land on section-1 record boundaries — every one of 261 000 pointers is sec1 + 96·k with zero remainder;
• the reference arrays are packed contiguously in cell order — item[i].refs == sec5 + 4·Σ item[j<i].n, exact, and the total equals counts[5];
• counts[4] equals the number of relocated section-3 pointers equals the number of occupied cells;
• the cell ordering is x-fastest, then y, then z. A tetrahedron's bounding sphere reaches the box of a cell that lists it in 98.7 – 100 % of all 261 000 references; transposing the axes — the natural control — drops that to 18 – 28 %.

The list is a strict subset of "every cell the bounding sphere touches" (Jaccard ≈ 0.4 – 1.0), i.e. the build used a tighter test than sphere-vs-box. That is expected and is not claimed as decoded.

✅ Section 1 is a tetrahedron — 96 bytes

+0x00  f32[3]   bounding-sphere centre
+0x0c  f32      bounding-sphere radius
+0x10  u16[4]   vertex indices  → section 0
+0x18  u16[4]   face indices    → section 2
+0x20  6 × { f32 cost; f32 ❔ }   one pair per face pair, in the order
                                 (0,1) (0,2) (0,3) (1,2) (1,3) (2,3)
+0x50  u32      the record's own index
+0x54  u8[4]    flags, values 0/1

The check that makes this a decode, not a reading: each of a tetrahedron's four faces must pass through exactly three of its four vertices. Over 253 722 (tetrahedron, face) pairs on the disc, the count of vertices lying on the plane is 3 in 100.00 % of cases. The control — the same test with a randomly chosen face of the same object — gives 3 in 0.07 – 2.2 %, and touches no vertex at all 96 % of the time.

Two more, both 11 of 11: the bounding sphere encloses all four vertices in 100 % of the 63 410 records (with ~0.1 % padding), and the word at +0x50 is the record's own index in 100 %.

✅ The six floats at +0x20 are the portal-graph edge costs

For face i of a tetrahedron, let omit(i) be the one vertex not on it. Then

cost[k]  ==  | V[omit(i)] − V[omit(j)] | / 3      for the k-th pair (i<j)

which is exactly the distance between the centroids of faces i and j — the A* step cost of crossing the tetrahedron from one portal to another. It holds to 1e-4 relative in 380 460 of 380 460 values, all 11 objects.

❔ The second float of each pair is unread. It is a genuine varied float, zero in 8 – 26 % of slots. 🔴 Refuted: "zero marks a hull edge" — P(zero) is the same for edges on the hull as for interior ones (e.g. 2.9 % / 16.4 % against 16.7 % / 64.0 % — no lift at all). A clearance width is the obvious reading and is not established.

✅ Section 2 is a face — a plane plus the adjacency graph

+0x00  f32[3]   unit normal
+0x0c  f32      d
+0x10  f32[3]   a point on the plane
+0x1c  f32      1.0
+0x20  u16[3]   the face's three vertex indices → section 0
+0x26  u16      the face's own index
+0x28  u16[2]   the tetrahedra on either side; 0xFFFF = hull (no neighbour)
+0x2c  u16[2]   which of that tetrahedron's four face slots this is

The old page's plane reading was the same 16 bytes early, which is why it reported "four zeros" at the front: those were the previous record's four integer words, read as floats.

Verified over every face of every object (11 of 11, 100.00 % each):

• the word at +0x26 is the record's own index;
• for each non-0xFFFF side, tet[side].faces[slot[side]] == this face;
• the face's three vertices are a subset of that tetrahedron's four.

And the Euler relation closes: 4·T == 2·(F − B) + B exactly on every object (e.g. 4 × 1172 = 4688, F = 2584, B = 480 hull halves).

✅ What a REGN object is

A stage's MapPath is a tetrahedral navigation mesh of the whole play volume, plus a uniform grid for point location:

• vertices, tetrahedra, and faces form a conforming tet mesh with full face adjacency and hull markers;
• each tetrahedron carries the six face-to-face traversal costs, so A* over the portal graph needs no geometry at query time;
• the uniform grid answers "which tetrahedra could contain this point" in O(1), which is what a flight game needs to localise a ship into the mesh each frame.

The 100 km-cube smoke-test map (e993b93e, counts = [8, 6, 18, …]) is the textbook six-tetrahedron decomposition of a cube — 8 corners, 6 tets, 18 distinct faces (24 faces less the 6 shared internally) — which is as strong a confirmation of the reading as the statistics are.

🔴 Corrections to the sections above, kept rather than deleted

Every one of these was a real observation; each fails for the same single reason, and that is worth having on the page.

earlier claim	status
"four section offsets at 0x70"	🔴 there are six, 0x70–0x84
"the first section offset is always 0x80"	🔴 the value is 0x80; the section is at 0x90 — the base is +0x10
"counts[4] = occupied cells + 2, unexplained"	🔴 artefact of the base error; counts[4] = occupied cells exactly
"the constant 96-byte tail after the plane list"	✅ explained: two all-zero sentinel face records
"record +0x1c is a bounding-sphere radius (ratio 1.001 on one object, 0.13–0.27 on the rest)"	🟡 half right — +0x0c is a bounding-sphere radius, of the tetrahedron; the 1.001 was a coincidence of that map, where every tet shares the cube's circumsphere
"(count, offset) pairs point at leaf arrays of count × 4 bytes"	🟡 right mechanism, wrong record — it is the cell item at +0x10/+0x14 pointing into section 5, not the cell index
"slots 8–11 are integers (denormal as float)"	✅ correct, and they are the four vertex + four face u16 indices
"slot 7 is a local scale, ~14× smaller than the inter-node distance"	✅ correct as measured — it is a tetrahedron's bounding radius, which is exactly that small
"the BVH reading is refuted, no node sphere contains another"	✅ stands, and is now explained: these are sibling tetrahedra, not a tree
"the cell payload holds section-1 indices"	✅ stands — it holds a pointer to an array of pointers, and no index anywhere
"the static-correlation avenue is exhausted"	✅ stands for correlations; the file's own fixup table was never a correlation

❔ Still open

• the second float of each portal pair at tetrahedron +0x24, +0x2c, … ;
• the four flag bytes at tetrahedron +0x54 (values 0/1);
• the exact predicate the tools used to decide cell membership (tighter than sphere-vs-box);
• the runtime consumer. The deserialiser is found and proven; the code that queries the grid is not. Searches that came up empty, so they are not repeated: functions loading the header field groups off one base register (only stack frames match); vctsxs/vctuxs float→int conversion (16 functions, only one outside the XDK ranges); and the magic-comparison route, which cannot exist (above). The likely reason the field-offset search fails is that a float4-aligned header is read with VMX loads, which carry no useful displacement signature.

Tooling

tools/re-capture/regn_decode.py — standalone, stdlib only.

regn_decode.py list   hidden/MiscBin.pak
regn_decode.py dump   hidden/MiscBin.pak [name_hash]
regn_decode.py verify hidden/MiscBin.pak     # every check quoted above

verify prints, per object: the POF0 pointer-slot shape, the reference-array packing, the face/vertex incidence with its random control, the sphere/cell agreement with its transposed-axis control, and the portal-cost identity.