A practical reconstruction of the configuration flow behind Region, SubRegion, StampInfo, JavaScript heightmap experiments, deterministic C++ porting, and a UE5 editor/runtime design.
Previous article: From Rules to World: C++ Runtime Verification for Procedural Terrain
Before we start: this is not a 1:1 recreation claim
We spent a long time studying and recreating the Desert_Dune terrain from the reference game. The work produced ten 4096×4096 16-bit heightmaps, an unpacked type and configuration database, many statistical reports, a live JavaScript heightmap generator, several C++ port branches, and a UE5.7 editor/runtime design.
It would be easy to describe the process as: inspect the heightmaps, find Region, SubRegion and Stamp, copy the apparent rules, and move the result into UE5. That is not what happened.
We initially treated lowland and highland in PlanetData as two independent height domains. We treated Voronoi as the direct source of plateau height. We read a six-element float field as six terrain levels. We called bright segmented regions “plateaus”. We treated Circle and Rectangle as final visible outlines. We mixed roads, POI walls, explosion craters and natural terrain into one Stamp layer. We also kept raising noise and erosion strength in the name of making the ground “more natural”, until the result looked like a real landscape rather than a playable game level.
Most of those interpretations were later rejected by the data or by repeated comparison with the ten references.
The useful distinction is between three kinds of information:
- Structures confirmed by the unpacked data. Types, instances, fields, arrays, hashes and resource links really exist.
- Models inferred from the ten heightmaps. These are image-based hypotheses that must survive experiments; they are not recovered source-code conclusions.
- Our reconstruction. It borrows the reference game terminology and structural ideas, but it is an engineering model that explains the evidence currently available to us.
This article does not claim to recover the original the reference game algorithm. It also does not turn the current roughly 60–70% visual progress into a finished product. The practical question is narrower:
When all we have is unpacked structure, static configuration and final heightmaps, how can we recover a plausible production pipeline one stage at a time, and turn every assumption into a runnable experiment that can be compared or rejected?
Our current working model is that Desert_Dune is neither a noise image nor a random pile of thousands of Stamps. A more useful interpretation is a configuration pipeline: a continuous and playable macro terrain is established first, local terrain is organized through Stamp groups, and roads, POIs and dynamic displacement modify the surface later.
This is one article in three parts:
- Part I covers the unpacked the reference game structures and the heightmap reverse analysis.
- Part II covers the JavaScript/C++ reconstruction and the experiments that failed.
- Part III describes how the verified stages could be organized into a UE5 editor and runtime tool.
The three parts are at different maturity levels:
| Area | Current status |
|---|---|
| the reference game structural reverse analysis | Partially confirmed; the runtime ownership chain is incomplete |
| JavaScript terrain recreation | A runnable, continuously iterated baseline exists |
| C++ port | Some historical frozen stages were validated; the current Stamp11 default still needs a fresh cross-check |
| UE5 editor/runtime | Architecture and prototype construction plan, not a finished product |
Roads and POIs are also outside the current scope. This reconstruction covers the natural Desert_Dune base layer; roads, POI foundations/walls, and their flattening or displacement of the surface remain separate systems for a later stage.
Reference images and reverse-engineering boundary
Ten heightmaps are more useful than one attractive screenshot
A single procedural result is dangerous evidence. One map may happen to contain a memorable highland, or may look complex because a POI or a road was included. If we fit a generator to that image, accidental content quickly becomes an invented biome rule.
The Desert_Dune reference set contains ten original heightmaps. They are 4096×4096 16-bit data representing an approximately 4 km scene scale. To study natural terrain, we also had to separate the circular presentation border, the outer falloff ring, and obvious later-stage structures.
Across all ten images, the stable observations were not one special geometric primitive but a distribution of shapes:
- large continuous low-slope walkable areas;
- visible high/low variation without regular staircase terraces;
- medium and large structures appearing as irregular patches or clusters;
- small details appearing as discrete constructions rather than full-image noise;
- some maps being almost plain while others contain a large continuous high region;
- high regions usually being off-centre rather than mechanically centred in the disc;
- a shared visual language with significantly different placement rhythm between seeds.
This changed our direction. The missing ingredient was usually not more noise energy. It was discrete shape language at the right scale.
The final heightmap is not a generator’s raw output
Some reference images contain hard lines, long straight edges, platform walls, flat areas around buildings and trench-like marks. If all of those are abstracted as natural Stamps, the generator reliably produces roads, POI walls and regular craters. They may be present in a final map, but that does not make them part of the Desert_Dune natural layer.
Our working separation is:
A line with stable width, continuous direction and deliberate bends is more likely to come from a route, path, spline or POI. A hard-edged platform aligned with a structure is more likely to be Flatten or mission terrain than a natural plateau. A circular depression with a full positive rim may be an explosion, meteor or other dedicated content. It should not become a default natural Stamp merely because it appears in the final image.
This is a boundary for reconstruction, not a claim that we recovered the original call order.
Static structure and Stamp resources
PlanetData and the lowland/highland trap
The unpacked LevelGenerationPlanetData records connect planet-level data to Region names, IDs and types. In the data we examined, the static lowland and highland slots repeatedly behaved like mirrored slots of the same Region configuration rather than two independently authored terrain domains.
The audit found:
- 431 lowland/highland pairs with matching structure;
- 30 unique Region names and 30 unique Region IDs in the relevant static set;
- 71
GenerationRegionSettingsrecords; SubRegionSettings[16]andSubRegionSettingsOverride[16]in each Region record.
The practical conclusion is simple: do not build the reconstruction around two separate “lowland terrain” and “highland terrain” generators. The double slot is a configuration distinction whose runtime use still needs to be mapped.
Region and SubRegion are rule slots, not a visible 16-cell terrain grid
The 16-element arrays are tempting to draw as a 4×4 spatial grid. The static data does not justify that interpretation. They are better treated as fixed rule slots until a runtime consumer proves otherwise.
The same caution applies to an FP32[6] field found in several Region records. In most instances its values look more like one-hot or near one-hot selection weights than six actual elevations. SubRegionHeight exists as an enum, but its metre-scale meaning has not been recovered. HeightAreaIncrease also exists, yet we did not find enough instance or reference evidence to claim that it drives six expanding plateau levels.
This was an important negative result. A field that looks like six numbers is not automatically six visible terrain heights.
Where Voronoi belongs
Voronoi-related types such as Cell, Edge and Corner exist in the unpacked material. They are useful clues about site partitioning, adjacency, boundaries or placement. They do not, by themselves, prove that a Voronoi cell is written into the heightmap as a plateau.
Our implementation therefore keeps the concept available as a layout or site-partition stage, but does not use “Voronoi equals plateau height” as a default rule. This single distinction removed a large amount of artificial polygonal terrain from the preview.
The Stamp resource chain
The most reliable resource chain we recovered is:
The word Stamp should not be reduced to “height patch”. In this article it may include geometric envelopes, configuration, weights, connections and combination information. Only after the height asset and the final mixing function are known can we say how a Stamp becomes visible height.
Circle, Rectangle and Spline are confirmed components or geometry types. A Circle record contains centre/radius candidates and additional control data. A Rectangle contains two-dimensional endpoints and extra parameters. A Spline contains a type, dynamic control-point storage and endpoint candidates. These records prove that the shapes exist in the configuration system. They do not prove that their outlines are directly written as final pixels.
When we wrote those primitive outlines directly into height, the result was predictable: regular circular mounds, capsule-shaped clusters, bead-like rows and hard composite footprints. Those forms do not match the natural Desert_Dune reference set. The safer interpretation is that the primitives define occupancy, envelope, scatter radius, overlap or connectivity, while visible height comes from another profile or asset layer.
What 2416 valid Stamps actually means
The unpacked database contains roughly 2416 valid Stamp records. That number is useful, but it does not mean there are 2416 independent height textures.
The records can include variants, combinations, geometry entries, flags, weights and references. Many may share the same family or participate in parent/child composition. The correct statement is:
2416 is a count of valid configuration and geometry records, not a count of 2416 visible heightmap patches.
The same rule applies to the Sandy candidate chain. Sandy is a valuable candidate pool for a desert-like configuration path; it has not been proven to be a synonym for the final Desert_Dune asset set. We narrowed one investigation from 106 candidates to 82 usable candidates, but we did not recover a one-to-one mapping from those candidates to the ten references.
Image families and evidence levels
Image families are our labels, not the reference game class names
Because the actual visual height assets were not recovered, we classified residual shapes from the ten heightmaps. These labels constrain our generator; they are not official the reference game Stamp names.
The four useful families were:
- broad platform-like parents;
- broken shoulders and partial ledges;
- short dependent ridges or wall-like fragments;
- wide, shallow and open winding gullies.
The broad parent family matters most. A positive composite cluster often has a median diameter around 104 m and a median aspect ratio around 2.16, with more than half showing genuine multi-lobe structure. It should not be rendered as several independent circular hills. A parent shape needs to organize child lobes, connectors and internal height variation.
Natural terrain versus displacement and POI content
FlattenHeightmapAO and DisplacementComponent are important, but they do not automatically belong to the natural Desert_Dune layer. Flattening can create a construction-ready area. Displacement represents an ability to move the surface. Explosion is one possible runtime cause of displacement; it is not evidence that every crater belongs in the base terrain.
For the natural reconstruction we excluded roads, POI walls, explosion signatures and runtime displacement. If those systems are implemented later, they should remain separate, switchable layers instead of being baked into every Desert_Dune base heightmap.
Evidence levels
To keep the article honest, we use four labels:
- A — Confirmed: directly present in unpacked data or a repeatable file audit.
- B — Structural inference: a model that explains several confirmed structures but is not a recovered call chain.
- C — Image inference: a rule inferred from the ten heightmaps and tested experimentally.
- R — Rejected: a rule that produced a stable mismatch or contradicted the available data.
For example, StampGroup → StampInfo → HashMap is A-level structure. “A StampGroup selects a parent shape and dependent child shapes” is B-level. “Desert_Dune needs broad positive parents and open gullies” is C-level. “Voronoi cell directly writes a plateau” is R-level for our current model.
JavaScript/C++ reconstruction experiments
Why JavaScript came first
We built a JavaScript heightmap workbench before trying to complete the C++ port. The browser was useful because every stage could be toggled, parameter changes were immediate, and ten seeds could be rendered into a gallery without a long build cycle.
The workbench keeps the stages visible:
The key design rule is that a stage should produce inspectable data, not only a final image. Support geometry, placement, delta fields and final height must be viewable separately. Otherwise a good-looking result can hide a wrong mechanism.
The failed directions were useful
Several early versions looked plausible in isolation and failed as soon as we compared all ten maps.
Regular stacked terraces
We divided the height into several levels, shrank the inner footprint and added each level on top of the previous one. It quickly produced an obvious stair-step effect. The references contain height differences, but their high regions are generally continuous and irregular. Regular nested rings were removed from the main Desert_Dune path.
Curved continental splits
We tried to create a large plateau by cutting the disc with a curved boundary. This generated a designer-like continent split. It was not supported by the references and made each seed share the same large visual seam.
Global noise and erosion
More high-frequency noise improved some frequency metrics but turned the walkable space into water ripples. More erosion produced real-looking landforms, not the controlled game terrain visible in the reference game The reference set needs discrete small structures, not noise energy everywhere.
Direct Circle and Rectangle outlines
These generated too many small convex blobs, hard walls and rounded pits. They were useful as support-domain experiments, but they were not acceptable as visible natural terrain.
The common lesson was that the problem was not one bad slider. The order of generation and the responsibilities of each stage were wrong.
The support-domain distinction
We eventually separated three things that had been mixed together:
- Support domain: where a group is allowed to exist.
- Placement: where parent and child elements are arranged.
- Visible height: the profile that is actually rasterized into the height field.
This explains why a support-domain preview should look clean and geometric. It is not supposed to contain random bumps. It also explains why a Circle-only candidate can result in an irregular visible shape: the Circle may only define occupancy, while the interior profile comes from another layer.
The Desert_Dune macro model
Our current baseline uses a continuous, low-amplitude macro surface plus a sparse positive construction layer. The macro layer provides broad playable areas, regional height difference and a few large parent zones. It does not create a field of pits, walls or water-like ripples.
The main controls are deliberately few:
- macro height contrast;
- parent plateau coverage;
- shoulder width and softness;
- medium-group density;
- micro detail density;
- stamp scale;
- stamp amplitude;
- negative feature enable/disable.
The web UI later gained sliders for overall Stamp scale and height contrast because these are global decisions during visual tuning. Per-family controls remain available in debug mode, but the default view should not expose every internal number.
R5-RS and the base-surface audit
After several Stamp experiments failed, we audited the surface before Stamp placement. The old RecoveryBase used a blurred regional field as a spatial proxy. Even with Stamp disabled, it formed low-frequency cloud patches. Once Stamp was enabled, those cloud edges became bright fragments and the result looked much rougher than the reference.
The revised R5-RS path treats the reference-derived support mask as a proxy asset rather than as recovered the reference game data. It is useful for freezing macro layout while testing Stamp families, but it must remain replaceable. When a more direct Region Variant ownership chain or base rule is recovered, the proxy layer can be swapped without rewriting the UI, statistics or UE backends.
Stamp11 as an engineering checkpoint
Stamp11 was not called “the the reference game algorithm”. It was a checkpoint with explicit scoring:
| Area | Weight | Result |
|---|---|---|
| Macro plateau span | 30 | 28 |
| Medium-scale rhythm | 30 | 20 |
| Stamp shape language | 20 | 8 |
| Flatness and slope | 15 | 10 |
| Forbidden negative features | 5 | 5 |
| Total | 100 | 71 |
This is a project acceptance score, not pixel similarity. A frequency-band RMS ratio of 95.2% only says that the amount of energy in that band is similar. A collection of round blobs and a collection of broken shoulders can have the same RMS.
We also measured low-frequency support correlation, but it must be described as support-domain correlation. It is not “99.4% the reference game restoration”. The current visual progress was estimated at roughly 60–65% because macro span and medium energy were close while small shape language, configuration diversity and true height semantics were still missing.
Why Stamp12–15 were rejected
Stamp12 extracted positive outlines from the references and used them to replace part of the repeated circular Stamp set. The A/B gallery was almost indistinguishable. Soft clipping removed the outside of an existing primitive union, but did not change its internal height structure.
Stamp13 tried topology changes. Stamp14 replaced whole two-dimensional group patches. Stamp15 preserved group-level structure and added manually selected positive height patches as internal modulation. The latter was safer, but the internal change was barely visible at 512². Increasing the gain only produced more sharp fragments and uneven ground.
The result was not that the code was useless. It showed that extracting a small residual from a final heightmap and putting it back into the current Stamp program does not recover the original asset semantics. The missing information is more likely in group composition, parent/child layout and family selection.
Deterministic C++ porting
Once the JavaScript rules were stable enough, we started the C++ migration. The target was not a faster implementation that merely looked similar. The target was a layer-by-layer comparison:
The current C++ status needs a clear qualification. Some historical frozen stages reached zero-pixel error under their fixture. That result does not mean the latest Stamp11 default chain has already passed a complete C++ comparison. The C++ branch is best described as a deterministic implementation of frozen rules, with a new fixture and comparison still required for the current default.
Cross-language details matter. JavaScript uses double precision while typical C++ height paths use float. Primitive parameters and final quantized height need different tolerances. We should not demand bitwise equality where the formats differ, but we also should not hide a structural mismatch behind a generous visual tolerance.
The same seed must drive the same random stream. Site tables should be precomputed. Stamp placement should use spatial bins rather than scanning every Stamp for every pixel. Golden data must include the first divergent stage, not only a final hash.
What the web tool is for
The web preview is an experimental instrument, not the final terrain runtime. It supports:
- stage selection;
- 2D heightmap view;
- hillshade and 3D inspection;
- support-domain preview;
- Stamp group and family toggles;
- global height and scale sliders;
- seed and resolution changes;
- ten-seed galleries;
- JSON statistics and comparison exports.
The most important feature is not the 3D camera. It is the ability to turn off a stage and see whether the unwanted feature disappears. If a 500-line algorithm does not change the ten-map gallery or the metrics, it should remain an experiment rather than silently becoming the default.
UE5 editor and production-tool route
Scope of the UE5 section
This part describes the architecture and construction route for a UE5 TerrainGen tool. It is not a claim that the complete Desert_Dune UE5 editor or runtime product has already been delivered.
The intended flow is:
One core must feed both backends. The editor is where artists inspect and edit results. Runtime is where the same recipe and seed must produce an equivalent playable surface. The core should not contain Landscape-only assumptions.
Versioned Recipe and LayoutData
The browser prototype started with sliders and constants scattered through functions. In UE5, inputs must become versioned data assets. A Recipe should contain the seed, world size, resolution, macro contrast, parent coverage, group densities, Stamp scale and amplitude, negative-feature policy, and the selected proxy family.
LayoutData should record the generated sites and placements without storing a full heightmap. That gives us three benefits:
- a server can replicate a compact layout rather than a complete height field;
- the editor can modify one group and rebake only the affected region;
- debug views can display support and placement directly instead of guessing from the final surface.
The generated data needs a version, seed, recipe hash, coordinate convention and source stage. A later algorithm change should create a new version rather than silently changing old maps.
HeightFieldSampler and stage ownership
The central core can be organized around a sampler that maps world coordinates to:
It should not know whether the result will be written to Landscape, a DynamicMesh or a runtime heightfield. selectStampGroupRecipes should produce placement and parent/child relations without writing pixels. Rasterization belongs in one explicit stage so that the height asset or blend function can be replaced later.
Positive natural Stamps should not create negative pits by accident. Circular masks and output quantization should happen at the end, after interior height has been composed. The support domain should remain independently inspectable.
Landscape editor backend
For the editor path, the core output can be quantized into a Landscape-compatible height field. The tool should show at least three views side by side:
- support-domain geometry;
- the 2D heightmap;
- the final 3D relief.
This prevents the same mistake we made in the browser: treating a geometric Circle envelope as the visible terrain height.
Landscape Edit Layers are useful for artist corrections, but they are additive edits rather than semantic constraints. A manual correction near an old plateau can move to a completely different area when the seed changes. The editor therefore needs semantic selection of Region, StampGroup and Placement, with edits saved back to generated configuration where appropriate.
Runtime backend
Runtime should consume the same HeightField and LayoutData but use a backend suitable for streaming and physics. DynamicMesh, a runtime heightfield representation or a dedicated terrain tile mesh are possible choices. The exact choice depends on collision, world partition and memory requirements.
World Partition can stream buildings and props, but it does not generate terrain for us. A “generate terrain tile when a WP cell becomes active” design is an integration option, not an existing built-in UE terrain generation feature.
For multiplayer, the server must be authoritative over the recipe version, seed, layout hash and any runtime displacement events. Clients can regenerate the base height deterministically and apply the authoritative changes. If the terrain changes because of an explosion, that event belongs to the displacement layer, not to the natural Desert_Dune recipe.
Validation and Golden data
The validation ladder should be explicit:
Golden data must include both layout and height. A final image alone can miss a parent/child swap that affects only a small overlap region. The useful fixture set includes seed, recipe hash, site table hash, placement list, per-stage statistics, final height hash and a rendered comparison image.
The historical zero-error C++ result should remain labelled as a frozen-stage result. The current Stamp11 default must go through the same ladder again before it is described as a fully equivalent implementation.
Remaining work and conclusion
What is still missing
The largest visual gap is still Stamp shape language. We recovered groups, infos, hashes and geometric envelopes, but not the original visible height blending. More circular blobs will not solve that gap. The next useful work is to recover group-level combination semantics, parent/child dependencies and family selection, then validate them on the ten-map gallery.
The natural base also needs a final freeze before roads, POI foundations, cave entrances and explosion deformation are added. Those are separate systems with separate ownership. Mixing them into the base makes comparison harder and creates the same false walls and pits that caused several earlier regressions.
Conclusion
This project did not end with a claim that one generated heightmap is identical to the reference game It produced a working way to reduce uncertainty:
- separate unpacked facts from image inference and implementation choices;
- keep support, placement and visible height as different stages;
- use JavaScript to test ideas quickly;
- move only frozen rules into C++ and compare them layer by layer;
- design UE5 around one deterministic core and separate editor/runtime backends;
- keep roads, POIs and dynamic displacement out of the natural base layer;
- record rejected experiments so that the team does not repeat them.
The current reconstruction is a foundation, not a finished the reference game clone. Roads and POI terrain have not been implemented yet. It is close enough in macro span and medium-scale energy to support continued work, but still short of the original Stamp diversity, small-scale shape language and recovered configuration semantics. The next stage is to improve those natural layers first, then add roads, POI foundations and local flattening as separate systems. That distinction is important: a plausible screenshot is useful, but a replaceable and testable pipeline is what lets the next iteration improve for the right reason.
Next: from natural terrain to a runnable level surface
This article closes the foundation of the natural terrain pipeline: how configuration is passed through the system, how Region and SubRegion form support domains, how Stamps enter the heightmap, and how the same parameter meaning is carried between the JavaScript prototype, the C++ core and the UE5 editor.
The next article will move toward level production. It will separate road and route adaptation, POI and base areas, mission-area flattening, and the way those systems cover or modify the natural terrain. It will also introduce generation styles, so roads, POIs and local surfaces are not simply drawn on top afterward, but can enter the generation flow through the same configuration model. On the UE5 side, we will connect the runtime C++ path and verify how editor-generated results reach runtime while keeping the JavaScript prototype, C++ core and UE5 output aligned.
That work is not finished yet, so this section is intentionally a lead-in to the next article rather than a claim of completion.
Appendix — Terminology and evidence boundary
| Term | Status | Safe usage |
|---|---|---|
LevelGenerationPlanetData |
confirmed in unpacked data | planet-to-Region name/ID/type linkage |
| static lowland/highland slots | confirmed mirrored structure | not two independent height domains |
71 GenerationRegionSettings |
confirmed count | not yet mapped to a specific Desert_Dune variant |
SubRegionSettings[16] |
confirmed array | fixed rule slots, not sixteen spatial cells |
SubRegionHeight |
confirmed enum | metre-scale meaning unknown |
| Voronoi Cell/Edge/Corner | confirmed types | purpose unresolved; not direct height proof |
StampGroup → StampInfo → HashMap |
confirmed resource chain | selection/combination path, not a recovered height blend |
| 2416 valid Stamps | confirmed record count | configuration/geometry records, not height textures |
| Sandy candidate pool | candidate inference | not proven equivalent to Desert_Dune |
| Stamp11 score 71/100 | our engineering checkpoint | not pixel similarity or the reference game restoration percentage |
| UE5 TerrainGen | design/prototype route | not a finished production plugin |