VoxelForge/Standalone/Research/WorldAssemblerM3/Astra3/PROMPT.md

VoxelForge — read-only design review: per-block bit flags (masks) to skip work

You are reviewing an idea against real code. Do not edit, create or delete any file, and do not build or run anything. Read code and reason. Be thorough; mark each claim as [CODE] (with file:line), [MEASURED] (from a report), or [INFERENCE].

Context

VoxelForge Core (Standalone/Core) generates a density field: negative = solid, positive = air, 25 cm voxels, 32³ tiles, LOD0–8 clipmap, marching cubes. The production mesher for the standalone path is in Standalone/Source/..., and Core is also compiled into Unreal. Same seed must give the same world on every machine and worker count; byte-identity with older versions is NOT required.

Branch assembler/world (HEAD 7022d02's parent line, currently 4041d4b) has the smooth inter-strate tunnels. Readiness target: LOD0–2 near terrain in ~1 s on arrival. Measured today: SW ~0.7–0.8 s, VS ~0.9 s, FI/TN ~1.0 s headless. In Linux UE, start→LOD0–2 is ~2.2–2.5 s. At 30 m/s in UE, near coverage is ~40%.

Reports to consult: Standalone/Research/WorldAssemblerM3/Linux1*/REPORT.md, especially:

• L77/L87/L117, cost census;
• L124, shape gate and per-strate timings;
• L125/L126/L128, tunnel prepare: per-segment work, 67–73% pair overlap, support up to 7.9 m;
• L128, where an exact one-owner slab scheme halved pairs but got slower because of per-sample ownership tests.

Tile skipping already exists at tile level: box verdicts / classify, where all-solid or all-air tiles are skipped.

The idea (from the owner)

Keep bit flags per block (1 bit per voxel, or per small brick of e.g. 4³ or 8³ voxels): for example "certainly deep solid", "certainly deep air", "near a surface", "touched by a tunnel", "already evaluated". Use them to skip work in generation and meshing, and possibly elsewhere (collision, streaming, edits, AI/nav, lighting).

Questions

1. Where does time actually go per tile today, and which of that work a mask could skip? Cover density fill, classification, mesher (marching cubes, normals/gradients, skirts, seam refinement), passage prepare, and composition. Use measured census numbers where they exist.
2. Which flags are sound? A flag must be a proof, never a guess. A mask "certainly solid" must be derived from a conservative bound (the bound must be the supremum of what the evaluator produces), or the mesher will delete surfaces. Which bounds already exist in the code (box verdicts, interval bounds) that a brick-level mask could reuse? Name the existing hazards. For example, Identity means Sdf >= T, and ClassifyTile proving below-TerrainZ solid would delete 3D caves.
3. Granularity: per-voxel bits vs per-brick (4³/8³) vs per-column. What does each cost to build, versus what it saves? Consider SIMD and cache behaviour. Marching cubes needs only cells whose corner signs differ, and gradients need a halo.
4. "Already evaluated" or "checked" flags: where would they be correct (memoisation of identical queries), and where would they be wrong (nearest-of-many queries like the tunnel segments)? Is there repeated identical evaluation today, for example halo samples shared between neighbouring tiles, or skirt/seam re-queries?
5. Other uses: player edits (diff layer), collision-only server tiles, streaming priority, nav. Which would a mask genuinely help, given the multiplayer rule (replicate seed + layout + diff, never geometry)?
6. Recommendation: the one or two mask designs most likely to pay off, with the expected gain (a range, marked inference), the measurement that would prove or kill each, and the risks. Keep it short.

Write plain Markdown, at most ~1,200 words.