The owner played 64f5d61 and reported the truth: "generation still takes ages...
TunnelNetwork doesn't even finish generating, as big as the surface world" while
SurfaceWorld completed in under 10s, and stopping PIE hung for 30+ seconds.
e08b49a's 21x was real and irrelevant. It fixed per-CHUNK state rebuilds, which
dominate the commandlet export path. The game is bound by per-VOXEL evaluation.
Same symptom, different bottleneck, and nobody had measured the second one.
WHY PIE HUNG
bShuttingDown was never checked inside VoxelMarchingCubesMesher.cpp -- zero
occurrences. A worker inside GenerateMesh could not abort, so 64f5d61's correct
unconditional EndPlay wait was waiting on tiles physically unable to stop. The
hang was not a teardown bug; it was evidence that one tile took tens of seconds.
Added shutdown polling per slab/row in the mesher and through GenerateTileResult;
aborted results carry Epoch + bAborted and ProcessQueue drops them. EndPlay still
waits unconditionally -- the 3s mark only logs now.
PIE stop 3.409s / 44.759s -> 4 ms teardown, 38 us worker drain
WHERE THE PER-VOXEL COST WAS
The owner's own comparison was the sharpest instrument available. Profiled both:
GetDensityAt TunnelNetwork 12.64 us/sample SurfaceWorld 1.32
tunnel candidates evaluated 7.088 per sample 0
tunnel-core candidates evaluated 7.201 per sample 0
room candidates evaluated 1.000 per sample 0
largest buckets: RoomGraphSource 2.57, TunnelCorePosts 0.76,
PassageCarveOp 0.22, PassageStructuralPosts 0.20
The three regressing commits map cleanly, and one is innocent:
7a20eee drainage tree -- cache-build work, NOT per-voxel
413c15d landings -- repeated full passage modification per sample
55bf807 landing rooms -- room SDF + tunnel/core evaluation per sample
Fixes: FPassageCarveOp carves only, landing/support moved to the structural MC
post; tunnel core support and SDF fused into one pass; room graph caches shared
per worker on complete deterministic keys; tunnel density cache uses open
addressing with 4096 slots. Room cache rebuilds fell to 9 per 42,875 samples, so
what remains is genuine O(local cached room/tunnel count) work.
TunnelNetwork 128^3, seed 1337 slot 1, same region:
342.2 s / 163.161 us/vox -> 2.623 s / 1.251 us/vox (130x)
Geometry SHA-256 aaf95559..066b4, IDENTICAL to the pre-optimisation run at the
same roughness. 153,692 triangles either way. Verified independently of the
agent's own report.
NOT FIXED, and the first one is the next real target:
- L4 tiles still cost 16.93 s. Hit rate falls 99.9% (L0) -> 23.7% (L4), but
1024 -> 4096 slots only moved 18.39s -> 16.93s and the 1,927 misses ARE the
distinct key count. That is low reuse, not eviction. A bigger cache will not
save it.
- TunnelNetwork is still ~10x SurfaceWorld (0.354s vs 0.028s on a matched 32^3).
- The live PIE tile table is SurfaceWorld: this checkout's PIE map is configured
that way. TunnelNetwork went through the same mesher and density path via the
commandlet, but no TunnelNetwork tile has been timed in an actual game session.
Export numbers are not presented as game numbers.
Still outstanding, untouched here: the inter-strate passage has intersections it
should not have, routes through open passage when it should not, and should
descend from a low point of the current strate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012aheo2crrZmHuYtPpdY2Cb
Fr0zkaandClaude Opus 5
0576e800c4