beezm
3b5bc5e5d6
Core: BlockRegistry gains WATER, with the reason it is wire-safe (block IDs are never serialized) AND the reason it is a registry identity only rather than a voxel the terrain path writes. Corrects the now-false line "Nothing at runtime consumes the water data yet" -- it does, as of this task. ChunkData's new per-column water fields and the Constants tunables. Client: how the water sheet is built and, more importantly, WHY it is a second mesh instead of a block in the density field -- the trap here is that writing water into a Marching-Cubes field fuses it into the terrain instead of laying it on top, and that is not obvious until you have done it. Notes translucency came free from the separate material. Server: the per-column water rule, which section is the authority for what (WBID presence, WSRF level, WBTB fallback), that an unknown body leaves the column dry rather than guessing, and why depth for shading comes from blueprint heights rather than the clamped rendered geometry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
65 lines
4.2 KiB
Markdown
65 lines
4.2 KiB
Markdown
# Server Module
|
||
|
||
Authoritative world building. Turns the static `WorldBlueprint` in RAM into physical 3D chunks. In a
|
||
future multiplayer setup this is the side that dictates terrain and ships chunk data to clients.
|
||
|
||
## `ServerChunkManager.cs`
|
||
|
||
Attached to the `World` root node of `Scenes/Main.tscn`. Runs the whole 3D world at boot.
|
||
|
||
### Startup
|
||
1. Loads `ServerConfig.json` and the seed's `.dat` blueprint (v2 or legacy v1 — the parser
|
||
dispatches automatically; see `Core/Scripts/BLUEPRINT_FORMAT.md`).
|
||
2. **Cross-checks the blueprint's embedded params** (v2 only) against the config and logs a
|
||
prominent `BLUEPRINT/CONFIG DESYNC` warning if the seed or MapSize disagree — a config edited
|
||
after generation is loud now, not silent.
|
||
3. **Finds the Capitol** in the parsed town list and uses it as the world origin point.
|
||
4. Converts its pixel position to chunk coordinates (`pixel / CHUNK_SIZE`).
|
||
5. Builds a `(2 × ChunkRadius)²` grid of chunks around it — **synchronously, all at boot**.
|
||
6. Teleports the `Camera3D` to 120 m above the Capitol, looking down.
|
||
|
||
⚠ **Two things to know about startup.** The chunk grid is built in one blocking pass with no
|
||
streaming or unloading, so `ChunkRadius` directly controls boot cost — 32 means 4,096 chunks and
|
||
roughly 3.6 GB. And the camera `LookAt` points straight down, which is a degenerate case: the up
|
||
vector ends up parallel to the view direction, so camera roll is undefined and Godot logs a warning.
|
||
|
||
### Per-chunk generation
|
||
- **Road culling first.** Only the road segments whose bounding box reaches this chunk are kept,
|
||
each tagged with its `RoadTier`. The padding is derived from the widest shoulder any tier has plus
|
||
a margin, so widening a road cannot silently truncate it at chunk edges.
|
||
- **Water per column** (task 13) — the blueprint is the **authority** on where water is; the server
|
||
only reads it. `WBID` decides presence (it is the water stage's own classification output, the
|
||
same set the biome grid's Ocean/Lake pixels form by construction), `WSRF` gives the surface level
|
||
per pixel, and the `WBTB` body table is the fallback when a column is flagged wet but carries the
|
||
`WSRF` no-water sentinel. A body the table does not know leaves the column **dry** rather than
|
||
guessing a level. The level is scaled by the same `HEIGHT_SCALE` as the terrain, so the sheet and
|
||
the seabed cannot drift apart. Depth for shading is taken from **blueprint** heights, not rendered
|
||
geometry — the terrain render clamps its floor at `Y = 2`, which would otherwise flatten every
|
||
deep-ocean column to one value. Each run logs what it drew (`[Server] Water at rest: …`).
|
||
- **Surface height per column** (`GetExactSurface`) — the blueprint height scaled into the chunk's
|
||
usable vertical band, then modified by any road carving.
|
||
- **Density per voxel** — `(y − surfaceY)` normalised by the local slope, giving a signed distance to
|
||
the surface. Positive above, negative below.
|
||
- **Block IDs per voxel** via `BiomePalette`, plus the per-column data the renderer needs.
|
||
- Hands the finished chunk to a `ChunkRenderer`.
|
||
|
||
### Road carving
|
||
All four tiers carve, each with its own character (widest and smoothest for highways, narrow and
|
||
terrain-hugging for trails — values in `Constants.cs`).
|
||
|
||
For each column, the carve finds **the nearest road whose shoulder actually reaches it** — not simply
|
||
the nearest road, since tiers have different reach and a nearby footpath must not shadow a highway
|
||
still covering the column. It then reads the roadbed height at the closest point *along* that
|
||
segment, blending between a straight ramp between the segment's endpoints ("holds a grade") and the
|
||
terrain directly beneath ("hugs the land") according to the tier.
|
||
|
||
Inside the road radius the column is flattened to that height and flagged with the tier's surface
|
||
material; out to the shoulder radius it eases back to natural ground with a smoothstep.
|
||
|
||
`HeightAtPixel` samples the heightmap **bilinearly** — road path points are fractional, and nearest-cell
|
||
sampling produced a metre-scale staircase along the roadbed.
|
||
|
||
## Not here yet
|
||
No chunk streaming or unloading, no collision, no networking, no player. The "server" is currently a
|
||
node in the same scene as the renderer — the server/client split is structural, not a process
|
||
boundary.
|