An asset becoming available is not the same event as an asset becoming safe to use. A worker may have decoded bytes while the scene is still using an older revision. A GPU command may still reference a resource after the CPU has decided that a finer representation is preferable. Physics may need collision data long after the camera has turned away.
The streamed-world work makes those lifetimes explicit. The aim is to show a coarse representation promptly, then refine within bounded I/O, staging, upload, and publication budgets. The coarse result is a usable fallback, not an excuse to stall the frame while an unbounded queue catches up.
A handle needs an identity and a lifetime
The residency contract uses stable identities and immutable revisions. A request for a particular asset can therefore be cancelled or replaced without making an unrelated request accidentally refer to the same storage. Generation information matters because a recycled slot must not make an old handle valid again.
CPU payload ownership belongs to the asset side. GPU cache ownership belongs to the renderer. World systems request what they need, with priorities, rather than allowing an arbitrary worker to mutate a scene or record into a buffer already in use. Those boundaries are less visually exciting than a loading transition, but they are what make the transition repeatable.
An eviction decision must account for every relevant owner. The camera’s lack of interest is not permission to remove collision beneath an active body. Conversely, retaining every resource forever to avoid that mistake would merely turn a correctness problem into a memory problem.
Budgets need to describe different kinds of work
Bytes read, bytes decompressed, CPU payload memory, staging memory, and GPU uploads are related but different quantities. A single generic loading budget can hide a large temporary peak. The contract tracks the work separately and keeps the worker count bounded.
Publication is another cost. Producing a replacement off-thread does not make the scene update free. The owning thread still needs to admit the result at a safe point, preserve the old fallback until the new representation is ready, and retire replaced data only when its users are finished.
The following is explanatory pseudocode for that ownership sequence, not an engine API:
request immutable asset revision with a bounded priority
prepare replacement while the coarse representation stays usable
when staging is ready and publication budget permits:
publish on the owning thread
retain the previous representation for its remaining users
retire previous data only after its leases and GPU work completeThe final condition is intentionally separate from publication. Showing the new asset is not proof that the old one’s last GPU command has finished.
The Vulkan synchronization guide provides the lower-level background: execution order and memory visibility are explicit responsibilities. In this engine, that requirement appears as resource ownership and graph declarations rather than as a promise that the CPU’s latest pointer swap instantly changes work already queued on the GPU.
Detail has to survive cooking
The car inspector in Drune is valuable because it exposes the actual cooked asset instead of showing an unrelated source model. Stored detail levels, bounds, and metadata can be compared with the representation selected in a running view. That closes a gap between authoring intent and shipped data.
Meshoptimizer’s documentation is useful background for simplification and mesh processing. It describes ways of changing a mesh’s representation and storage. It does not, by itself, decide when a particular game may discard a representation or how that representation relates to collision. A streaming system needs both the processed data and the surrounding ownership policy.
This is also why source resolution, rendered terrain resolution, and collision resolution should be named separately. They may share an origin, but they solve different problems. A diagnostic label that conflates them can make a valid implementation look broken, or conceal an invalid comparison.
A shipped foundation does not finish every consumer
The coarse-first residency milestone was accepted and merged on 18 October. The 29 October Glasswake request goes further: start from a minimal menu, fetch the minimum playable scene after Play, prioritize nearby needs, and refine only when measured headroom permits. That later issue was still in progress in the audited tracker.
These are connected stages, but they are not interchangeable claims. The older milestone establishes ownership and bounded residency. The newer consumer work must prove the complete delivery path, including hashes, cache identity, cancellation, retries, visible refinement, and the first usable frame. Keeping that distinction in the journal makes progress more informative than a single percentage labelled loading.
References & further reading
Primary papers and documentation related to the techniques discussed here. Research references explain the background; the article describes implementation and validation at its dated checkpoint.
Have a thought or a question?
I'd love to hear it. ↗