Open-world games have a scale problem. Traditional level streaming — manually dividing your world into sublevels, writing trigger volumes, and managing load/unload transitions — breaks down when your world gets genuinely large. Managing 200 hand-placed streaming volumes across a 64 km² map isn't level design. It's bookkeeping.

Unreal Engine 5's World Partition system replaces all of that with an automatic, grid-based approach that scales to worlds far larger than what traditional streaming can handle. Combined with One File Per Actor (OFPA) for team collaboration and Data Layers for gameplay-driven streaming, you can build worlds that would have required a custom engine a few years ago.

This guide covers how World Partition works, how to set it up, how to avoid the pitfalls that catch most developers, and how tools like the Procedural Placement Tool integrate with partitioned worlds to fill massive landscapes with content.

Beyond Traditional Level Streaming

To understand why World Partition matters, let's look at what it replaces.

The Old Way: Persistent Level + Sublevels

In the traditional UE4/early UE5 approach:

• A persistent level contains your core game logic and always-loaded actors
• The world is divided into sublevels, each containing a portion of the environment
• Level Streaming Volumes or Blueprint logic controls which sublevels are loaded
• Sublevels load and unload as the player moves through the world

This works for linear games and moderate-sized open worlds. It falls apart for several reasons:

Manual management. Every sublevel boundary is a decision you make and maintain. Add a new area? Create a new sublevel, set up streaming volumes, test transitions. Move a building that crosses a sublevel boundary? Reparent actors between levels.

Team friction. In UE4, a sublevel is a single file. If two artists need to work in the same area, one of them waits. Binary level files can't be meaningfully merged, so check-out-based workflows are the norm, and they serialize collaboration.

Memory cliffs. A sublevel is all-or-nothing. If one sublevel contains a dense city block and another contains sparse grassland, they have wildly different memory footprints. Loading the city sublevel might spike memory by 2 GB regardless of how much of it the player can actually see.

Streaming hitches. Loading a sublevel synchronously freezes the game. Loading asynchronously risks the player seeing pop-in. The "sweet spot" loading distance is different for every sublevel, and getting it wrong either wastes memory (loaded too early) or causes visible pop-in (loaded too late).

The New Way: Automatic Grid-Based Streaming

World Partition replaces all of this with a single world that's automatically divided into a grid. Each grid cell loads and unloads independently based on player proximity. You don't manage sublevels. You place actors in the world, and the system figures out which grid cell they belong to.

The result:

• No manual streaming management — the grid handles it
• Per-actor granularity — each actor is saved as its own file (OFPA), eliminating team conflicts
• Distance-based loading — actors load based on proximity, with per-actor or per-class streaming distances
• Consistent memory usage — grid cells have more uniform memory footprints than hand-authored sublevels

What Is World Partition?

World Partition is a streaming management system built into UE5 that divides the world into a uniform grid and manages loading/unloading of grid cells automatically.

Core Concepts

Grid cells. The world is divided into a regular grid (default cell size is typically 12800 units, or 128 meters at default scale). Each cell contains the actors whose origins fall within it. Cells load and unload as independent units.

Streaming source. The player's position (or any actor registered as a streaming source) determines which cells to load. Cells within the streaming distance are loaded. Cells outside it are unloaded. The system handles transitions smoothly.

Loading range. Each actor class can specify how far away it should start loading. Large landmarks load at 2 km. Small props load at 200m. This is per-class, not per-sublevel, which gives much finer control than traditional streaming.

Runtime hash. World Partition uses a spatial hash to quickly determine which cells are relevant. This is faster than checking individual streaming volumes and scales to very large worlds.

What It Replaces

World Partition replaces:

• Level Streaming Volumes (the grid handles proximity-based streaming)
• Manual sublevel management (no more sublevels to organize)
• World Composition (the UE4 tile-based system for large landscapes)

It does not replace:

• Level Instances (reusable level templates, like dungeon rooms, still work)
• Data Layers (a complementary system, covered below)
• The concept of a persistent level (your World Partition map is the persistent level)

One File Per Actor (OFPA)

OFPA is the collaboration backbone of World Partition. Instead of saving all actors in a level into a single .umap file, each actor is saved as its own external actor file (.uasset).

Why OFPA Matters

Parallel editing. Two artists can work on adjacent buildings without conflicts. Artist A modifies Building01 (its external actor file), Artist B modifies Building02 (a different file). Both check in without merging.

Granular version control. Instead of a 500 MB level file that changed because someone moved a rock, you get a 5 KB diff on a single actor file. Code reviews, history tracking, and blame are all meaningful.

Reduced contention. In team environments using Perforce or similar lock-based systems, OFPA means you only lock the specific actor you're editing, not the entire level.

OFPA in Practice

When World Partition is enabled, OFPA is the default save mode. Actors are saved in an __ExternalActors__ folder alongside the level.

Things to know:

• External actor files are lightweight but numerous. A large level might have 50,000+ external actor files. Your version control system needs to handle this scale.
• Actor references work the same way — you reference actors by soft or hard reference as usual. The engine resolves the external files transparently.
• Some actors can't be external (level-specific actors like World Settings). These remain in the main level file.
• Cooking and packaging handle external actors automatically. You don't need to manage them during builds.

Working with Large Actor Counts

With OFPA, it's easy to end up with tens of thousands of actor files. This is normal and intentional, but it requires discipline:

• Use naming conventions. External actor filenames are generated from the actor's name and path. Give your actors meaningful names so the files are identifiable in version control.
• Organize with folders in the Outliner. The Outliner's folder hierarchy helps you manage actors visually even though they're all technically in one level.
• Don't be afraid of the file count. Modern version control systems handle 100K+ files in a directory without issues. Git users should consider Git LFS or Perforce for large projects.

Setting Up World Partition

New Projects

For new projects, World Partition can be enabled when creating a level:

1. Create a new level (File > New Level)
2. Select the "Open World" template, which enables World Partition by default
3. Or create any level type and enable World Partition in World Settings > World > Enable World Partition

Existing Projects

Converting an existing level to World Partition requires the World Partition conversion commandlet:

1. Back up your project (seriously)
2. Run the conversion commandlet from the command line
3. Review the converted level — actor placement should be unchanged, but streaming behavior will differ
4. Test thoroughly — streaming distances, loading order, and memory behavior all change

Honest assessment: Converting a large existing project is nontrivial. Actor references that depended on sublevel load order may break. Streaming logic that relied on trigger volumes needs replacement. Budget a few days for a medium project, a few weeks for a large one.

Grid Size Configuration

The default grid cell size works for most projects. Adjust it if:

• Your world is very dense (urban environments) — smaller cells load more granularly but increase streaming overhead
• Your world is very sparse (open landscapes) — larger cells reduce overhead but load more content per cell
• Memory is tight (consoles, mobile) — smaller cells give finer memory control

Grid size is set in World Settings > World Partition > Runtime Hash > Grid Size. Start with the default and profile before changing it.

Streaming Distance Setup

Each actor (or actor class) can specify its loading distance:

• Default streaming distance — set in World Settings, applies to actors without a custom distance
• Per-class override — set in the class defaults, applies to all instances of that class
• Per-instance override — set on individual actors for special cases (a unique landmark that should load from far away)

Guidelines:

• Large terrain features and landmarks: 2000m+
• Buildings and major structures: 500-1000m
• Medium props (vehicles, furniture): 200-500m
• Small props (ground clutter, small decorations): 50-200m
• Trigger volumes and gameplay actors: match the distance at which they're relevant

Data Layers and Streaming

Data Layers are World Partition's answer to gameplay-driven streaming. While the grid handles proximity-based streaming automatically, Data Layers let you control streaming based on game state.

What Data Layers Do

A Data Layer is a named group of actors that can be loaded and unloaded as a unit, independent of the grid. Examples:

• Night layer: Adds street lights, reduces ambient light actors, spawns nocturnal NPCs
• Quest layer: Loads quest-specific actors when the quest is active (barricades, NPCs, set pieces)
• Destruction layer: Replaces intact buildings with destroyed versions after a story event
• Season layer: Swaps foliage and weather systems based on in-game time

How They Work

1. Create Data Layers in the World Partition editor
2. Assign actors to layers (an actor can belong to multiple layers)
3. Activate/deactivate layers at runtime through Blueprint or C++
4. Actors in active layers follow normal grid-based streaming. Actors in inactive layers are never loaded.

Key distinction: Data Layers control whether an actor can load, not whether it is loaded. An actor in an active Data Layer still uses proximity-based streaming. An actor in an inactive Data Layer never loads regardless of proximity.

Data Layer Strategies

Start with one layer (default). Don't over-layer your world. Most actors belong in the default layer and stream normally. Only use Data Layers for actors that need gameplay-driven control.

Layer transitions need design. Activating a layer loads actors. If those actors are within streaming distance, they appear immediately. If the layer contains hundreds of actors in the player's vicinity, the load spike can cause a hitch. Activate layers during transitions (loading screens, cutscenes, fast travel) when possible.

Test layer interactions. If Layer A and Layer B have actors in the same physical space (intact building vs. destroyed building), ensure they're never active simultaneously. The system doesn't prevent overlapping layers — that's your responsibility.

Landscape at Scale

Large open worlds need large landscapes, and Landscape in UE5 has its own scale considerations.

Landscape Configuration for Large Worlds

Component size. Landscape is divided into components, each rendered independently. Larger components (255x255 quads) reduce draw call overhead but increase per-component memory and LOD granularity. Smaller components (63x63 quads) give finer LOD control but more draw calls. For worlds larger than 8 km², 127x127 is a good default.

Section size. Each component contains sections, which are the actual draw units. Sections should be 63x63 or 127x127 for most hardware.

Overall resolution. A 16 km² landscape at 1m resolution is 4097x4097 vertices. At 0.5m resolution, it's 8193x8193. Higher resolution means more detail but more memory. For worlds over 64 km², consider whether you actually need sub-meter heightmap resolution everywhere.

Landscape and World Partition

Landscape components participate in World Partition streaming. Large landscapes are automatically divided into the World Partition grid, and landscape components load/unload with their grid cells. This means:

• You can have a landscape that spans the entire world without loading it all into memory
• Landscape LOD still works — distant landscape renders at reduced detail
• Landscape streaming integrates with the same proximity system as other actors

Important: Landscape proxy actors (created by World Partition when a landscape is divided) are the streaming units. Each proxy contains a portion of the landscape and streams independently.

Heightmap Import at Scale

For very large landscapes, importing heightmaps can be challenging:

• 16-bit PNG/RAW files support up to 65536 height values — sufficient for most terrain
• Tiled import lets you import heightmap tiles that stitch together automatically
• World Machine, Gaea, or other terrain generators can export tiled heightmaps sized for UE5's landscape system
• Runtime Virtual Texturing (RVT) is nearly essential for large landscapes — it avoids the need for unique textures across the entire terrain

Procedural Placement in Partitioned Worlds

A 64 km² world is too large to hand-place every tree, rock, and bush. Procedural placement is necessary, and it needs to work with World Partition's streaming model.

The Challenge

In a traditional level, you scatter 100,000 foliage instances into Instanced Static Mesh Components (HISM). All instances exist in memory all the time. In a World Partition world, you need those instances to stream with the grid. If a grid cell unloads, its foliage should unload too.

How the Procedural Placement Tool Integrates

The Procedural Placement Tool is designed for exactly this scenario. Here's how it works with World Partition:

Grid-aware scattering. When you run a scatter operation across a partitioned world, instances are automatically assigned to the correct grid cells. Each cell gets its own HISM component containing only the instances within that cell's bounds.

Streaming-compatible output. The resulting HISM components participate in World Partition streaming. When a cell loads, its foliage loads. When a cell unloads, its foliage unloads. Memory usage scales with the visible area, not the total world size.

Incremental updates. You don't need to re-scatter the entire world when you modify terrain in one area. The tool supports region-based operations that only affect specific cells or areas.

Biome zones at scale. For a large world with multiple biomes (forest, desert, tundra, swamp), the tool's biome zone system lets you define biome boundaries and scatter different vegetation sets per zone. The biome boundaries can span multiple grid cells, and the scatter respects both the biome rules and the grid cell boundaries.

Scatter Performance at Scale

Filling a world with foliage at this scale requires specific considerations:

• HISM vs. individual actors. Never place individual static mesh actors for repeated content. HISM reduces draw calls by orders of magnitude. The Procedural Placement Tool uses HISM by default and can push 100,000+ instances per second.
• Nanite foliage. Nanite support for foliage drastically reduces the rendering cost of dense vegetation. Enable Nanite on foliage meshes whenever possible.
• Density culling. Not every instance needs to render at every distance. Configure distance-based density reduction so that distant areas show fewer grass blades and small rocks.
• Spline scatter for paths and roads. Use the tool's spline-based scatter to populate along roads, rivers, and paths with appropriate vegetation (riverbank plants, roadside grass) that streams correctly with World Partition.

A Practical Workflow

Here's the workflow we use for populating a large partitioned world:

1. Landscape first. Set up your landscape with World Partition enabled. Import heightmaps, paint base materials.
2. Define biome zones. Use the Procedural Placement Tool to define biome boundaries based on elevation, slope, moisture maps, or painted regions.
3. Scatter major features. Populate forests, rock formations, and landmark vegetation first. These define the visual identity of each area.
4. Scatter ground cover. Add grass, small rocks, flowers, and ground debris. These are high-density, low-visual-impact elements that fill the spaces between major features.
5. Spline scatter for linear features. Populate river banks, road edges, cliff faces, and fence lines using spline-based scatter.
6. Review per-cell. Check individual World Partition cells for density, variety, and streaming transitions. Adjust loading distances if foliage pops in too visibly.
7. Profile memory. Each grid cell has a memory budget. If dense cells exceed it, reduce scatter density or increase LOD aggressiveness.

Performance Monitoring

World Partition shifts performance concerns from "does the whole level fit in memory?" to "do the loaded cells perform well?"

Key Metrics

Loaded cell count. How many grid cells are currently loaded? More cells mean more memory and more actors ticking. If the streaming distance is too large, too many cells load simultaneously.

Memory per cell. Individual cells should have relatively uniform memory footprints. A cell containing a dense city block and a cell containing empty grassland should not differ by 10x — if they do, consider adjusting grid size or splitting dense areas.

Streaming latency. How long does it take to load a cell when the player approaches? If loading takes longer than the approach speed, the player sees pop-in. Profile with stat streaming and stat levels.

Actor count per cell. More actors per cell means longer load times and more per-frame overhead. If a cell has thousands of ticking actors, consider whether they all need to tick, or whether some can use reduced tick rates or demand-based activation.

Profiling Commands

• stat streaming — streaming metrics, load times, pending loads
• stat levels — loaded level/cell information
• stat memory — memory breakdown by category
• memreport -full — detailed memory report saved to log
• World Partition editor visualization — toggle grid overlay in the editor to see cell boundaries, loaded state, and actor distribution

Optimization Strategies

Adjust streaming distances per class. If small props are loading too far away, reduce their streaming distance. If landmarks pop in, increase theirs. This is the single most impactful optimization.

Use HLOD (Hierarchical Level of Detail). World Partition supports HLOD, which generates simplified meshes for distant cells. Instead of loading all actors in a distant cell, the engine loads a single low-poly proxy mesh. This drastically reduces the cost of distant content.

Enable runtime virtual texturing. For large landscapes, RVT avoids the need to have unique texture data loaded for the entire terrain. Only the visible portion of the terrain's textures are in memory.

Profile on target hardware. PC development machines with 64 GB RAM and NVMe drives load cells invisibly. A console with 12 GB shared memory and a slower storage bus behaves very differently. Always profile on your target platform.

Common Pitfalls

Pitfall 1: Not Testing Streaming Transitions

The editor loads all cells by default, so you never see streaming transitions until you play the game. Enable World Partition > Enable Streaming in Editor or test in Play-In-Editor to see what the player actually experiences.

Pitfall 2: Oversized Grid Cells

If grid cells are too large, each cell contains too much content and loading one cell causes a memory spike. If cells are too small, the system has too many cells to manage and streaming overhead increases. Start with the default and adjust based on profiling.

Pitfall 3: Ignoring HLOD

Without HLOD, distant cells are either loaded (expensive) or invisible (ugly). HLOD gives you a middle ground — simplified representations of distant content that look reasonable and cost little. Setting up HLOD requires work, but it's essential for large worlds.

Pitfall 4: Actor References Across Cells

If Actor A in Cell 1 holds a hard reference to Actor B in Cell 2, loading Cell 1 forces Cell 2 to load too. This creates chain loading that undermines the grid system. Use soft references, level instances, or data-driven lookups (data tables, data assets) to avoid cross-cell hard references.

Pitfall 5: Not Planning for World Origin Rebasing

Very large worlds (64 km+ in any dimension) run into floating-point precision issues at extreme distances from the world origin. Distant geometry jitters, physics behave erratically, and animations stutter. UE5 supports World Origin Rebasing (shifting the origin to keep the player near 0,0,0), but it needs to be planned for — actors need to handle the rebasing event, and some systems (particle effects, audio) need special attention.

Pitfall 6: Landscape Material Complexity

A landscape spanning 64 km² with 12 material layers per component is expensive. Each layer adds a texture sample, and the fragment shader cost scales with layer count. Limit landscape material layers to 4-6 per component. Use Runtime Virtual Texturing to blend layers without per-pixel overhead.

Pitfall 7: Forgetting the Minimap

Large worlds need navigation aids. A minimap or world map that shows the entire world needs either a pre-rendered texture or a runtime rendering system. This is a content and UI task that gets overlooked until late in development.

Getting Started

If you're planning a large open-world project in UE5:

1. Start with World Partition enabled. Don't build with traditional streaming and convert later. Start with World Partition from day one. The workflow is cleaner and the earlier you learn it, the better.

2. Set up OFPA immediately. Configure your version control for per-actor files. If using Git, set up LFS for binary assets. If using Perforce, the actor files integrate naturally.

3. Block out your world at scale. Before placing detailed content, block out the full world extent with placeholder landscape and major landmarks. This validates your grid size, streaming distances, and memory budget early.

4. Use the Procedural Placement Tool for vegetation. Hand-placing foliage across 64 km² isn't feasible. The tool's biome zones, HISM output, and World Partition integration handle the scale. Start with coarse scatter passes and refine.

5. Profile early and often. Set up target hardware testing as soon as you have a representative cell. One cell at target density tells you whether your entire world will work within budget.

6. Set up HLOD early. Don't wait until the end of production to configure HLOD. It affects distant visuals significantly, and artists should be able to see the HLOD representation during development.

Building massive open worlds used to require a large team and a custom engine. With World Partition, OFPA, Data Layers, and the right tooling, a small team can manage worlds that rival AAA scope. The system isn't simple — there are genuine pitfalls and a learning curve — but it's dramatically more accessible than the alternatives. The key is starting with it from the beginning and profiling throughout, not treating it as an optimization pass at the end.