Fr0zkaandClaude Opus 5
d97373c5a8
From walking a TunnelNetwork preset at (0,0). Four corrections, and two of
them were the same mistake.
2a. The (0,0) landing room is sized to host a FUTURE straight vertical
shaft from the surface, with flooring around the origin itself. The
room is the landing for a shaft the player digs later.
2b. The inter-strate descent no longer starts at the spine -- placed by
deterministic hash within a radius around (0,0). The spine room is for
the surface shaft; the descent is elsewhere.
2c. ⛔ DELETED the landing->hub connector roads from 413c15d. Jahni:
"its straight up making other tunnels straightly through everything...
they have nothing to do here." Zero references remain.
2d. ⭐ FLATTEN THE ROOM JOINS instead. Where two spherical rooms intersect
and leave a lip above head height, the join is brought down to a
walkable level.
⭐ 2c AND 2d ARE ONE CORRECTION. I solved "rooms do not connect" by
TUNNELLING BETWEEN THEM when the answer was MAKING THEIR FLOORS MEET. The
81-run sweep had already said so -- zero narrow-gap events, every failure a
vertical severance, renders showing "a sharp diagonal ledge descending into
black open space". A radial corridor to the origin could never have fixed
that; flattening the joins is aimed at exactly it.
2e. Descent tunnel 1.5x wider, per "1.5x bigger wouldn't be too much".
2f. Corridors WANDER. Jahni, from the renders: "its not a maze, its still a
latice made straight paths." The spanning tree changed WHICH edges
exist, not what an edge looks like -- every corridor was a straight
axis-aligned capsule, every junction 90 degrees. Now hash-jittered
chains, seam-safe like the tree.
RENDERER: 192x128 -> 512x288, and cameras are now seeded from the
player-fit set -- "a density-checked pose from the exact player-fit walk
mask". Previously they sat INSIDE ROCK looking at back-faces, which Jahni
spotted instantly and no metric could. First genuinely legible pictures of
this world.
ParallelFor landed at 6 sites in VoxelStrateMeasure before I stopped the
run; the rest of that work continues next.
⚠️ AND THE RENDERER IS ARCHITECTURALLY WRONG, per Jahni: "why, in engine,
does it take a minute to have clear view of thousands of angles, but in our
renderer it takes ages?" Because the engine MESHES ONCE and rasterises --
~32k density calls per chunk, then every angle is free. I RAYMARCH: tens of
millions of density calls PER IMAGE, nothing reused between frames. We
already have the mesher and an export mode. Next task renders from the
mesh.
Also from him: runs must stay under 30 minutes. This one hit 33 and
produced 2 images.
Build clean. Committed as a checkpoint -- the task was stopped mid-Part-3,
not finished.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012aheo2crrZmHuYtPpdY2Cb
36 lines
691 B
Plaintext
36 lines
691 B
Plaintext
{
|
|
"FileVersion": 3,
|
|
"Version": 1,
|
|
"VersionName": "1.0",
|
|
"FriendlyName": "VoxelForge",
|
|
"Description": "A voxel terrain generation plugin - built from scratch to learn",
|
|
"Category": "Procedural Generation",
|
|
"CreatedBy": "You",
|
|
"CreatedByURL": "",
|
|
"DocsURL": "",
|
|
"MarketplaceURL": "",
|
|
"SupportURL": "",
|
|
"CanContainContent": true,
|
|
"IsBetaVersion": true,
|
|
"IsExperimentalVersion": false,
|
|
"Installed": false,
|
|
"Plugins": [
|
|
{
|
|
"Name": "RealtimeMeshComponent",
|
|
"Enabled": true
|
|
}
|
|
],
|
|
"Modules": [
|
|
{
|
|
"Name": "VoxelForge",
|
|
"Type": "Runtime",
|
|
"LoadingPhase": "Default"
|
|
},
|
|
{
|
|
"Name": "VoxelForgeEditor",
|
|
"Type": "Editor",
|
|
"LoadingPhase": "Default"
|
|
}
|
|
]
|
|
}
|