beezm/islaApocalypse
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
islaApocalypse/Core
History
beezm f9ea2da3f4 roads: enable Rugged+Trail carving + per-tier character (D-022) 
All four road tiers now carve into the 3D world. Rugged and Trail were
generated, exported and parsed all along, but nothing ever consumed them —
which is why county roads visible on the 2D map did not exist in 3D.

Tier identity is now carried into the carve via a RoadSegment struct, so each
tier gets its own width, shoulder and grade-smoothing from one tunable block in
Constants: highways widest and holding a grade, trails narrow and hugging the
land. Rugged and Trail surface as dirt rather than asphalt.

Because tiers now have different reach, nearest-by-distance was no longer a
sound way to pick the governing road — a nearby footpath could shadow a highway
whose shoulder still covered the column. The carve now considers only roads
whose shoulder actually reaches, and takes the closest of those.

The per-chunk cull pad is derived from the widest shoulder plus a margin, so
widening a road cannot silently truncate it at chunk edges.

Untouched: density field, Marching Cubes interpolation/welding, chunk dims,
the .dat contract, the 2D A* generation, and mesher normals.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-05 03:53:32 -04:00
..
Scripts roads: enable Rugged+Trail carving + per-tier character (D-022) 2026-08-05 03:53:32 -04:00
README.md baseline: working salvaged prototype on Godot 4.7.1 (pre-F1) 2026-08-05 01:45:41 -04:00

README.md

Core Module - IslaApocalypse

Phase 2 Status: Active (Voxel Math & Parsing Online)

Overview

The Core directory contains the mathematical foundation, data structures, and parser required to bridge the 2D procedural generation with the 3D Voxel Engine. It is strictly logic-driven and contains no Godot Nodes or visual elements.

Key Architecture & Components

1. The Data Bridge (MapDataParser.cs)

Responsible for deserializing the highly compressed binary .dat file generated by the /Tools pipeline.

  • Outputs: A WorldBlueprint object held in RAM.
  • Capabilities: Reads the 2D heightmap, biome map, and town locations. Crucially, it parses all four tiers of A* road vectors (Highways, Branch Roads, Rugged Roads, Trails) for the Server to use in terrain flattening.

2. Voxel Data Containers (ChunkData.cs & Constants.cs)

  • Chunk Dimensions: Defined in Constants.cs. Currently optimized to 32x32 horizontal with a massive 256 vertical height limit to allow for true AAA-scale mountain ranges without heightmap compression.
  • Seamless Borders: ChunkData.cs expands its scalar field arrays (Densities and BlockIDs) by +1 on all axes. This allows the Marching Cubes algorithm to sample the neighboring chunk's data, ensuring meshes connect perfectly without gaps.

3. The Math Engine (MarchingCubes.cs)

Transforms the raw ChunkData scalar fields into physical Godot ArrayMesh geometry.

  • Analytical Normals: Instead of flat shading, the algorithm calculates exact 3D slope gradients at the corners of each voxel. This produces smooth, realistic lighting across curved terrain.
  • Vertex Painting: Reads the BlockID assigned to each voxel corner and applies physical RGB colors directly to the mesh vertices before committing the geometry.

4. Biome & Material Mapping (BiomePalette.cs, BlockRegistry.cs)

Translates the 2D world into physical 3D materials.

  • BlockRegistry: A byte-based lookup table defining physical materials (SAND, STONE, WASTELAND_DIRT, ASPHALT).
  • BiomePalette Logic: Uses the 2D Biome pixel combined with the 3D currentY depth to determine the block type. For example, Biome.Wasteland combined with a depth of 0 yields WASTELAND_DIRT, while a depth > 4 yields STONE.