unreal-pcg

Unreal 5.8 PCG

Build and optimize procedural content graphs

---
name: unreal-pcg
description: Design, implement, optimize, automate, and debug Procedural Content Generation workflows in Unreal Engine 5.8. Use for PCG Graphs, points, density, metadata attributes, spatial data, samplers, filters, exclusion zones, Static Mesh Spawner, splines, graph parameters, subgraphs, editor tools, manual overrides, deterministic seeds, partitioned or hierarchical generation, runtime generation, PCG with World Partition/Data Layers/HLOD, GPU execution, procedural GPU instancing, PCG Builder commandlets, profiling, caching, validation, or PCG-based vegetation, roads, fences, buildings, biomes, and world population.
---

# Unreal 5.8 PCG

## Ownership boundary

This skill owns procedural sampling, graph data, generation, cleanup, and generated-output ownership.
Route source-path mechanics to [`unreal-splines`](../unreal-splines/SKILL.md), source-terrain
deformation/paint to [`unreal-landscape`](../unreal-landscape/SKILL.md), and World Partition cells,
streaming sources, Data Layers, and HLODs to
[`unreal-world-partition`](../unreal-world-partition/SKILL.md).

## Select generation ownership

- Use **editor generation** for authored world content that must persist, cook, build HLODs,
  support collision/navigation, or be manually reviewed before shipping.
- Use **non-partitioned generation** for bounded tools and small generation domains.
- Use **partitioned generation** when a large domain must split into streamable cells.
- Use **hierarchical generation** when large-scale shared work and small-scale detail require
  different grid sizes.
- Use **runtime generation** only when content genuinely depends on runtime sources/state and
  its generation, cleanup, memory, and visual-pop costs fit the target budget.
- Use GPU execution only after a representative CPU/GPU trace proves enough parallel work to
  amortize transfers and dispatch preparation.

Read [`references/system-selector.md`](references/system-selector.md) before choosing.

## Design the data contract first

1. Identify the spatial source: volume, surface, spline/line, points, actor data, or polygon.
2. Declare each metadata attribute's name, type, units, producer, consumer, and default.
3. Define stable seeds and which operations intentionally mutate them.
4. Separate selection data from spawn/presentation data.
5. Define exclusion/clearance rules before adding variation.
6. Choose output ownership: instances, Actors, data assets, or downstream graph data.
7. Decide what is authoritative, persisted, streamed, rebuilt, or disposable.

Read [`references/data-model-graph-design.md`](references/data-model-graph-design.md).

## Build in dependency order

1. Confirm the PCG plugin and any required interop plugins are enabled.
2. Create the smallest graph: input -> sample -> debug/inspect -> output.
3. Establish bounds, projection, point density, and deterministic seed behavior.
4. Filter invalid slopes, heights, surfaces, tags, and exclusion volumes.
5. Add transforms and mesh/actor selection through explicit attributes.
6. Spawn only after point data is correct.
7. Expose instance parameters and extract reusable subgraphs/templates.
8. Choose partition/hierarchy/runtime grids from content scale and streaming ownership.
9. Integrate Data Layers/HLOD and batch builders for persistent large-world output.
10. Profile node cost, scheduling, instance count, memory, CPU/GPU transfers, and visual pops.

Use [`references/sampling-spawning-patterns.md`](references/sampling-spawning-patterns.md),
[`references/parameters-tools-overrides.md`](references/parameters-tools-overrides.md), and
[`references/world-partition-integration.md`](references/world-partition-integration.md).

## Respect UE 5.8 maturity boundaries

- PCG Editor Mode is **Experimental**.
- UE 5.8's non-destructive manual editing/Data Override system is **Experimental**.
- PCG GPU Processing is **Beta**.
- GPU Procedural Instancing in the GPU Static Mesh Spawner path is **Experimental** and lacks
  persisted instances, collision, navigation, ray tracing, distance-field lighting, HLOD, and
  static baked-lighting support.
- PCG Biome Core/Sample remains **Experimental**; treat it as an example architecture.

Read [`references/gpu-processing.md`](references/gpu-processing.md).

## Required answer format

Return:

1. **Generation-mode and output-ownership choice**.
2. **Spatial/attribute/seed contract**.
3. **Ordered graph procedure** with exact node categories/names and parameter effects.
4. **Partition, hierarchy, runtime, Data Layer, and HLOD design** where applicable.
5. **Maturity and platform constraints** for editor/manual/GPU features.
6. **Debug views, validation cases, profiling captures, and regeneration test**.

Do not invent node names, defaults, supported GPU features, determinism, or performance wins.

## Hard rules

- Inspect points and attributes before spawning content.
- Keep graph parameters typed, named, documented, and instance-overridable only when intentional.
- Never rely on uncontrolled randomness; preserve a reproducible seed path.
- Do not use runtime PCG for content that can be baked without losing the required behavior.
- Do not alternate CPU/GPU nodes repeatedly; transfers can erase GPU gains.
- Do not use Experimental GPU instances when collision, nav, ray tracing, HLOD, or persistence is
  required.
- Never assume generated gameplay Actors replicate or become authoritative automatically.
- Preserve artist-authored/manual overrides through the supported override system; do not bake
  accidental edits into opaque graph logic.
- Cleanup, regenerate, cook, and test from a clean state before declaring a graph reliable.
- Profile on target hardware and at shipping content density.

Read [`references/runtime-scheduling.md`](references/runtime-scheduling.md),
[`references/debugging-validation.md`](references/debugging-validation.md), and
[`references/use-cases.md`](references/use-cases.md). See
[`references/sources.md`](references/sources.md) for the UE 5.8 source trail.

## Ownership boundary

This skill owns procedural sampling, graph data, generation, cleanup, and generated-output ownership.
Route source-path mechanics to [`unreal-splines`](/unreal/unreal-splines/), source-terrain
deformation/paint to [`unreal-landscape`](/unreal/unreal-landscape/), and World Partition cells,
streaming sources, Data Layers, and HLODs to
[`unreal-world-partition`](/unreal/unreal-world-partition/).

## Select generation ownership

- Use **editor generation** for authored world content that must persist, cook, build HLODs,
  support collision/navigation, or be manually reviewed before shipping.
- Use **non-partitioned generation** for bounded tools and small generation domains.
- Use **partitioned generation** when a large domain must split into streamable cells.
- Use **hierarchical generation** when large-scale shared work and small-scale detail require
  different grid sizes.
- Use **runtime generation** only when content genuinely depends on runtime sources/state and
  its generation, cleanup, memory, and visual-pop costs fit the target budget.
- Use GPU execution only after a representative CPU/GPU trace proves enough parallel work to
  amortize transfers and dispatch preparation.

Read [`references/system-selector.md`](/unreal/unreal-pcg/system-selector/) before choosing.

## Design the data contract first

1. Identify the spatial source: volume, surface, spline/line, points, actor data, or polygon.
2. Declare each metadata attribute's name, type, units, producer, consumer, and default.
3. Define stable seeds and which operations intentionally mutate them.
4. Separate selection data from spawn/presentation data.
5. Define exclusion/clearance rules before adding variation.
6. Choose output ownership: instances, Actors, data assets, or downstream graph data.
7. Decide what is authoritative, persisted, streamed, rebuilt, or disposable.

Read [`references/data-model-graph-design.md`](/unreal/unreal-pcg/data-model-graph-design/).

## Build in dependency order

1. Confirm the PCG plugin and any required interop plugins are enabled.
2. Create the smallest graph: input -> sample -> debug/inspect -> output.
3. Establish bounds, projection, point density, and deterministic seed behavior.
4. Filter invalid slopes, heights, surfaces, tags, and exclusion volumes.
5. Add transforms and mesh/actor selection through explicit attributes.
6. Spawn only after point data is correct.
7. Expose instance parameters and extract reusable subgraphs/templates.
8. Choose partition/hierarchy/runtime grids from content scale and streaming ownership.
9. Integrate Data Layers/HLOD and batch builders for persistent large-world output.
10. Profile node cost, scheduling, instance count, memory, CPU/GPU transfers, and visual pops.

Use [`references/sampling-spawning-patterns.md`](/unreal/unreal-pcg/sampling-spawning-patterns/),
[`references/parameters-tools-overrides.md`](/unreal/unreal-pcg/parameters-tools-overrides/), and
[`references/world-partition-integration.md`](/unreal/unreal-pcg/world-partition-integration/).

## Respect UE 5.8 maturity boundaries

- PCG Editor Mode is **Experimental**.
- UE 5.8's non-destructive manual editing/Data Override system is **Experimental**.
- PCG GPU Processing is **Beta**.
- GPU Procedural Instancing in the GPU Static Mesh Spawner path is **Experimental** and lacks
  persisted instances, collision, navigation, ray tracing, distance-field lighting, HLOD, and
  static baked-lighting support.
- PCG Biome Core/Sample remains **Experimental**; treat it as an example architecture.

Read [`references/gpu-processing.md`](/unreal/unreal-pcg/gpu-processing/).

## Required answer format

Return:

1. **Generation-mode and output-ownership choice**.
2. **Spatial/attribute/seed contract**.
3. **Ordered graph procedure** with exact node categories/names and parameter effects.
4. **Partition, hierarchy, runtime, Data Layer, and HLOD design** where applicable.
5. **Maturity and platform constraints** for editor/manual/GPU features.
6. **Debug views, validation cases, profiling captures, and regeneration test**.

Do not invent node names, defaults, supported GPU features, determinism, or performance wins.

## Hard rules

- Inspect points and attributes before spawning content.
- Keep graph parameters typed, named, documented, and instance-overridable only when intentional.
- Never rely on uncontrolled randomness; preserve a reproducible seed path.
- Do not use runtime PCG for content that can be baked without losing the required behavior.
- Do not alternate CPU/GPU nodes repeatedly; transfers can erase GPU gains.
- Do not use Experimental GPU instances when collision, nav, ray tracing, HLOD, or persistence is
  required.
- Never assume generated gameplay Actors replicate or become authoritative automatically.
- Preserve artist-authored/manual overrides through the supported override system; do not bake
  accidental edits into opaque graph logic.
- Cleanup, regenerate, cook, and test from a clean state before declaring a graph reliable.
- Profile on target hardware and at shipping content density.

Read [`references/runtime-scheduling.md`](/unreal/unreal-pcg/runtime-scheduling/),
[`references/debugging-validation.md`](/unreal/unreal-pcg/debugging-validation/), and
[`references/use-cases.md`](/unreal/unreal-pcg/use-cases/). See
[`references/sources.md`](/unreal/unreal-pcg/sources/) for the UE 5.8 source trail.

unreal 5.8 pcg design, implement, optimize, automate, and debug procedural content generation workflows in unreal engine 5.8. use for pcg graphs, points, density, metadata attributes, spatial data, samplers, filters, exclusion zones, static mesh spawner, splines, graph parameters, subgraphs, editor tools, manual overrides, deterministic seeds, partitioned or hierarchical generation, runtime generation, pcg with world partition/data layers/hlod, gpu execution, procedural gpu instancing, pcg builder commandlets, profiling, caching, validation, or pcg-based vegetation, roads, fences, buildings, biomes, and world population. data model and graph design data model and graph design pcg data shapes | shape | use | |---|---| | volume | bounded 3d domain and boolean/spatial sampling | | surface | landscape/2d domain projected into the world | | line | spline and landscape spline data | | point data | explicit candidates with transform, bounds, density, steepness, color, seed | | polygon 2d | closed planar areas and polygon union/intersection/difference | | composite data | lazy spatial union/intersection/difference before concretizing | | attribute set | nonspatial typed metadata/parameters | keep spatial operations lazy as long as useful; convert/sample to explicit points only when a downstream point operation or spawner requires it. point contract for every point stream, document: - coordinate space and projection surface; - bounds represented by each point; - density meaning and expected range [0,1]; - seed source and any mutate seed boundary; - required metadata attributes, types, units, and defaults; - whether transform scale is semantic size or spawn transform; - which node owns rejection versus presentation. point seeds are derived in part from position for world-position consistency. operations that duplicate points can also duplicate random behavior; use mutate seed where independent random branches are intentional. graph layering use a readable staged graph: text input and bounds -> sampling/projection -> environmental attributes -> hard filters and exclusion -> density/weight shaping -> selection attributes -> transform variation -> spawn/output name reroutes and comment the contract at each stage. delete temporary attributes before expensive copy/spawn operations when they are no longer needed. attribute rules - prefer semantic names such as surfaceslopedegrees, biomeid, mesh, clearancecm. - do not silently reuse one attribute with multiple units or meanings. - use graph parameters for tool-level inputs; use point attributes for per-point decisions. - use match and set attributes for data-driven selection tables and weighted choices. - use typed complex attributes in ue 5.8 only when downstream nodes/cook targets support them. determinism test generate, record point count/transforms/selected assets, cleanup, and regenerate with unchanged inputs. results must match wherever deterministic output is required. then change only the exposed seed and confirm intended variation changes without violating hard constraints. debugging, validation, and profiling debugging, validation, and profiling graph-debug procedure 1. enable node debug on the earliest suspicious stage. 2. inspect the data view and attributes list: count, bounds, density, transforms, seed, attributes. 3. move the debug point downstream one stage at a time. 4. disable spawners while validating data. 5. use graph/node profiling to identify cpu cost; use unreal insights for system-level cost. 6. cleanup and regenerate to eliminate stale output. runtime tools - pcg.runtimegeneration.enabledebugoverlay 1: scheduler/runtime overview. - pcg.graphexecution.debugdrawgeneratedcells 1: sources, generating cells, grid/coordinates. - pcg.runtimegeneration.enabledebugging: verbose scheduler logging. - pcg.runtimegeneration.refresh: cleanup and schedule regeneration. - pcg.runtimegeneration.enable: freeze/enable runtime generation. - pcg.gpu.fuzzmemory: expose uninitialized gpu output assumptions. debug overlays are not generally available in shipping and may differ by build configuration. validation matrix - empty input and zero points; - smallest and largest bounds; - steep/vertical/overhanging surfaces; - overlapping exclusion volumes and data layers; - seed zero, repeated seed, and changed seed; - missing asset/table row/soft reference; - cleanup -> regenerate -> reload -> cook; - source control clean checkout and commandlet generation; - target platform scalability/feature-level switches; - fast traversal/teleport and multiple runtime sources; - maximum shipping density plus hlod/nav/collision build where required. common failures | symptom | first check | |---|---| | points exist but nothing spawns | mesh/actor selector attribute, bounds, node enabled, output path | | same random choice repeats | duplicated seeds; place mutate seed at intentional branch | | content leaks into roads/buildings | exclusion input/bounds and difference mode/order | | graph regenerates constantly | tracked actor/component changes or circular dependencies | | runtime pop-in | generation radius, bounds modifier, scheduler budget, traversal speed | | cleanup leaves stale actors | generation ownership, partition actors, grid change cleanup sequence | | gpu path slower | transfers, small data, compute-graph fragmentation, preparation cost | | packaged result differs | editor-only input/node, unsupported platform path, unbuilt persistent output | performance record record point count, spawned instance/actor count, cpu node times, gpu execution/memory, generation latency percentile, cache memory, cleanup time, streaming overlap, and final render cost. pcg graph time alone does not include the lifetime cost of what it spawned. gpu processing gpu processing maturity - pcg gpu processing: beta in ue 5.8. - gpu execution is available only on a subset of nodes, including custom hlsl and supported point/ spawner operations. - gpu procedural instancing through gpu static mesh spawner: experimental. adoption procedure 1. profile the cpu graph and record node cost/point count. 2. confirm the target nodes support gpu execution on every shipping platform/feature level. 3. form one or a few long connected gpu compute regions. 4. minimize cpu -> gpu uploads and gpu -> cpu downloads. 5. compare end-to-end time, frame spikes, memory, and time-to-visible—not kernel time alone. 6. verify output equality/acceptable variation and regenerate under stress. 7. keep a cpu fallback or platform branch when coverage requires it. gpu setup and transfer have cpu cost. small data sets or graphs that bounce between cpu and gpu can be slower than cpu-only execution. experimental gpu procedural instances use only for runtime visual meshes that do not require: - persisted/saved instance data; - collision or physics; - navigation; - ray tracing; - distance-field lighting contribution; - static baked lighting; - hlod. these instances live only at runtime in gpu memory. a gpu visual forest is not automatically a walkable, collidable, nav-aware, hlod-buildable forest. custom hlsl - declare inputs/outputs and created attributes explicitly or use ue 5.8's supported source parsing path. - initialize every output; test with pcg.gpu.fuzzmemory to expose uninitialized memory use. - bound threads/data sizes and handle empty inputs. - use platform/feature-level switches for unsupported paths. - keep the hlsl contract documented beside the node; shader code is not self-validating. profiling ue 5.8 adds gpu execution time and gpu-created memory to the pcg profiling window. use platform gpu tools for kernel detail. runtime pcg is bursty; use profile kernel index only as a controlled profiling aid and disable it afterward. parameters, subgraphs, tools, and manual overrides parameters, subgraphs, tools, and manual overrides expose parameters deliberately expose only values that define a meaningful tool instance: - density/count target; - seed; - allowed slope/height; - clearance distance; - asset set or selection table; - scale/rotation range; - grid/runtime generation settings when instance variation is legitimate. give each parameter a category, order, description, unit, safe range, and default in ue 5.8's graph parameters hierarchy editor. do not expose internal scratch attributes. reuse hierarchy - use named subgraphs for reusable pipeline stages. - use ue 5.8 embedded subgraphs for graph-local function-like logic. - use graph instances for variations that share implementation but override parameters. - mark a graph as a template when it is a starting structure, not a live shared dependency. - keep the interface small; sprawling pins usually indicate missing stage boundaries. pcg editor mode pcg editor mode is experimental in ue 5.8. it provides draw spline, draw spline surface, paint, and volume tools driven by graphs/presets. for a tool graph: 1. set compatible tool tags (splinetool, splinesurfacetool, painttool, volumetool). 2. define the initial actor class and a clear spawned-actor/component naming policy. 3. expose only instance parameters the artist needs while interacting. 4. define raycast rules for landscapes, meshes, ignored pcg components, allowed classes, and selection constraints. 5. test apply, cancel, undo/redo, reload, source control, and regeneration. ue 5.8 manual editing/data overrides the new non-destructive manual-editing/data override system is experimental. - mark only the node/output that owns artist-editable data for manual editing. - use selection, exclusion, modification, and restore rather than detaching the whole result. - inspect all overrides in the data overrides window. - define team policy: override intent, author, and whether it survives graph regeneration. - verify overrides after upstream graph edits, cleanup/regenerate, map reload, cook, and merge. - prefer a source input/exclusion layer when an exception is systemic; reserve manual overrides for genuine local art direction. do not silently convert override data into graph constants or delete it during cleanup. runtime generation and scheduling runtime generation and scheduling configure runtime generation 1. set the pcg component generation trigger to generate at runtime. 2. enable hierarchical generation if multiple grid scales are required. 3. configure generation radius for each grid size. 4. configure cleanup radius multiplier so content is not destroyed immediately at the generation boundary. 5. use generate/cleanup bounds modifiers to begin work before the source looks toward content and reduce visible pops. 6. define generation sources: player/camera, editor viewport for testing, or custom sources. 7. choose a scheduling policy from actual traversal direction, distance, and urgency needs. 8. test source teleport, rapid direction reversal, fast vehicles, multiple players/sources, and no-source cleanup. budget controls relevant ue 5.8 variables include: - pcg.frametime: runtime pcg execution budget in milliseconds. - pcg.runtimegeneration.numgeneratingcomponents: parallel generating components. - pcg.runtimegeneration.framesbetweengraphschedules: scheduler delay between schedule passes. - pcg.runtimegeneration.enablepooling: partition-actor pooling. - pcg.cache.runtime.enabled: runtime cpu-node cache; disabled by default. - pcg.cache.runtime.memorybudgetmb: runtime cache memory cap. do not copy documented defaults blindly. tune on target hardware for time-to-screen, hitching, memory, and background contention with gameplay/streaming. failure policy define behavior when generation is late: - hide with fog/distance/occlusion; - preserve lower-detail/baked fallback; - prevent access until generation completes; - reduce small-grid detail before missing large silhouette content; - prioritize forward/travel-direction cells. do not let missing collision or gameplay actors become a visual-pop problem; that is a correctness failure. multiplayer pcg output is not automatically authoritative or replicated. choose explicitly: - identical local cosmetic generation from controlled inputs/seeds; - server-generated replicated gameplay actors; - baked/persisted world content streamed normally; - server-authored compact state that each client converts into local presentation. test determinism across builds/platforms before relying on identical local generation for anything more than cosmetic presentation. sampling, filtering, and spawning sampling, filtering, and spawning surface scatter procedure 1. obtain actor/landscape/surface data within explicit component bounds. 2. use surface sampler or the appropriate sampler to produce candidate points. 3. project/re-project after transforms that move points off the target surface. 4. compute slope, height, surface type/tag, density, and clearance attributes. 5. apply hard filters before random thinning. 6. subtract roads, structures, water, paths, and gameplay-clearance shapes with difference or point filters. 7. use density/weights for natural distribution and mesh choice. 8. transform points within bounded rotation/scale ranges. 9. inspect points and bounds before static mesh spawner/spawn actor. exclusion and spacing - use spatial difference for clear exclusion shapes. - use distance to create a gradient near another point set; filter/remap the result. - use self pruning or neighborhood logic for overlap/spacing, choosing bounds and pruning order intentionally. - account for final mesh bounds, not only pivot distance. - keep critical traversal and gameplay sightlines as hard constraints, never probability alone. mesh selection - drive mesh/material/scale selection from explicit attributes or weighted selector data. - use data tables/attribute sets plus match and set attributes for editable catalogs. - keep asset references soft/async where the generation and loading model requires it. - prefer instancing for repeated static meshes; use actors only when actor behavior is required. spline pattern 1. get spline data from the intended actor/component. 2. sample by distance, subdivision, or control-point semantics appropriate to the asset. 3. write tangent/orientation/width/side attributes. 4. offset or project candidates. 5. exclude intersections and invalid surface regions. 6. spawn fence posts, roadside objects, or downstream spline/mesh data. use shape grammar when a repeatable module grammar materially simplifies fences/buildings; do not force grammar onto free-form scatter. spawn-output selector | output | use | |---|---| | ism/hism/static mesh spawner | repeated static visual content | | spawn actor | behavior, identity, components, or independent lifecycle required | | output node data | downstream pcg component/subgraph consumes points/attributes | | pcg data asset | reusable baked data exchange | do not spawn thousands of actors for decoration. do not use gpu procedural instances for outputs that need collision, nav, hlod, persistence, ray tracing, or distance fields. ue 5.8 primary sources ue 5.8 primary sources all links were checked against epic's ue 5.8 documentation on 2026-07-19. core framework - pcg framework - pcg overview - pcg data types reference - pcg node reference - pcg generation modes ue 5.8 workflows and performance - ue 5.8 release notes: pcg - pcg editor mode - pcg with gpu processing - pcg runtime generation debugging - shape grammar with pcg - pcg biome core overview large-world integration and automation - pcg with world partition - world partition builder commandlets - working with pcg and llms using unreal mcp ue 5.8 maturity notes - pcg editor mode and the new manual data override system are experimental. - pcg gpu processing is beta. - gpu procedural instancing and pcg biome core/sample are experimental. pcg system selector pcg system selector choose the generation mode | need | mode | cost/constraint | |---|---|---| | small bounded authoring tool | non-partitioned editor generation | simplest; one component domain | | large persistent generated area | partitioned editor generation | grid cells integrate with streaming | | multiple detail scales | hierarchical generation | shared large-grid work feeds smaller grids | | viewer/source-dependent transient content | runtime generation | scheduler, memory, cleanup, and pop budget | pcg generation modes are not visual-quality settings. select them from domain size, update frequency, output lifetime, and streaming requirements. bake versus runtime prefer editor-generated/baked output when content needs: - manual art review and source-control visibility; - hlod or static baked lighting; - persistent instance data; - collision, navigation, ray tracing, or distance-field participation; - deterministic cook output without runtime generation stalls. use runtime generation when player position, runtime terrain/state, or effectively unbounded content makes baking impractical. runtime generation must define generation sources, radii, cleanup radii, scheduling policy, memory/caching, and what happens when generation falls behind. partitioned versus hierarchical - partitioned generation divides one component's domain into pcg grid cells. - hierarchical generation lets branches execute at different grid sizes through grid size nodes. - put broad, reusable calculations on larger grids and dense local detail on smaller grids. - data produced on a larger hierarchical grid is cached for smaller-grid execution. - choose cell/grid size from content size and cost, not one universal number. cpu versus gpu stay on cpu for small point counts, frequent cpu consumers, actor spawning, unsupported nodes, or when transfer overhead dominates. evaluate gpu when long connected gpu-capable regions process enough points to amortize upload/download and compute-graph setup. pcg gpu processing is beta. gpu procedural instancing is a narrower experimental output path with major persistence and feature limitations. see gpu-processing.md. related skills - route world partition/data layer/hlod ownership to $unreal-world-partition. - route spline construction and spline meshes to $unreal-splines. - route asset definitions/soft loading to the future unreal-data-assets-tables skill. - route final bottleneck work to $unreal-insights-profiling when available. use cases use cases vegetation scatter - landscape/surface -> slope/height/surface attributes -> road/water/poi difference -> density noise -> weighted species selection -> bounded transform -> instanced mesh spawn. - partition/hierarchy by plant scale: trees on larger grids, grass/flowers/stones on smaller. - keep gameplay clearance, landmarks, paths, and sightlines as hard filters. - use persistent cpu instances when hlod/collision/nav are required; gpu instances only for the supported purely visual runtime case. roadside/fence generator - spline input -> distance sampling -> tangent/side/width -> terrain projection -> intersection/ endpoint rules -> post/module selection -> spawn. - use shape grammar for repeating modules and corner/end pieces when rules stay legible. - route spline deformation/mesh segment details to $unreal-splines. building/city blocks - polygon 2d city boundary -> cut/subdivide by splines -> offset for setbacks -> create surfaces -> sample parcels -> attribute-driven building archetype -> spawn actor/level instance. - keep roads and utility corridors as source geometry, not late random exclusions. - validate entrances, navigation, collision, streaming ownership, and hlod output. biome architecture - separate climate/biome classification, broad distribution, species selection, local exclusion, and spawn into subgraphs. - use data assets/tables for species rules and weights. - pcg biome core is experimental; mine it for patterns rather than treating it as a production guarantee. authored exceptions - use input splines/volumes/tags for repeatable design rules. - use ue 5.8 manual overrides for isolated art-directed exceptions only after accepting the experimental status and defining merge/regeneration policy. - if the same override occurs repeatedly, promote it into graph input or rule data. acceptance test for any generator the generator must produce valid constraints across at least ten representative seeds, regenerate identically for a fixed seed/input, survive cleanup/reload/cook, remain editable by intended creators, and meet total runtime/render/streaming budgets on target hardware. world partition integration world partition integration ownership model treat the systems as separate layers: - pcg decides what data/content to generate. - pcg partition/hierarchy decides where and at what generation grid work executes. - world partition decides which persisted actors/cells stream. - data layers decide which authored/runtime content set is loaded or activated. - hlod decides what distant proxy represents unloaded source content. do not assume pcg grid size and world partition runtime cell size are the same setting or must match one-to-one. persistent generated content 1. choose partitioned/hierarchical editor generation for the large domain. 2. assign the source pcg actor/component to the intended data layer and hlod layer. 3. configure spawn actor/create target actor data layer source type intentionally. self inherits source-component data layers. 4. generate and inspect actor/data layer/hlod assignment. 5. build hlods after stable generation. 6. cleanup and regenerate after grid changes; stale partition actors are not evidence of the new configuration. 7. run the pcg world partition builder commandlet from a clean source state for reproducibility. pcg-generated actors assigned through the source asset inherit matching data layer/hlod ownership according to the documented integration path. runtime generation in a partitioned world - define runtime pcg generation sources independently from world partition streaming sources. - set generation and cleanup radii by pcg grid level. - ensure world partition cells and required source data load early enough for generation. - prewarm teleport destinations before player arrival; verify both streaming completion and pcg generation completion rather than assuming one implies the other. - keep gameplay-critical collision/nav content persisted or use a runtime path that explicitly supports and finishes it before access. data layer transitions if pcg content follows a runtime data layer: 1. server/gameplay authority changes the data layer state in networked play. 2. separate loaded from activated behavior. 3. test generated content cleanup/reappearance through state changes. 4. measure the burst; activating many assets/layers together can degrade streaming performance. route detailed streaming, data layer, and hlod configuration to $unreal-world-partition.

Data model and graph design

# Data model and graph design

## PCG data shapes

| Shape | Use |
|---|---|
| Volume | bounded 3D domain and boolean/spatial sampling |
| Surface | landscape/2D domain projected into the world |
| Line | Spline and Landscape Spline data |
| Point Data | explicit candidates with transform, bounds, density, steepness, color, seed |
| Polygon 2D | closed planar areas and polygon union/intersection/difference |
| Composite Data | lazy spatial union/intersection/difference before concretizing |
| Attribute Set | nonspatial typed metadata/parameters |

Keep spatial operations lazy as long as useful; convert/sample to explicit points only when a
downstream point operation or spawner requires it.

## Point contract

For every point stream, document:

- coordinate space and projection surface;
- bounds represented by each point;
- density meaning and expected range `[0,1]`;
- seed source and any `Mutate Seed` boundary;
- required metadata attributes, types, units, and defaults;
- whether transform scale is semantic size or spawn transform;
- which node owns rejection versus presentation.

Point seeds are derived in part from position for world-position consistency. Operations that
duplicate points can also duplicate random behavior; use `Mutate Seed` where independent random
branches are intentional.

## Graph layering

Use a readable staged graph:

```text
Input and bounds
  -> Sampling/projection
  -> Environmental attributes
  -> Hard filters and exclusion
  -> Density/weight shaping
  -> Selection attributes
  -> Transform variation
  -> Spawn/output
```

Name reroutes and comment the contract at each stage. Delete temporary attributes before expensive
copy/spawn operations when they are no longer needed.

## Attribute rules

- Prefer semantic names such as `SurfaceSlopeDegrees`, `BiomeId`, `Mesh`, `ClearanceCm`.
- Do not silently reuse one attribute with multiple units or meanings.
- Use graph parameters for tool-level inputs; use point attributes for per-point decisions.
- Use `Match And Set Attributes` for data-driven selection tables and weighted choices.
- Use typed complex attributes in UE 5.8 only when downstream nodes/cook targets support them.

## Determinism test

Generate, record point count/transforms/selected assets, cleanup, and regenerate with unchanged
inputs. Results must match wherever deterministic output is required. Then change only the exposed
seed and confirm intended variation changes without violating hard constraints.

Debugging, validation, and profiling

# Debugging, validation, and profiling

## Graph-debug procedure

1. Enable node Debug on the earliest suspicious stage.
2. Inspect the Data View and Attributes List: count, bounds, density, transforms, seed, attributes.
3. Move the debug point downstream one stage at a time.
4. Disable spawners while validating data.
5. Use graph/node profiling to identify CPU cost; use Unreal Insights for system-level cost.
6. Cleanup and regenerate to eliminate stale output.

## Runtime tools

- `pcg.RuntimeGeneration.EnableDebugOverlay 1`: scheduler/runtime overview.
- `pcg.GraphExecution.DebugDrawGeneratedCells 1`: sources, generating cells, grid/coordinates.
- `pcg.RuntimeGeneration.EnableDebugging`: verbose scheduler logging.
- `pcg.RuntimeGeneration.Refresh`: cleanup and schedule regeneration.
- `pcg.RuntimeGeneration.Enable`: freeze/enable runtime generation.
- `pcg.GPU.FuzzMemory`: expose uninitialized GPU output assumptions.

Debug overlays are not generally available in Shipping and may differ by build configuration.

## Validation matrix

- empty input and zero points;
- smallest and largest bounds;
- steep/vertical/overhanging surfaces;
- overlapping exclusion volumes and Data Layers;
- seed zero, repeated seed, and changed seed;
- missing asset/table row/soft reference;
- cleanup -> regenerate -> reload -> cook;
- source control clean checkout and commandlet generation;
- target platform scalability/feature-level switches;
- fast traversal/teleport and multiple runtime sources;
- maximum shipping density plus HLOD/nav/collision build where required.

## Common failures

| Symptom | First check |
|---|---|
| Points exist but nothing spawns | mesh/actor selector attribute, bounds, node enabled, output path |
| Same random choice repeats | duplicated seeds; place `Mutate Seed` at intentional branch |
| Content leaks into roads/buildings | exclusion input/bounds and Difference mode/order |
| Graph regenerates constantly | tracked actor/component changes or circular dependencies |
| Runtime pop-in | generation radius, bounds modifier, scheduler budget, traversal speed |
| Cleanup leaves stale actors | generation ownership, partition actors, grid change cleanup sequence |
| GPU path slower | transfers, small data, compute-graph fragmentation, preparation cost |
| Packaged result differs | editor-only input/node, unsupported platform path, unbuilt persistent output |

## Performance record

Record point count, spawned instance/Actor count, CPU node times, GPU execution/memory, generation
latency percentile, cache memory, cleanup time, streaming overlap, and final render cost. PCG graph
time alone does not include the lifetime cost of what it spawned.

GPU processing

# GPU processing

## Maturity

- PCG GPU Processing: **Beta** in UE 5.8.
- GPU execution is available only on a subset of nodes, including Custom HLSL and supported point/
  spawner operations.
- GPU Procedural Instancing through GPU Static Mesh Spawner: **Experimental**.

## Adoption procedure

1. Profile the CPU graph and record node cost/point count.
2. Confirm the target nodes support GPU execution on every shipping platform/feature level.
3. Form one or a few long connected GPU compute regions.
4. Minimize CPU -> GPU uploads and GPU -> CPU downloads.
5. Compare end-to-end time, frame spikes, memory, and time-to-visible—not kernel time alone.
6. Verify output equality/acceptable variation and regenerate under stress.
7. Keep a CPU fallback or platform branch when coverage requires it.

GPU setup and transfer have CPU cost. Small data sets or graphs that bounce between CPU and GPU
can be slower than CPU-only execution.

## Experimental GPU procedural instances

Use only for runtime visual meshes that do **not** require:

- persisted/saved instance data;
- collision or physics;
- navigation;
- ray tracing;
- distance-field lighting contribution;
- static baked lighting;
- HLOD.

These instances live only at runtime in GPU memory. A GPU visual forest is not automatically a
walkable, collidable, nav-aware, HLOD-buildable forest.

## Custom HLSL

- Declare inputs/outputs and created attributes explicitly or use UE 5.8's supported source
  parsing path.
- Initialize every output; test with `pcg.GPU.FuzzMemory` to expose uninitialized memory use.
- Bound threads/data sizes and handle empty inputs.
- Use platform/feature-level switches for unsupported paths.
- Keep the HLSL contract documented beside the node; shader code is not self-validating.

## Profiling

UE 5.8 adds GPU execution time and GPU-created memory to the PCG Profiling window. Use platform GPU
tools for kernel detail. Runtime PCG is bursty; use Profile Kernel Index only as a controlled
profiling aid and disable it afterward.

# Parameters, subgraphs, tools, and manual overrides

## Expose parameters deliberately

Expose only values that define a meaningful tool instance:

- density/count target;
- seed;
- allowed slope/height;
- clearance distance;
- asset set or selection table;
- scale/rotation range;
- grid/runtime generation settings when instance variation is legitimate.

Give each parameter a category, order, description, unit, safe range, and default in UE 5.8's
Graph Parameters hierarchy editor. Do not expose internal scratch attributes.

## Reuse hierarchy

- Use named subgraphs for reusable pipeline stages.
- Use UE 5.8 embedded subgraphs for graph-local function-like logic.
- Use graph instances for variations that share implementation but override parameters.
- Mark a graph as a template when it is a starting structure, not a live shared dependency.
- Keep the interface small; sprawling pins usually indicate missing stage boundaries.

## PCG Editor Mode

PCG Editor Mode is Experimental in UE 5.8. It provides Draw Spline, Draw Spline Surface, Paint,
and Volume tools driven by graphs/presets.

For a tool graph:

1. Set compatible tool tags (`SplineTool`, `SplineSurfaceTool`, `PaintTool`, `VolumeTool`).
2. Define the initial actor class and a clear spawned-actor/component naming policy.
3. Expose only instance parameters the artist needs while interacting.
4. Define raycast rules for landscapes, meshes, ignored PCG components, allowed classes, and
   selection constraints.
5. Test Apply, Cancel, undo/redo, reload, source control, and regeneration.

## UE 5.8 manual editing/data overrides

The new non-destructive manual-editing/Data Override system is Experimental.

- Mark only the node/output that owns artist-editable data for manual editing.
- Use selection, exclusion, modification, and restore rather than detaching the whole result.
- Inspect all overrides in the Data Overrides window.
- Define team policy: override intent, author, and whether it survives graph regeneration.
- Verify overrides after upstream graph edits, cleanup/regenerate, map reload, cook, and merge.
- Prefer a source input/exclusion layer when an exception is systemic; reserve manual overrides
  for genuine local art direction.

Do not silently convert override data into graph constants or delete it during cleanup.

Runtime generation and scheduling

# Runtime generation and scheduling

## Configure runtime generation

1. Set the PCG Component Generation Trigger to Generate at Runtime.
2. Enable Hierarchical Generation if multiple grid scales are required.
3. Configure generation radius for each grid size.
4. Configure Cleanup Radius Multiplier so content is not destroyed immediately at the generation
   boundary.
5. Use Generate/Cleanup Bounds Modifiers to begin work before the source looks toward content and
   reduce visible pops.
6. Define generation sources: player/camera, editor viewport for testing, or custom sources.
7. Choose a scheduling policy from actual traversal direction, distance, and urgency needs.
8. Test source teleport, rapid direction reversal, fast vehicles, multiple players/sources, and
   no-source cleanup.

## Budget controls

Relevant UE 5.8 variables include:

- `pcg.FrameTime`: runtime PCG execution budget in milliseconds.
- `pcg.RuntimeGeneration.NumGeneratingComponents`: parallel generating components.
- `pcg.RuntimeGeneration.FramesBetweenGraphSchedules`: scheduler delay between schedule passes.
- `pcg.RuntimeGeneration.EnablePooling`: partition-actor pooling.
- `pcg.Cache.Runtime.Enabled`: runtime CPU-node cache; disabled by default.
- `pcg.Cache.Runtime.MemoryBudgetMB`: runtime cache memory cap.

Do not copy documented defaults blindly. Tune on target hardware for time-to-screen, hitching,
memory, and background contention with gameplay/streaming.

## Failure policy

Define behavior when generation is late:

- hide with fog/distance/occlusion;
- preserve lower-detail/baked fallback;
- prevent access until generation completes;
- reduce small-grid detail before missing large silhouette content;
- prioritize forward/travel-direction cells.

Do not let missing collision or gameplay Actors become a visual-pop problem; that is a correctness
failure.

## Multiplayer

PCG output is not automatically authoritative or replicated. Choose explicitly:

- identical local cosmetic generation from controlled inputs/seeds;
- server-generated replicated gameplay Actors;
- baked/persisted world content streamed normally;
- server-authored compact state that each client converts into local presentation.

Test determinism across builds/platforms before relying on identical local generation for anything
more than cosmetic presentation.

Sampling, filtering, and spawning

# Sampling, filtering, and spawning

## Surface scatter procedure

1. Obtain actor/landscape/surface data within explicit component bounds.
2. Use Surface Sampler or the appropriate sampler to produce candidate points.
3. Project/re-project after transforms that move points off the target surface.
4. Compute slope, height, surface type/tag, density, and clearance attributes.
5. Apply hard filters before random thinning.
6. Subtract roads, structures, water, paths, and gameplay-clearance shapes with Difference or
   point filters.
7. Use density/weights for natural distribution and mesh choice.
8. Transform points within bounded rotation/scale ranges.
9. Inspect points and bounds before Static Mesh Spawner/Spawn Actor.

## Exclusion and spacing

- Use spatial Difference for clear exclusion shapes.
- Use Distance to create a gradient near another point set; filter/remap the result.
- Use Self Pruning or neighborhood logic for overlap/spacing, choosing bounds and pruning order
  intentionally.
- Account for final mesh bounds, not only pivot distance.
- Keep critical traversal and gameplay sightlines as hard constraints, never probability alone.

## Mesh selection

- Drive mesh/material/scale selection from explicit attributes or weighted selector data.
- Use Data Tables/Attribute Sets plus `Match And Set Attributes` for editable catalogs.
- Keep asset references soft/async where the generation and loading model requires it.
- Prefer instancing for repeated static meshes; use Actors only when Actor behavior is required.

## Spline pattern

1. Get Spline Data from the intended actor/component.
2. Sample by distance, subdivision, or control-point semantics appropriate to the asset.
3. Write tangent/orientation/width/side attributes.
4. Offset or project candidates.
5. Exclude intersections and invalid surface regions.
6. Spawn fence posts, roadside objects, or downstream spline/mesh data.

Use Shape Grammar when a repeatable module grammar materially simplifies fences/buildings; do not
force grammar onto free-form scatter.

## Spawn-output selector

| Output | Use |
|---|---|
| ISM/HISM/static mesh spawner | repeated static visual content |
| Spawn Actor | behavior, identity, components, or independent lifecycle required |
| Output node data | downstream PCG component/subgraph consumes points/attributes |
| PCG Data Asset | reusable baked data exchange |

Do not spawn thousands of Actors for decoration. Do not use GPU procedural instances for outputs
that need collision, nav, HLOD, persistence, ray tracing, or distance fields.

UE 5.8 primary sources

# UE 5.8 primary sources

All links were checked against Epic's UE 5.8 documentation on 2026-07-19.

## Core framework

- [PCG framework](https://dev.epicgames.com/documentation/en-us/unreal-engine/procedural-content-generation-framework-in-unreal-engine)
- [PCG overview](https://dev.epicgames.com/documentation/en-us/unreal-engine/procedural-content-generation-overview)
- [PCG data types reference](https://dev.epicgames.com/documentation/en-us/unreal-engine/procedural-content-generation-framework-data-types-reference-in-unreal-engine)
- [PCG node reference](https://dev.epicgames.com/documentation/en-us/unreal-engine/procedural-content-generation-framework-node-reference-in-unreal-engine)
- [PCG generation modes](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-pcg-generation-modes-in-unreal-engine)

## UE 5.8 workflows and performance

- [UE 5.8 release notes: PCG](https://dev.epicgames.com/documentation/unreal-engine/unreal-engine-5-8-release-notes?lang=en-US)
- [PCG Editor Mode](https://dev.epicgames.com/documentation/en-us/unreal-engine/pcg-editor-mode-in-unreal-engine)
- [PCG with GPU Processing](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-pcg-with-gpu-processing-in-unreal-engine)
- [PCG Runtime Generation Debugging](https://dev.epicgames.com/documentation/en-us/unreal-engine/pcg-runtime-generation-debugging-in-unreal-engine)
- [Shape Grammar with PCG](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-shape-grammar-with-pcg-in-unreal-engine)
- [PCG Biome Core overview](https://dev.epicgames.com/documentation/en-us/unreal-engine/procedural-content-generation-pcg-biome-core-and-sample-plugins-overview-guide-in-unreal-engine)

## Large-world integration and automation

- [PCG with World Partition](https://dev.epicgames.com/documentation/en-us/unreal-engine/using-pcg-with-world-partition-in-unreal-engine)
- [World Partition Builder commandlets](https://dev.epicgames.com/documentation/en-us/unreal-engine/world-partition-builder-commandlet-reference)
- [Working with PCG and LLMs using Unreal MCP](https://dev.epicgames.com/documentation/unreal-engine/working-with-pcg-and-llms-using-unreal-mcp-in-unreal-engine)

## UE 5.8 maturity notes

- PCG Editor Mode and the new manual Data Override system are Experimental.
- PCG GPU Processing is Beta.
- GPU Procedural Instancing and PCG Biome Core/Sample are Experimental.

PCG system selector

# PCG system selector

## Choose the generation mode

| Need | Mode | Cost/constraint |
|---|---|---|
| Small bounded authoring tool | Non-partitioned editor generation | simplest; one component domain |
| Large persistent generated area | Partitioned editor generation | grid cells integrate with streaming |
| Multiple detail scales | Hierarchical generation | shared large-grid work feeds smaller grids |
| Viewer/source-dependent transient content | Runtime generation | scheduler, memory, cleanup, and pop budget |

PCG generation modes are not visual-quality settings. Select them from domain size, update
frequency, output lifetime, and streaming requirements.

## Bake versus runtime

Prefer editor-generated/baked output when content needs:

- manual art review and source-control visibility;
- HLOD or static baked lighting;
- persistent instance data;
- collision, navigation, ray tracing, or distance-field participation;
- deterministic cook output without runtime generation stalls.

Use runtime generation when player position, runtime terrain/state, or effectively unbounded
content makes baking impractical. Runtime generation must define generation sources, radii,
cleanup radii, scheduling policy, memory/caching, and what happens when generation falls behind.

## Partitioned versus hierarchical

- Partitioned generation divides one component's domain into PCG grid cells.
- Hierarchical generation lets branches execute at different grid sizes through Grid Size nodes.
- Put broad, reusable calculations on larger grids and dense local detail on smaller grids.
- Data produced on a larger hierarchical grid is cached for smaller-grid execution.
- Choose cell/grid size from content size and cost, not one universal number.

## CPU versus GPU

Stay on CPU for small point counts, frequent CPU consumers, Actor spawning, unsupported nodes, or
when transfer overhead dominates. Evaluate GPU when long connected GPU-capable regions process
enough points to amortize upload/download and compute-graph setup.

PCG GPU Processing is Beta. GPU procedural instancing is a narrower Experimental output path with
major persistence and feature limitations. See `gpu-processing.md`.

## Related skills

- Route World Partition/Data Layer/HLOD ownership to `$unreal-world-partition`.
- Route spline construction and spline meshes to `$unreal-splines`.
- Route asset definitions/soft loading to the future `unreal-data-assets-tables` skill.
- Route final bottleneck work to `$unreal-insights-profiling` when available.

Use cases

# Use cases

## Vegetation scatter

- Landscape/surface -> slope/height/surface attributes -> road/water/POI Difference -> density
  noise -> weighted species selection -> bounded transform -> instanced mesh spawn.
- Partition/hierarchy by plant scale: trees on larger grids, grass/flowers/stones on smaller.
- Keep gameplay clearance, landmarks, paths, and sightlines as hard filters.
- Use persistent CPU instances when HLOD/collision/nav are required; GPU instances only for the
  supported purely visual runtime case.

## Roadside/fence generator

- Spline input -> distance sampling -> tangent/side/width -> terrain projection -> intersection/
  endpoint rules -> post/module selection -> spawn.
- Use Shape Grammar for repeating modules and corner/end pieces when rules stay legible.
- Route spline deformation/mesh segment details to `$unreal-splines`.

## Building/city blocks

- Polygon 2D city boundary -> cut/subdivide by splines -> offset for setbacks -> create surfaces ->
  sample parcels -> attribute-driven building archetype -> Spawn Actor/Level Instance.
- Keep roads and utility corridors as source geometry, not late random exclusions.
- Validate entrances, navigation, collision, streaming ownership, and HLOD output.

## Biome architecture

- Separate climate/biome classification, broad distribution, species selection, local exclusion,
  and spawn into subgraphs.
- Use Data Assets/Tables for species rules and weights.
- PCG Biome Core is Experimental; mine it for patterns rather than treating it as a production
  guarantee.

## Authored exceptions

- Use input splines/volumes/tags for repeatable design rules.
- Use UE 5.8 manual overrides for isolated art-directed exceptions only after accepting the
  Experimental status and defining merge/regeneration policy.
- If the same override occurs repeatedly, promote it into graph input or rule data.

## Acceptance test for any generator

The generator must produce valid constraints across at least ten representative seeds, regenerate
identically for a fixed seed/input, survive cleanup/reload/cook, remain editable by intended
creators, and meet total runtime/render/streaming budgets on target hardware.

World Partition integration

# World Partition integration

## Ownership model

Treat the systems as separate layers:

- PCG decides **what** data/content to generate.
- PCG partition/hierarchy decides **where and at what generation grid** work executes.
- World Partition decides **which persisted actors/cells stream**.
- Data Layers decide **which authored/runtime content set is loaded or activated**.
- HLOD decides **what distant proxy represents unloaded source content**.

Do not assume PCG grid size and World Partition runtime cell size are the same setting or must
match one-to-one.

## Persistent generated content

1. Choose partitioned/hierarchical editor generation for the large domain.
2. Assign the source PCG actor/component to the intended Data Layer and HLOD Layer.
3. Configure Spawn Actor/Create Target Actor Data Layer Source Type intentionally. `Self` inherits
   source-component Data Layers.
4. Generate and inspect actor/Data Layer/HLOD assignment.
5. Build HLODs after stable generation.
6. Cleanup and regenerate after grid changes; stale partition actors are not evidence of the new
   configuration.
7. Run the PCG World Partition Builder commandlet from a clean source state for reproducibility.

PCG-generated actors assigned through the source asset inherit matching Data Layer/HLOD ownership
according to the documented integration path.

## Runtime generation in a partitioned world

- Define runtime PCG generation sources independently from World Partition streaming sources.
- Set generation and cleanup radii by PCG grid level.
- Ensure World Partition cells and required source data load early enough for generation.
- Prewarm teleport destinations before player arrival; verify both streaming completion and PCG
  generation completion rather than assuming one implies the other.
- Keep gameplay-critical collision/nav content persisted or use a runtime path that explicitly
  supports and finishes it before access.

## Data Layer transitions

If PCG content follows a Runtime Data Layer:

1. Server/gameplay authority changes the Data Layer state in networked play.
2. Separate Loaded from Activated behavior.
3. Test generated content cleanup/reappearance through state changes.
4. Measure the burst; activating many assets/layers together can degrade streaming performance.

Route detailed streaming, Data Layer, and HLOD configuration to `$unreal-world-partition`.