re: the last base-solver blocks -- two findings, and a correction to how I read the index

CORRECTION FIRST: a row in name-block-bases.txt is a (function, REGISTER) pair,
not a function.  Every one-line label I carried for these blocks quoted one of
two rows, and the other row of the same function is an unrelated schema:
sub_822E3EC8 r11 = 29 shader constants + techniques, r10 = 15 material map slots;
sub_822AFA50 r11 = XDK shader-compiler tokens, r10 = 13 menu camera tags;
sub_823AE908 r11 = the 43-name S16 boss collision table, r31 = 33 shader tokens
(the dense-block false positive).  Quote the register.

The engine's material vocabulary (into xbg7-mesh.md, which owns the
_col/_spc/_gls/_lum suffixes): nine base map slots -- ColorMap, LuminosityMap,
SpecularityMap, GlossinessMap, ReflectionMap, TransparencyMap, NormalMap,
FresnelMap, EdgeTransparencyMap -- and seven *MapArray twins; 9 - 7 = 2, and the
two without a twin are FresnelMap and EdgeTransparencyMap.  Four of the nine are
exactly the four documented suffixes; the other five have no suffix in the
shipped meshes, so the engine supports more channels than the assets use.  Plus
17 g_* shader constants, three cube samplers, and DepthOnly / MotionVector /
Transparent techniques -- the ...Last matrices with the motion-vector technique
say the renderer keeps the previous frame's per-object transform.

The S16 boss's collision parts (into collisionset.md): sub_823AE908 r11 is an
interleaved (mesh, logical-part) table -- rou_e901_body_02_c ->
Boss16CollisionBody02, five wing pairs, both tails, barrier, rou_e910_core_cmesh
-> Boss16CollisionCore, and mob_n900{,_b01,_b02,_gear}_cmesh -> Room00/01/02 +
Gear00/01/02.  23 logical parts + 20 meshes = 43, differing by exactly three:
Body01 opens with no mesh and the one gear mesh carries three gear names.  Cross-
links the S16 Guardian/Core object found during the PlayerParams work.

Not settled: whether those meshes are CollisionSet entries, why Body01 has no
mesh, and no shader slot was traced to a shipped shader.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PMRJjbxLqZtsb5Vb7KunPE

docs/re/structures/collisionset.md

@@ -157,3 +157,32 @@ exports any named mesh.
 record is exactly counts, positions and indices — so whatever distinguishes a
 hull hit from a shield hit is not stored here. And the library is not indexed:
 lookup is presumably by name from the unit tables, which has not been traced.
+
+## ✅ The Stage 16 boss's collision parts, named in the executable (2026-08-27)
+
+Found by the base-solver ([[player-tuning-tables]]): **`sub_823AE908`, `r11`,
+43 names**, and the list is an **interleaved (mesh, logical-part) table**:
+
+```
+rou_e901_body_02_c   → Boss16CollisionBody02      rou_e901_wing_0N_{L,R}_c → …Wing0N{L,R}
+rou_e901_tail_{L,R}_c→ Boss16CollisionTail{L,R}   rou_e901_barrier_cmesh   → …Barrier
+rou_e910_core_cmesh  → Boss16CollisionCore        mob_n900_cmesh           → …Room00
+mob_n900_b01_cmesh   → …Room01                    mob_n900_b02_cmesh       → …Room02
+mob_n900_gear_cmesh  → …Gear00 / …Gear01 / …Gear02
+```
+
+**23 logical parts + 20 meshes = 43**, and the two counts differ by exactly
+three: `Boss16CollisionBody01` opens the list with no mesh before it, and
+`mob_n900_gear_cmesh` is followed by **three** gear names. A second row
+(`sub_823C0260`, 15 names) lists the hull parts alone — `Body01…03`, `TailL/R`,
+`Wing01L…Wing05R` — with no meshes.
+
+🔑 **This is the same boss the `PlayerParams` work turned up**: the S16
+`Guardian` / `Core` object ([[player-tuning-tables]]) names its weapons
+`Shell_S16Boss_*`, and here `rou_e910_core_cmesh → Boss16CollisionCore` gives the
+`Core` record a collision hull. `rou_e901` is the boss craft; `mob_n900` is the
+station/room structure it sits in, whose three `Gear` parts share one mesh.
+
+🟡 Not settled: whether these meshes are entries of the `CollisionSet` library
+above (all 18 blobs are byte-identical, so a name-level join was not attempted),
+and why `Body01` has no mesh in the list.

docs/re/structures/player-tuning-tables.md

@@ -236,15 +236,22 @@ census that followed is in that document. The same base `0x8208583C` also serves
 `sub_82338EE0` (97 names, `Weapon TargetType SpecialWeaponType ReticleType
 IsCharging …`) — the **weapon** datasheet loader, likewise not previously named.
 
-**Other unowned blocks the index surfaces** (measured, not investigated):
-`sub_822215D0` (205/206, `PGHUD_*` / `PGREMAIN_NUM%d` / `PGTIMER_NUM%d` — HUD
-part names; [[mission-script-manifest]] mentions `PGHUD_SUBTARGET` only),
-`sub_822814D8` + `sub_8227A3A0` (`STAGE_RESULT`, `stage_num_shoot_down_aircrafts`,
-`EX_OVERVIEW` — results/leaderboard fields), `sub_822E3EC8`
-(`g_mWorldViewProjection`, `NormalMap`, `GlossinessMap` — engine shader/material
-slots), `sub_823C0260` + `sub_823AE908` (`Boss16CollisionBody01…`,
-`rou_e901_body_02_c` — the S16 boss collision parts, cross-linking the `Guardian`
-object above), and `sub_822AFA50` (`roh_n001_menu1_cam_pos` — menu camera tags).
+⚠️ **CORRECTION (2026-08-27) — a row is a (function, REGISTER) pair, not a
+function.** My one-line labels for those blocks each quoted **one of two** rows,
+and the other row of the same function is a different schema entirely:
+
+| function | one row | the other row |
+|---|---|---|
+| `sub_822E3EC8` | `r11` 29 — shader constants + techniques | `r10` 15 — the material **map slots** |
+| `sub_822AFA50` | `r11` 16 — XDK shader-compiler tokens (`__vspltw`, `__vsel`) | `r10` 13 — the **menu camera tags** |
+| `sub_823AE908` | `r11` 43 — the **S16 boss collision** table | `r31` 33 — shader tokens (the dense-block false positive) |
+
+**Read `docs/re/data/name-block-bases.txt` by row, and quote the register.**
+The three findings themselves are written up where they belong:
+[[xbg7-mesh]] (material slots + shader constants) and [[collisionset]] (the S16
+boss's 23 collision parts over 20 meshes). `sub_822AFA50`'s camera-tag row is
+13 `roh_n001_menu{1,2}_*_cam_{pos,tag}` names — the menu scene's camera
+positions and look-at tags, with `menu2` having sub-shots `2_0`–`2_4b`.
 
 🟡 None of those five were opened; the index says what each names, not what each
 means.

docs/re/structures/xbg7-mesh.md

@@ -1727,3 +1727,39 @@ resident but the unit never appeared).
 So the anchor line of work is **done for practical purposes**: every real mesh the
 engine draws in three captured missions decodes, at the offsets the GPU used, with
 index runs matching byte for byte (93/93 and 128/128).
+
+## ✅ The engine's material slots and shader constants (2026-08-27)
+
+This document names the **TX2D channel suffixes** — `_col` albedo, `_spc`
+specular, `_gls` gloss, `_lum` luminance. What it did not say is what the engine
+calls those slots. `sub_822E3EC8` reads two blocks (base-solver,
+[[player-tuning-tables]]):
+
+**`r10` — 15 material map slots.** Eight base maps, `LuminosityMap`,
+`SpecularityMap`, `GlossinessMap`, `ReflectionMap`, `TransparencyMap`,
+`NormalMap`, `FresnelMap`, `EdgeTransparencyMap`, plus **seven `*MapArray`
+twins** — `ColorMapArray`, `LuminosityMapArray`, `SpecularityMapArray`,
+`GlossinessMapArray`, `ReflectionMapArray`, `TransparencyMapArray`,
+`NormalMapArray`. ⚠️ `ColorMap` itself sits in the *other* block, so the base set
+is **nine**; **`FresnelMap` and `EdgeTransparencyMap` are the two with no array
+twin** (9 base − 7 arrays = 2, named in full).
+
+🔑 **Four of the nine slots are exactly the four suffixes above** — `ColorMap`
+(`_col`), `SpecularityMap` (`_spc`), `GlossinessMap` (`_gls`), `LuminosityMap`
+(`_lum`). The other five (`NormalMap`, `ReflectionMap`, `TransparencyMap`,
+`FresnelMap`, `EdgeTransparencyMap`) have **no suffix observed in the meshes this
+document decodes** — the engine supports more channels than the shipped assets
+use.
+
+**`r11` — 29 shader constants and techniques.** `g_mWorldViewProjection`,
+`g_mWorldViewProjectionLast`, `g_mObjectToView`, `g_mObjectToViewLast`,
+`g_mWorld`, `g_Params`, `g_UVParams`, `g_LayerParams`, `g_MapEnable`,
+`g_MapLayerEnable`, `g_vWorldEyePos`, `g_vLightDirection`, `g_LightColor`,
+`g_EffectLightPosition`, `g_EffectLightColor`, `g_fogEnable`, `g_fogParams`;
+cube samplers `DiffuseCube`, `SpecularCube`, `GlossCube`; and the techniques
+`DepthOnlyTechnique`, `MotionVectorTechnique`, `TransparentTechnique` (+ a
+"Normal technique found" / "Shadow map technique found" log pair).
+
+🔑 The `…Last` matrices and `MotionVectorTechnique` together say the renderer
+keeps the **previous frame's transform per object** — i.e. a motion-vector pass.
+🟡 None of this was traced to a shipped shader; it is the slot vocabulary only.