beezm
69bf91b3d6
Closes the C1-polish carryover. The cause was confirmed by a read-only dump BEFORE any code was written, per the filed note's discipline; the chat had guessed twice from screenshots. DIAGNOSIS. WBID is classified from the UNCURVED heightmap — the classify path that keeps the biome/water oracle byte-identical through all of Phase B — while the mesh renders the CURVED one. Outside the crater those two agree EXACTLY, and provably so: the curve is identity at sea and monotonic, so Apply(raw) < sea iff raw < sea. Inside the crater they do not. The carve lerps two different bases toward one target -- classify from raw, rendered from Apply(raw) -- and Apply(raw) < raw throughout the lowland band (the toe compresses raw 0.15..0.516 into 0.15..0.206). So the rendered surface sinks FASTER than the classify surface, leaving an annulus that renders below the waterline while WBID still calls it dry. MEASURED, seed 1825907253, map-wide: wet columns 32,799,866 WATER-OVER-DRY (wet, mesh above Y) 1,101 scattered, not the story DRY-UNDER-WATER (dry, mesh below sea) 375,824 <- the seam ...of which inside the crater carve: 100 % Dump across the gradient at z=905: at x=3800 the classify surface sits at 47.55 m while the mesh renders 22.38 m -- 25 m apart, no water drawn. The ring is west of the Capitol, which is exactly the developer's "flush on the right, lifted toward the left". Neither of the task's two candidate causes, and worth saying so: the water LEVEL is flat and correct at 37.65 everywhere it is drawn (rules out B), and the per-cell flat sheet is a rounding error next to this (1,101 px vs 375,824). It is the filed note's classify-vs-render mismatch, with the crater carve as the mechanism. THE FIX. Presence now takes two clauses: the blueprint's classification, OR the rendered ground actually being under the ocean's surface. The second clause tests exactly what the mesh draws (exactSurfaceY) against the OCEAN BODY'S OWN level from WBTB -- the runtime still derives nothing, it only notices that the ground it is drawing is under a surface the blueprint gave it. By the identity above that clause can only ever fire inside the carve, which is precisely the flooded bay it exists for. MEASURED after, same seed: 241,415 -> 358,576 water columns, 454 -> 648 chunks, 117,161 seam columns recovered in the loaded region. Each run now reports its own seam count. 2D PIPELINE UNTOUCHED, verified rather than asserted: the only changed file is the runtime chunk manager, and a regeneration is byte-identical to task 13's in every section but PRMS (timestamp + git hash). All four snapshot PNGs md5-identical. Static flat sheet, no animation, no water DATA change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| Scripts | ||
| README.md | ||
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
- Loads
ServerConfig.jsonand the seed's.datblueprint (v2 or legacy v1 — the parser dispatches automatically; seeCore/Scripts/BLUEPRINT_FORMAT.md). - Cross-checks the blueprint's embedded params (v2 only) against the config and logs a
prominent
BLUEPRINT/CONFIG DESYNCwarning if the seed or MapSize disagree — a config edited after generation is loud now, not silent. - Finds the Capitol in the parsed town list and uses it as the world origin point.
- Converts its pixel position to chunk coordinates (
pixel / CHUNK_SIZE). - Builds a
(2 × ChunkRadius)²grid of chunks around it — synchronously, all at boot. - Teleports the
Camera3Dto 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.
WBIDdecides presence (it is the water stage's own classification output, the same set the biome grid's Ocean/Lake pixels form by construction),WSRFgives the surface level per pixel, and theWBTBbody table is the fallback when a column is flagged wet but carries theWSRFno-water sentinel. A body the table does not know leaves the column dry rather than guessing a level. The level is scaled by the sameHEIGHT_SCALEas 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 atY = 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.