Both constants were worked out by hand and a byte off each: the tiles' bake wrote "LAAK" and "LDT2", which
ludic bake --check refuses, and r3d_baked_read, holding the same wrong constant, would have refused
ludic.base's correct files (the sun's shadow among them) while accepting its own. Now 0x4B41424C and
0x3254544C, checked against the strings; the unused LTT1 constant is gone. A re-bake is needed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The tiles' photograph side is 0 when the map has none: no photograph or coarse photograph sections, no
decode, ter_o answers 0, and no coarse photograph texture - as such a map has always drawn. The cut and
terrain_tiles_bake no longer require one.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Heights as u16 over each 64 m tile's own minimum and step (a tile spanning 200 m steps 3 mm), normals
octahedral 8 + 8, the photograph RGB8, and the coarse level (2048: heights f32, normals, photograph)
- 30 + 32 + 48 + 16 + 8 + 12 MB, about 146 MB a map where the float tiles were 192 plus nothing coarse.
The writer puts the whole copy back to the quantized values as it goes, so the build's own queries,
the physics, the placements' bake and every machine read the same numbers; a tile read decodes them
into the pools the queries and the page pool already use.
terrain_tiles_bake(path, key, version, inputs_hash) writes a bake's file (ludic.base's LBAK header,
the tiles as its payload) from a made map; terrain_from_baked(path, key, version, half, ox, oz) opens
one at boot in place of terrain_use_dem / terrain_use_ortho, and terrain_init then generates nothing
(and bakes the sun's shadow from the coarse level unless terrain_shadow_from_bytes gave it). Without a
bake the cut writes the same format to <dir>/<key>.tiles and reads it back. The GPU's coarse level is
made from the file's coarse sections (the blit from the whole maps is gone).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
