3 Commits

Include renames

Author	SHA1	Message	Date
Fr0zkaandClaude Opus 5	55bf807f60	feat(descent): landing ROOMS and a walkable tunnel -- per Jahni's correction ... Jahni corrected the design: "the connection between level is a tiny tunnel connecting both strate, not vertical, it needs to be walkable" and "'the spine' shouldn't be carved except optionally from the top first strate, then it's used to have a landing room". COMPOSER-NOTES §6.8 had said the spine "provides a clean landing space, not a continuous open shaft" -- and the implementation carved a vertical cylinder anyway. A vertical cylinder has no walkable floor except at its bottom, so a carve guaranteeing open AIR guaranteed nothing STANDABLE. That one omission is behind five of my dead hypotheses this week. Now: origin spine a finite rounded ROOM per strate, no vertical bore. radius 14 -> 8 m wide, 7.5 m tall descent a walkable tunnel, single-file by design: 3 m mouth, 2.5 m waist, gradient capped at a NAMED 15 deg exotic styles VerticalShaft / SpiralDescent / CascadingDrops / CrackCrevice preserved, no longer the default ⚠️ THE GEOMETRY BITES, and it is worth Jahni's eye: at 15 deg a 32 m drop needs 119.4 m of horizontal run -- about 59.7 m per switchback leg. That is a long walk between strates. It is the honest consequence of "walkable", not a tuning artifact, and the alternative is a steeper number. ⭐ AND THE ROOT CAUSE GOT NAMED A THIRD TIME, by Codex mid-run: "the round tube was hollow air but had no authored support strip, so 'open' still did not mean 'standable'." Tunnels now carry a floor band, and the root join terminates in the finite origin room rather than an annular shaft hub. Measured, commandlet sweep, 8 archetypes x 8 seeds, 64/64 valid: origin column has player-fit cells 17/64 -> 63/64 origin column reachable 0/64 -> 7/64 arrival landing probes 315/320 fit AND in the arrival component tunnel audit 5,916/5,916 floor and capsule samples pass; zero gradient, floor, capsule, geometry or seal failures narrow-gap events 0 box verdicts 14 checked, 0 violations ⚠️ arrival->departure is 6/64. The landings and tunnels are now provably walkable; what remains is the INTRA-STRATE vertical connectivity problem found in 6b91669 -- floors at different levels inside a strate with nothing joining them. Separate and larger. Not tuned toward. ⚠️ PROCESS: this took 5.7 hours, of which Codex used 4 SECONDS of CPU. The rest was polling the 73-minute automation suite at ~10% machine load. The commandlet exists to avoid exactly that. New rule recorded: iterate with the commandlet, full suite ONCE at the end. Editor + Shipping builds clean. Automation 32/32, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aheo2crrZmHuYtPpdY2Cb	2026-09-08 02:14:37 +02:00
Fr0zkaandClaude Opus 5	6b916699af	test(explore): 81 runs in an afternoon -- every failure is a DROP, not a squeeze ... First real use of the commandlet, and it paid for itself immediately: 64 sweep runs + failure renders + origin probes, which at the old 73-minutes- per-automation-run would have been days. ⭐ FINDING 1: THE WORLD IS FRAGMENTED VERTICALLY, NOT PINCHED. Across all 64 runs: ZERO narrow-gap events. Every failed run has separate arrival/departure fit components with a positive gap, 12.75 m to 72.98 m. So corridors are not too tight anywhere -- the space is severed. And for the first time in this project we LOOKED at a failure instead of inferring from aggregates: FlatPlain/42 "a broad flat floor sheet with a sharp diagonal ledge descending into black open space" -- a drop, gap 63.9 m SurfaceWorld/7 "terrain shelves and a large black void between them. There is no connecting floor" -- gap 51.8 m Maze/42 "a massive solid rock wall/overhang fills the separation" -- gap 27.7 m I checked the images myself. FlatPlain shows two floor LEVELS 27 m apart in Z with nothing joining them. ⇒ The missing thing is VERTICAL CONNECTION between floor levels. Ramps, slopes, ledges, stairs. Every archetype builds floors; nothing builds a way between them. ⭐ FINDING 2: THE ORIGIN HUB IS NOT REACHABLE, which contradicts 413c15d. agent's reachable set included the origin column: 0 / 64 runs origin column had ANY player-fit cell: 17 / 64 runs Maze slot 4, all 8 seeds: 0 fit cells, unreachable Even in the 17, the origin cells were not in the arrival component. The reason is structural and obvious in hindsight: the origin spine is a VERTICAL CYLINDER. A vertical shaft has no walkable floor except at its bottom, so a scalar-density carve that guarantees open air guarantees nothing standable. The landings join a hub you cannot stand in. That is a finding about the §6.5 hub join as exposed to the player-fit layer -- not walk tuning. Recorded rather than patched. Also from Jahni, looking at the renders -- two things numbers missed: - The render cameras sit INSIDE ROCK, viewing tunnel surfaces from the solid side. Cameras must be seeded from the player-fit set. - ⚠️ THE MAZE IS STILL A LATTICE OF STRAIGHT PATHS. The spanning tree changed WHICH edges exist, not what an edge LOOKS like: every corridor is still a straight axis-aligned capsule between cell centres, every junction 90 deg. So 15.9% dead ends and mean degree 2.504 measured maze-ness of the TOPOLOGY while the eye sees a sparser grid. Sixth time a metric answered a question adjacent to the one that mattered. Two tool issues found: PowerShell needs -modes="render,walk" quoted or it parses as render-only; and "showcase slot" is ambiguous (cards use 1/6, the Maze diagnosis uses 4). Determinism spot-checked: repeated arguments give identical SHA-256 JSON. Measurement-only changes; no generation, parameter or threshold edits. Editor build succeeded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012aheo2crrZmHuYtPpdY2Cb	2026-09-07 18:33:15 +02:00
Fr0zkaandClaude Opus 5	bd547c35c4	feat(explore): a commandlet -- 91x faster, and the first real PICTURE ... Every experiment in this project cost a build + full-suite cycle. The landing task took 52 of them over ~9 hours. And nobody could SEE the world: every visual judgement all session was made on density SLICES -- diagrams, not pictures. That is how a floor heaving 1.4 m every two metres got described as "roughness visible but modest" while Jahni spotted it in thirty seconds by walking it. -run=VoxelForgeExplore, editor-only module, three modes, one build many runs: render raymarched PNGs, fixed 0.25-voxel step + 10 bisection iterations (NOT sphere tracing -- the op stack yields density, not a signed distance, so a long step tunnels through walls). Three views, each with a 1.76 m human marker in frame, because every scale mistake here came from numbers with no body beside them. walk an agent using the EXISTING VF player-fit stencil, never its own movement model -- two definitions of "can a player stand here" would drift and we could not tell which was lying. export OBJ through the canonical UVoxelMarchingCubesMesher. No second mesher; a forked meshing invariant is the bug this project keeps paying for. 23.2 MB, 106,762 verts, 200,842 tris for 128^3. ⭐ THE NUMBER THAT JUSTIFIES IT: the full automation run takes 4,396 s (73m16s). The commandlet does all three modes in 48.1 s wall, 5.9 s of which is engine startup. ~91x faster. And I had guessed the suite cost ~90 s -- it is 73 MINUTES. The iteration loop was far more expensive than I knew. First real walk metrics on the Maze (seed 0, slot 4): distance 214 m · tortuosity 4.98 · dead ends 0.935/100 m narrow-gap events 0 · reachable fit fraction 3.01% result NotConnectedAtThisResolution Tortuosity ~5 is a genuinely winding route, which is right for a maze. 3% reachable is not. Editor Development build clean. SHIPPING build clean with the receipt containing VoxelForge and NOT VoxelForgeEditor -- the instrument cannot reach a packaged game. Automation 32/32, 0 failed. ⚠️ Codex initially shipped this UNBUILT, and correctly: I omitted the ## Validation section from that spec, so it fell back to CLAUDE.md's "NEVER build or compile". 100+ compile errors from three causes -- bare TCondensedJsonPrintPolicy and TJsonWriter needing their template arguments, and a missing UObject/Package.h. That include is the SECOND miss this session, so CODEMAP §6 now carries the gotcha. ⚠️ Unrelated, found in passing: VoxelForge.uplugin does not declare RealtimeMeshComponent although the runtime module uses it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K8V9my1PL68pmQb2gutZZV	2026-09-07 04:07:07 +02:00