GEODATA_TERRAIN_CHAIN.md

pipelines/GEODATA_TERRAIN_CHAIN.md

The Geodata to Game Terrain Chain

Technical research brief. Scope: how a pipeline can programmatically take real-Earth

terrain/imagery for the 69 real-world regions and land it in Unreal Engine (5.x line) as

alterable, populated, playable terrain.

Method: every claim below was checked against official docs, vendor sites, or the

project's own GitHub repos during this research pass (mid-July 2026), not recalled from

training data. Each claim is tagged:

• VERIFIED — confirmed against an official/primary source this session (cited).
• INFERRED — a synthesis or recommendation this brief is making by combining several

verified facts; not itself a documented single fact. Flagged so it can be challenged.

• UNVERIFIED / FLAG — something this pass could not confirm and that should not be

assumed true before a pipeline decision is built on it.

Training cutoff for the assistant that wrote this is January 2026; the current UE5 line

has moved since then (5.8 shipped this same month, per below), so version numbers here

are the live-web numbers, not memory.

---

1. Cesium for Unreal

What it is (VERIFIED). Cesium for Unreal is Epic/CesiumGS's plugin for streaming 3D

Tiles — terrain (quantized-mesh), photogrammetry, point clouds, 3D Gaussian Splats (added

to the 3D Tiles ecosystem 27 Apr 2026), and OSM/photorealistic buildings — into UE at

runtime with automatic LOD. Current version is Cesium for Unreal 2.28.0 (July 2026

release), supporting UE 5.8; this is stated to be the last release supporting UE 5.5,

future versions require 5.6+.

Cesium Releases in July 2026,

cesium-unreal releases,

Cesium for Unreal product page

Georeferencing (VERIFIED). A CesiumGeoreference actor anchors a WGS84 lat/lon/height

at the Unreal origin (0,0,0). For a multi-region game, georeferenced sub-levels let

each region define its own "central location" — when that sub-level is active its origin

becomes (0,0,0) in Unreal, so per-region coordinates stay small and gravity/physics behave

normally; this is Cesium's built-in analogue of Unreal's origin-rebasing for Large World

Coordinates. This maps directly onto "one sub-level per region page."

Building Global Scenes with Georeferenced Sublevels,

ACesiumGeoreference reference

Data sources (VERIFIED). Cesium ion is not required. A tileset's "Source" can be

set to "From URL" and pointed at a local directory, your own server, or any 3D-Tiles/TMS

-compliant endpoint instead of ion. Ion itself offers curated global content (Cesium World

Terrain, Bing/Google Photorealistic 3D Tiles, Cesium OSM Buildings) plus your own uploaded

assets.

Adding Datasets

You can upload your own (already-altered) GeoTIFF DEM to Cesium ion and have it tiled

into quantized-mesh 3D Tiles terrain: ion's "Raster Terrain" asset type accepts a

single-band float/int elevation GeoTIFF, reprojects to EPSG:4326, and you specify height

unit/reference (MSL vs ellipsoid). So "alter, then feed to Cesium" is a real, supported

path — for the ion-hosted, runtime-streamed route.

Terrain tiling docs

Licensing (VERIFIED). Cesium ion tiers:

Paid tiers explicitly permit commercial games, but redistributing ion integration in

"solutions used outside your organization" requires contacting sales.

Cesium ion pricing

Cesium ion Self-Hosted (VERIFIED) is a Kubernetes-based, on-prem/edge deployment of the

same codebase, aimed at data-sovereignty/air-gapped enterprise needs (e.g., Ansys). It is

still a runtime tile-streaming architecture — not a "bake once, own forever" product —

and is almost certainly overkill for a solo project.

How Cesium ion Self-Hosted Works,

Cesium ion Self-Hosted product page

**Can streamed tiles be baked into editable static terrain? (VERIFIED, and the answer is

weak-no for our purposes.)** Community reports confirm you can save loaded Cesium tiles as

a static mesh, but materials/textures do not transfer in that conversion. Cesium World

Terrain and other ion tilesets are explicitly not available offline, and Cesium

describes itself as still "evaluating the best way to enable offline access" to that

content. A Geometry-Script/Blueprint tutorial exists for clipping sections out of a stream

with a Cartographic Polygon actor, but that is a workaround, not a supported "convert to a

paintable Landscape" pipeline.

Cesium Unreal FAQ,

"Part of the world as static mesh",

"Convert 3D tiles in Static Mesh"

Synthesis (INFERRED). Cesium for Unreal is built and priced for **live, streamed,

globe-scale visualization** (GIS viewers, digital twins, flight sims) — not for producing

the hand-alterable, paintable, foliage-populated Landscape/Mesh-Terrain tiles this project

needs as durable, owned game assets. Its correct role in this pipeline, if any, is a

reference/preview layer (e.g., a flyover/loading-screen globe, or distant unplayable

background beyond a region's edge) — not the authoring path for the 69 playable regions.

The authoring path is the DEM → GDAL/rasterio → heightmap → Landscape chain in sections 2–4

below, which needs no Cesium ion account, subscription, or attribution at all.

---

2. DEM download contracts

USGS 3DEP is US-only (VERIFIED) — not usable for the 69 world regions. All 3DEP

products are public domain, free, with no use restriction, at 1 arc-second (~30 m), 1/3

arc-second (~10 m), and down to 1 m where lidar exists — but coverage is the United States

and territories. None of the example regions (Indonesia, the Sahel, the Andes, Mongolia,

the Baltic) are in the US, so 3DEP only matters if a future region page happens to land

inside the US.

About 3DEP Products & Services,

API access to USGS 3DEP rasters via OpenTopography

Global 30 m sources actually usable for all 69 regions (VERIFIED):

• Copernicus GLO-30 (derived from the TanDEM-X mission; DLR/Airbus/ESA/EU). Global,

free, worldwide, **explicitly for both commercial and non-commercial use, without time

limit. Requires an attribution notice always, and — because this pipeline alters**

the DEM — an additional notice on modified data ("produced using Copernicus

WorldDEM-30 © DLR e.V. ...") plus a liability disclaimer if redistributed. Generally the

best-quality modern global 30 m source (newer radar-interferometry data than SRTM).

Copernicus DEM license,

Copernicus DEM on AWS Open Data

• NASADEM — a 2020s reprocessing of SRTM with better void-filling (auxiliary fill from

ASTER GDEM, ALOS PRISM, USGS NED, Canada/Alaska DEMs), same ~1 arc-second/30 m

resolution, openly available, no restrictive license found. Effectively "SRTM, but

already void-filled" — use this instead of raw SRTM.

USGS EROS SRTM Void Filled,

OpenTopography NASADEM

• ALOS World 3D-30m (AW3D30) — JAXA. Free for commercial and non-commercial use;

requires attribution to JAXA on publication; JAXA disclaims all warranty/liability.

Current product version found this pass: v4.1.

JAXA AW3D30 terms of use,

AW3D30 dataset page

• SRTM (raw) — near-global 60°N–56°S, 1 arc-second (~30 m), open per NASA EOSDIS

policy, but contains voids in steep terrain/water that NASADEM already fixes — no

reason to use raw SRTM over NASADEM for this pipeline.

Practical bounding-box → GeoTIFF workflow (VERIFIED). OpenTopography's Global DEM API

is a single REST call across all of the above datasets:

https://portal.opentopography.org/API/globaldem?demtype=COP30&south=<lat>&north=<lat>&west=<lon>&east=<lon>&outputFormat=GTiff&API_Key=<key>

Valid demtype values include SRTMGL3, SRTMGL1, SRTMGL1_E, AW3D30, AW3D30_E,

SRTM15Plus, NASADEM, COP30, COP90, EU_DTM, GEDI_L3. API keys are free, issued

instantly at signup. Enterprise/high-volume commercial API use is a separate arrangement

(email OpenTopography). Copernicus and USGS data are also mirrored as bulk Cloud-Optimized

GeoTIFFs on the AWS Open Data program if a per-call API isn't wanted for a batch job over

69 regions.

OpenTopography Global DEM API example,

OpenTopography for Developers,

Updated Copernicus 30m DEM available

Recommendation (INFERRED). Copernicus GLO-30 as primary (best modern quality + the

cleanest explicit worldwide commercial license); NASADEM as fallback/cross-check where

Copernicus has a gap or artifact; AW3D30 as a second independent cross-check/blend source

for any region where the two disagree oddly. Skip 3DEP entirely unless a specific region

page's bounding box happens to fall inside the US.

---

3. GeoTIFF/DEM to UE Landscape

UE Landscape height encoding (VERIFIED). Heightmap values are 16-bit (0–65535,

mapping to a signed range of roughly ±256 before scaling). The working conversion found in

Epic's own forum guidance: `Z Scale = (max height of heightmap in meters) × 100 (m→cm) ×

0.001953125 (=1/512)`. At the landscape's default Z-scale of 100, the vertical range is

±256 m. For a region whose real terrain spans, say, -50 m to 2,800 m, the Z-scale must be

set to cover that (plus headroom for anything the alteration step adds — new peaks,

raised fantasy sites).

Importing/Exporting Landscape Heightmaps,

UE forum: heightmap Z-scale math

Formats (VERIFIED). 16-bit grayscale PNG (65,536 levels) or RAW16 with a companion

JSON describing width/height/bit-depth. gdal_translate -ot UInt16 converts a GeoTIFF DEM

into this form directly; QGIS's "Heightmap Export" plugin does GeoTIFF → 16-bit PNG in one

step at a chosen resolution.

unrealheightmap generator,

QGIS Heightmap Export plugin

Size/tiling constraints (VERIFIED, official Landscape Technical Guide). A section's

vertex dimension must be a power of two (max 256×256); quads-per-component follow 2ⁿ−1

(single section: 63/127/255) or 2ⁿ−2 (2×2 sections: 126/254). Epic's own recommended

ceiling is 1,024 Landscape Components per actor, giving the commonly-cited maximum single

Landscape actor of 8,129×8,129 vertices (127 quads/section × 2×2 sections × 32×32

components). Separately, the raw heightmap import file ceiling is much larger — up to

43,351×43,351 px — specifically so a large real-world region can be sliced into

multiple 8,129-capped Landscape actors/streaming proxies.

Landscape Technical Guide,

UE forum: landscape larger than 8129×8129

World Partition (VERIFIED). Automatic grid-based streaming (One File Per Actor + Data

Layers) that tiles a world into cells loaded/unloaded by distance from the player,

combined with Large World Coordinates (64-bit world-space floats) to remove the old

practical size ceiling. Real-world reports: 32 km × 32 km (1,024 km²) with foliage

before things get heavy. Guidance found: past ~64 km² it's worth asking whether sub-meter

heightmap resolution is needed everywhere, rather than applying it uniformly.

UE5 World Partition forum thread,

World Partition docs

The real resolution mismatch (VERIFIED problem, INFERRED handling). Source DEMs are

30 m/pixel. Most UE Landscape tutorials assume roughly 1 m (or finer) per vertex.

Mapping a 30 m DEM 1:1 onto vertices either (a) makes each vertex represent 30 real

meters — fine, and arguably correct, if that IS the intended scale for a compressed region

(ties to §7) — or (b) gets resampled/interpolated to a finer grid, which does not

manufacture real detail, it just smooths/upscales, producing visible terracing/over-smooth

slopes. This is a documented limitation, not a guess: the GeotiffLandscape plugin's own

docs call it out directly (SRTM's 30 m/px vs UE4's common 1 px/m convention "requires

upscaling that introduces artifacts"). This is precisely the gap erosion synthesis (§6) or

hand sculpting is meant to close, not something the resample step alone can fix.

GeotiffLandscape plugin

Forward-looking flag (VERIFIED feature, UNVERIFIED maturity). UE 5.8 (this same

July 2026 release) ships an experimental Mesh Terrain system: true XYZ-mesh terrain

(not a heightfield), so it can represent overhangs/caves/arches, supports variable

resolution across one terrain, uses a non-destructive modifier stack, can import either a

mesh or a heightmap, and is fully integrated with PCG and World Partition/OFPA. Epic frames

it as the intended long-term replacement for heightfield Landscape, with both systems

coexisting "for some time." Because it is brand-new and experimental in this exact

release, classic heightfield Landscape (everything cited above) is the proven, documented

near-term import target; Mesh Terrain is worth tracking but not building the pipeline

around yet.

Mesh Terrain in Unreal Engine docs,

StraySpark: Mesh Terrain in UE 5.8

Scripted import — closing the automation loop (VERIFIED). Epic's Python API exposes,

on unreal.LandscapeProxy, stable (present in the 4.26 through 5.5 docs, i.e., a mature,

long-lived API very likely intact in 5.8):

landscape_import_heightmap_from_render_target() / landscape_export_heightmap_to_render_target()

for height, and the equivalent landscape_import_weightmap_from_render_target() /

landscape_export_weightmap_to_render_target() for paint layers, with paint_layer (a

LandscapeLayerInfoObject) and edit_layer_name parameters. This means the **final

"land it in Unreal" step can run headlessly**, inside the Editor's Python environment,

driven by the same pipeline that ran GDAL beforehand — not a manual drag-and-drop.

unreal.LandscapeProxy Python API (5.5)

Direct GeoTIFF import plugin (VERIFIED, but stale). The community GeotiffLandscape

plugin (github.com/iwer/GeotiffLandscape) imports a GeoTIFF DEM straight into a Landscape

heightmap+weightmap, skipping the PNG/RAW conversion step — but its UE5 branch is only

verified up to UE 5.1, so treat it as a reference implementation of the conversion

math rather than a dependency to build the 5.8 pipeline on. The GDAL/QGIS →16-bit

PNG/RAW → Editor-Python-import path above is the version-proof route.

---

4. Alteration workflows — which leg does what

Two real, complementary mechanisms exist; they are not substitutes for each other.

Leg A — pre-import raster editing (GDAL/rasterio/Python) (VERIFIED mechanism). Best

for anything that must run unattended across all 69 regions: mosaicking DEM tiles that

cross a region's bounding box (gdalwarp/gdal_merge), reprojecting, clipping to the

exact AOI, resampling to the chosen meters-per-vertex, and — the actual "carve a fantasy

site into real terrain" operation — burning a vector footprint (the zone catalog's site

polygon) into the elevation raster via rasterio.features.rasterize plus a numpy

blend/feather at the boundary to avoid a visible seam, then gdal_translate -ot UInt16

for the final format. This leg is deterministic, diffable, and re-runnable — the natural

home for anything the pipeline must do identically and unattended for all 69 regions.

**Leg B — in-engine sculpting (Landscape Edit Layers / Patches / Splines, or Mesh Terrain

modifiers) (VERIFIED mechanism).** Edit Layers are a stack of independent,

non-destructive height/paint containers — a hand-tweak lives in its own layer on top of

the imported real-world base layer and can be hidden/reordered/reverted without touching

the base data. Specialized procedural layers exist for Splines (roads/rivers) and Patches.

Sculpt Mode always writes to the currently-active edit layer, so nothing is destroyed.

This is the right place for a designer's one-off, reversible, "I'm looking at the result

and want to touch this ridge" pass — and it's *also* scriptable, via the same

landscape_import_heightmap_from_render_target(..., edit_layer_name=...) call, targeted

at a specific layer instead of the base.

Landscape Edit Layers docs,

Landscape Sculpt Mode docs

Division of labor (INFERRED, grounded in the two verified mechanisms above). Run every

alteration that must apply identically and unattended across all 69 regions — mosaicking,

site-carving from the zone catalog's bounding boxes, resampling to the scale-compression

target, erosion-detail synthesis (§6) — in Leg A, before anything touches Unreal, because

it is the only leg that is fully batchable without opening the Editor. Reserve Leg B for

the smaller set of hand-finishing passes a designer explicitly wants to keep editable and

reversible after the fact (a ridge that reads wrong at ground level, a spline river that

needs a human eye). Both legs are real and both are scriptable, but they are not

interchangeable: raster edits are the bulk leg, edit layers are the human-iteration leg.

---

5. Satellite imagery / landcover for materials and PCG biomes

ESA WorldCover (VERIFIED). Global 10 m landcover, 11 classes: tree cover, shrubland,

grassland, cropland, built-up, bare/sparse vegetation, snow/ice, permanent water,

herbaceous wetland, mangrove, moss/lichen (LCCS taxonomy, UN FAO). Delivered as

Cloud-Optimized GeoTIFFs in 3°×3° tiles. Downloadable by drawing an AOI in the WorldCover

viewer, programmatically via the terracatalogueclient Python package, or directly off

the public AWS bucket (s3://esa-worldcover-s2, eu-central-1) for the underlying

Sentinel-2 composites.

WorldCover data access,

ESA-WorldCover datasets repo

Sentinel-2 (VERIFIED). True-color/multispectral imagery via the Copernicus Data Space

Ecosystem (STAC/OpenSearch/OData/Sentinel Hub APIs — free, open, token-authenticated);

also mirrored on AWS Open Data. True color = bands B04/B03/B02 (L2A). Coverage: L1C

globally since June 2015, L2A globally since Jan 2017 (Europe from Nov 2016).

Copernicus Data Space Ecosystem APIs,

Sentinel-2 on AWS Open Data

**Landcover class → UE material layer → PCG spawn chain (INFERRED pipeline, built from

verified parts).** Reclassify WorldCover's 11 classes into the project's own material-layer

taxonomy (e.g., collapse into forest / grass / crop / bare-rock / snow / water / wetland /

urban), rasterize each target class into its own 0–255 weightmap on the *same* pixel grid

as the region's heightmap (same AOI, same resample step as §3), then import each weightmap

into the matching Landscape paint layer with the verified

landscape_import_weightmap_from_render_target() Python call from §3. From there, **PCG

Biome Core — confirmed to be an official Epic plugin bundled with the engine** (not a

marketplace asset), with its current form dating to the UE 5.6 release and backward

-compatible into 5.8 — explicitly supports "using landscape layer weights painting" as one

of its generator subtypes to control what spawns where. So "landcover class drives PCG

biome spawning" is a documented, real mechanism, not a hypothetical — though the exact

node-level wiring (which sampling/filter nodes read which layer) needs a hands-on pass

inside the Biome Core sample graphs rather than doc-reading; flagged below.

PCG Biome Core overview guide,

PCG Biome Core reference guide

Sentinel-2 true-color pixels themselves (as distinct from the WorldCover classification)

can additionally feed the Landscape's base albedo/diffuse texture — a "satellite drape"

under the material-layer blend — using the same reprojection-to-grid treatment as the

landcover weightmaps; no extra API beyond what's already documented above.

---

6. Where Gaea fits

Current state (VERIFIED, with one timing flag). Gaea 2.3 shipped (CG Channel, June

2026): Macros (package a graph into a reusable node with exposed parameters), improved

Regions/large-scale-world support, erosion/simulation refinements. Gaea 3.0 was

unveiled in Dec 2025 and reported as expected "mid-2026," bringing a new Thermal

Erosion model, native USD import/export (preserving heightmaps/masks/attributes for

pipeline interchange), and a physically-based meandering Rivers system.

UNVERIFIED/FLAG: this pass could not confirm whether Gaea 3.0 has actually shipped yet

versus still being "in development" — treat "3.0 announced" as solid, "3.0 shipped" as

unconfirmed.

QuadSpinner unveils Gaea 3.0,

QuadSpinner releases Gaea 2.3,

Gaea 3.0 — Now in Development

Licensing (VERIFIED). Perpetual, no subscription, free minor updates. Tiers gate by

company revenue, not just features: Community (free, non-commercial, 1K export cap),

Indie $99 (<$100K revenue, 8,192×8,192 single-build cap), Professional $199 (<$1M

revenue, 16,384×16,384 single / 262,144×262,144 tiled), Enterprise $299 (>$1M revenue,

same resolution ceiling as Pro). A solo dev under $100K revenue qualifies for Indie at a

one-time $99. Worth noting: Indie's 8,192 cap lines up almost exactly with UE Landscape's

~8,129-vertex single-actor ceiling from §3 — a convenient coincidence for single-tile

regions.

Gaea edition comparison

Automation (VERIFIED existence, UNVERIFIED tier-gating). Gaea advertises CLI

automation ("arguments, variables, and direct file manipulation... easy to integrate

Gaea's build engine into any production pipeline") and an official .tor-file automation

repo (QuadSpinner/Gaea.Automation on GitHub, explicitly marked work-in-progress) for

headless graph builds and bridges to third-party tools like Houdini. **FLAG: one general

search result claimed "Professional or Enterprise edition is required" for automation

features, but the official edition-comparison page (fetched directly this pass) does not

mention CLI/automation anywhere in its tier table** — so that claim is unconfirmed either

way. Do not assume the $99 Indie tier is sufficient for a headless CI pipeline without

confirming directly with QuadSpinner before committing to it.

Building a Bridge with the CLI,

Gaea.Automation repo

Gaea's actual value-add in this specific chain (VERIFIED capability, INFERRED framing).

Gaea explicitly supports importing real-world heightmaps (an OpenTopography/SRTM source

picker appears directly in its import flow, per a cited walkthrough) specifically so its

erosion/thermal/snow simulation graph can run physically-scaled ("Real Scale") erosion on

top of a coarse real DEM. That means Gaea's role here is not terrain download

(OpenTopography/GDAL already own that, §2) and not the final Unreal import (§3 owns

that) — it is the middle synthesis step: turning a smoothed/blocky 30 m-source

heightmap into one with physically-plausible erosion micro-detail, sediment deposition,

and meandering rivers that a raw 30 m DEM structurally cannot contain, before the

heightmap goes to UE. This is exactly the artifact-quality gap identified in §3.

Terrain Scale docs

**If dropped for an NVIDIA world-gen tool (UNVERIFIED — flag this as a premise check, not

just a comparison).** This research pass found NVIDIA's 2026 public terrain-adjacent work

to be GDC-era rendering/geometry technology — RTX Mega Geometry (GPU geometry clustering

for path-traced foliage/detail) and neural rendering (ReSTIR PT) — which is **rendering

technology, not a terrain-authoring replacement for Gaea**. No shipped, licensable

"NVIDIA world-gen terrain tool" equivalent to Gaea (erosion authoring, .tor graphs, DEM

import) was found. The wider industry trend is GPU-accelerated erosion (several vendors,

not NVIDIA-exclusive) and academic diffusion-model terrain generation (e.g., a

"terrain-diffusion" SIGGRAPH '26 research repo) — neither is a drop-in production

replacement today. **This should go back to Josh as a named-product question rather than

be assumed**: if a specific NVIDIA tool is intended, naming it would let this research

target it directly; as stated, "an NVIDIA world-gen tool" does not appear to refer to a

real, shippable product yet. What would be lost if Gaea were dropped with nothing

named to replace it: the mature hand-tunable erosion/river node library, the reusable

.tor macro format, and Gaea's file-based determinism (same input + same graph = same

output every time, which matters for a canon-driven pipeline that must reproduce identical

terrain from the same region-page inputs on every rebuild) — a neural/generative

replacement would likely trade that determinism away unless explicitly seeded/pinned.

NVIDIA RTX Innovations blog,

terrain-diffusion (SIGGRAPH '26) repo

---

7. Real-world scale strategy

Precedent (VERIFIED). Microsoft Flight Simulator targets literal 1:1 global scale

(real elevation + imagery + procedural generation), but even there, "no player travels

that far without technical tricks" — floating-point precision, streaming, and performance

limits bite at 1:1 before any content problem does. Ubisoft's *The Crew* compresses the

entire continental US into a ~5,000–7,000 km² drivable space — a heavily compressed but

internally-consistent relative-geography approach. General industry rationale (verified

across multiple sources): compression trades literal scale for playability, production

cost (every meter of world needs art/QA), fun-density (compress landmarks so more player

time is spent on meaningful content, less on empty traversal), and controlled design (1:1

scale reproduces real-world dead space/travel-time problems that don't serve a directed

RPG).

Editorialge on largest open-world maps

**Tie to the DEM resample step (INFERRED, this is the load-bearing synthesis of this

section).** Scale compression is not a separate art pass bolted on later — it is decided

at the exact moment the DEM is resampled in §3/§4 Leg A. The ratio between a region's real

bounding box (from the region page's zone-catalog area bounds, in real km²) and the target

in-engine Landscape footprint (one 8,129-vertex tile, or an N-tile World-Partition grid)

determines the meters-per-vertex the gdalwarp -tr <x_res> <y_res> resample call must

target. In other words: **scale-compression policy is a pipeline parameter — one number

(or one formula) applied per region — not a per-region manual redesign.** Once a

meters-per-vertex target is chosen, every other step in this chain (Z-scale math, tile

count, World Partition cell count, erosion detail budget) falls out of that one number.

Residual open question — flag for Josh, not resolved here. What compression ratio (or

target playable km² per region, equivalently meters-per-vertex) the 69 regions should use

is a design decision this technical pass cannot make: it depends on traversal pacing,

mount/vehicle speeds, and the zone-catalog's own area-bounds field — none of which were in

scope here. Per the standing decision-analysis protocol, this is exactly the kind of fork

that needs the fan-out-alternatives + deep-dive + adversarial-review treatment against CVD

• RCM + traversal design before being set as a pipeline-wide constant, not a bare number

picked in a technical brief.

---

THE WORLD CHAIN, STEP BY STEP

Input to the whole chain: a region page's zone catalog (zone name, terrain type, gameplay

function, area bounds, ambient threat, vril density, climactic affordances), which

supplies the bounding box every step below operates on.

Step 1 — DOWNLOAD

• Artifact in: region page zone-catalog area bounds (lat/lon bounding box).
• Mechanism: scripted HTTPS REST calls, one set per region.
• Elevation: OpenTopography Global DEM API —

GET https://portal.opentopography.org/API/globaldem?demtype=COP30&south=..&north=..&west=..&east=..&outputFormat=GTiff&API_Key=..

(primary: COP30; fallback/cross-check: NASADEM, AW3D30).

• Landcover: ESA WorldCover 10 m via terracatalogueclient or the public AWS bucket.
• Imagery: Sentinel-2 L2A true color via the Copernicus Data Space Ecosystem API.
• Artifact out: raw GeoTIFF DEM (float, EPSG:4326), raw GeoTIFF landcover

classification, raw Sentinel-2 GeoTIFF/JP2 tiles — all per-region, all still in native

projection/resolution.

• License note: Copernicus/AW3D30/WorldCover/Sentinel-2 are all free for commercial

use worldwide; Copernicus and AW3D30 require attribution notices carried forward,

Copernicus specifically requires an additional notice once the data is modified (which

this pipeline always does in Step 3).

Step 2 — PREPROCESS

• Mechanism: GDAL/rasterio Python scripts, fully deterministic and batchable across

all 69 regions.

• Reproject to a consistent regional projection (a local UTM or equidistant projection,

so meters-per-pixel is uniform across the AOI) — gdalwarp.

• Mosaic/merge any DEM tiles crossing the AOI boundary — gdalwarp/gdal_merge.
• Clip to the exact bounding box.
• Resample to the chosen meters-per-vertex (the §7 scale-compression parameter) —

gdalwarp -tr <x> <y>.

• Reclassify WorldCover's 11 classes into the project's material-layer taxonomy and

rasterize one 0–255 weightmap per target class, aligned to the same grid as the

elevation raster.

• Artifact out: one analysis-ready elevation GeoTIFF, N landcover weightmap GeoTIFFs,

one color/imagery GeoTIFF — all pixel-aligned on the same grid, same projection, same

resolution.

Step 3 — ALTER

• Bulk/deterministic leg (before Unreal):
• Burn zone-catalog site footprints into the elevation raster —

rasterio.features.rasterize + numpy blend/feather at the boundary (carve fantasy

sites into real terrain).

• Optionally route the resampled DEM through Gaea's erosion graph (CLI/.tor

automation, license tier TBD — see §6 flag) to synthesize physically-plausible

micro-detail, sediment, and rivers the 30 m source cannot contain; export back to a

16-bit raster.

• Hand/reversible leg (after Unreal import): Landscape Edit Layers / Patches /

Splines (or, later, Mesh Terrain modifiers) for designer touch-ups, stacked

non-destructively on the imported real-world base layer; scriptable via

landscape_import_heightmap_from_render_target(..., edit_layer_name=...) if a specific

layer needs to be pipeline-driven rather than hand-painted.

• Artifact out: an altered elevation GeoTIFF (bulk leg), later an in-engine Edit Layer

stack (hand leg).

Step 4 — IMPORT

• Mechanism:
• Format conversion: gdal_translate -ot UInt16 (or QGIS Heightmap Export) → 16-bit

grayscale PNG or RAW16+JSON, computing Z-scale from the region's real min/max

elevation (plus headroom for anything Step 3 added).

• Tiling: respect the 8,129-vertex single-Landscape-actor ceiling; regions bigger than

that get sliced into a multi-proxy Landscape fed by World Partition's distance

streaming.

• Landing it: either the manual Landscape import dialog (heightmap + per-layer

weightmaps), or — for full pipeline automation — headless UE Editor Python:

unreal.LandscapeProxy.landscape_import_heightmap_from_render_target() for height,

landscape_import_weightmap_from_render_target() per landcover paint layer.

• Artifact out: a native UE Landscape (World-Partition-streamed, tiled as needed) with

paint layers matching the landcover taxonomy from Step 2.

• Forward flag: UE 5.8's new Mesh Terrain system is a plausible future import target

(handles overhangs/caves, variable resolution) but is experimental this release; not

recommended as the near-term target format.

Step 5 — POPULATE

• Mechanism: PCG Biome Core (official, engine-bundled) graphs sample the Landscape's

paint-layer weights (the landcover-derived layers from Steps 2/4) to decide what spawns

where — a forest-biome graph keyed to the "tree cover" layer, scrub/grass graphs keyed

to "grassland/shrubland," etc. Region-specific gameplay affordances from the zone

catalog (gameplay function, ambient threat, vril density, climactic affordances) should

drive which PCG graph runs, and how it's parameterized, per zone — not landcover

alone — via Bounds/Volume actors keyed to the zone catalog's own zone polygons.

• Artifact out: a populated, playable Landscape/Mesh-Terrain with foliage, props, and

encounter/ambient-threat volumes matching the zone catalog.

• Flag: the landcover→layer→PCG-spawn chain is a documented, real Epic mechanism; the

zone-catalog-polygon → PCG-bounds-actor → graph-selection binding is project-specific

integration work with no existing documented product feature to point at — it has to be

built, not just configured.

---

Residual unknowns (do not build on these unconfirmed)

1. The exact source datasets Cesium World Terrain itself fuses (SRTM/ASTER/other) were not

confirmed this pass. Irrelevant if Cesium is only used as a reference/preview layer per

the §1 recommendation, but would matter if that recommendation is later overridden.

2. Whether Gaea's CLI/automation features are gated to Professional/Enterprise or already

available on the $99 Indie tier is unconfirmed — get a direct answer from QuadSpinner

before assuming Indie suffices for a headless pipeline.

3. Whether Gaea 3.0 has actually shipped (vs. still "in development") is unconfirmed as of

this pass.

4. Whether "an NVIDIA world-gen tool" refers to a specific, real, shippable product is

unconfirmed — this research found none matching that description; get the actual

product name before treating a Gaea-replacement as a live option.

5. The target scale-compression ratio (meters-per-vertex / playable km² per region) is a

design decision, not a technical unknown — flagged in §7 for the standing

decision-analysis protocol, not resolved here.

6. The precise PCG Biome Core node graph that reads landscape layer weights (which

sampling/filter nodes, exactly) needs a hands-on pass inside the shipped sample graphs;

the docs confirm the mechanism exists but not its exact wiring.

7. Whether UE 5.8's new Mesh Terrain should eventually replace heightfield Landscape as

this pipeline's target format is a live open question given how new/experimental it is

this release — worth revisiting, not a decision this brief makes.

---

8. COMPARATOR PIPELINE ADDENDUM — HOW THE TEACHERS BUILD AND MEASURE OPEN WORLDS (2026-08-05)

Provenance. Josh, 2026-08-05, verbatim: *"What about their pipelines?"* The comparator program had

studied the teachers' outcomes and never their production. This addendum lands the world-building half

of that research on the dossier that owns the terrain chain (pipe-dossiers-bind law, commit 732f9bff).

The quest-authoring and world-population half lands on

PIPE_CONTROL_PLANE_2026-07-29.md §8 — read both; they are one research pass split by ownership.

Claim tags follow this brief's existing convention (VERIFIED = confirmed against a cited source this

pass · INFERRED = this addendum's own synthesis · FLAG = could not be confirmed). Source tiers:

FIRST-PARTY = the studio's own publication or talk page; TALK-RECAP = a named recap of a named session

with the speaker identified.

8.1 UBISOFT / FAR CRY 5 — the deterministic nightly world rebuild (the closest analog to our chain)

GDC 2018, *"Procedural World Generation of 'Far Cry 5'"*, Etienne Carrier (Ubisoft Montreal). The pipeline

is Houdini plus Houdini Engine driving the Dunia editor.

GDC Vault session ·

detailed talk notes ·

80.lv writeup ·

PlayStation Blog

WHAT IT TEACHES OURS.

1. F1 is our exact situation, stated by someone who solved it. Our region terrain will iterate for the

whole project (real-Earth DEM → alteration → population, §§2-5 above). Everything hand-placed in

THE WORLD CHAIN, STEP BY STEP Step 5 — POPULATE silently rots the moment Step 3 (ALTER) re-runs.

The chain as written is a manual step list; F1-F4 say Step 5 must be a re-runnable job, not a step.

2. F3 is a hard requirement we have not yet stated anywhere. Determinism is why FC5 could rebuild

nightly without desyncing map junctions or navmesh. Our control plane already has an artifact record with

generation_prompt_hash (PIPE_CONTROL_PLANE §3) — the world-population lane needs the same discipline:

same seed plus same inputs equals the same world, provably, or the nightly rebuild is not safe to run.

harness/check_generation_lifecycle.py is the existing home for that tooth.

3. F4's 64 m sector is a directly adoptable number. We have no unit of world regeneration at all; our

granularity is the region page (76 rows covering 79 nodes). A sector grid inside each region gives us

partial regeneration and the three refresh scopes for free, and it is the natural key for a

population-density table (see PIPE_CONTROL_PLANE §8.3, R2).

4. F7 gives §5's PCG biome work a real rule vocabulary. §5 currently says "landcover feeds PCG biomes"

and Residual Unknown 6 admits the exact node graph is unverified. **Viability / priority / priority radius

/ density ramp / size-linked-to-viability is the vocabulary to build that graph against** — it is the

published shape of a shipped AAA biome system, and it maps cleanly onto our

env_density_band_default and ambient_elemental_affinity columns becoming *inputs to a rule* rather

than decorative bands.

5. F6 is the reason to keep abiotic layers as first-class derived data. Slope, curvature, occlusion,

flow, illumination and altitude are all derivable from the DEMs §2 already downloads. Deriving them once

per region and storing them turns every later placement rule into a cheap lookup — and they are the same

inputs the cliff, freshwater and biome tools consume.

6. F9 is the counterweight, and it should be quoted at our own lanes. "Excessive automation can lead to

issues" and "sometimes manual control outperforms automation" come from the team that automated the most.

Our AAAAA slice (Prologue → Ch 13) is exactly where manual control should win; the procedural chain earns

its keep on the other 66 nodes. INFERRED, flagged as this addendum's own recommendation.

8.2 GUERRILLA / HORIZON — placement as artist-authored RULES, evaluated at runtime

WHAT IT TEACHES OURS.

1. G1/G2 open a genuine architecture fork this brief has not named: BAKE-TIME versus RUN-TIME placement.

Far Cry 5 bakes nightly and ships the result (F2); Horizon evaluates rules as the player moves (G1).

Our chain assumes bake-time throughout (Steps 4-5). Run-time placement would make region content a

rule set that travels with the region page rather than a baked level — which is exactly the shape our

registries already have, and exactly the shape docs/RUNTIME_GENERATIVE_LAYER.md is reaching for.

This is a director-level fork, not a lane decision; it is stated here rather than resolved. INFERRED.

2. G2 is the throughput claim that matters to a solo dev: when placement is rules, a world-scale change

costs one edit instead of a repaint. That is the same economics as the LoRA-versus-per-row-reference

ruling on the art lane (ART_CONSISTENCY_MECHANISM_RULING_2026-08-04) — amortise the mechanism, do not

pay per row forever.

3. **G4 says the endgame of a mature open-world pipeline is non-programmer authoring of *systems*, not just

of content** — and independently corroborates Nintendo's LayoutEditor/SLink finding

(PIPE_CONTROL_PLANE §8.2, N5). Our equivalent is already partly built: registries plus

harness/condition_expr.py plus docs/CONDITION_EXPRESSION_GRAMMAR.md. The gap is that our grammar

currently expresses *conditions* and not *behaviour*.

8.3 NINTENDO / BREATH OF THE WILD — the only published, measurable density doctrine

From the GDC 2017 talk (Fujibayashi / Takizawa / Dohta) and the CEDEC 2017 talks in Matt Walker's

translation: translation gist ·

Nintendo Everything ·

Radiator Blog analysis ·

Nintendo Life

WHAT IT TEACHES OURS.

1. Z1 is authorable as a registry column and gate-checkable — that is the point. "Interesting terrain"

is unmeasurable; "this region carries landmark-scale, view-blocking-scale and tempo-scale relief, and

they are of different sizes" is measurable directly off the DEM-derived slope and altitude layers (F6).

T0_Region_Index already carries terrain_feature_class_ids and env_density_band_default across 76

rows. A three-scale relief mix per region is the single cheapest world-quality tooth available to us,

and it can be computed rather than judged.

2. Z3 is the instrument we are missing, and we can have it before Josh ever plays. We have no heat map

because we have no players — but the AI QA loop *is* our player (memory: josh-playtest-target-ch2-slice),

and its traversal is loggable. **Log QA-loop positions per region, render the heat map, and the linearity

defect Nintendo caught by measurement becomes catchable by us by measurement** rather than by taste. This

is the honest-tier-register version of a play-quality claim: structure-tier evidence, measured.

3. Z2 versus §7's scale-compression decision. §7 leaves meters-per-vertex and playable km² per region as

an open design decision (Residual Unknown 5). Z2 reframes it: the number that matters is not area, it is

how many attractors of differing visibility a region carries and whether they compete. A small region

with three competing attractors reads richer than a large one with a corridor. **INFERRED; it is a

recommendation for how that decision should be framed when it is taken.**

4. **Z4 corroborates F2 from a second studio: nightly regeneration of derived world artifacts is normal AAA

practice, on 2017 hardware.** Two independent teachers rebuild the world's derived data every night. Our

5090 window is idle overnight by design (5090_SETUP_RUNBOOK Stage W). **The nightly world rebuild is the

single most obvious unused capacity in the plan.**

5. Z5 is a discipline note for the whole comparator program: the most-quoted open-world density numbers

on the internet are not Nintendo's. If a lane cites a "40-second rule" it must cite the practitioner, not

the game. (Memory: a-search-that-cannot-match-reports-zero — the same class of error, applied to

provenance instead of to grep.)

8.4 CD PROJEKT RED — the deliberate counter-example

*"The quest content dictated the size of the world, not the other way around"* — level designer Miles Tost;

and *"Everything that is made in a level was hand-crafted… some person has worked on placing that tree or

that rock or that house"* — procedural generation was rejected outright for The Witcher 3.

Kotaku · VERIFIED ·

TALK-RECAP/interview. Rockstar reached the same conclusion for RDR2 — the world *"had to be scripted so that

it all feels right"*

(GamesBeat).

WHAT IT TEACHES OURS. Two of the four teachers automated world placement heavily (Ubisoft, Guerrilla) and

two rejected it (CDPR, Rockstar) — and all four shipped genre-defining worlds. The split is not

quality-versus-shortcut; it is team shape. The studios that automated had large worlds and needed the

world to survive terrain churn (F1); the studios that hand-placed had the headcount to pay per rock.

**We have neither the headcount nor a frozen terrain, so the FC5 posture is the correct default for the 66

nodes outside the slice — and the CDPR posture is the correct default inside the AAAAA slice

(Prologue → Ch 13), where the Josh Gate's bar is set.** That is a per-node decision the region page should

carry as a field, not a project-wide stance. **INFERRED — this addendum's recommendation, named so it can be

vetoed.**

8.5 WHAT THIS ADDENDUM CHANGES IN THE CHAIN ABOVE (proposed, not applied)

1. THE WORLD CHAIN, STEP BY STEP Step 5 — POPULATE becomes a re-runnable, deterministic JOB with three

scopes (all sectors / local / camera), keyed to a sector grid inside each region (F2, F3, F4).

2. Add a Step 2b — DERIVE ABIOTIC LAYERS (slope, curvature, occlusion, flow, illumination, altitude) once

per region, from the DEMs §2 already downloads; every later placement rule reads them (F6).

3. §5's PCG biome work adopts the FC5 rule vocabulary — viability, priority, priority radius, density

ramp, size-linked-to-viability — which also closes Residual Unknown 6 with a target shape to build against

(F7).

4. Add a three-scale relief requirement per region (landmark / view-blocking / tempo), computed off the

abiotic layers, as a gate rather than a review opinion (Z1).

5. Log AI-QA traversal per region and render heat maps as the standing world-quality instrument (Z3).

6. Record the bake-time versus run-time placement fork as an open director decision, with Horizon's

run-time rule evaluation as the live alternative to our current bake-time assumption (G1, G2).

7. Carry a per-node placement posture field — hand-crafted inside the slice, rule-driven outside it

(§8.4) — on T0_Region_Index rather than deciding it project-wide.

Residual unknowns added by this addendum. Far Cry 5's generation wall-clock per sector, the size of the

team running it, and its total nightly cost are not published — so F2's "overnight" carries no throughput

number we can plan against. Horizon's run-time placement performance envelope on a 2026 PC target is

unverified. And the Creation Kit alias documentation behind PIPE_CONTROL_PLANE §8.4 (B1-B4) returned HTTP

403 this pass and is search-index-sourced; re-verify before building the fill contract on it.

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