Open-World Streaming

01The world doesn't fit

The player can ride to any mountain on the horizon without a loading screen, but the whole world will never fit in memory at once. A modern open world is tens to hundreds of gigabytes on disk; runtime memory is a fraction of that. The streamer's job is to keep resident only the slice of the world near the camera, paging cells in as the player approaches and out as they recede. Mark Cerny's PS5 talk framed the change in exactly these terms: on PS4, system memory had to hold everything the next 30 seconds or so of gameplay might use, while a fast enough SSD lets a game load data when it turns out to be needed instead of parking it in RAM in advance^[1].

02Partitioning into cells

Streaming needs a unit: something small enough to load in the background and large enough that the loader isn't juggling millions of separate objects. Cut the world into a grid of cells (sometimes called sectors or tiles): each cell owns the actors, meshes, and collision in its footprint, baked as one loadable unit. The cell the player stands in plus a radius of neighbors is what stays resident. Unreal's World Partition does this with a 2D runtime spatial hash grid by default, which removed the need to split large maps into hand-managed sublevels^[2]. The grid-versus-quadtree mechanics are the Spatial Partitioning tutorial's territory; here the only new state per cell is its residency.

The map below streams cells around a wandering player. It starts with the cells around the player resident, as if a loading screen had filled them. Cells inside the load radius queue, then load over real time; cells past the eviction radius are freed. Drop the bandwidth or raise the speed until the player outruns the loader and the player dot turns red: that's pop-in:

03Loading radius & priority

A dozen cells are queued and the loader can fetch a few a second. Which goes first? The set of cells to keep resident is a streaming volume around each streaming source (usually the camera, sometimes also a fast vehicle or a spectated player). Within that volume, requests are ordered by priority rather than issued all at once. A common priority blends three signals.

• Distance. Nearer cells first; they are what the player reaches soonest.
• Visibility. Cells inside the view frustum outrank cells behind the camera. Unreal's texture streamer uses the same family of heuristic, ranking by the on-screen texel-to-pixel ratio and whether a thing is visible at all^[4].
• Velocity prediction. Bias the volume along the predicted path so a cell finishes loading before the player arrives, rather than as they cross into it.

04Getting the bytes

Read a cell's file on the thread that draws frames and the game freezes for as long as the disk takes. A queued cell's data is read on a worker thread, never on the thread that draws frames. This is the stage most often assumed to be the bottleneck. The File Streaming tutorial built the async read path and the residency pool; the streamer dispatches cell loads onto the job system and is handed back a buffer when the read completes.

05The integration budget

The game holds 60 fps on an NVMe SSD, yet it stutters for one frame every time the player crosses into a new region. The load-bearing idea of the whole tutorial: a streaming hitch (one frame that blows the budget) is usually not the disk read. On an SSD the bytes are already in RAM by the time you notice. A common cause is the main-thread cost of making the loaded data live: registering components, building GPU resources, adding primitives to the scene, creating physics bodies. In Unreal, making a streamed level visible runs AddToWorld, which applies the level transform, updates and registers components, initializes actors and routes their initialization functions^[9]; Epic's level-streaming hitching guide covers how to spot these hitches in Unreal Insights captures^[7]. Unity's Addressables documentation says the same of scene loads: the load is async, but "the final part of scene loading requires operation on the main thread. This can be blocking."^[8]

A cell finishes loading every second or so and brings a chunk of main-thread integration work. Integrate it all at once and the frame bar spikes over the 16.7 ms line (a hitch); time-slice it and the frame stays smooth while the cell takes a few extra frames to go live:

// Worker thread (NOT the frame thread): read the cell, then queue it for activation.
void onCellLoaded(Cell& cell, Bytes raw) {
    cell.deserialize(raw);                  // parse off-thread; still not "live"
    std::lock_guard lock(handoffMutex);     // workers and the frame thread share this list
    loadedCells.push_back(&cell);           // hand to the main thread
}

// Main thread, once per frame: spend only the budget, finish the rest next frame.
void integrateStreamedCells(std::chrono::microseconds budget) {
    {
        std::lock_guard lock(handoffMutex); // take what the workers finished; lock held briefly
        pendingIntegration.insert(pendingIntegration.end(), loadedCells.begin(), loadedCells.end());
        loadedCells.clear();
    }
    auto sliceStart = std::chrono::steady_clock::now();
    while (!pendingIntegration.empty()) {
        if (std::chrono::steady_clock::now() - sliceStart > budget) break;  // time-slice (cf. UE's update time limit)
        Cell* cell = pendingIntegration.front();
        if (cell->integrateNextChunk())     // register a few components / upload one batch
            pendingIntegration.pop_front(); // the cell is fully live
    }
}

// Worker thread: read + parse the cell, then hand it to the main thread for activation.
fn on_cell_loaded(mut cell: Cell, raw: Bytes, loaded: &Sender<Cell>) {
    cell.deserialize(raw);                  // parse off-thread; still not "live"
    loaded.send(cell).ok();                 // move it to the frame thread
}

// Main thread, once per frame: spend only the budget, finish the rest next frame.
fn integrate_streamed_cells(world: &mut World, loaded: &Receiver<Cell>, budget: Duration) {
    world.pending_integration.extend(loaded.try_iter());   // take what the workers finished
    let slice_start = Instant::now();
    while let Some(cell) = world.pending_integration.front_mut() {
        if slice_start.elapsed() > budget { break; }       // time-slice
        if cell.integrate_next_chunk() {                    // register / upload one quantum
            let live = world.pending_integration.pop_front().unwrap();
            world.add_live_cell(live);                      // fully live
        }
    }
}

06Eviction & persistence

Memory fills as the player explores, so something has to go. Cells leave memory when the player moves away. A streaming-memory counter or a distance or LRU policy decides what goes. The GTA III-era engine kept a counter that rises by each resource's size on load and falls on unload; over the limit, it frees resources nothing is using first, then buildings, preferring ones out of sight and far away^[10]. The less obvious question is when to evict.

07LOD, HLOD & the far field

A cell beyond the load radius still has to be seen if it's on the horizon. Rendering it at full detail blows the budget; showing nothing leaves a hole. The answer is detail that falls off with distance: full meshes near, lower LOD at mid range, and a single baked HLOD proxy for the unloaded far cells. Unreal builds HLOD proxies offline (instanced, merged or simplified meshes) to stand in for unloaded World Partition cells and cut draw calls in the distance^[11].

The widget shows concentric rings of detail around the player, with illustrative per-cell triangle counts. Near cells are full meshes, mid cells drop to a cheaper LOD, far cells collapse to an HLOD proxy. Toggle HLOD off and the far field reverts to full meshes and blows the triangle budget; the other alternative is an empty horizon that pops in as you approach:

Texture detail streams on the same principle one level down: pick a mip from the on-screen texel-to-pixel ratio and the memory budget, dropping one mip at a time when the plan is over budget^[4]. Sparse virtual texturing takes that further, mapping a small physical cache to a huge logical texture through a page-table indirection. Many implementations decide which pages to stream from GPU feedback (a readback of which pages the visible pixels needed); clipmaps, an older scheme that suits terrain, instead keep a window of each mip level centered on the viewpoint and need no feedback pass^[12]. The File Streaming tutorial derives SVT and the I/O fast path in full. Texture streaming is a related but distinct system from world-cell streaming.

Wrong answers, and why: a per-region stutter on an SSD is main-thread integration (time-slice it), not the disk or cell size; a blob-then-detail swap is pop-in (throughput), not a hitch or GC; and boundary thrash is fixed by asymmetric load/evict radii (hysteresis), not by resizing cells or never evicting.

08Pitfalls

09What's next

Streaming keeps the world resident around the player; the changes the player makes to it have to outlive the session. The next module, Save Games & Serialization, persists that mutable state: the object graph (you cannot write a pointer to disk), versioning so old saves still load, and the atomic write that keeps a crash from corrupting a save. The full path is on the series hub.

1. Mark Cerny. "The Road to PS5" (2020). Talk on YouTube; coverage by Dean Takahashi, VentureBeat, "PlayStation 5: Mark Cerny's deep dive into SSD memory" (archived copy). On PS4, system memory held everything the next 30 seconds or so of gameplay might use; a fast SSD lets data load when it is needed.
2. Epic Games. "World Partition in Unreal Engine." dev.epicgames.com. The default 2D runtime hash grid of streaming cells, streaming sources, an example configuration of 256 m cells with a 768 m loading range, and that it removes the need to split large maps into sublevels.
3. StraySpark (2026). "World Partition Deep Dive: Streaming, Data Layers, and HLOD for Massive Open Worlds." strayspark.studio. Cell size as a churn-versus-memory-spike tradeoff, with 64 m, 128 m and 256 m cells compared.
4. Epic Games. "Texture Streaming Overview" (Unreal Engine 4.27). dev.epicgames.com. Mip selection from the resolution needed for a good texel-per-pixel ratio plus visibility; visible mips load first; over budget, the planned quality drops one mip at a time.
5. Oracle. "An Introduction to the io_uring Asynchronous I/O Framework." blogs.oracle.com. The submission/completion rings and batching many reads through one io_uring_enter.
6. Tokio. tokio::fs module documentation. docs.rs. File operations run as ordinary blocking calls on a spawn_blocking thread pool "because most operating systems do not provide asynchronous file system APIs"; io_uring is named as a possible future backend.
7. Epic Games. "Level Streaming Hitching Guide." dev.epicgames.com. How to recognize common level-streaming hitches in Unreal Insights captures, with links to settings that address them.
8. Unity Technologies. Addressables LoadSceneAsync. docs.unity3d.com. The load is async, but "the final part of scene loading requires operation on the main thread. This can be blocking."
9. Peter Leontev. "Level Streaming and Garbage Collection Optimization Tweaks in UE4." peterleontev.com. What AddToWorld does when a level becomes visible, s.LevelStreamingActorsUpdateTimeLimit time-slicing it across frames, the component-registration granularity, and forced versus incremental GC after levels stream out.
10. GTAMods Wiki. "Resource Streaming." gtamods.com. The GTA III / Vice City / San Andreas streamer: a five-state pipeline per resource, a streaming-memory counter driving eviction (unused resources first, then distant and out-of-sight buildings), and disc reads ordered by position on the disc.
11. Epic Games. "World Partition — Hierarchical Level of Detail." dev.epicgames.com. Offline-built HLOD layers (instanced, merged or simplified meshes) standing in for unloaded grid cells to cut distant draw calls.
12. J.M.P. van Waveren. "Software Virtual Textures" (2012). mrelusive.com; Andreas Neu. "Virtual Texturing" (arXiv:1005.3163, 2010). arxiv.org. The page-table indirection and the GPU-feedback residency path (van Waveren); Neu's survey of earlier schemes, including clipmaps, which clip each mip level to a window around the viewpoint and suit terrain.
13. NVIDIA. "Accelerating Load Times for DirectX Games and Apps with GDeflate for DirectStorage." developer.nvidia.com. GPU decompression speeds bytes-to-VRAM (load time and pop-in), which is a different leg from the main-thread integration hitch.