How to Seamlessly Transition Between Two Large World Partition Maps at Runtime?

Hello everyone,

I am developing an open-world game in UE5 and have two very large city maps. Each city is a separate level that uses World Partition.

I would like to know how to transition between these two World Partition maps at runtime while making the transition appear seamless to the player.

My requirements:

  • Both cities are very large and use World Partition for automatic world streaming.

  • Each city should remain a separate map so that I can develop and maintain them independently.

  • The player should be able to travel from one city to the other during gameplay.

  • Ideally, the transition should happen without a visible loading screen, black screen, or noticeable interruption to gameplay.

  • The destination city should be loaded and ready before the player arrives, if possible.

My questions:

  1. Is it possible to preload a second World Partition map while the player is still exploring the first map?

  2. What is the recommended approach for transitioning between two independent World Partition maps without a noticeable loading pause?

  3. Can Level Streaming or other UE5 streaming systems be used alongside World Partition to achieve this?

  4. Would you recommend keeping both cities as separate maps, or combining them into a single World Partition map?

  5. Are there any engine limitations or important considerations regarding memory usage, streaming performance, and lighting when implementing this?

I would appreciate any recommendations for the appropriate architecture, relevant UE5 features, or practical implementation examples in Blueprint or C++.

Thank you!

You cannot have two World Partition worlds loaded and streaming as one world. World Partition streaming belongs to a single UWorld: one persistent level owns the grid, the runtime cells, and the streaming source. Streaming a second World Partition map in as a sublevel does not merge the two grids, and Open Level on a World Partition map is a travel. That travel always has a load, even if you hide the loading screen.

What actually works:

One World Partition map, with the two cities far apart on the same grid, or split by Data Layers. This is the only setup that streams with no travel. The cost is memory. Keep cell size and HLODs so you are not holding both cities at full detail, and use Data Layers so you can load one city in the editor while the other stays unloaded. Lighting stays consistent because it is one world. Two maps will not share a Lumen scene without a reload.

Separate maps, if you really need independent packages. Travel is the supported path. You cannot preload the destination world’s grid while the source world is still current. The usual pattern is a small corridor or vehicle interior that is its own light level: start the travel while the player is in that corridor, and only hand over when the destination’s first cells are up. The player does not see a hard cut. Seamless travel (bUseSeamlessTravel) only removes the engine loading screen. On a large World Partition map it still hitches, because the load is still there.

A streaming source only feeds the active world’s grid, so do not try to drive both cities from one player. One map plus Data Layers if the crossing has to be truly seamless. Separate maps plus a corridor and a travel if they have to stay separate packages, and treat “no loading at all” as unavailable across a world boundary.

Thank you for your answer. I tried creating a non-World Partition persistent level as my main level, while enabling World Partition in the sublevels. I then streamed different WP sublevels through the main level. The World Partition streaming functionality works as expected, and multiple WP levels can coexist and remain active simultaneously within the persistent level.

Although this setup already meets my requirements, I’m still unsure whether there are any potential risks or limitations. My current test levels contain only a small number of Actors and relatively small environments, so I can’t yet determine whether this architecture will cause any performance or stability issues as the map grows significantly in size.