From 6ab2f0bc22b6cfeee21f0202929d7ea8c6a732da Mon Sep 17 00:00:00 2001 From: Valentin Popov Date: Sat, 18 Jul 2026 18:09:09 +0400 Subject: [PATCH] docs(terrain): trace shade cache population --- docs/tomes/05-render.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/docs/tomes/05-render.md b/docs/tomes/05-render.md index e9ebfe4..d831e6d 100644 --- a/docs/tomes/05-render.md +++ b/docs/tomes/05-render.md @@ -1611,8 +1611,17 @@ to zero. The profile-bank region starts at subobject `+332`: every one of the 100 banks has a 116-byte header followed by a 96-byte initialized stream, hence the recovered 212-byte stride. The byte selected from each table entry is therefore a bank index into a constructor-owned, fixed 100-bank region. This -proves the cache's allocation layout; it does **not** yet identify the code that -populates individual entry records from map resources. +proves the cache's allocation layout. Its population path is also now located. +`Terrain.dll` RVA `0x10280` resets the count, recreates the base entries from +the 28-byte stream at parent `+756`, and assigns bank zero. RVA `0x12e20` +copies one `0xd4`-byte profile header into bank `profile_count`, increments that +count, and remaps supplied keys to 28-byte records through the entry table. A +mapped record is stored as `profile_record_base + 28 * record_index` with the +new bank byte; a mapping whose second index is `-1` stores only the profile +ordinal, below `0x1000`, and is deliberately rejected by the lookup routine. +This explains the runtime sentinel without interpreting it as a missing WEAR +row. The input map is not yet tied to a named on-disk stream, so this proves the +cache builder's mechanics but not its complete asset-to-profile mapping. On success the method returns the shared result view at cache offset `+24`, not the stored-record pointer and not a WEAR row. Thus the dispatcher's observed