What World Partition changed for teams
Before Unreal Engine 5, collaborating on a large level meant sublevels and discipline. You carved the world into persistent and streaming sublevels, assigned each one to a person, and hoped nobody needed to touch two at once. It worked, but it was bookkeeping, and the boundaries were driven by team structure rather than by the game.
World Partition replaced that with an automatic spatial grid. The world streams by distance rather than by hand-authored sublevel, and One File Per Actor is enabled by default so each actor lives in its own file. The result is that two people can dress two different districts of the same city simultaneously and never touch the same file.
What lands in your project folder
A World Partition project produces a few directories worth understanding before you decide what to version:
Content/
Maps/
OpenWorld.umap ← small shell; the grid config
__ExternalActors__/Maps/OpenWorld/ ← every placed actor, one file each
__ExternalObjects__/Maps/OpenWorld/ ← per-actor external objects
HLOD/ ← generated proxy meshesThe .umap is now small: it holds the partition settings, the grid setup, and data layer definitions. The world itself lives in __ExternalActors__. That directory is not incidental output, it is your level, and it must be versioned.
HLOD/ is the one genuinely optional piece, and it is covered below.
Data layers as a team boundary
Data layers let you group actors logically rather than spatially: a gameplay pass, a lighting pass, a set of debug volumes, seasonal variants of the same district. Because they are independent of the streaming grid, they map neatly onto how a team actually divides work.
A practical pattern is one data layer per discipline on shared areas. Environment art, lighting, and gameplay scripting each get a layer over the same physical space. Everyone can load only their own layer plus whatever context they need, which keeps editor load times sane and makes it obvious who owns a given actor.
Data layer definitions live in the .umap. That means creating or renaming a layer touches the level file itself, which is exactly the shared file OFPA was designed to keep free. Treat layer changes as a deliberate, announced operation rather than something people do casually mid-session.
The HLOD decision
Hierarchical Level of Detail generates proxy meshes for distant cells. It is derived data: you can always rebuild it from the actors it summarizes. That makes versioning it a genuine choice rather than an obvious yes or no.
Commit it when you want every machine and every build agent to produce identical results, when your team includes people who should never have to run a build step, or when HLOD generation is slow enough that rebuilding is a real tax on the day.
Exclude it when your artists regenerate constantly and you do not want a large binary churning in history every time someone moves a rock.
Where locking still matters
World Partition plus OFPA removes most collisions. It does not remove all of them, and the ones that survive are the ones people stop watching for.
The level file itself. Partition settings, grid configuration, and data layer definitions all live in the .umap. Two people changing those at once still conflict, and the file is binary, so there is no merge.
Individual actors. Two people can absolutely reach for the same hero prop or the same scripted volume. Their changes now land in one small file rather than one enormous one, which makes the loss smaller but no less real.
Shared Blueprints and materials. These were never covered by World Partition at all. A master material used across the world is one binary asset with one editor at a time.
Per-file locking handles all three the same way. Lock what you are about to edit, and everyone else finds out instantly instead of at merge time. Because locks are per file, the rest of the world stays open, which is the whole point of the feature.
A setup checklist
Everything above, condensed into what to actually do:
✓ Version __ExternalActors__ and __ExternalObjects__ (this IS your level)
✓ Version the .umap (grid + data layer definitions)
✓ Exclude Saved/, Intermediate/, DerivedDataCache/, Binaries/, Build/
? HLOD/ — pick commit or exclude, document it, apply it consistently
✓ One data layer per discipline on shared areas
✓ Lock before opening: level file, hero actors, shared materials
✓ Announce data layer creation and renames — they touch the shared .umapIn USourceControl the exclusions in that list are already the defaults, so most teams only need to make the HLOD call and agree on the locking habit. The setup guide covers the rest of the first-commit walkthrough.
Frequently asked
Can multiple people edit the same World Partition level at once?
Yes. That is what World Partition and One File Per Actor were built for. Each actor is saved in its own file, so people working on different actors never touch the same file and never conflict. Locking covers the remaining cases where two people reach for the same actor or change the level file itself.
Should I commit the HLOD folder?
Either choice is defensible, as long as it is consistent. Committing it guarantees identical results across machines and build agents and saves rebuild time. Excluding it keeps history smaller when artists regenerate frequently. What causes real problems is a partially committed HLOD directory, so decide once and document it.
Do data layers replace sublevels for team organization?
Largely, yes. Data layers group actors logically rather than spatially, so they map onto disciplines and passes rather than onto geography. One layer per discipline over shared areas is a common pattern. Note that layer definitions live in the .umap, so creating or renaming one touches the shared level file.
What still causes conflicts in a World Partition project?
Three things: the .umap itself (grid settings and data layer definitions), individual actors when two people edit the same one, and shared assets like master materials and Blueprints that World Partition never covered. All three are binary and unmergeable, so per-file locking is the answer to each.
Does World Partition work with Perforce and Git?
Perforce handles it well; its locking and file handling suit OFPA's many-small-files pattern, which is part of why it stays the AAA default. Git with LFS technically works but degrades as the world fills, because each actor file needs its own pointer and the index grows accordingly. USourceControl treats many small binaries as the normal case, with per-file locking and delta sync.
How big can a World Partition project get?
On USourceControl, storage and bandwidth are unlimited on every plan including Free, with a 5 GB ceiling per individual file and up to 25,000 files in a single commit. A full level rebuild fits in one operation.