SLICE_STATE_2026-08-14.md

programs/SLICE_STATE_2026-08-14.md

The vertical slice, measured: Prologue → Chapter 13

Josh, 2026-08-14: *"We don't have a photorealistic world down to the grain of sand yet that I can

walk through the entire vertical slice with my character, fight through it, and complete all the

quests and beat all the bosses."*

He is right. This is the first time the whole slice has been measured against that sentence rather

than reported chapter by chapter. Every number below was read off the live registries, the live data

tables in the engine, or a gate run at HEAD — nothing here is carried forward from a summary.

The short version

The design is complete and verified for all thirteen chapters. The **beat data is already in the

engine for the whole game. What does not exist is the world to walk it in and the staging

that turns beats into placed encounters**. Neither is blocked; both are work orders with the tools

already built.

What is done, and verified at HEAD

layer	state	evidence
Quest reachability, Pro→Ch13	14/14 PASS	`harness/check_quest_reachability.py`, exit 0. 179 main beats, 61 forks, every fork resolves, no dead ends
Boss invariant, slice floor	PASS, 0 findings	`harness/check_boss_invariant.py`, exit 0
Boss design coverage	52 rows for the slice	`T0_Boss_Encounter_Registry`, 284 rows total; every slice chapter carries a primary boss id plus secondaries in `T0_Chapter_Index`
Beat data in the engine	909 rows, all 79 nodes	`DT_Beat` — CH_PR 16, CH_01–CH_77, CH_EP 8. Plus `DT_SideQuestBeat` 370 rows
Zone coordinates for every slice region	canon, populated	each region page's zone catalog carries real `zone_bounds_wgs84` per zone

One finding that is not a pass and should not be buried: the boss gate reports a knife edge.

Six of twelve mains are destructive-exempt, which is *exactly* the tooth's limit — it fails above

half. Any lane adding a seventh exemption must retire an existing one or argue the tooth. That is a

standing constraint on future boss authoring, not a defect today.

What is missing, in the order it blocks

1. Terrain — one region of twelve

Saved/Terrain holds four .r16 rasters and all four are flores_island. Bali.umap exists

with no heightmap behind it. So eleven of the twelve slice regions have no ground to walk on.

This is a work order, not a blocker, and every input exists:

The coordinates are canon. 61 zones across the ten missing real-world regions carry real WGS84

bounds — bali 7, sumatra_java 4, sri_lanka 7, south_india 7, swahili_coast 5, ethiopia 7,

rift_valley 6, central_africa_congo 3, west_africa 7, south_africa 8.

The pipeline is general. Tools/terrain_fetch_preprocess.py fetches COP30 for any bbox on

Earth, reprojects, void-fills, and emits absolute-metre-encoded heightmaps that stitch, plus

WorldCover weightmaps. OPENTOPOGRAPHY_API_KEY is set.

The composer is the pattern. Tools/compose_flores_island.py composites real DEM patches into

one continuous playable island, placing zones by the chapter's spine route order rather than by

geodesy.

The only real constraint is the API budget: 50 live calls per rolling 24 h, enforced by the

tool's own guard. 61 zones does not fit in one day. Ch 4–11 are in flight now (46 patches); Ch 12

West Africa and Ch 13 South Africa are deferred on budget alone.

Ch 1's Fairy Realm is not a terrain job — canon rules it designed last, on the matured pipeline

(Realm Design Program).

2. Staging — the beats exist, the encounters do not

The engine has every beat as data and almost none of it placed. Measured on FloresIsland's render

state: 1 encounter volume, 1 boss character, 1 site marker. Tool-side, only CH02, CH03 and CH04

have staged beat work at all.

So "fight through it and beat all the bosses" is a staging job over 176 slice beats and 52 boss

rows, and it is gated on §1 — an encounter needs ground to stand on.

3. The ground itself is not photoreal, and the reason is now measured

Three independent auditors converged on it: the near-field ground was a geometrically flat plane

because both routes to relief were closed at once. That has changed today:

The landscape is now Nanite — enable_nanite TRUE, nanite_components 0 → 3,

used_with_nanite TRUE, saved to disk. Three is the *complete* count:

NumNaniteRequiredComponents() = DivideAndRoundUp(140, 64) = 3 (LandscapeProxy.h:1089-1091).

The displacement pin is open — MP_Displacement is UMETA(Hidden) so Python cannot name it;

C++ can, and now does (UHumanityMaterialEditorLibrary, 5/5 self-test).

r.Nanite.Tessellation already defaults to 1 in this engine (NaniteCullRaster.cpp:93).

And the honest limit on the source, from the terrain meta's own field: *"COP30's native ground sample

is ~30 m; this tile is authored at 3.9 m/post, so the DEM is upsampled ~7.7×. The 31 m-scale landform

is real measurement; sub-30 m detail is cubic interpolation, not survey."* **No resampling of a 30 m

DEM will ever produce millimetre relief.** It has to come from material displacement and scattered

scanned geometry — which is exactly what is in flight.

Note also that the zone catalog carries a canon meters_per_vertex column, and it is finer than what

ships: on Flores the hero sites read 1 m, the recharge waterfall 2, the cone country 5, while the

built world serves 3.9 m everywhere. The build is below its own ratified rung.

The order of work this implies

1. Ground displacement to real millimetre relief on Flores *(in flight)*.

2. Terrain for Ch 4–11 *(in flight)*, then Ch 12–13 on tomorrow's API budget.

3. Import and dress each composed region.

4. Stage the 176 slice beats and 52 bosses as placed encounters.

5. Play it end to end and fix what only playing finds.

Generated by harness/site/structure_site.py — the URL path is the repo path. review root