From Multiplayer Synchronization to Level Production: POI Layout, Road Interfaces, and Natural Terrain Reconstruction

Revision note (2026-09-30): This article records work from 2026-08-22. Early proxy designs, sample measurements, and evidence about the original algorithm are distinguished below. Pending work retains its historical validation scope. Later progress is covered in heightmap reconstruction and POI, Stamp, vegetation, and rock layouts.

Runtime PCG Development Retrospective · Level Layout and Natural Terrain

The previous article, “From Playable World to Multiplayer Session: UE5 Runtime Terrain, POI Placement, and Dedicated Server Synchronization”, focused on runtime engineering: how the editor, clients, and Dedicated Server can derive the same result from the same Recipe, Seed, and layout inputs; when terrain becomes queryable; when collision becomes available; and how client-side differences are detected and repaired.

When the server and every client see the same terrain, the multiplayer path is working. That still does not make the result a playable level.

The next set of problems belongs to level production. Which POIs appear in this session? Where do objectives, outposts, and resource sites fit? How does the real Cell footprint enter collision checks? Which entrance should a road use? Before any of those structures are placed, can the terrain provide a continuous, playable foundation?

This pass brings those problems into one validation chain. The existing Runtime/DS baseline already produces consistent multiplayer results from the same configuration and Seed. The new 25-POI layout and regional roads now run in the Web reconstruction and are being checked as UE spatial inputs; item-by-item Runtime/DS digests are still pending. Desert_Dune and Icy_Glaciers have also moved forward, with Region, SubRegion, StampGroup, and StampInfo split into stages that can be inspected on their own.

One boundary needs to stay explicit. Cell, StampCircle, Rectangle, Entry, and internal Spline data come from unpacked data or reconstructed UE assets. POI selection, candidate scoring, regional roads, and some height proxies are reconstruction code written to exercise the production path. They are not confirmed implementations of the original HD2 runtime algorithms.

The rest of the article follows the production path and labels direct evidence, current reconstruction, and unresolved runtime behavior separately.

---

1. One Production Chain for Layout, Terrain, and Runtime

Three areas moved forward together in this pass.

Level layout selects the Cells for a session, calculates POI positions and orientations, checks the available footprint constraints against map bounds and occupied space, and then organizes mission relationships and roads.

The tools divide the engineering work by environment. The Web tool is quick for data inspection, stage replay, and fixed-Seed comparisons. The UE editor is where assets and coordinates are checked. Runtime creates terrain and POIs in the actual scene. The Dedicated Server checks whether a multiplayer session still converges on the authoritative result.

Natural terrain starts with the continuous Region/SubRegion structure rather than a stack of noise layers. Broad support, medium-scale forms, local residuals, and support-domain-constrained natural Stamps are added afterward.

The same configuration and Seed connect all three areas. Designers adjust candidate and road rules on the Web, artists inspect terrain stages and Stamp combinations, and programmers carry the same input into UE, Runtime, and DS. When something goes wrong, the team can return to the responsible configuration or generation stage instead of guessing from the final scene.

The Web tool currently covers only part of the landform set. Final surface materials, vegetation, complete road presentation, and all biomes are also missing in UE. What is stable now is the route back into the work: layout issues stay in layout, terrain issues return to their generation stage, and network differences are checked through sessions and digests.

2. Separate Known Data from Runtime Decisions

One common misunderstanding in procedural layout work is treating the unpacked candidate set as the final map. Runtime decisions still sit between those two states.

The input snapshot used for this pass is listed below. These values freeze the test conditions; they do not represent the full HD2 content scale or its original budget rules.

Item	Test value
Difficulty	D6
Faction condition mask	bit 10
PlanetTemplate	2
Seed	20260820
Map radius	500 m
Provisional POI budget	25
LevelGenerationLocation pools	14
Exploration records	58
Cache records	35
LocationStampInfo records	843
Unique StampIDs	837

These records tell us what content can be selected and which footprint components form a Cell. They do not directly reveal how the original HD2 runtime allocates budgets, performs weighted retries, enforces Spawn Limits, or assigns the exact semantics of the remaining candidate pools.

The rest of the discussion uses three evidence groups:

• Unpacked data: candidate pools, Cell-to-Stamp relationships, StampCircle/Rectangle components, Entry data, and Splines.
• Missing runtime behavior: the production selector, weight arbitration, budget allocation, retries, and some category semantics.
• Reconstruction proxies: a fixed category list, a 25-POI budget, candidate sampling, scoring, and road routing.

Keeping these groups separate makes the selector replaceable. New runtime evidence can change selection and placement without forcing a rewrite of validated Cell geometry, spatial interfaces, or the baseline UE/DS path.

3. A POI Is a Rotating Spatial Footprint, Not a Point

Early prototypes often represent a POI as a center point with an empirical radius assigned by category. That is sufficient for a schematic, but not for placing a real Cell.

A compound may contain several offset StampCircle and Rectangle components. Together they describe the two-dimensional space occupied by buildings, rocks, platforms, or artificial structures. When the POI orientation changes, the implementation must rotate the complete set of local components around the Cell origin and then translate them into world space. Rotating only an icon is not enough.

One primary-objective Cell, for example, contains four unpacked StampCircle components:

Component	Local center X / Y	Radius
C1	-25.49 m / -36.26 m	44.28 m
C2	14.09 m / -23.78 m	56.06 m
C3	40.70 m / 26.12 m	51.77 m
C4	-26.52 m / 23.26 m	56.69 m

The four circles produce an axis-aligned extent of roughly 175.7 m × 160.5 m and an overall bounding radius of about 100.1 m. A single center and radius may waste large amounts of space on one side while allowing an offset structure to invade a neighboring POI on the other.

The placement stage handles a rotated set of footprint components rather than an isolated point:

1. Generate candidate positions and orientations.
2. Transform the Cell’s StampCircle and Rectangle components into world space for display, output, and spatial checks.
3. On the verified path, test each StampCircle against boundaries, collisions, and clearance rules.
4. Use a conservative enclosing range for Rectangle components until exact rotated-rectangle collision is implemented.
5. Select a legal candidate and record its position, orientation, and footprint components.

The StampCircle in this context is a layout footprint. It is neither the visible building outline nor a natural-terrain height Stamp. The similarly named objects have different responsibilities and maturity levels:

Name	Evidence source	Stage	Changes height	Current use and status
POI StampCircle / Rectangle	Unpacked data or Cell asset reconstruction	Layout	No	Spatial footprint; Circle uses precise filtering, while Rectangle uses a conservative range
Natural StampGroup / StampInfo	Unpacked configuration relationships	Natural terrain	Indirectly	Parent-child relationships and support components are known; the original runtime height mechanism is unknown
Natural Stamp height proxy	Current reconstruction	Natural terrain	Yes	Web prototype for validating support domains, combinations, and stage ownership
POI platform / Gameplay Stamp	Current runtime implementation	POI terrain adaptation	Yes	Implemented in the existing Runtime/DS baseline; not yet integrated item by item with the new 25-POI layout
Road terrain shaping	Planned interface	Road/terrain integration	Intended to	This pass validates two-dimensional roads only; height shaping is not a completed item

4. Candidate Generation, Filtering, and Locking: A Verifiable Engineering Baseline

The available HD2 material does not expose the complete runtime implementation for POI selection and placement. To validate the data structures, spatial constraints, road interfaces, and runtime path first, the tool uses multi-candidate sampling and hard-constraint filtering.

The approach follows the spatial-separation principle seen in best-of-N sampling and Poisson disk sampling: generate many candidate positions and orientations, reject boundary and collision violations, and select a stronger spatial result from the survivors. This implementation is not Bridson’s active-list Poisson disk algorithm, and it does not imply that HD2 uses the same method.

In one test using a 500 m map radius, the primary objective first generates 2,600 X/Y/Yaw candidates. The four StampCircle components of the example Cell rotate and translate together. A candidate advances only when every circle satisfies:

distance(circleCenter, mapCenter) + circleRadius <= mapRadius - boundaryMargin

The boundary margin for this pass is 30 m. In the example, 55 candidates are rejected because at least one footprint circle crosses the boundary.

Each surviving candidate is then compared circle by circle against every locked POI. Two circles must satisfy:

distance(ci, cj) >= radius_i + radius_j + categoryClearance

categoryClearance depends on the POI category pair. The test uses graded clearances such as 24, 18, 12, and 6 m. Another 126 candidates are rejected because their circular footprints conflict. Rectangle transforms are preserved, but this article does not count them as verified exact per-component collision until oriented-bounding-box tests are complete.

The remaining legal candidates are scored for nearby free space, boundary distance, a small deterministic perturbation derived from the Seed, and deviation from the target radius. After one placement is selected and locked, later POIs treat it as an existing obstacle and cannot retroactively change it. Candidate ordering, tie-breaking, and POI locking order are part of the algorithm identity: changing any of them can produce another layout even when the Seed remains the same.

For now, this baseline makes each Seed reproducible and keeps layout failures visible in Web playback. Too few candidates, tight boundaries, poor category clearances, and scoring bias all point to a specific stage. The gameplay rules are not finished: mission topology, regional meaning, terrain slope, resource pacing, and hostile distribution still need to enter the same arbitration process.

5. Roads Connect to Cell Entries, Not POI Centers

Once POIs are placed, a road should not simply connect two center points. A real Cell commonly defines one or more Entry points on specific edges. Each Entry has a local position and facing direction, and an internal Spline extends from it toward a stop point inside the compound.

In this reconstruction, road access is organized into two segments. A regional road reaches the Entry, while the Cell’s internal Spline extends from the Entry into the built space. Once the POI position and orientation are fixed, Entry and Spline data transform into world space together so that the regional router can choose the intended access point.

A center-to-center road can cut through a building or rock, hit the back of a compound wall, or ignore an entrance ramp already built into the asset. With Entry data, the regional road only has to reach the entrance. The Cell’s own Spline owns the final segment inside the compound.

One unpacked Entry/Spline set was compared with a reconstructed UE Cell in the same coordinate system. The example Cell contains two Splines and four endpoints: two connection points face outside the Cell, and two stop points lie inside it. The top-view endpoints correspond to built spaces in the UE Cell. This supports continued validation of the Entry/Spline data as a road interface for the reconstruction. It demonstrates consumable spatial relationships, but does not by itself prove that the original HD2 regional-road runtime uses the same connection and routing flow.

Regional roads remain a reconstruction solution. The engineering flow first creates a Region trunk between the primary objective and extraction, builds a candidate topology from local adjacency, selects a Cell Entry, searches through a cost field, and reuses nearby segments where practical. The internal Cell Spline is unpacked evidence; the regional trunk, cost-based routing, and segment merging must not be described as confirmed HD2 algorithms.

Road-related information	Evidence level	Current conclusion
Local Entry/Spline coordinates, directions, and connection/stop relationships	Unpacked or asset-reconstruction fact	Can be consumed as an internal Cell spatial interface
Endpoint correspondence with built spaces in the UE Cell	Engineering validation	Shows that the coordinate transform and spatial relationship are usable
Region trunk, cost field, branch merging, and access strategy	Current reconstruction	Completes an inspectable regional-road loop
Original HD2 road selector, merge, and routing process	Unconfirmed	Requires runtime implementation evidence or more direct data

After all 25 POIs are locked, the tool can overlay mission relationships, the Region trunk, merged branches, and internal Cell Splines in one view. Validation then checks more than whether every icon appears. It also checks connectivity between the primary objective and extraction, use of the intended Entry, and continuity between the regional road and the Cell’s final internal segment.

6. Natural Terrain Forms the Continuous Foundation Before POIs and Roads Are Added

Level layout organizes artificial content. Natural terrain defines the world on which that content will be placed.

Desert_Dune and Icy_Glaciers currently have the strongest prototypes. The Web tool can generate complete circular areas for fixed Seeds while retaining the distinct large-scale morphology of each biome. Other landform families remain in development. These results validate terrain recovery and the toolchain; they do not represent final materials, vegetation, or level art.

The Desert_Dune experiments quickly exposed a problem with “base noise plus a few Stamps”: the result was a collection of bumps, not a continuous landform. Using the unpacked fields and current results, the reconstruction is now divided into the ten stages below. Some stages have direct data support; their spatial evaluation and composition functions are still engineering reconstructions.

1. Region configuration defines entry conditions, scope, weights, and available recipes.
2. SubRegion ownership divides the space into regions.
3. HeightGroups establish vertical relationships between regions.
4. CornerHeights provide boundary conditions for continuous interpolation.
5. Boundary conditioning removes hard edges between discrete partitions.
6. Broad support establishes large playable foundations.
7. Medium morphology adds shoulders and continuous undulation.
8. Local residual contributes low-amplitude detail only inside valid support domains.
9. StampGroup and StampInfo organize local structures inside parent-owned ranges.
10. The layers combine into the natural heightfield.

There is one hard rule: a later layer cannot repair missing spatial structure in an earlier one. Without a continuous Region/SubRegion skeleton, more Stamps only create more isolated bumps. Without broad support, medium-scale noise fragments the map. POI platforms, road flattening, and runtime deformation must not be used to hide an unfinished natural layer.

The implementation uses the following relationship to keep natural terrain and later artificial changes separate:

Hnatural = HRegion/SubRegion
         + ΔHbroad
         + ΔHshoulder
         + ΔHresidual
         + ΔHnaturalStamp

Hfinal = Hnatural
       + ΔH_POI
       + ΔH_road
       + ΔH_runtime

This is not an original HD2 formula recovered from unpacked data. It is an engineering boundary: natural terrain, POI grounding, road shaping, and runtime destruction are recorded, validated, and synchronized separately.

The terms in the formula also have different maturity levels. The stage ownership of Hnatural is established, but its internals mix unpacked facts with evidence-constrained reconstruction. ΔH_POI is implemented in the existing Runtime/DS Gameplay Stamp baseline, while the new 25-POI combination has not yet been integrated item by item. ΔH_road is a reserved responsibility; the road result in this article does not prove that height shaping is complete. ΔH_runtime denotes a separate runtime-deformation layer and is not a completed item in this article.

The natural-terrain chain can be divided into three evidence classes. D means unpacked or direct asset evidence, R means a reconstruction constrained by that evidence, and U means that the original runtime behavior remains unknown.

Stage	D: direct fact	R: current reconstruction	U: still unknown
Region / SubRegion	Configuration relationships, ranges, and references	Continuous ownership and regional skeleton	Complete original selection and scheduling flow
HeightGroups / CornerHeights	Fields and hierarchy	Vertical relationships, boundary interpolation, and continuity conditioning	Original evaluation order and exact functions
StampGroup / StampInfo	Parent-child references and Circle/Rectangle support components	Support domains, falloff, grounding, and height proxies	Original height patches and blend functions
POI / road overlay	Cell footprints and Entry/Spline spatial data	POI platforms and regional-road interfaces	Original terrain adaptation and road-shaping flow

7. StampInfo Provides Geometric Support, Not the Original Height Shape

Unpacked StampInfo can contain two-dimensional support components such as Circle and Rectangle. These components provide position, size, rotation, and overlap relationships. They confirm which local ranges compose a Stamp, but they do not reveal an original height texture.

The Web tool therefore exposes two entry points. The Stamp browser inspects the component combinations in 2,416 valid Stamp configuration records; this does not mean that 2,416 original height patches were recovered. The height gallery interprets those two-dimensional components as continuous support domains and applies falloff, flat-top, shoulder, and grounding rules to build composable height proxies.

The proxy answers three engineering questions. Can the components form a continuous silhouette? Are parent and child Stamps organized inside the correct configuration-owned ranges? Does the blended local increment affect only the permitted support area? It cannot prove that the original HD2 runtime uses the same profile function, and Circle or Rectangle components must not be called recovered original heightmaps.

In Desert_Dune, the primary Stamp first attaches to an established support domain. Grounding removes floating or hard seams before child Stamps form a local cluster around it. Short ridges, shoulder fragments, and microstructures contribute only low-amplitude increments. They may be almost invisible in isolation, but together they change the local silhouette and slope rhythm.

This preserves an important responsibility boundary. Stamps add organized local morphology; they do not rebuild the map’s large-scale terrain. If real height patches or stronger runtime-ownership evidence become available, the proxy can be replaced without discarding the Region/SubRegion structure, parent-child ranges, or stage-based validation.

8. What Web, UE, Runtime, and DS Each Prove

Similar images from four environments do not mean that the environments prove the same thing.

Environment	Primary purpose	What it can prove now	What it cannot prove alone
Web	Fast inspection and stage replay	Configuration relationships, fixed-Seed execution, candidate filtering, spatial geometry, and terrain-stage behavior	UE asset lifecycle, production collision, or network consistency
UE editor	Asset and spatial comparison	Whether Cell, Entry, Spline, Landscape, and world coordinates correspond and remain editable	Packaged runtime and DS session behavior
UE runtime	Production consumption path	Whether terrain, POIs, and local modifications can be created and exposed to gameplay queries at runtime	Whether multiple clients enter the same result
Dedicated Server	Authoritative session	Whether a packaged server can arbitrate inputs, generate authoritative data, and drive clients into a consistent session	Whether the artistic morphology has reached final quality

This is why the loop retains all four entry points. A Web screenshot cannot replace Cell validation in the engine, and a client image cannot replace a server digest. Conversely, matching DS digests show that data agrees, not that POI pacing or terrain morphology is good.

The existing Runtime/DS baseline must also remain separate from this new layout. The previous article validated authoritative LayoutData, Gameplay Stamp ordering, LayoutDigest, all 256 Tile digests, and process-level DS/client consistency. That session used 18 Gameplay Stamps. The 25 POIs and new regional roads build on the same baseline path, but do not yet have equivalent end-to-end digest evidence.

Data or stage	Existing Runtime/DS baseline	New 25-POI / road status	Acceptance evidence
Session, Recipe, Final Seed	Integrated with the authoritative session	Reuses the same input boundary	Version, RecipeDigest, and Final Seed
LayoutData and Gameplay Stamp	Implemented; example session used 18 Gameplay Stamps	New POI list not yet integrated item by item	Stamp ID, position, order, and LayoutDigest
Field / Tile	DS and client verified with 256 matching Tile digests	Reusable path, but the new combination must be rerun	Every Tile digest matches and no FAIL is reported
New 25 POI IDs, positions, and orientations	Not part of the previous evidence	Reproducible in the Web tool; UE spatial consumption is under validation	Item-by-item digest and UE generation record remain pending
New regional-road topology	Not part of the previous evidence	Web reconstruction complete; Entry interface compared spatially	Runtime/DS digests for segments, endpoints, and connections remain pending

Here, “production loop” means that data ownership, tool entry points, and validation paths are connected. The new layout has not passed final network validation. Before it can be marked Runtime/DS complete, the server must report POI IDs, transforms, road endpoints, and connection relationships, and clients must acknowledge them item by item. Matching screenshots are not enough.

In the existing frozen Runtime/DS baseline, packaged-DS terrain generation completes in under ten seconds. This number does not include end-to-end validation of the new 25 POIs and regional roads. After integration, terrain generation, layout, roads, Cell creation, collision, and digest costs must be measured separately. The existing result supports functional multiplayer validation, but it is not a final performance target.

9. What Still Needs to Be Built

Designers, artists, and programmers can now discuss the same Seed and inspect the same stages. Four areas still need explicit, repeatable acceptance tests.

Gameplay and POI Semantics

Mission topology, regional themes, difficulty, resources, factions, primary/secondary pacing, and road relationships must enter selection and scoring. The search for direct evidence of the original HD2 runtime selector also continues. The next stage should evaluate at least 100 fixed Seeds for mission-topology completeness, critical-POI distribution, and road connectivity.

Art and Natural Terrain

Other biomes still require recovery, followed by materials, vegetation, road presentation, POI-to-surface blending, and more credible Stamp height assets. Acceptance should compare fixed Seeds at near, far, and multi-biome views, checking morphology continuity, material transitions, and the grounding of artificial structures separately.

Server and Network

DS generation budgets, authoritative collision, layout and road digests, reconnection, repair, and timeout paths must be measured independently. Acceptance should record server time, client digest match rate, state restoration after reconnection, and both successful and failed repair outcomes.

Client and Scene Performance

Actor count, draw calls, material complexity, HLOD, collision, streaming, queries, memory, loading, and frame time all need explicit budgets. Comparisons should include fixed-camera FPS, scene-object count, peak memory, peak streaming cost, and time to a playable state instead of reporting only one total duration.

Conclusion

This pass connects data interfaces from configuration to layout, roads, terrain, and engine tools. The existing Runtime/DS baseline has separate validation; the new 25-POI layout and regional roads still require equivalent end-to-end checks.

A Cell is no longer an icon on a map. It is a spatial asset with footprint components, orientation, Entry points, and internal Splines. Roads no longer default to center-to-center lines; they approach the access points designed into the asset. Natural terrain is not replaced by later Stamps or artificial shaping. Region/SubRegion first establishes a continuous foundation, and dependent local structure is added in later stages.

The limits are equally clear. POI selection and regional roads remain engineering reconstructions. Natural Stamp height is still a proxy constrained by unpacked geometry. The new 25-POI combination does not yet have item-by-item Runtime/DS digests. When stronger evidence arrives, only the unconfirmed modules should change; the working data structures, tools, and multiplayer validation path can stay in place.

The next step is to make the same Seed produce more than a consistent map: it should produce a level that can be built, verified, and played.

---

AI Collaboration Retrospective

The article was assembled from the project presentation, unpacked configuration, Web prototypes, and UE/DS validation records. AI helped organize the material, align terminology, and check evidence boundaries. Cell data, road endpoints, terrain stages, and runtime results still come from engineering data and engine captures. During review, the new 25-POI layout was separated from the older Runtime/DS baseline, and three open items were retained: exact Rectangle collision, the original regional-road algorithm, and the original natural-Stamp height functions.

---

Contact

Email: 30260955@qq.com

WeChat: traceplus