What is PCG?

An overview of Unreal's PCG framework and the problem it solves.

In 5.7 Unreal’s PCG plugin moved to production from experimental, so it seems like a good time to start digging into it. This is the first in what will hopefully become a series of PCG posts. I plan to use this blog to keep notes and share some things that I learn as I go.

The problem: filling a world

This is a key challenge for large open worlds. You’ve got kilometres of terrain that needs trees, rocks, grass, debris, fences, props, that all need to be placed sufficient variation and intelligence. Environment artists paint foliage by hand, area by area. Technical artists write scattering scripts. But then someone reshapes a hillside or decides to move a road or path to a different location and a lot of these traditional workflows breakdown. The workflow can still function, but the iteration loop is too slow and it scales badly.

Most existing approaches are either manual (slow, fragile when things change) or custom-built (flexible, but you’re maintaining your own system). PCG is Unreal’s attempt at solving this natively.

How it’s been done before

The Foliage Tool is what most Unreal artists reach for first. Brush-based, decent filters for slope and density, and still the right choice for hand-crafted hero areas. But painting an entire map takes weeks, and terrain changes mean repainting.

Blueprint scattering can work quite well but not out of the box. Construction scripts can do a lot if you’re willing to build your own point data system, filtering, and instancing from scratch. You can end up writing a homemade PCG without the engine-level optimisations or any standardised reuse.

Houdini is the one bigger studios tend to use. The friction is the roundtrip between Houdini and Unreal, the learning curve, the licence cost, and the fact that it only runs at edit-time. All three approaches can work, but the friction compounds at scale.

What PCG is

PCG (Procedural Content Generation) is a graph-based framework that shipped with Unreal Engine 5.2. It runs entirely inside the engine, no external software or licences. You build a node graph that pushes point data through a pipeline:

  • Sample: generate candidate points from a landscape, volume, spline, or mesh
  • Filter: remove the ones that don’t fit (too steep, wrong biome, too close to a path)
  • Transform: randomise scale, align to the surface normal, add variation
  • Spawn: output instanced static meshes into the level

If you know Houdini SOPs the mental model is quite similar. In practice you stick a PCG Component on an actor, point it at a graph, and generate. The feedback loop is quick, change a parameter and regenerate to see the result.

What changes in practice

The big one is that it’s non-destructive. Terrain changes and PCG just regenerates to match, no manual placement or scattering required. It’s also properly scalable since you define rules once and apply them across the whole world. The graph takes time to set up, but after that you’re regenerating large areas in seconds. Done correctly, it allows you to spend more time on creating your ideal ruleset and less time on repetitive scattering and placement tasks.

It uses Unreal’s node-based UI, which means anyone comfortable with Blueprints can have a look at PCG graphs without learning a completely new tool. And it goes beyond foliage: fences, debris, road edges, cliff dressing, modular structures. I haven’t explored all of these yet but the range is there. PCG can also run at runtime, not just in the editor, which I’m hoping to write a separate post about.

Future posts will get more hands-on as I work through building graphs and figuring out the details.