World Partition is the system that redefines Unreal Engine 5's approach to open-world development. In the UE4 era, large maps were carved manually into sublevels, managed through Level Streaming Volumes, and team members touching the same file regularly produced merge conflicts. World Partition retires that model: the scene is automatically partitioned into a grid, the engine manages which cell is loaded, and every actor is stored in a separate file.
At Althera Games, Potion Rise Simulator's small-village scope doesn't currently demand World Partition; but if the city and shop ecosystem grows, it becomes a candidate. In this article we cover the architecture of World Partition, the mechanics of cell streaming and HLOD, the conditional loading power of Data Layers, OFPA's effect on team workflow, and when it makes sense for indie projects. For broader UE5 introductions, our UE5 guide hub and UE5 indie development guide are good companion reads.
What Is World Partition?
At its simplest, World Partition is a system that automatically divides your world into regions and loads only the regions close to the player at runtime. In the old Level Streaming approach, the developer had to program by hand which area to load when; World Partition delegates that responsibility to the engine. The result is a simpler developer experience and a serious team-collaboration improvement.
The system has three core components. World Partition Subsystem: the engine system that manages the grid structure and which cell loads when. OFPA (One File Per Actor): the data format that stores each actor in its own disk file. HLOD (Hierarchical Level of Detail): the automatic LOD system that creates simplified versions of distant cells. Together, these three components keep large worlds manageable for both development and player experience.
For official references, Epic's World Partition documentation is a thorough starting point. SIGGRAPH talks from Brian Karis and the Epic technical team explain the engineering foundations of the system in depth.
Cell Streaming and HLOD
The heart of World Partition is cell streaming. The moment your world is activated, it is automatically split into square cells; the default size is 25600 cm, or 256 meters. When the player approaches a cell, that cell and its neighbors load; when they move away, they unload. The loading radius is governed by runtime grid cells and streaming source settings.
The cell-size decision is the trade-off between memory and streaming overhead. Small cells (12800 cm, for instance) hold less data in memory but generate more frequent IO; if the player moves quickly, they cross many cell boundaries and risk streaming hitches. Large cells (51200 cm) require fewer IO operations but inflate memory footprint. For most open worlds, 25600 cm is a safe starting point; the final value is determined through profiling around your character speed and scene density.
HLOD precomputes simplified versions of cells far from the player. If a cell is near, it uses full geometry; at medium distance, a moderately detailed mesh proxy; far away, a simplified blob mesh. A 3-tier HLOD setup is enough for most indie projects. HLOD generation can take a full overnight pass for an open world; the process can be distributed via build farms or automated in a CI pipeline.
The main benefit of HLOD is that mountain ranges, distant cities, and broad forests on the player's horizon are visible without actually being loaded. Combined with the Nanite technology covered in our Nanite guide, geometric density doesn't have to be capped, even in open-world contexts.
Data Layers for Conditional Loading
Data Layers is World Partition's conditional content system. Beyond deciding whether a cell loads, you can decide which content within a cell loads. This is critical for modern open-world design.
Practical use cases: a day/night layer that activates different NPCs, lights, and threats at night; a story layer that swaps regions of the world after a quest is completed; a multiplayer layer where a team's structures load only for that team's players; a development layer for editor-only debug actors that never enter a production build but live in the editor.
To use Data Layers properly, first map out your world's state matrix. Which layers are active under which conditions? If the matrix is messy, unexpected runtime combinations appear; if it's tight, the relationships among layers stay predictable. Our planned layers for Potion Rise Simulator: a base village layer (always on), a day-market layer (08:00-18:00), a night-watch layer (22:00-06:00), and a festival layer (during in-game holidays).
Migrating from World Composition
Many UE4-era projects still run on World Composition, the older system built around manually configured sublevels. It is still supported in UE5, but it is not recommended for new projects and will be deprecated long term. New projects should go directly to World Partition.
Migrating an existing World Composition project to World Partition usually requires manual labor. Epic's OneFilePerActor Migration Tool automates the first step, but converting sublevels into the World Partition cell layout often requires manual intervention. Practical steps: take a copy of the project first (never work on the original), merge all sublevels into the persistent level, then activate World Partition and run the OFPA convert.
Do not underestimate the migration cost; for a mid-sized UE4 open world, a developer can need 1-2 weeks of full-time work. The gains in return (automatic streaming, OFPA-driven team workflow, modern editor support) justify the investment. But if your project is at launch stage or your team is tiny, deferring the migration to a sequel or next-major-version is a reasonable choice.
OFPA and Source Control
OFPA is perhaps the least talked about and yet most impactful World Partition feature for team workflow. In traditional UE projects, a level is stored as a single .umap file holding every actor in the scene. When two developers work on the same level, merge conflicts are practically inevitable; merging binary .umap files is, for all practical purposes, impossible.
OFPA dismantles that model. Each actor is stored on disk as a separate small .uasset file. When two developers work on different actors in the same level, there is no conflict; their changes live in separate files and merge cleanly. For team workflow this is a revolutionary win, especially for 3-10 person indie teams.
Source control choice also shifts with OFPA. Perforce supports OFPA fully; the file-locking semantics for binary assets pair perfectly with OFPA's many-file structure. For Git teams, OFPA works but requires care; many small binary files can stress Git LFS, while keeping them in regular Git inflates repo size. Practical recommendation: keep small .uasset files in regular Git (binary, but small), and route large assets like Megascans through LFS. Our Blueprint vs C++ article adds perspective on team workflows.
OFPA is World Partition's invisible hero. For an indie studio working as a team, its economic value in developer hours often outweighs even the streaming system itself.
Open World Performance Tips
An open world running on World Partition rarely performs well at default settings. For production-grade performance, each of the following levers usually needs tuning.
Cell-size profiling: extract a player movement profile. What is the average speed, the peak speed, the average dwell time per cell? Calibrate cell size against that profile. Fast-moving players (motorcycle, flying) benefit from larger cells; slow-moving (walking, indoor) from smaller ones.
Loading-range tuning: r.WorldPartition.LoadingRange controls the load radius. You may want cell loading to start before HLOD is visible on the horizon. Values too low produce streaming hitches; values too high inflate memory. The 12800-25600 cm range is a strong starting point for most projects.
Streaming source weight: in addition to the player camera, you can mark certain NPCs or vehicles as streaming sources, so cells around them also load. This is critical for cinematic cameras or vehicle chases.
Initially Loaded: some cells should always be loaded (the player's starting region, the main hub, the spawn area). Marking those cells as Initially Loaded prevents them from unloading even after the player moves away.
HLOD settings: HLOD's proxy mesh quality is high by default; for small indie projects, two HLOD tiers instead of three are often enough and cut build time substantially. Our Lumen guide covers how those settings interact with lighting performance.
When World Partition Makes Sense for Indies
World Partition isn't a default-good decision; it is a right decision, but only when the project actually needs it. For a small local game (closed apartment, village, interiors), World Partition adds unnecessary complexity. The criteria we use:
- Is your map larger than 5 km²? If not, you probably don't need World Partition.
- Are multiple developers working on the same level? If yes, OFPA alone may justify World Partition.
- Are build times stretching into hours? That signals that the manual sublevel structure is failing.
- Is open-world streaming part of your gameplay? Seamless horseback riding or vehicle traversal? Then World Partition is required.
- Do you have multiplayer and server-streaming needs? If yes, World Partition's server streaming infrastructure is critical.
For Potion Rise Simulator, those answers currently keep us off World Partition; the village is small, the map is under 1 km², and our team is small. If the city ecosystem expands across multiple districts, World Partition migration enters the conversation. For NightRecord: Thin Walls, World Partition is unnecessary; the game lives entirely inside a closed apartment and the map is small-scale.
Practical advice: don't activate World Partition early. If you decide on it, set it up at project start, since later migration carries real cost; but if you're undecided, start with a classic level structure and migrate when the need genuinely emerges. Adopting too early for the wrong reasons drags many indie teams into avoidable technical complexity. You can follow the architectural decisions of Potion Rise Simulator on our games page.
Frequently Asked Questions
Is World Partition necessary for small indie projects?
World Partition is built for open worlds of 5 km² or larger; for small local maps (a closed apartment, a small village, interiors) it adds unnecessary complexity. If your map is under 1 km², Level Streaming Volumes or a straightforward single-level approach is more pragmatic. The criterion to move to World Partition is when the need actually emerges: the map starts struggling, build times stretch into hours, or multiple team members start touching the same sublevel.
How does World Partition behave in multiplayer?
World Partition operates in multiplayer through the Server Streaming Source concept; the server manages which cells are loaded per player. This is the right architecture for open-world MMOs or battle royales where players are in different regions. Bandwidth planning is critical, however; to keep replication stable as players cross cell boundaries, Data Layer and Initially Loaded settings must be configured carefully.
Is OFPA (One File Per Actor) compatible with Git LFS?
Yes, but it requires care. With OFPA enabled, each actor is stored as a separate .uasset file on disk, which can push your file count into the tens of thousands. Git LFS is designed for large binary files and can suffer with very large counts of small files. A practical recommendation: keep OFPA files in regular Git (they are binary uassets but small), and route large assets like Megascans through LFS. For Perforce teams, OFPA is fully supported. For small Git teams, atomic commit discipline matters more than ever.
How do you find the optimum cell size?
Cell size sets the trade-off between memory and streaming overhead. Very small cells (1024 cm for example) cause excessive IO operations and streaming hitches; very large cells (51200 cm for example) cost a lot of memory and slow load times. For most open-world projects, 25600 cm (256 m) is a strong starting point; with high character movement speed, 51200 cm; with slower characters or dense interiors, 12800 cm can be tried. The final value is set by per-project profiling.
Is migration from World Composition to World Partition mandatory?
World Composition is still supported in UE5, but it is not recommended for new projects and will be deprecated in the long term. New projects should go directly to World Partition. For large existing projects coming from UE4, Epic provides an official migration tool, though the process requires manual level merging and sublevel reorganization. Migration is not easy, but the iteration speed and team workflow gains of World Partition justify it.
Conclusion: The Right Decision at the Right Time
World Partition is the most mature and modern solution UE5 offers for open-world design. With cell streaming, HLOD, Data Layers, and OFPA together, both developer experience and player experience step forward. But like every modern solution, it is the right decision for the right project; for the wrong project, it is added technical complexity.
The takeaway for indie teams is this: even if you find World Partition attractive, ask whether your project actually needs it. A small local horror game does fine on a classic level structure; a wide RPG open world makes World Partition mandatory. Our UE5 guide hub serves as a wider reference for engine-level decisions; you can follow our own architectural evolution from our games page.