The blueprint has carried water since task 03 -- WBID per-pixel body id, WBTB body table, WSRF per-pixel surface level. Nothing ever drew it. Now the runtime does. No new water data: the blueprint is the authority on where water is and at what level, and this only reads it. WHY WATER IS ITS OWN MESH, not a block in the terrain field. The terrain is a Marching-Cubes iso-surface over ChunkData.Densities. Writing WATER into that field would not lay a sheet on top of the seabed -- it would move the iso-surface, fusing the sea into the terrain as if it were solid ground. A second surface is the only way water can sit at ITS level independent of the ground under it. So ChunkRenderer builds a water MeshInstance3D as a child of the chunk's terrain mesh. TRANSPARENCY IS SHIPPED, NOT DEFERRED (Step 2.4's cheap branch). Because water is a distinct MeshInstance3D it carries its own StandardMaterial3D, so alpha is one flag and Godot sorts transparent surfaces after opaque ones by itself. Zero mesher changes. Alpha runs 0.62 shallow -> 0.97 deep, so the shelved coast stays readable and open ocean closes up. WHICH DATA DROVE IT: WSRF for the level (per-pixel, quantised to 1/32768 raw ~ 7.7 mm, far under the 1 m voxel, and no table lookup), WBID for presence (it is the water stage's own classification output -- the same set the biome grid's Ocean/Lake pixels form by construction), WBTB as 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. Details worth keeping: - Water Y uses Constants.HEIGHT_SCALE, the SAME mapping as the terrain surface, named so the sheet and the seabed cannot drift apart if the vertical band is ever retuned. - Depth for shading comes from BLUEPRINT heights, not rendered geometry: the terrain render clamps its floor at Y=2, so every deep-ocean column would otherwise read as one flat ~36 m and the gradient would die exactly where the ocean gets interesting. - A cell is drawn if ANY corner is wet, flat at the highest wet level. Drawing onto a partly-dry cell is deliberate -- it carries the sheet under the shoreline where the opaque terrain hides it. Only-fully-wet cells retreat the waterline a metre and leave a dry gap around every coast and lake. - Non-metallic, roughness 0.35: the scene environment is minimal, and a metallic surface reads near-black when there is nothing to reflect. BlockRegistry gains WATER (id 11). Wire-safe: block IDs are never serialized -- the blueprint's section table stores heights, biome ordinals and water data, never block IDs, and chunks are not persisted yet. MEASURED on seed 1825907253: 241,415 water columns across 454 of 4096 chunks; surface Y 37.6..37.6 m (flat, = 0.15 x 251 -- the flat sea model, rendered); depth to 32.3 m, matching an independent read of the blueprint exactly. Both an ocean and a lake fall in the default view. NO REGRESSION to the 2D pipeline, verified section by section: a regeneration of the working seed is byte-identical to task 12's run in TCRV, TDTL, HGTS, BIOM, WBID, WBTB, WSRF, TOWN and all four road sections; only PRMS differs, and only in its write timestamp. All four snapshot PNGs md5-identical. No storms, no waves, no animation, no flow -- water at rest. Those are C2+. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| BiomePalette.cs | ||
| BiomePalette.cs.uid | ||
| BlockData.cs | ||
| BlockData.cs.uid | ||
| BlockRegistry.cs | ||
| BlockRegistry.cs.uid | ||
| BLUEPRINT_FORMAT.md | ||
| BlueprintFormat.cs | ||
| BlueprintFormat.cs.uid | ||
| BlueprintWriter.cs | ||
| BlueprintWriter.cs.uid | ||
| ChunkData.cs | ||
| ChunkData.cs.uid | ||
| ConfigManager.cs | ||
| ConfigManager.cs.uid | ||
| Constants.cs | ||
| Constants.cs.uid | ||
| Enums.cs | ||
| Enums.cs.uid | ||
| MapDataParser.cs | ||
| MapDataParser.cs.uid | ||
| MarchingCubes.cs | ||
| MarchingCubes.cs.uid | ||
| MATH_MARCHING_CUBES.md | ||
| README.md | ||
/Core/Scripts
Pure C# data structures, shared enums, and static maths. Compiled into the shared assembly used by
both /Server and /Client.
"Pure data, zero state." These scripts define what things are and how to calculate them. They never track live game events — who is online, which chunks are loaded, what time it is.
What's actually here
Voxel materials
BlockData.cs— struct describing one block type (ID, name, IsSolid, BaseColor).BlockRegistry.cs— the byte-ID master list (AIR0,BEDROCK,STONE,DIRT,SAND, the three grasses,SNOW,WASTELAND_DIRT,ASPHALT) with a safeGetBlocklookup.BiomePalette.cs— decides which material sits where, given biome, depth, and whether the column is roadbed. Two paths on purpose: an integer classification that decides what is stored in each voxel, and a float-depth version used for rendering that returns the two materials either side of a boundary so colours fade rather than snap.
⚠ Note that BlockRegistry and the mesher's colour table hold different RGB values for some
blocks. The mesher's table is what you actually see; BlockData.BaseColor is currently unused by
rendering.
Shared identifiers
-
Enums.cs—Biome,TownTier,MapHalf,RoadTier.⚠
BiomeandTownTierare the.datwire format (u8 in the v2 container, i32 in legacy v1). They are declared without explicit values, so each member's ordinal is the number written to disk. Append only, at the end — never reorder or insert. The v2 reader range-checks ordinals so drift fails loudly at parse time, but only the append-only rule keeps old files meaning the same thing. Legacy v1 has no gate and no validation at all.RoadTieris exempt: road tiers live in separate sections of the file, so it is never serialized.
World data
BLUEPRINT_FORMAT.md— the byte-accurate.datcontainer contract (v2 tagged sections + the v1 legacy summary). Read this before touching the writer or parser.BlueprintFormat.cs— the single registry of v2 constants: magic, version gate, section tags (FourCC), validation bounds, re-encode sentinels.BlueprintWriter.cs— writes aWorldBlueprintas a v2 file. Blueprint-typed on purpose: the map generator and the round-trip harness are both just callers.MapDataParser.cs— decodes a.datblueprint into aWorldBlueprint(heightmap, biome map, towns, four road tiers, and — v2 only — the embedded generation params, per-town highway-node flag, and the optional water-bodies data:WaterBodyIds,WaterBodiestable,WaterSurfaceQ). Dispatches on the first byte: v2 tagged-section files get validation (version gate, size bounds, section-length and ordinal range checks); legacy v1 files still load, intact, with a deprecation warning. Nothing at runtime consumes the water data yet.ChunkData.cs— one chunk's density and block-ID fields,+1padded on every axis so the mesher can reach into the neighbouring chunk, plus the per-column data the renderer needs.Constants.cs— chunk dimensions,ISO_LEVEL,VOXEL_SCALE, and the visual/road tunables (material blend band; per-tier road width, shoulder, grade smoothing and surface).
Maths
MarchingCubes.cs— density field →ArrayMesh, with analytical normals and deterministic integer-keyed vertex welding.MATH_MARCHING_CUBES.md— an explainer of the algorithm.
Rules
- No Godot node inheritance. Pure classes, structs and statics.
- No
_Process/_Ready. Nothing here is attached to a live scene object. - Dependencies flow inward only.
/Serverand/Clientreference/Core;/Corenever references them.