City chunks and floating origins keep large exports manageable
A city chunk is a bounded piece of terrain, road or infrastructure stored with local vertex coordinates and a recorded world-space origin. This structure avoids one monolithic mesh, supports selective replacement and gives an importer explicit data for reconstructing the city.
Last updated: 25 August 2026 · City manifest version 3 and incremental chunk export verified
- 256 × 256 mDeterministic physical chunk grid
- Local geometryVertices stay near a chunk origin
- Manifest v3Origins, bounds, materials and dependencies
- IncrementalExport explicit dirty chunk IDs
World position equals local position plus chunk origin
Large coordinates can make geometry harder to inspect and manage. In a floating-origin handoff, a chunk records an originMeters value while its vertices remain local to that origin. An importer places the chunk resource at the recorded origin to recover its world position.
Conceptually, reconstruction is simple: worldPosition = originMeters + localVertexPosition. The manifest is therefore part of the asset, not optional documentation. Moving only a GLB without its manifest entry discards the context needed for deterministic placement.
This export structure uses local floating-origin coordinates. It does not automatically configure an engine's runtime world-origin rebasing, streaming system or World Partition.
What manifest v3 describes
| Resource | Packaging model | Placement data |
|---|---|---|
| Buildings | Independent GLB files with local pivots | World transforms retained for each placed asset |
| Terrain | Geometry clipped into deterministic physical chunks | Chunk origin and three-dimensional bounds |
| Roads | Chunk-local road resources under stable paths | Origin, bounds and explicit dependencies |
| Infrastructure | Chunk-local supporting geometry | Origin, bounds and stable material identifiers |
| Manifest | manifest.metropolygonia-city.json | Version, included chunks, assets and reconstruction metadata |
Reconstruct a package without guessing
- Read the manifest first.Verify the manifest version and whether the package is complete or incremental before importing resources.
- Resolve stable resource paths.Load the building assets and the resources listed beneath each included chunk rather than scanning filenames heuristically.
- Apply recorded placement.Use each building transform and each chunk's origin. Do not bake a second offset into already-local geometry.
- Respect dependencies.Use explicit dependency and material identifiers when deciding what must be refreshed with a changed chunk.
- Validate boundaries.Inspect adjacent chunks for gaps, overlaps, duplicate resources and material discontinuities.
Choose the package from the update operation
A full-city ZIP is the baseline transfer: it carries the complete set represented by the export. Use it for the first import, a clean rebuild or a pipeline verification pass. An incremental ZIP contains explicitly requested dirty chunk IDs and marks exactly which chunks are present. Use it only when the destination already has a compatible baseline and can replace selected resources transactionally.
- Do not interpret a missing chunk in an incremental package as a deletion unless your update protocol explicitly says so.
- Track the manifest version and source project alongside the imported city.
- Replace all resources and dependencies listed for a dirty chunk as one update.
- Keep buildings independently manageable when their placement or asset identity changes outside chunk geometry.
Chunking is a handoff structure, not runtime optimisation
Chunks give a destination pipeline smaller addressable resources and explicit local coordinates. They do not decide when the game streams a chunk, what becomes an HLOD, how collision is generated or how navigation crosses boundaries. Those choices depend on the engine, target hardware and gameplay.
Test a central chunk, an outer chunk, a road crossing, elevation changes and a boundary with placed buildings. Large exports and unusual terrain or road junctions still require project-specific verification.
City chunk FAQ
Why not export one city mesh?
One mesh is harder to replace, stream, cull and inspect. Separate buildings and physical chunks preserve more useful asset boundaries.
Are chunk coordinates already world coordinates?
The physical chunk geometry is local to its recorded origin. Use the manifest origin to reconstruct world placement.
Can I import only changed chunks?
Yes, the current exporter supports explicit dirty-chunk packages. The destination must already understand the compatible baseline and replacement rules.
Does this create Unreal Engine World Partition?
No. The package supplies structured source assets and placement metadata. Engine-specific World Partition, streaming and optimisation remain downstream work. See the Unreal Engine guide.