The PCG framework in Unreal Engine has always had an identity problem. On paper, it is a visual scripting system for procedural content generation. In practice, through UE 5.4 and 5.5, it felt more like a back-end system that happened to have a graph editor bolted on. You built graphs, attached them to actors, and pressed Generate. There was no direct manipulation. No painting. No drawing. If you wanted to interactively place procedural content in your level, you needed to hack together workarounds involving spline components, manual point placement, and a lot of patience.

UE 5.7's PCG Editor Mode changes this. It transforms PCG from a "set it and forget it" generation framework into something that feels like an actual tool — the kind of tool you would build in Houdini Engine for your artists, except it runs natively inside the Unreal Editor with no external dependencies.

This post walks through what PCG Editor Mode actually is, how its new interaction primitives work, and how to build three practical procedural tools using nothing but PCG graphs. We will also cover where PCG Editor Mode fits alongside dedicated tools like the Procedural Placement Tool, because they solve overlapping but different problems.

What PCG Editor Mode Actually Is

PCG Editor Mode is a new editor mode (like Landscape Mode or Foliage Mode) that you activate from the toolbar. When active, it gives you direct manipulation tools for interacting with PCG graphs in the viewport.

The core idea: Instead of PCG graphs only consuming static inputs (landscapes, volumes, static splines), they can now consume interactive inputs that you draw, paint, and sculpt directly in the viewport while the graph regenerates in real time.

This is not a minor UI convenience. It changes the fundamental workflow of PCG from "configure parameters, press button, evaluate result" to "draw in the viewport, see procedural content appear immediately." The feedback loop goes from seconds to milliseconds.

The Three Interaction Primitives

PCG Editor Mode introduces three new input types that PCG graphs can consume:

Drawable Splines. You click in the viewport to place control points, and a spline is generated that feeds directly into your PCG graph. This is similar to the existing Spline Component workflow, but with critical differences: you do not need to create a separate actor, the spline lives within the PCG subsystem, and you can draw multiple splines that all feed into the same graph. Splines update the graph in real time as you adjust them.

Paintable Points. A brush tool that lets you paint point data directly onto surfaces. Each painted point becomes a PCG point with full attribute support — you can configure the brush to stamp position, rotation, scale, density, and custom attributes. Think of it as the Foliage Tool, but instead of placing static mesh instances directly, it feeds point data into your PCG graph for procedural processing.

Volumes. You draw 2D shapes in the viewport that extrude into volumes. These volumes act as spatial filters, inclusion zones, or exclusion zones within your PCG graph. Unlike the existing PCG Volume actor, these are drawn interactively and can be reshaped on the fly.

Performance: Nearly 2x Across the Board

PCG Editor Mode's real-time feedback loop would not work without the performance improvements that landed in UE 5.7. The roughly 2x improvement in graph execution speed is not just a nice-to-have — it is what makes interactive workflows viable.

In our testing, a vegetation scatter graph operating on a 500m x 500m area with roughly 50,000 output instances regenerates in under 200ms when you adjust a drawable spline. That is fast enough to feel responsive. The same graph in UE 5.5 took 800-1200ms per regeneration, which created a laggy, unpleasant interaction loop.

The performance gains come from three sources:

Incremental regeneration is the most important for Editor Mode workflows. When you move a single control point on a drawable spline, the engine does not re-execute the entire graph from scratch. It identifies which downstream nodes are affected by the change and only reprocesses those portions. For complex graphs with multiple independent branches, this means the interactive feedback only pays the cost of the branch you are actually modifying.

Building a Procedural Scatter Tool: Node-by-Node Walkthrough

Let us build something practical. We are going to create a vegetation placement tool that lets you draw regions in the viewport, automatically scatters contextually appropriate vegetation within those regions, and handles slope-based filtering, density variation, and clustered placement.

The end result is a tool that non-technical artists can use to paint forests, meadows, and rocky outcroppings without understanding the underlying graph.

Step 1: Set Up the PCG Graph

Create a new PCG Graph asset (right-click in Content Browser > PCG > PCG Graph). Open it in the PCG Graph Editor.

The default graph starts with a Get Landscape Data node connected to a Surface Sampler. Delete both of these. We are going to use Editor Mode inputs instead.

Step 2: Add the Input Node

Add an Editor Mode Volume Input node. This is new in 5.7 and only appears in the node palette when you have the PCG Editor Mode plugin enabled (it ships with the engine but needs to be activated in the Plugin Manager).

This node outputs the volume shapes you draw in the viewport as Polygon2D data — more on this data type shortly. Each volume you draw becomes a separate data element flowing through the graph.

Configure the node:

Editor Mode Volume Input
├── Input Name: "Scatter Region"
├── Color: (0.2, 0.6, 0.1) — green, so artists can identify it
├── Allow Multiple: true
└── Default Height: 1000.0 — extrude height for 3D filtering

Step 3: Surface Sampling Within the Volume

Add a Surface Sampler node and connect the Volume Input to its Bounding Shape pin.

Surface Sampler
├── Points Per Square Meter: 2.0
├── Surface: Landscape (auto-detected)
├── Execution Mode: Auto — lets the engine decide CPU vs GPU
└── Looseness: 1.0 — slight oversample to avoid edge artifacts

The Surface Sampler generates points on the landscape surface, but only within the volume boundaries. This is the fundamental "paint a region, get points inside it" interaction.

Step 4: Slope-Based Filtering

Most vegetation should not appear on steep slopes. Add a Get Landscape Data node (not to sample new points, but to query landscape attributes at existing point locations). Connect the Surface Sampler output to it.

Then add a Density Filter node:

Density Filter (Slope)
├── Attribute: $Normal.Z
├── Min Value: 0.7 — roughly 45 degrees
├── Max Value: 1.0 — flat ground
├── Falloff: 0.1 — soft transition at slope boundaries
└── Invert: false

Points on slopes steeper than roughly 45 degrees get filtered out. The falloff creates a gradual density reduction rather than a hard cutoff, which looks more natural.

Step 5: Density Noise

Uniform density looks artificial. Add a Density Noise node to break up the regularity:

Density Noise
├── Noise Type: Perlin
├── Scale: (500.0, 500.0) — world-space frequency
├── Amplitude: 0.4 — removes up to 40% of points
├── Offset: (0.0, 0.0) — shift the noise pattern
└── Seed: 42 — deterministic results

Step 6: Clustering with Voronoi Partitioning

This is where the graph gets interesting. Instead of scattering vegetation uniformly, we want clusters — groups of trees with gaps between them, which matches natural forest distribution patterns.

Add a Voronoi 2D node. This is new in 5.7 and works with the new Polygon2D data type. It partitions the point cloud into cells around randomly generated seed points.

Voronoi 2D
├── Num Cells: 20
├── Relaxation Iterations: 3 — Lloyd relaxation for even cell sizes
├── Seed: 42
└── Output: Cell Index attribute on each point

Follow this with a Density Filter node configured to read the distance-from-cell-center attribute:

Density Filter (Cluster)
├── Attribute: $VoronoiDistance
├── Min Value: 0.0 — cell center (full density)
├── Max Value: 50.0 — 50 meters from center (zero density)
├── Falloff Type: Exponential
└── Invert: false

Points near cell centers survive. Points far from centers get culled. The result is natural-looking clusters with organic gaps.

Step 7: Mesh Assignment and Output

Finally, add a Static Mesh Spawner node with mesh assignment:

Static Mesh Spawner
├── Mesh Entries:
│   ├── [0] SM_Tree_Oak_01 — Weight: 0.3
│   ├── [1] SM_Tree_Oak_02 — Weight: 0.3
│   ├── [2] SM_Tree_Birch_01 — Weight: 0.2
│   ├── [3] SM_Bush_01 — Weight: 0.1
│   └── [4] SM_Bush_02 — Weight: 0.1
├── Scale Range: (0.8, 1.2) — 20% scale variation
├── Random Rotation: Yaw only
└── Use HISM: true — Hierarchical Instanced Static Mesh

Enable HISM. This is critical for performance. Without it, each spawned mesh gets its own component, and you will hit draw call limits fast. HISM batches all instances of the same mesh into a single draw call with LOD support.

The Complete Graph

Here is the full node chain:

Editor Mode Volume Input
    └── Surface Sampler
            └── Get Landscape Data
                    └── Density Filter (Slope)
                            └── Density Noise
                                    └── Voronoi 2D
                                            └── Density Filter (Cluster)
                                                    └── Static Mesh Spawner

Nine nodes. No code. The artist draws a region in the viewport, and contextually appropriate clustered vegetation appears within it in real time.

The Polygon2D Data Type

UE 5.7 introduces Polygon2D as a first-class PCG data type. This deserves its own section because it unlocks capabilities that were previously impossible without custom C++ nodes.

What Is Polygon2D?

Polygon2D represents a closed 2D shape projected onto a surface. Unlike the existing PCG spatial types (Point, Spline, Volume), Polygon2D supports:

• Boolean operations. Union, intersection, difference between shapes.
• Offsetting. Inward and outward offsetting with configurable corner treatment.
• Subdivision. Breaking a polygon into triangles or quads for mesh generation.
• Area and perimeter queries. Procedural decisions based on shape metrics.

Spline Intersection Operators

The new spline intersection operators work with Polygon2D to solve a common problem: how do you create procedural content that respects road and path boundaries?

Spline to Polygon2D converts a spline with a width parameter into a Polygon2D strip. Polygon Difference subtracts one Polygon2D from another. Together, they let you do things like:

1. Draw a scatter region (Polygon2D from Editor Mode Volume)
2. Draw a road path (Polygon2D from Editor Mode Spline + width)
3. Subtract the road from the scatter region
4. Scatter vegetation only in the remaining area

Volume Input (Forest Region)
    └── Polygon2D
            └── Polygon Difference ← Spline Input (Road) → Spline to Polygon2D
                    └── Surface Sampler (within remaining area)
                            └── ... scatter nodes ...

This kind of boolean spatial operation required Houdini or custom code before 5.7. Now it is three nodes.

Practical Polygon2D Operations

The Polygon Skeleton operation is particularly clever. Given a Polygon2D shape, it extracts the medial axis — the center line of the shape. This is useful for generating paths that follow the natural center of an irregularly shaped region, or for placing linear features (fences, hedgerows, streams) that follow the internal geometry of a scatter zone.

Practical Example: Road Generation

Let us build a second tool. This one lets you draw a spline in the viewport and generates a complete road with shoulders, ditches, and edge vegetation.

The Spline Input

Start with an Editor Mode Spline Input node:

Editor Mode Spline Input
├── Input Name: "Road Path"
├── Color: (0.5, 0.5, 0.5) — gray for roads
├── Min Points: 2
└── Close Loop: false — roads have endpoints

Road Surface Generation

Convert the spline to a mesh strip for the road surface:

Spline to Mesh
├── Width: 800.0 — 8 meters
├── Resolution: 50.0 — point every 50cm along spline
├── UV Mode: Along Spline
├── Material: M_Road_Asphalt
└── Conform to Landscape: true

Shoulder and Ditch Geometry

Use Polygon Offset on the road's Polygon2D representation to create concentric zones:

Road Spline → Spline to Polygon2D (Width: 800)
    ├── Polygon Offset (Distance: 200) → Shoulder zone (800-1000 from center)
    ├── Polygon Offset (Distance: 400) → Ditch zone (1000-1200 from center)
    └── Polygon Offset (Distance: 800) → Vegetation transition (1200-1600 from center)

Each zone gets its own scatter rules:

Shoulder zone:
├── Material: M_Road_Gravel
├── Scatter: Small rocks, gravel decals
└── Density: Low

Ditch zone:
├── Landscape deformation: -30cm depression
├── Scatter: Puddle decals, tall grass
└── Density: Medium

Vegetation transition zone:
├── Scatter: Mixed ground cover, gradually increasing tree density
└── Density: Gradient from low (road side) to high (wilderness side)

Intersection Handling

When two road splines cross, you need special handling. The new Spline Intersection node detects where splines cross and outputs intersection point data:

Spline Intersection
├── Input A: Road Spline 1
├── Input B: Road Spline 2
├── Output: Intersection points with tangent data
└── Tolerance: 100.0 — snap threshold in cm

At each intersection, you can place a procedural intersection mesh (a flattened quad with appropriate road marking material) and suppress the shoulder/ditch generation within a radius.

This is roughly 15-20 nodes total. An artist draws paths, and a complete road network with proper edge treatment materializes. No code, no manual mesh placement, no hand-painting.

Practical Example: Village Layout

The third tool is more ambitious. Given a Polygon2D region, it generates a procedural village layout with building footprints, paths connecting them, and surrounding vegetation.

Zone Definition

Start with an Editor Mode Volume for the village boundary:

Editor Mode Volume Input
├── Input Name: "Village Area"
└── Allow Multiple: false — one village per graph instance

Building Footprint Placement

Use Poisson Disk Sampling to place building seed points with guaranteed minimum spacing:

Polygon2D → Poisson Disk Sampler
├── Min Distance: 2000.0 — 20 meters between buildings
├── Max Attempts: 30
└── Seed: Village seed parameter

Then, at each point, generate a rectangular Polygon2D footprint:

Point to Polygon2D
├── Shape: Rectangle
├── Width Range: (600, 1200) — 6-12 meters
├── Depth Range: (400, 800) — 4-8 meters
├── Rotation: Towards village center + random offset
└── Snap to Grid: 50.0 — buildings align to a subtle grid

Path Network

This is where the Polygon Skeleton operation shines. Take the village boundary Polygon2D, subtract all building footprints, and extract the skeleton of the remaining space:

Village Area
    └── Polygon Difference (subtract all building footprints)
            └── Polygon Skeleton
                    └── Spline simplification → village path network

The skeleton of the space between buildings naturally forms paths that connect buildings while avoiding them. It is surprisingly elegant and requires zero pathfinding code.

Vegetation Zoning

Subtract building footprints and paths from the village area. Scatter the remaining space with appropriate vegetation: garden plots near buildings (low ground cover, flowers), open areas in between (grass, occasional tree), and dense vegetation at the village boundary.

Village Area
    └── Polygon Difference (buildings + paths)
            ├── Proximity to buildings < 5m → Garden scatter
            ├── Proximity to buildings 5-15m → Open area scatter
            └── Proximity to boundary < 10m → Dense tree scatter

Building Mesh Assignment

The building footprint Polygon2Ds drive mesh selection:

Footprint area < 5m² → SM_Shed variants
Footprint area 5-8m² → SM_House_Small variants
Footprint area 8-12m² → SM_House_Large variants
Footprint aspect ratio > 2:1 → SM_Barn variants

The complete village generation graph is roughly 30-40 nodes. Complex, but entirely visual. An artist draws a village boundary, adjusts a few parameters (building density, vegetation density, path width), and gets an instant preview that they can iterate on.

Integrating PCG with World Partition

If you are building large worlds, you need PCG to work with World Partition. UE 5.7 improves this integration significantly, but there are still workflow considerations.

How PCG and World Partition Interact

World Partition divides your level into cells that load and unload at runtime. PCG graphs need to generate content within specific cells without affecting neighboring cells.

The key setting: On your PCG Component, set Generation Grid Size to match your World Partition cell size. This tells PCG to generate independently within each cell boundary, ensuring that loading or unloading a cell does not trigger regeneration in adjacent cells.

PCG Component Settings for World Partition
├── Generation Grid Size: Match WP cell size (e.g., 12800 for 128m cells)
├── Use Grid: true
├── Unbounded: false — constrain to grid cells
└── Generate At Runtime: true — for runtime streaming

Seam Handling

The biggest challenge with PCG + World Partition is seams. When PCG generates content independently per cell, you get visible seams at cell boundaries — trees that clip through the boundary, density changes, pattern discontinuities.

UE 5.7 addresses this with Border Overlap:

PCG Component
├── Border Overlap: 500.0 — generate 5m beyond cell boundary
└── Overlap Fade: true — density fades in the overlap region

This generates content slightly beyond each cell's boundary. When two adjacent cells are both loaded, the overlapping content blends together. When only one cell is loaded, the overlap ensures that the cell boundary is not visible as a hard edge.

Limitation: Border Overlap increases generation cost proportionally to the overlap distance. A 500cm overlap on 12800cm cells adds roughly 8% more points to process. This is usually acceptable, but if you are running tight on generation time budget, keep the overlap as small as visually necessary.

Runtime Generation

For truly procedural worlds that generate at runtime (roguelikes, survival games, procedural exploration), PCG can now generate content during cell loading:

PCG Component (Runtime)
├── Generate At Runtime: true
├── Runtime Generation Budget: 5.0ms — per-frame time budget
├── Priority: Distance to player
└── Async Generation: true — does not block game thread

The Runtime Generation Budget is critical. It caps how much time PCG can spend per frame generating content for newly loaded cells. If a cell requires 50ms of PCG generation and your budget is 5ms, the generation will spread across 10 frames. This prevents frame hitches when entering new areas but means content "pops in" gradually.

For shipping products, we recommend generating PCG content during cooking and baking the results as static instances. Runtime generation is better suited for development iteration and true procedural games where pre-baking is not possible.

PCG Editor Mode vs. the Procedural Placement Tool

This comparison is worth making explicitly, because both systems solve aspects of the same problem: populating levels with procedural content.

Where They Overlap

Both systems let you define regions and scatter content within them. Both support density control, slope filtering, and mesh variation. Both output instanced meshes for performance. If your goal is "scatter trees in this area," either system can do it.

Where PCG Editor Mode Excels

Custom logic. PCG is a general-purpose visual programming system. You can build any procedural logic you can express as a node graph — road networks, village layouts, cave systems, puzzle piece placement. The Procedural Placement Tool is purpose-built for environment scatter and does not try to solve arbitrary procedural generation problems.

One-off bespoke tools. If your game needs a specific procedural tool that does not exist yet — say, a crystal cave generator or a shipwreck debris field placer — PCG Editor Mode lets you build it from scratch as a graph.

Engine integration depth. PCG has deep access to engine systems: landscape data, physics queries, navigation mesh data, and other subsystems. It can make procedural decisions based on any data the engine exposes.

Where the Procedural Placement Tool Excels

Immediate productivity. The Procedural Placement Tool is a finished product. You drop a Biome Zone actor into your level, configure your biome rules, and generate. There is no graph to build, no nodes to learn, no debugging of procedural logic. It works out of the box with sensible defaults.

Biome-aware scatter. The tool's core concept — biome zones that define complete vegetation and detail scatter rules — is purpose-built for the most common procedural placement task. Transition blending between biomes, exclusion volumes that respect multiple biomes, and priority-based layering are all built in. Recreating this in PCG requires substantial graph work.

Cluster grouping. Natural vegetation grows in clusters. The Procedural Placement Tool has built-in cluster algorithms that produce organic-looking groupings without the Voronoi workaround described earlier. The clustering respects inter-species relationships (trees suppress understory ground cover, bushes cluster around tree bases).

HISM optimization. The tool automatically handles Hierarchical Instanced Static Mesh batching, LOD transitions, draw call budgeting, and culling distance management. In PCG, you need to configure HISM manually and manage these performance concerns yourself.

How They Complement Each Other

The most effective workflow we have found combines both:

1. Use the Procedural Placement Tool for your base environment: biome zones, vegetation scatter, ground cover, rocks, and detail meshes. This covers 80% of environment population with minimal setup.

2. Use PCG Editor Mode for bespoke procedural content that sits on top of the base environment: road networks, settlements, specific gameplay areas with custom procedural rules, and one-off set pieces.

3. Use PCG Exclusion nodes to read the Procedural Placement Tool's exclusion volumes, so your PCG content properly clears space in the base vegetation.

This division of labor plays to each system's strengths. The Procedural Placement Tool handles the bread-and-butter environment work fast and reliably. PCG Editor Mode handles the custom, creative procedural challenges that a general-purpose tool cannot anticipate.

What Does Not Work (Yet)

PCG Editor Mode in UE 5.7 is a major step forward, but it is not without limitations. Here is what you should know before committing to it for a production workflow.

Undo/Redo Is Unreliable

This is the most frustrating issue. Undo/redo for Editor Mode interactions (drawing splines, painting points, adjusting volumes) works approximately 80% of the time. The other 20%, you get partial undos that leave the graph in an inconsistent state, requiring a manual regeneration to fix. Epic has acknowledged this as a known issue and it is on their fix list, but for now, save frequently.

No Multi-User Support

PCG Editor Mode interactions are purely local. In a multi-user editing session (UE's Multi-User Editing feature), PCG Editor Mode inputs do not synchronize between users. If two artists draw scatter regions on the same PCG graph, only one set of inputs will survive when the session is reconciled. This is a significant limitation for teams.

Workaround: Assign PCG Editor Mode responsibilities to a single artist per region, and use level streaming to partition responsibility.

Performance Cliff with Complex Graphs

The "real-time feedback" promise holds for graphs up to roughly 30-40 nodes with moderate point counts (under 100,000 points). Beyond that, you start hitting the limits of incremental regeneration. Some node types — particularly the Polygon2D boolean operations — do not support incremental evaluation yet, meaning any change upstream of a boolean node triggers a full re-evaluation of that entire branch.

Workaround: Split complex graphs into multiple smaller graphs that communicate via shared attributes. Each graph stays within the interactive performance envelope.

Limited Attribute Visualization

When debugging PCG graphs, you often want to visualize intermediate attributes — see the density values as a color gradient, or display the Voronoi cell assignments. PCG Editor Mode's attribute visualization is basic: you can color points by a single attribute, but there is no heatmap view, no histogram, and no way to visualize attributes on the final spawned meshes.

Drawable Splines Lack Tangent Control

The drawable spline tool in Editor Mode creates linear or Catmull-Rom splines. There is no Bezier tangent handle editing in the viewport. If you need precise spline shapes (and you often do for roads), you need to draw an approximate shape in Editor Mode, then switch to the standard actor editing mode to adjust tangent handles manually.

No Animation or Sequencer Integration

PCG Editor Mode inputs are static. You cannot keyframe a drawable spline in Sequencer to create animated procedural content. The inputs are purely for level design, not for runtime or cinematic procedural effects.

Tips for Production Use

Based on our experience building procedural tools with PCG Editor Mode, here are recommendations for teams adopting it:

Name everything. PCG graphs get complex fast. Every node should have a descriptive name. Every attribute should have a clear naming convention. Future-you will thank present-you.

Use subgraphs aggressively. PCG 5.7 supports subgraphs (reusable graph fragments). Extract common patterns — slope filtering, noise-based density, HISM output — into subgraphs that your team shares. This reduces graph complexity and ensures consistency across different tools.

Set up parameter presets. PCG graphs can expose parameters to the Details panel. Create named presets for common configurations: "Dense Forest," "Sparse Meadow," "Rocky Hillside." Artists should be picking presets, not tweaking raw numbers.

Profile before optimizing. The PCG Profiler (Window > Developer Tools > PCG Profiler) shows per-node execution time. Identify bottlenecks before rearranging your graph for performance. The bottleneck is almost never where you expect it.

Bake when done. Once you are happy with a PCG generation result, bake it to static instances using the "Bake to Static Meshes" option. This removes the PCG runtime overhead and gives you standard static mesh actors that are simpler to debug and ship. Keep the PCG graph as the source of truth, but ship baked results.

Version your graphs. PCG graph assets are binary, which makes them awkward in version control. Export graph descriptions as JSON (right-click > Export Description) alongside the binary asset. The JSON export is human-readable and diff-friendly, making code reviews possible.

Getting Started: A Minimal First Graph

If this is your first time with PCG, here is the simplest possible Editor Mode workflow to get your feet wet:

1. Enable the PCG plugin (Edit > Plugins > search "PCG").
2. Create a new PCG Graph (Content Browser > right-click > PCG > PCG Graph).
3. Place a PCG Component on any actor in your level.
4. Assign your graph to the PCG Component.
5. Open the PCG Graph Editor.
6. Add an Editor Mode Volume Input node.
7. Connect it to a Surface Sampler.
8. Connect the Surface Sampler to a Static Mesh Spawner.
9. Assign any static mesh to the spawner.
10. Switch to PCG Editor Mode in the toolbar.
11. Draw a volume in the viewport.

You should see meshes appear inside your drawn volume. From there, add filtering, noise, and clustering nodes to refine the result.

The learning curve is real. PCG is a deep system with many node types and non-obvious behaviors. But the payoff — custom procedural tools that exactly match your game's needs, built without writing a line of code — is worth the investment.

Wrapping Up

PCG Editor Mode in UE 5.7 closes a gap that has existed in the engine for years. We have had the ability to build procedural generation graphs since UE 5.2, but we have not had a good way to interact with them as tools. Editor Mode fixes that.

The combination of drawable splines, paintable points, and volumes as first-class PCG inputs means you can build interactive procedural tools that feel native to the editor. The nearly 2x performance improvement makes those interactions responsive enough for real-time iteration. And the new Polygon2D data type with boolean operations opens up tool-building possibilities that previously required Houdini or custom C++ plugins.

For environment population specifically, combining PCG Editor Mode with the Procedural Placement Tool gives you the best of both worlds: purpose-built biome scatter for the 80% case and unlimited procedural flexibility for the 20% that requires custom logic.

If you have been waiting for PCG to mature before investing in it, 5.7 is the version where that investment starts paying off. Build a simple scatter tool, learn the node library, and gradually work toward more complex procedural tools. The framework is finally ready for production use.