3. Target architecture

What the decisions add up to: one grid, two representations, two meshers, two damage models, two pipelines — and a subsystem-by-subsystem delta from the code today.

The shape of it

                          VoxelWorld  (hash map of chunks, streamed)
                       per cell: type | material | density | class
                                        │
                 ┌──────────────────────┴──────────────────────┐
                 │                                             │
          class == Terrain                            class == Construction
                 │                                             │
       density field, 0..255                        discrete, always full
                 │                                             │
        ┌────────┴────────┐                           ┌────────┴────────┐
        │  MarchingCubes  │                           │   CubeMesher    │
        │     Mesher      │                           │   (+ greedy)    │
        └────────┬────────┘                           └────────┬────────┘
                 │  construction reads as                      │
                 │  full density → surface                     │
                 │  closes against walls                       │
                 │                                             │
        ┌────────┴────────┐                           ┌────────┴────────┐
        │ terrain pipeline│                           │ cube pipeline   │
        │ triplanar+splat │                           │ per-face UV +   │
        │ gradient normals│                           │ crack overlay   │
        └─────────────────┘                           └─────────────────┘
                 │                                             │
                 └──────────── interpenetrate ─────────────────┘
                              (no shared boundary)

Two damage models

The split from D5 / D6 reaches further than rendering — it decides where the state lives and what a strike costs.

Terrain: damage is density

1. A strike subtracts from Voxel::density in the dense chunk array.
2. The chunk goes dirty; Marching Cubes rebuilds it; the new surface is uploaded.
3. The surface has visibly receded around the struck cell — because MC interpolates between neighbouring densities, lowering one cell pulls the surface inward and dimples its neighbourhood rather than cutting a cube-shaped bite.
4. When density falls past the threshold, the cell is empty and the dimple becomes a hole.

No separate damage record exists. Persistence, collision solidity, the material blend and the visible shape are all driven by the one byte.

Construction: damage is a shader lookup

1. A strike increments the sparse DamageMap entry for that cell.
2. Nothing is remeshed. The geometry is unchanged by definition.
3. Per chunk, a small damage buffer or texture — indexed by cell coordinate — is updated and read by the fragment shader, which blends a crack overlay from a stage texture array over the base tile.
4. At full damage the cell is cleared, which does dirty the chunk — once, at the end, instead of on every hit.

Why chunks at all?

A reasonable question, given how much of the design spends effort on chunk seams: why not mesh all visible terrain as one buffer and have no seams to reconcile?

Because rebuild granularity is set by edit granularity, not by render granularity. Under D5 every strike changes one density byte, and the cost of that depends entirely on how much geometry has to be rebuilt in response. For a 12-chunk radius with bounded Y = 384:

Roughly 500× the work per swing. Patching sub-ranges of the big buffer instead requires knowing which byte ranges changed — which is a spatial partition of the buffer, i.e. chunking again, implicit and harder to reason about. Four further reasons, in rough order of severity: streaming (chunks enter and leave constantly while walking, each a full rebuild), frustum culling (one mesh is one draw and cannot be culled; per-chunk culling typically discards ~70% at that radius), parallelism (chunks are the unit of work for the job queue — one mesh is one job on one thread), and LOD (per-region resolution is its definition).

Against that, the seam cost is small: one ownership convention — a chunk owns the MC cubes whose minimum corner lies inside it — and one rule — evaluate each edge crossing from its lower-coordinate endpoint. Both are verified by the exhaustive table test.

What you can have instead: a suballocated arena

The instinct behind the question has a real answer. Separate the two concerns that "one mesh" conflates:

• Chunk = the unit of rebuild and culling. Must be small, because edits are frequent and local.
• Buffer = the unit of allocation. Can be huge.

Place every chunk's mesh into one large GPU vertex/index buffer as sub-ranges and draw them with multi-draw-indirect: one buffer binding and effectively one submission for all visible terrain, while still rebuilding only the ~110 KB that changed. Strictly better than a monolithic mesh — the same render efficiency without the update cost.

Today's code is one buffer and one draw per chunk (ChunkRender in Engine.cpp), which is the simple version. The arena is a later optimisation, not a phase-3 requirement. One wrinkle if it is taken: chunks carry a per-chunk model matrix today, and batched drawing needs that offset per-draw instead — a push constant or an instance buffer. Keep positions chunk-local rather than baking world space: the world is bounded now (D7), but its size is a parameter, and float precision still degrades with distance from the origin — a centre-anchored multi-kilometre world puts geometry several thousand units out in every direction.

And the chunk size is a dial

32³ is a default, not a law: bigger chunks mean fewer seams, fewer draws and a better surface-to-volume ratio, but rebuild cost scales with the cube of the side — 64³ is 8× the rebuild per edit. Minecraft uses 16³ sections; 7 Days to Die uses 16×16 columns with sub-chunks. If per-edit cost ever dominates, the lever is sub-chunk dirty regions rather than smaller chunks: keep the draw-side benefits of a large chunk and shrink only the rebuild unit.

Subsystem delta

Things that stay exactly as they are

Worth naming, because they are the parts of the existing design that were built for this and do not need to move:

• IMesher — the strategy interface takes a volume plus a neighbour source and returns plain MeshData. Marching Cubes fits behind it unchanged.
• IVoxelSource — resolves samples outside a chunk's own bounds. MC needs a one-cell border to mesh seam-correctly; this is exactly what provides it.
• terrainFieldDensity() — reports construction cells as full density. The single function that makes "terrain closes against walls, no shared boundary" work.
• The renderer interface layer — IRenderer, IRenderPipeline, ICommandBuffer. A second pipeline is an addition, not a change.
• The dirty-flag protocol on VoxelWorld::set, including marking border-adjacent neighbours. MC needs this for the same reason the cube mesher does.
• The chunk-coordinate bit-packing already written for the DamageMap key — a ready-made hash key for the streamed chunk map.

Where the two representations touch

Three interactions, all of which have an answer that avoids the trap from Epic #24: