VoxelForge/RESEARCH-SPEED-2026-09.md

VoxelForge speed research — 29 September 2026

Consolidated decision

Build the spatial/evaluation redesign first and keep the current precise float procedural math. Compile the seed, layout, composer and operator stack once per region into a stable local program; bin rooms, tunnel segments and passages into 8³-cell bricks; compute cheap final-field solid/air certificates; share lattice samples across tiles and LODs; contour uncertain bricks. Use a versioned, explicitly rounded 16-bit lattice density as the common mesh/edit/query cache. Keep the procedural float evaluator as the cache producer and on-demand lattice-sample fallback; player collision queries interpolate the same quantized lattice, including newly generated cells, so visual and collision signs cannot diverge through an off-grid float query. The quantization scale, zero tie and interpolation rule belong to the new world ABI. This changes the world version without requiring a full fixed-point rewrite of Perlin and every content operator. Build flags already pin FPSemanticsMode.Precise; noise has table-free Perlin and a scalar/SSE4.1 path written op for op; geometry math uses VoxelMath::DetSinCos. This supports the current same-build CPU contract, although full-world hashes on the actual supported CPU/compiler combinations remain a release gate. MSVC documents both the ordering guarantees and limits of /fp:precise; it is not a GPU-vendor parity mechanism. MSVC floating-point semantics, MSVC cross-CPU cautions.

For the player, provisionally choose field-aware movement against the versioned lattice, with cooked Chaos bodies as a compatible background path. This is the route that can use the new edit epoch immediately when a dig removes support; a delayed cook cannot be authoritative in that frame. Before committing to Mover, instrument the existing cook pipeline and try reserving generation capacity. If a small set of player-support tiles cooks quickly and a CMC edit-time field override passes the same-frame floor/velocity test, retain CMC plus a prioritized-cook/field-overlay hybrid. A fast cook by itself does not solve an underfoot edit. RMC's manager defers collision to end of frame, its future helper schedules work on GThreadPool, and its data path returns to the game thread to apply BodySetup/physics state; the observed 0.4–1.4 s is submit-to-ready, not measured Chaos compute. UE task priority does not preempt already running generation, and RMC's pool is a distinct queue whose threads still compete for CPU. Epic UE Tasks, Epic BodySetup readiness.

For rendering, measure the current RMC drain before grouping. MaxMeshAppliesPerFrame=4 and MaxMeshApplyMilliseconds=2 are settings, not a hardware limit. The source comment's “~0.1 ms per 32³ apply” is an estimate, not a captured sustained upload rate; no surviving [VoxelForgeApplyFrame]/render-thread trace in the repo establishes one. With ~341 visible nonuniform tiles and a 0.35 s generation budget, the remaining 0.65 s requires ≥525 visible applies/s, or 9/frame at 60 Hz and 6/frame at 90 Hz if results are ready together. At 4/frame the caps are 240/s and 360/s, respectively. If all 512 tiles are nonuniform, the 60 Hz requirement rises to 14/frame. Raise the cap in an isolated saturation test and measure game-thread drain, RMC render enqueue, RHI completion and first visible frame. Group 2³ tiles into at most 64 spatial pages, retaining independently updateable sections, only if per-component or render-thread overhead misses that rate. The archived 128³ export emitted 7.435 MB of logical mesh output for 64 tiles, an average 116 kB/tile; extrapolating that mix to 341 visible tiles is ~39.6 MB of payload, not a measured GPU transfer or component cost. Local attribution.

A large spell still needs a single visual transaction. At radius 10 m the round-two probe found 714 touched 8³ bricks and up to 64 current tiles; its cached-field composition was 0.861–0.914 ms, excluding upload. Keep a GPU-resident copy of the visible quantized lattice and apply an integer edit command to the whole affected region in one render dependency, with a complete-region mesh or bounded raymarch fallback. Match CPU and GPU quantized sign, interpolation and zero ties; publish all touched tiles/LODs at one edit sequence. The GPU need only perform integer edit composition and mesh decisions. Replacing the entire procedural float generator with integer is conditional on a later full-GPU base-generation win. This retains cross-machine world authority on the CPU and avoids treating the round-two integer AVX2 probe as a production speedup.

Separate the two proposed changes

Change	Evidence and expected contribution	Decision
(a) Region-local evaluation and sparse sampling	At the supplied ~2 µs/sample, shared lattice alone cuts 21.952 M requests to 17.374 M and an ideal six-worker clock from 7.32 s to 5.79 s: only 1.26×. The proposed 0.35 s worker budget requires a further 16.5× effective reduction in cost or evaluated points after sharing: (17.374 M × 2 µs)/(6 × 0.35 s). This is the required result, not a measured gain. The scalar synthetic probe's ~170 ns of aggregate worker CPU/sample (six workers × ~0.47 s / 16.8 M points) shows hardware headroom but uses a different, much cheaper graph. Brick certificates, candidate binning, removal of per-point routing and local compiled ops are the mechanisms to test; no number from another workload is assigned to them.	Necessary first experiment. Keep float while measuring it, so gains can be attributed.
(b) Full integer/fixed-point procedural generator	The round-two explicit AVX2 kernel beat its own integer scalar reference 4.25–5.86×; that comparison says nothing reliable about integer versus the plugin's optimized float/SSE noise or its feature-search cost. Merely changing numeric type leaves the ~30.7 counted candidate visits/sample and cache routing intact. There is no measured production speed credit, so assign zero guaranteed speedup toward the 16.5× goal. New world version permission removes compatibility cost, but not implementation or proof risk.	Defer full conversion. Use deterministic quantization at the lattice boundary and integer edit/mesh decisions on GPU. Convert base generation only if an exact CPU/GPU float-versus-integer production ablation proves a faster end-to-end path.

The ~2 µs sample is an end-to-end GetDensityAt cost, not a Perlin operation. The available attribution closes where time goes but does not supply additive CPU shares for each nested operation. In the archived 128³ TunnelNetwork export, 590.923/606.128 ms (97.49%) was shared-grid fill; the following cell scan/mesh/merge was ~15.2 ms. Dividing 590.923 ms by its 2,248,091 unique samples yields only 263 ns/sample in that different workload/window. It therefore cannot be substituted for the owner's current ~2 µs/sample or used as an additive timing breakdown of it. The export generated these work counters: 11.10 M room candidates / 1.73 M evaluated, 28.95 M tunnel candidates / 3.46 M evaluated, and 28.95 M tunnel-core candidates / 1.88 M evaluated. That is about 4.94 + 12.88 + 12.88 = 30.7 candidate visits per sample across the three reported counters, with about 3.15 actual evaluations/sample. Candidate passes may revisit the same feature, and the counters are not additive time buckets. Binning local features once per brick attacks this work directly. Local attribution.

Per-sample work visible in code	What the redesign removes; what it cannot claim
GetDensityAt recomputes chunk coordinates and checks manager/layout/lifetime, routing, tunnel cache, tile-window policy and diff version. The measured tunnel cache had 2,248,043 hits and 48 misses: nearly every point pays lookup/key predicates despite few builds. GetDensityWithParams performs further box/fingerprint/terrain-op/tile-policy guards.	A prepared immutable region program moves these decisions to region/brick admission. This can remove repeated checks and indirection; their individual nanoseconds were not measured. These are multiple key comparisons, not a dozen expensive cache misses.
Rooms, tunnel segments, passage checks and warped search boxes are queried inside field evaluation; the candidate counts above show repeated local traversal.	Spatially bin features with conservative warp/blend reach, then evaluate only the local list. A false-negative bin is a geometry bug; exact sign tests across stratum and passage boundaries are mandatory.
The generic composer/operator path can visit roughly twenty ops, including locally inert ones. But the archived primary TunnelNetwork run uses the already fused evaluator, which bypasses EvalMC's per-op dispatch.	Compiling away generic op visits helps custom/composer and other nonfused recipes; it cannot be credited for the primary fused TunnelNetwork timing. That route still contains room/tunnel candidate work, routing and the common tail.
GetDensityAt follows the core with disturbance/structural/passage/landing-floor repairs, XY seal and diff application. The attribution lists structural-tail, density-post and passage-post sampled nested work, not wall shares.	A region program can pre-resolve which post passes can affect a brick and fuse their ordered math; the route/floor invariant must survive. Do not subtract the nested timings from 590.923 ms or assume the tail disappears entirely.
The code enters per-sample profiling scopes. The owner's latest stack sample attributes 4.9% to the profiling leaf; the archived same-argument profiled/unprofiled control differed by only 0.63%.	Disable profiling for acceptance timing and retain a diagnostic build. The 4.9% sample share is not a demonstrated 4.9% clean-build gain; sampling and instrumentation mode differ.

Ordered build plan for the orchestrator and coding agent

The steps below describe future plugin experiments. This research pass makes no Source/ change and does not run Unreal. Use the same machine, fixed seeds/layouts, cold world caches, and 20 spawn/teleport trials per UE gate; report the maximum as well as median because 20 trials are too few for a meaningful p99. Preserve gameplay while replacing one pipeline stage at a time.

1. Day-one falsification: stage the existing collision and upload clocks. Add timestamps for collision request, RMC end-of-frame dequeue, GThreadPool worker start, geometry extraction end, CookComplexMesh start/end, game-thread ApplyCollisionUpdate start/end, physics-state ready and first successful capsule sweep. Keep existing generation, mesh and gameplay behavior while profiling. Test one ~4,000-triangle tile and the pawn's current 3³=27-tile support neighborhood, idle at the current 14 generation tasks, and with the generation cap reduced to 12. If the cook's queue wait dominates, test a dedicated priority cook dispatched directly after player-support mesh extraction; compare its core cook and install times with RMC's route. In parallel, prequeue a 341-tile render corpus and run caps 4/8/16 with the same 2 ms drain guard; record visible applies/s, game/render/RHI clocks and first-visible frame. Pass the cook shortcut only if core cook p95 ≤10 ms, the 27-tile player support is ready ≤150 ms after meshes exist under load, and an edit-time field override can switch floor/support within the first simulated/rendered frame with zero invented velocity in 100 repeated underfoot digs. If any edit test fails, implement field-aware Mover as the player authority; if the shortcut passes all tests, use prioritized cooks for steady terrain plus field queries while an edit's cook is pending. Pass the ungrouped upload path only if it sustains ≥525 visible applies/s at 60 Hz with game-thread drain ≤2 ms/frame and no render/RHI backlog. These are decision thresholds, not existing measurements. Step 1 results (2026-09-30, commit 41b001b): core cook 1.50 ms p50 / 2.28 ms p95 (passes); through RMC's collision route the same support bodies were ready 8.5–10.8 s after their meshes existed (fails): the wait is RMC's path, not Chaos, so player-support collision must bypass it. CMC with a field override: 883 false-support frames in 100 underfoot digs (fails): step 4 is field-aware Mover. Uploads: cap 16 = 639 applies/s, drain p95 2.22 ms (misses 2 ms by 0.22 ms), no render/RHI backlog, so tune the drain and do not group yet. The "8× per-sample gap" was a denominator artefact: 263 ns was export wall time with 15 workers on a shared lattice (≈3.4 µs CPU per sample); the real per-sample CPU cost is ~2–3.4 µs in both paths, so the 12–16× reduction target stands.
2. Standalone exact-float evaluator ablation. Extract representative real TunnelNetwork and composer plans, including warped rooms, passages, stratum transitions, route floors and diff edits, into Saved/Research only. Keep the plugin's active evaluator and worlds untouched. Compare baseline point API to a prepared float region/brick API at the same lattice coordinates and op order. The reference is the chosen new-world float definition, not old-season geometry. Pass: zero 16-bit quantized-value disagreements and zero route/capsule regression across at least five seeds; ≤600 ms for the full 259³ cold ring on six workers before certificates. Record candidate visits, cache checks and worker CPU. Failure means local compilation did not remove enough work; investigate before rewriting numeric math.
3. Add certificates, shared lattice and contouring. Prove final-sign bounds after all writers and edits; classify 8³ bricks, evaluate uncertain ones, share global corners, and mesh them with today's marching-cubes table. Keep the old tile route as a versioned reference while the new route is validated. Pass: zero false-uniform bricks and zero sign mismatch at all 17,373,979 ring lattice sites for the test corpus, cold worker generation ≤350 ms, and max render-visible/full ring ≤900 ms in the later UE gate. If certification consumes more time than it saves, fall back to evaluating uncertain regions without that proof; do not repeat the archived 0.588→2.057 s interval-control mistake. 3b. AVX2 check against the new norm (owner's request, 2026-09-29). Once step 3's brick evaluator is the baseline, try an explicit 8-lane AVX2 version of its hot loop (the plugin's current noise path is 4-lane SSE4.1). The owner does not require AVX2 to match the scalar path bit for bit (clarified 2026-09-29): only the shipped product must be deterministic across players' machines. If adopted, the AVX2 path is the canonical world definition (FMA allowed, as long as it is always used), and every machine must run that same path: require AVX2 at startup rather than falling back to a scalar path that would produce a different world. Keep it only if it is faster on the step-3 corpus and the AVX2 path gives the same lattice hash on two runs and on two different AVX2 CPU models; otherwise record the number and drop it. The round-two integer AVX2 probe (4.25–5.86× over its own scalar) is the reference for what explicit vectorisation can buy.
4. Choose and implement player collision. Use step 1 to select prioritized Chaos+edit overlay or field-aware Mover; keep ordinary collision with nonterrain actors and keep NPC/projectile field-query backup. Version floor/contact state by edit sequence. Pass: at every teleport the player can perform an actual blocked capsule movement on the intended terrain ≤900 ms after the request, 100 underfoot digs add 0 spurious velocity impulses, and 100 excavations with no cave below have 0 frames of false support or false air. The full visible ring must also meet the separate ≤1,000 ms hard deadline. A successful cook timing without the edit tests is insufficient.
5. Decide render batching from measured throughput. Keep per-tile RMC if it sustains ≥525 visible applies/s and the first-visible gate ≤900 ms. Otherwise group 2³ tiles per page while retaining tile-addressable sections and the same materials/LOD transition topology; rerun the same corpus and require ≥99 page applies/s for at most 64 pages in 0.65 s, ≤2 ms/frame game-thread drain and no render-thread tail past the 1 s deadline. If grouping causes whole-page reupload on small edits or still misses, use a dedicated batched render proxy. Compare first-visible time against the same ≤900 ms gate.
6. Version the edit and GPU visual protocol. Quantize float-produced lattice density with specified rounding/saturation; use fixed integer edit composition, stable per-cell triangle counts/prefix sums, global edge ownership and one edit sequence across touched pages/LODs. Keep CPU procedural generation, composer, route graph and ordered edit replication as the authority. Test AMD and NVIDIA output hashes against CPU reference; on a single machine, two full cold runs must yield the same field/sign/mesh hash. Pass: a radius-10 m crater (up to 714 bricks/64 tiles) appears throughout its region in the first submitted render frame containing the edit, no gap/ghost/ripple at borders or LOD seams, CPU/GPU sign disagreement 0, and added GPU cost ≤2 ms within an 11.1 ms 90 Hz VR frame in 20 varied positions. If direct GPU remeshing exceeds that, test the complete-region raymarch overlay with the same visual and frame gates; do not publish a partial mesh.
7. Long-range and multiplayer gate. Provide LOD1 first at 16 cells per tile, refine later, reuse coincident lattice points and keep full 3D geometry for caves/overhangs/islands. Replay ordered edit transactions, including crater commands, on two supported CPU models and compare world-versioned hashes. Pass: first LOD1 preview ≤3 s after cold teleport, an 8 m/s five-minute run with 0 missing player support or visible near-ring gaps, equal hashes for two runs and both CPU models, and a successful late join after replay/checkpoint. If float parity fails on a supported CPU/compiler pair, lock an exact scalar FP path or then promote a full integer procedural ABI.

Still unproved: production float region-program throughput, brick-proof efficiency on the full composer, the actual RMC sustained apply rate, the Chaos queue-versus-compute split, whether CMC can support an edit-time field override, field-aware Mover query cost, and same-frame GPU/VR crater rendering. Each has an explicit gate above. The standalone integer result proves only that its synthetic 3D kernel can run quickly and match its own scalar reference on this Ryzen. Neither a source paper's scene timing nor a comment's estimated per-tile apply time closes these gaps.

Earlier evidence and alternatives

The consolidated choice above supersedes the round-two integer-first and unconditional grouping suggestions. The useful core remains a spatially pruned 8³-brick evaluator, shared lattice, conservative certificates and transaction-wide crater visual. Keep the 25 cm lattice, volumetric operators, walkable route graph and seed/layout/edit replication. Recent work on pruning SDF construction trees directly supports region-local programs, but its speedups on other scenes are not VoxelForge measurements. Lipschitz Pruning, Eurographics 2025, Accelerating Signed Distance Functions, 2025, OpenVDB paper.

The one-second target is plausible but not proved. The round-two six-worker AVX2 probe processed a synthetic 256³ composition in 80.3–107.5 ms across three three-trial runs with exact scalar parity; 17.374 M unique ring points at that measured throughput extrapolate to 83.2–111.3 ms, leaving roughly 0.89 s for classification, mesh extraction, upload and visibility. This is an arithmetic extrapolation across different data and cache patterns, not a measured UE ring. The scalar probe took 430.3–496.2 ms, a 4.25–5.86× paired speedup from explicit AVX2. The recommendation is conditional on a production-stack parity/timing experiment and a UE upload/VR edit spike. The arithmetic is decisive about what must change:

Quantity	Arithmetic or measurement	Consequence
Current tile requests	512 × 35³ = 21,952,000 samples	At the supplied ~2 µs/sample this is 43.9 CPU-seconds before collision/upload.
Shared lattice for 64 m cube plus halo	259³ = 17,373,979 unique points	Sharing alone removes 20.9% of requests, nowhere near enough.
Required density rate if generation gets 0.5 s on six cores	17.374 M / 0.5 / 6 = 5.79 M samples/core/s, or 173 ns/sample	Current ~2 µs/sample needs about 11.6× improvement even after sharing if every point is evaluated. This ignores meshing and upload.
Current render apply cap	~341 nonuniform tiles if one third are uniform; 4 applies/frame = 85.3 frames, 1.42 s at 60 Hz if all were queued together	This is the default configured cap, not measured sustained throughput. Raise it and measure game/render/RHI time first; group only if the actual rate misses the deadline.
Current collision	Owner's 0.4–1.4 s submit-to-ready per tile	This interval includes end-of-frame deferral, pool queueing, extraction, actual Chaos cook and game-thread installation; the cook's own CPU duration is unknown. Reserve capacity and instrument the stages before choosing field-only versus prioritized-cook hybrid. Epic BodySetup API, RMC source.
Running at 8 m/s (local design brief)	One 8 m tile crossing/s brings one 8×8 face = 64 new tiles/s; 64 × 35³ = 2.744 M requests/s	At current ~2 µs/request, that is ~5.49 CPU-seconds/s, or ~0.915 s on six ideal workers before upload/collision. A shared 32-cell slab is 259² × 32 = 2.147 M new points, still ~0.716 s on six ideal workers. Field collision on demand is also the safety net for unexpected movement or stalls.

Measured standalone feasibility probe on this machine: A synthetic 256³ 3D field with 48 integer sphere features and three octaves of integer lattice noise took 471–481 ms for 16,777,216 samples using six threads. Conservatively classifying 32,768 8³ bricks took 15.46 ms; evaluating only the 7,563 uncertain bricks then took 106–130 ms, with zero sign mismatches against the full evaluation over all 16,777,216 points. An eight-thread repeat took 349–367 ms full or 86–110 ms classified plus 15.59 ms classification. This is a kernel probe, not VoxelForge or a measured 512-tile load. Its primitive list and noise are far simpler than the current composer stacks. It shows that the required rate is physically credible on this CPU when work is converted to bounded integer kernels; it does not establish that the full game, render upload, or Chaos field integration finishes in one second. Benchmark details and limitations are below.

No evidence here proves that UE can present a cold 64 m cube in under 1 s or a radius-10 m crater in the same VR frame. The ordered gates above decide those questions. If they fail, change the render/collision implementation or explicitly revise the target; do not silently infer success from a synthetic density benchmark.

Local evidence and what it means

The code currently requests 35³ values for each 32-cell marching-cubes tile, and GetDensityAt builds/evaluates the stack in VoxelGenerator.cpp; VoxelMarchingCubesMesher.cpp spends most worker time filling the grid. The existing attribution measured 590.923 ms of 606.128 ms (97.49%) for a shared-grid fill in a 128³ TunnelNetwork export, with only ~15.2 ms for later meshing/merge. It also measured an interval-classifier route that grew from 0.588 s to 2.057 s instead of helping. Thus “add generic interval recursion” is already a failed local control; the new plan must compile cheap, conservative bounds and feature lists per brick, and fall back to evaluation if a bound is uncertain. Local attribution, failed early-out control.

The owner's 0.4–1.4 s collision figure is submit-to-ready in the current observation window. The archived 12 September headless run reported a 0.052945 s p95 cook stage in its different workload and instrumentation window. Neither number is a per-triangle CPU cost, and they should not be pooled or multiplied into a 512-tile total. The planned Unreal spike must capture the new ring's cold maximum, not reuse either statistic. Archived local timing.

The runtime already prioritizes edited and collision-critical work, but it applies at most four visible meshes per frame by default (VoxelSettings.h:65) and ApplyModification synchronously remeshes only the center tile while neighbors are asynchronous (VoxelWorld.cpp:10369). Underfoot carving can disable the old support component until recook (VoxelWorld.cpp:10290), directly explaining a transient disappearance. RMC can preserve old cooked collision while a replacement cooks (VoxelWorld.cpp:9858), which explains ghost support if the removed surface is still in that body. The default pawn collision box is radius one tile, 3³ = 27 tiles; the requested 512-tile collidable ring is a much stronger target than this implementation currently attempts (VoxelSettings.h:88, VoxelWorld.cpp:8168). These are code observations, not new timing measurements.

Standalone measurement, reproducible

Code: Saved/Research/brick_kernel.cpp. Built only this standalone program with installed MSVC; Unreal was not built or launched. From Saved\Research in PowerShell:

cmd /c '"E:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat" >nul && cl /nologo /O2 /std:c++20 /EHsc /arch:AVX2 brick_kernel.cpp /Fe:brick_kernel.exe'
./brick_kernel.exe
cmd /c '"E:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat" >nul && cl /nologo /O2 /std:c++20 /EHsc /arch:AVX2 /DVF_WORKERS=6 brick_kernel.cpp /Fe:brick_kernel_6.exe'
./brick_kernel_6.exe

The vcvars64.bat initialization printed a harmless missing-vswhere.exe notice; cl compiled and both programs exited successfully. Values are wall milliseconds from std::chrono::steady_clock, three repeats, Windows on the stated machine:

Stage	Eight workers (ms)	Six workers (ms)	Work
Full evaluation	362.538, 367.161, 349.001	479.017, 470.581, 481.011	16,777,216 grid points, each checks 48 spheres and computes 3 octave integer value noise.
Brick classification	15.590	15.464	32,768 bricks: 24,778 solid, 427 air, 7,563 uncertain. Conservative sphere/AABB extrema plus a proven ±224 noise envelope.
Classified evaluation	109.641, 86.959, 86.439	106.184, 129.769, 108.978	Full evaluation only for uncertain bricks; classified bricks retain their correct sign.
Verification	0 sign mismatches / 16,777,216	0 sign mismatches / 16,777,216	The sign of every classified point was checked against the full run. Density magnitudes in certified uniform bricks were intentionally not preserved.

The probe lacks passages, smooth Boolean operators, strata boundaries, edits, meshing, CPU cache competition with UE, upload and collision. Its 76.9% uniform-brick rate is synthetic and must never be substituted for the game's observed one-third uniform tile rate. The timing is evidence for the kernel's potential only. Full production sign/mesh/collision parity across seeds, strates, edits and CPU models is a release gate. The probe uses scalar integer code compiled with /arch:AVX2; that switch alone does not prove SIMD vectorization. AVX2 is a later optimization target, not a factor claimed in these numbers.

Three architectures considered

Architecture	Representation and pipeline	Main advantage	Main cost/risk	Verdict
A. Sparse compiled float bricks + CPU contouring + field-aware player edits	Seed/layout compile to a stable feature plan. Bin primitives to touched bricks. Each 8³ brick stores a final-sign certificate, quantized density cache and edit version. Mesh uncertain bricks with marching cubes; measure per-tile RMC upload before grouping. Use field queries for immediate player edits; test prioritized cook for steady collision. GPU edit transactions cover crater-scale changes.	Eliminates repeated feature traversal, supports edits and 3D topology, and avoids waiting on all ring cooks for player readiness.	Conservative certificates, movement integration and same-frame crater rendering still need UE/VR proof.	Recommended staged experiment.
B. Analytic CSG/BVH + raymarch render and collision	Keep a spatially indexed graph of implicit primitives and bounded noise, no resident sampled terrain except caches. GPU raymarches image-space rays through an acceleration structure; CPU queries analytic field for physics. Edits add CSG nodes.	Very long view and same-frame edits can avoid remeshing entirely.	Full-screen/stereo ray cost, non-SDF operators break safe sphere tracing, shadows/materials/UE integration; many edits enlarge BVH and query cost. It changes visual appearance.	Radical alternative if meshing/upload still dominate after A.
C. Integer GPU brick generation + compute meshing	CPU generates canonical integer plan/brick list; compute shader evaluates fixed-point density and emits deterministic mesh indices by prefix-sum, while CPU uses the same integer evaluator for authoritative player collision.	Could offload 17–22 M sample and contour work without collision readback; GPU Gems 3 demonstrates fully 3D GPU generation rather than a heightfield.	Cross-vendor integer ABI, duplicate CPU/GPU evaluators, VR frame contention, runtime mesh integration.	Research branch only until exact AMD/NVIDIA and CPU/GPU hash parity is demonstrated.

Architecture A should treat the plan as the source of truth and bricks as disposable caches. Compile op nodes once per region into a fixed order and collect local feature references by feature bounding box, with an explicit bound for noise, warps and edits. A brick certificate must enclose the final composed field: an operator that can add solid after a carve invalidates a carve-only proof. If any op cannot supply a safe bound, mark the brick uncertain. The current interval route's measured slowdown is a warning that a proof must cost less than the points it avoids. A local feature raster pass reverses the present “each point searches nearby features” loop and keeps shape data hot in cache. The sparse hierarchy stores occupied, empty and uncertain bricks; a compact, flat Morton or Z-major page table is likely better for the active 64 m cube than a pointer-heavy tree. OpenVDB provides a precedent for sparse, editable narrow-band fields, while sparse voxel octrees/DAGs are more compelling for static repeated geometry than for heavily edited procedural bricks. OpenVDB, Laine and Karras SVO report, Kämpe et al. sparse voxel DAG.

Retain marching cubes initially: in the local measured export, evaluation dominates, so changing the mesher first has little expected payoff. A later surface-nets or dual-contouring trial may reduce vertex/triangle output or preserve sharp authored features, but QEF placement, topology and transitions add complexity; benchmark the whole upload path before changing. Dual contouring's paper addresses Hermite samples and adaptive octrees; Transvoxel has explicit transition cells for adjacent marching-cubes LODs. The current skirts can visually hide cracks but are not a geometric continuity proof. Dual contouring paper, Transvoxel author, surface nets paper.

For A's collision, store an immutable field snapshot and expose a broad-phase AABB per resident spatial page. Its exact local ray/shape queries must use the canonical quantized lattice or a triangle patch made from it. The provisional player route is a purpose-built field-aware capsule sweep whose support state belongs to the current edit epoch; the staged cook and CMC override experiment in the consolidated plan may justify retaining prioritized cooked collision for steady terrain. For arbitrary Chaos rigid bodies, test a custom FImplicitObject/geometry-query adapter only if field-query fallback is insufficient; UE 5.7's installed Chaos/ImplicitObject.h exposes virtual PhiWithNormal and Raycast, but that does not prove the complete broad-phase, GJK/contact, CharacterMovement, navmesh or replication integration. A conservative collision box cannot stand in for a cave: it would block playable air. A signed density is not necessarily a distance bound, so ordinary sphere tracing may step through a thin wall; use interval subdivision/voxel traversal or a certified Lipschitz bound. Chaos API, Hart sphere tracing.

Determinism contract

A: Preserve the current precise-float CPU operator math and deterministic feature order as the first implementation. Pin build flags and CPU feature path, retain the scalar/SSE parity checks, and run full ring/edited-world hashes on every supported CPU/compiler pair. Define a versioned lattice ABI: integer world coordinates, float-to-int16 rounding/clamping, sign at zero, fixed interpolation/ties, ordered integer edit composition and material choice. Brick jobs may finish in any order because each writes a disjoint key and shared corners have one owner. The GPU consumes the quantized cache; it need not reproduce float Perlin for edit visuals. A full fixed-point procedural generator and AVX2 path remain conditional experiments. FastNoise2's own FAQ warns that automatically selected floating SIMD levels can differ across machines, so do not import that mode as world authority without locked semantics and hash tests. FastNoise2 FAQ, MSVC floating-point rules.

B: Analytic shape transforms and BVH construction need a stable sort and the same versioned CPU float/lattice contract. A GPU raymarch can remain a visual cache if it consumes canonical quantized samples or if its independently evaluated field passes CPU/GPU parity; arbitrary GPU float sin, sqrt and FMA cannot be assumed to match. /fp:precise helps source ordering but is not a cross-build magic guarantee, and CRT transcendental implementations can vary. The existing DetSinCos avoids one such dependency. MSVC /fp, CRT FMA3 selection.

C: Floating-point GPU density is ruled out for world decisions: Vulkan itself is not pixel exact, and available shader float controls have capability/operation limits. An integer GPU path is potentially deterministic only after restricting operations to defined 32-bit integer add/XOR/shift/multiply, explicitly emulating wider arithmetic if needed, forbidding unordered atomics for output order, using deterministic prefix sums, and hashing complete density/sign/mesh buffers on AMD, NVIDIA and CPU after every shader/compiler/driver class change. Until those parity tests pass, never make the GPU result authoritative for collision or replicated world state. Vulkan invariance, float controls proposal. GPU Gems 3 demonstrates speed opportunities for 3D terrain, but its floating-point GPU pipeline is no determinism proof. GPU Gems 3.

Preserving the game

3D and composition. The plan retains volumetric SDF/CSG regions, mountains, caves, overhangs and islands. A surface heightfield clipmap alone is disallowed: the original geometry-clipmap paper explicitly targets heightfields. Each current archetype, composer tag, structural post, passage and diff becomes a compiled op with a finite or explicitly unbounded influence declaration. Geometry clipmaps paper. The shipped examples support broad direction, not a claimed matching performance number: No Man's Sky describes its voxel-to-polygon pipeline and reports a later dual-marching-cubes rewrite improved loading; Astroneer describes re-polygonizing modified chunks; neither publishes a directly comparable one-second/64 m benchmark. Teardown's movable voxel volumes and packed occupancy hierarchy solve a different destructible-object problem, and Enshrouded's developer account confirms editable voxel terrain without exposing a transferable throughput figure. Dual Universe demonstrates a multiplayer editable voxel world, but its published material likewise gives no comparable generation latency. NMS GDC talk, NMS update, Astroneer developer account, Teardown developer's voxel rendering account, Enshrouded developer AMA, Dual Universe developer diary.

Walk guarantee. Keep the composer-generated entrance/exit route as an explicit graph of swept, capsule-clear walking corridors and landing floors. Apply that route as a late, protected operator whose minimum clearance and maximum slope have margins below the player capsule's mechanical limit; validate the final sampled collision representation with capsule sweeps. Decorative ops cannot narrow the protected clearance. For edits, protect a minimal support/clearance tube along one certified route; clip a crater's destructive part where it would remove the last walkable support or add an automatically generated bypass as part of the same transaction. A crater may therefore leave a thin protected bridge. This is a concrete rule that preserves the guarantee; the design of its visible cue is a gameplay/content task. The current route tests do not establish post-edit traversal, so verify it after each affected edit graph change.

Clean digging. Treat one edit as a transaction: allocate a monotonically numbered edit ID, compute every affected brick and one-cell halo from a single immutable pre-edit snapshot, and publish one canonical field/edit epoch before player movement in that frame. Border vertices use global lattice coordinates and a single owner, with identical edit IDs on both sides. The player queries the new quantized field immediately; a cooked body may serve steady terrain only while its edit epoch matches, and an obsolete cook cannot restore stale support. Character velocity is carried across an edit from actual displacement/input only; recompute grounded state without an invented downward impulse. A 1 m-radius interactive brush touches at most eight 2 m bricks at a grid corner before halo expansion. The render path switches the complete affected region in one frame using the GPU transaction described below, never a sequence of independent RMC tile updates. This does not yet prove same-frame edits: the UE/VR test must measure the whole transaction including GPU completion, stencil/depth, shadowing and stereo. Network edits carry server order and ID; prediction displays the same transaction locally and reconciles on authoritative order.

Streaming and long view. Keep a 3D clipmap but make LOD1 available first at 16 cells per tile: 19³/35³ = 0.160 of today's per-tile sample requests, an arithmetic count, not a measured 6.25× wall speedup. Applying that ratio to the supplied 16.5 M LOD1 requests yields 2.64 M requests; at the old ~2 µs/request this is 5.28 CPU-seconds, or 0.88 s on six ideally scaled cores, before upload. This arithmetic makes “a few seconds” credible for the preview even without the new brick speed, but it is no end-to-end guarantee. Refine to 32 cells later. Reuse lattice coordinates when coarse samples coincide with resident fine samples; outside the fine cube, evaluate coarse bricks independently. A far shell should be surface-aware and perhaps use a much lower-resolution 3D contour plus impostor for sealed distant strata; preserve visible caves/islands rather than flattening to terrain height. Use Transvoxel or a tested equivalent when meshes at unequal LOD meet. Prioritize spawn/teleport center, movement direction, falling support and edits; apply back-pressure to far work. UE Tasks priorities affect scheduling but do not preempt a running expensive tile; divide work into cancellable bricks. UE Tasks documentation, Transvoxel.

Multiplayer. Replicate seed, numeric ABI/content hash, compact plan/layout ID and ordered edit log. Do not replicate bricks, meshes or cooked physics. Hash canonical brick signs, surface vertices and collision answers on clients; reject incompatible builds rather than silently diverging. An edit arrives as one transaction with all affected brick IDs, never independent tile messages. For late joins, bound and checkpoint the edit log: Teardown's developer describes why replaying a deterministic command stream saves bandwidth but can become too slow after many edits. This is a qualitative design warning, not a VoxelForge timing estimate. Teardown multiplayer technical account.

Unreal rendering and Nanite

Keep RMC for the first experiment and measure its per-tile sustained apply rate with a raised frame cap. Group spatial pages and separate render pages from collision only if the measured game/render/RHI path misses the consolidated throughput gate. Replacing RMC with ProceduralMeshComponent only changes the wrapper around the same asynchronous cook; Epic documents bUseAsyncCooking, not a latency guarantee. UDynamicMeshComponent has useful edit representation but Epic lists no Nanite/LOD support and warns about render/memory efficiency. RMC's current upstream documentation claims runtime Nanite, and the locally installed RMC 5.4 source contains a runtime Nanite module and provider checks. Revisit Nanite as an isolated far/mostly static render benchmark, including PC VR stereo, page-build time, edit rebuild time and fallback mesh cost. It does not solve density evaluation or Chaos collision, and the first one-second ring should not wait for Nanite conversion. Nanite collision uses a fallback mesh, not Nanite triangles. PMC API, Epic dynamic-mesh guide, RMC docs, Epic Nanite fallback details.

Round two: wider search and revised engineering test

What the new local probe measured

Saved/Research/round2_probe.cpp is an independent C++20 program, not copied production code. It models the kinds found in VoxelNoise.h, VoxelDensityOpStack.cpp, and VoxelGenerator.cpp: hashed 3D gradient Perlin with a fixed-point quintic fade, three-octave fBm, ridged noise, one domain warp, upper/lower stratum bounds, a passage-like corridor, a room, and two smooth maxima. The gradient choice and fade shape follow the plugin, but the hash, coordinate scale, parameters, and composed graph differ. The code has a scalar reference and explicit eight-lane AVX2 integer evaluator; each lane writes exactly the same 16-bit value in the measured domain. The present plugin already has SSE4.1 x4 Perlin batching across octaves; the new speedup is therefore against this program's scalar reference, not against the production plugin's SSE path.

Build/run from Saved\Research on the owner's Ryzen/Windows machine:

cmd /c '"E:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars64.bat" >nul && cl /nologo /O2 /std:c++20 /EHsc /arch:AVX2 round2_probe.cpp /Fe:round2_probe.exe'
.\round2_probe.exe

MSVC compiled successfully; the installed setup script emitted a missing-vswhere.exe notice. Wall times below include six worker threads and output writes, exclude process startup and verification. Three three-trial runs with the same evaluation code (the second after dead-code cleanup, the third after adding the direct-query measurement) gave:

Work	Measured wall time	Meaning
256³ complete scalar field	492.0, 496.2, 469.6; 430.3, 456.2, 447.1; 478.6, 471.0, 444.3 ms	16,777,216 output points.
Same field, explicit AVX2	101.3, 106.0, 92.5; 89.2, 107.5, 94.6; 85.8, 80.3, 82.7 ms	Paired speedups 4.25–5.86×, zero value mismatches.
Full value comparison	0 mismatches in all 16,777,216 points on each trial	One machine and coordinate domain, not cross-vendor proof.
200,000 spatially scattered direct field queries	63.030, 62.785, 62.799 ms	313.9–315.1 ns/query, one scalar thread; all checksums equal. A synthetic player-query latency proxy, not a capsule sweep.
Radius-10 m spherical edit against cached field	0.865; 0.914; 0.861 ms	Six-worker max-composition over the 81³ bounding cube; excludes rendering and copy.
Copy entire 256³ 16-bit field	1.623; 1.422; 1.394 ms	An intentionally wasteful 32 MiB copy; local brick copy-on-write would copy much less.
Touched 8³ bricks / changed lattice sites	714 / 94,843	Exact for the synthetic sphere at a brick/tile boundary; geometry and edit content affect changed count.

Inference, not measured production latency: 17,373,979 ring points divided by the observed AVX2 throughput give 83.2–111.3 ms for this operator mix. Even the slowest scalar trial extrapolates to ~514 ms; a 0.5 s worker budget is close without AVX2 and leaves no room for a more expensive real composer. The scattered-query result implies ~635 queries in 0.2 ms at this synthetic rate, versus 100 at the supplied current ~2 µs/sample. A real player capsule sweep must be bounded and separately timed; this arithmetic does not establish a 0.2 ms sweep. SIMD is one possible factor in the required ~12× reduction, not the entire answer. Probe limitations: the plugin uses float Perlin today, its ridged noise has feedback/squaring absent from this simplified ridge, several operator classes and dynamic world-composer decisions are absent, the program computes all points without brick classification, the six worker threads contend with no UE tasks, and no mesher/upload/collision/VR frame is timed. A full fixed-point replacement would visibly alter worlds, which the owner now permits through a new world version, but its production speed benefit has not been established. Avoid claiming the synthetic 5× is a drop-in speedup. FastNoise2's fused SIMD graph and published 261.1 M 3D Perlin points/s on a different Intel CPU, FastNoise2 exact-reproducibility FAQ.

New evidence that changes the architecture

Source-measured or documented result	Transfer to VoxelForge
Eurographics 2025 Lipschitz Pruning reports 0.91–1.61 ms for 256³ discretization on a laptop RTX 4060 for scenes with 53–6,023 nodes, plus 0.72–14.29 ms pruning; its most complex model gained 629× in sphere-tracing against naïve evaluation.	Strong evidence for region-specific compiled operator programs, including smooth CSG, not a VoxelForge GPU speed prediction. The method assumes primitives/operators with computable 1-Lipschitz bounds; arbitrary warped scalar density needs derived bounds or a fallback. Its fluid scene with 27,977 close particles needs 125.5 ms pruning and 6.99 ms discretization, demonstrating layout sensitivity. Paper and Table 1.
Accelerating Signed Distance Functions reports up to three orders of magnitude on its construction-tree scenes, using proxy/LOD nodes. It expressly warns that a discontinuous proxy below a smooth union causes artifacts, and that manual LOD authoring and extra nodes cost memory.	Compile local plans and conservative proxies with operator-aware legality; no generic “replace any far branch with a constant.” Preserving the exact zero set near transitions matters for walking and digging. Paper.
Keeter's SIGGRAPH 2020 interval method simplifies complex closed-form expressions by region; Knoll et al. compared interval and affine arithmetic for implicit ray tracing.	Both are real alternatives for exotic operators, but the local blanket interval attempt worsened 0.588 s to 2.057 s. Use inexpensive analytic primitive influence and final-sign certificates first; profile any tighter affine bound by avoided evaluations per microsecond. Keeter, Knoll et al., local control.
Eurographics 2025 Fast Sphere Tracing of Procedural Volumetric Noise reports a detailed 3D procedural-noise scene at 16 ms for 1024² pixels on an Nvidia 4080 Ti, versus 110 ms naïve; the authors report up to 12× on opaque/constant-transparency scenes using derivative-aware stepping and nested fBm bounds.	Strongest recent case for the analytic-render alternative. Linear scaling from 1.05 M to 4.15 M stereo pixels would be ~63 ms on that different GPU/scene, before VR lighting; this is a cautionary inference, not a measured Quest 3 figure. Reuse its nested fBm bound idea for local-region culling even if raster meshes remain primary. Paper.
JCGT 2019 reports 15–20% faster 3D cellular noise traversal than standard Worley on its benchmark (for 16 M queries, one table row falls from 13.69 s to 11.15 s).	Relevant only to the plugin's cellular roughness branch, not its dominant gradient-Perlin calls; do not multiply this into a ring-wide speedup. JCGT paper.
Voxel Plugin 2's own change log claims up to 2× world generation from skipping cells far from surface, plus up to 40% VRAM reduction in an experimental Nanite path. Its docs separate collision and render invokers.	Confirms that surface sparsity and collision/render separation are practical in UE, but vendor numbers are not a transferable end-to-end 12×. Voxel Plugin 2 change log, collision design.
FastNoise2 reports 261.1 M AVX2 3D Perlin points/s on an Intel 7820X; its FAQ says floating SIMD levels can differ and advises strict FP plus a locked SIMD level for exact output.	Fuse whole op graph in registers; do not import float FastNoise2 with automatic SIMD dispatch as the canonical multiplayer field. Our fixed integer benchmark shows a path to parity on one CPU; cross-machine parity still needs testing. Library and benchmark, FAQ.
Epic's UE 5.7 Mover comparison says movement can use a root scene component without a collision primitive and custom movement modes; local UE 5.7 CharacterMovementComponent.cpp still makes floor and move sweeps through the engine collision scene.	Mover is the provisional field-aware movement route, preserving sweeps against nonterrain actors. A prioritized cook plus an edit-time CMC field override may be less invasive if the staged-cook and underfoot edit gates both pass. Simply leaving the old CMC capsule on an uncooked mesh does not fulfill “collidable.” Mover remains a migration risk under network prediction. Epic Mover comparison.
Epic's RDG documentation supports compute passes, dependency barriers and async compute but notes platform fallback to the graphics pipe.	A GPU edit mesher can be integrated with a render-graph transaction, but “async” does not establish same-frame latency or free VR time. Epic RDG guide.

Crater spell: one transaction, up to 64 tiles

A radius-10 m sphere is 40 lattice intervals at 25 cm. Its 20 m AABB reaches up to 4 tiles per axis when centered on a tile boundary, hence 64 full-detail 8 m tiles; at a tile center it reaches at most 27. The sphere's continuous volume is 4π40³/3 = 268,083 voxel cubes versus 81³ = 531,441 candidate lattice sites. The local exact sphere/AABB enumeration found 714 2 m bricks touching the ball. Independently contouring each 8-cell brick needs 714×9³ = 520,506 corner-sample reads before sharing; the real distinct set is smaller, and normal or LOD halos can add reads. A naïve re-evaluation at today's 2 µs/sample would cost about 1.04 CPU-seconds for those corners, so cache the base field and compose the edit over it. The measured synthetic cached-field edit took 0.865–0.914 ms, but no extraction or upload was measured. CPU copy-on-write at touched bricks has a raw 16-bit interior payload of 714×8³×2 = 731,136 bytes; a full near-field 32 MiB copy was measured at 1.422–1.623 ms. The crater itself is ~one command (center/radius/shape/seed/version), not 95,000 replicated voxels. A pathological marching-cubes upper bound is 714×512×5 = 1.83 million triangles; at three unshared 16-byte vertices each that is 87.7 MB of transient output. Realistic counts must be measured, and GPU buffer overflow must fall back to a complete-region visual path, never publish half a crater.

Proposed fast path. Commit an edit in a deterministic order with a monotonically increasing edit sequence. On the CPU, publish a new immutable edit-plan pointer for all 714 bricks before movement and render gather for that frame. A canonical signed integer field query composes the crater immediately, so player floor/capsule sweeps cannot see stale support; nonplayer traces use the same fallback until their optional Chaos mesh is ready. Never transfer a removed collision body's velocity or use old cooked floor data after the edit sequence changes. If the dig removes the floor, real gravity begins from the player's pre-edit velocity exactly once; if it adds terrain around the capsule, resolve penetration with a bounded positional correction that does not enter velocity. The entrance-to-exit route is a protected graph corridor: preflight the crater against a protected walkable tube and either clip its solid-adding part, carve a replacement bypass, or reject the spell by explicit gameplay rule. For pure excavation, connectivity cannot be reduced, though walking surfaces can be removed, so the route proof must include footholds/clearance, not only air connectivity.

For visuals, use one GPU edit transaction over the whole affected region. Keep the near lattice field resident on the GPU; upload the compact command, compute the changed bricks and their transition halo in a single render-graph dependency, generate canonical marching-cubes triangles with a stable per-cell prefix sum, and swap the entire region's draw descriptors together at a frame boundary. Suppress the old region only when its replacement is drawable; no per-tile apply loop. All visible coarser LOD footprints touched by the spell take the same edit sequence, using the corresponding coarse lattice and transition mesh; an unloaded distant region records the command for generation when it enters view. A local volume-raymarch overlay can cover the transaction while mesh extraction is late, using the same canonical cached field and edit command, with a one-cell overlap and exact depth writes. The overlay must be checked against the meshed boundary and stereo views to rule out cracks, double surfaces, and ghost shadows. This is an engineering design, not a proved same-frame guarantee: no UE/GPU measurement was authorized in this research pass. The decisive GPU/VR test must finish edit compute + descriptors + draw in the first submitted render frame whose simulation includes the command; an input received after that frame's render submission belongs to the next frame. No affected tile may show a different edit sequence in that frame. Epic RDG synchronization, GPU Gems 3's 3D GPU marching cubes.

The current crash mode is especially clear for crater scale: synchronous center-tile remesh followed by up to 63 independently queued neighbors produces a visible wave; disabling old collision and waiting 0.4–1.4 s for cooks creates a falling gap; retaining old BodySetup creates ghost support. The transaction above removes those three states. It does not assume that optional Chaos rigid bodies can all get exact crater collision in the same frame; the owner expressly accepts field-query fallback for NPCs, arrows and other physics until their mesh is ready.

Serious alternatives, with quantified wins and losses

Alternative	Where it could win	Why it is not the primary route now
Whole-world analytic raymarch (radical B)	No persistent triangle mesh; edit command changes the next render. Keeter and 2025 pruning show that complex trees can be raytraced after regional simplification.	At 1920×1080, 2.07 M rays per eye, or 4.15 M stereo rays before shadows/VR supersampling; at 32 field steps this is 133 M queries/frame. At the measured synthetic AVX2 throughput of ~156–209 M grid points/s across six cores, that many CPU queries would take ~0.64–0.85 s; GPU may be far faster. The 2025 procedural-noise paper measures 16 ms at 1024² on a 4080 Ti; simple stereo-pixel scaling to 4.15 M gives ~63 ms before VR lighting, a scene/hardware inference. Density is not necessarily a distance bound for safe sphere tracing, and a full GPU renderer is a larger rewrite. Keeter, EG 2025 noise tracing, SDF-grid ray tracing, JCGT.
All-GPU integer generation and meshing (C)	The Eurographics RTX 4060 paper's 256³ discretization at 0.91–1.61 ms shows enormous headroom in a suitable GPU expression, though its data/model differ. Could supply same-frame crater triangles.	Requires explicit 32/64-bit integer arithmetic rules, fixed division/rounding, no unordered atomics for vertex order, deterministic prefix sums, CPU/GPU/AMD/NVIDIA parity hashes, and an UE RHI path. Any float-transcendental or vendor-specific FMA noise breaks the canonical requirement. The paper's pruning and rendering are GPU-only and do not prove the CPU player query. Lipschitz Pruning, Khronos float controls.
Dual contouring / surface nets / adaptive power-diagram contouring	Potentially fewer vertices and sharper features; JCGT's SurfaceNets work reports better triangle quality than classic MC for segmentation models. A 2025 power-diagram method reconstructs complex SDF geometry from fewer samples.	Generation is ~97% density time in the local attribution, so changing contouring alone can save at most the remaining ~3% of that worker window. Adaptive sampling could save more but needs a certified error/feature rule for narrow passages. SIGGRAPH Asia 2024's GPU occupancy dual contouring still describes runtimes of a few seconds for its distinct reconstruction problem, not subsecond terrain streaming. Seam dependencies and LOD transition rules become more complex; neither solves cook or atomic edit transactions. Benchmark later if upload dominates after density rewrite. Dual contouring, JCGT SurfaceNets, Eurographics 2025 power-diagram contouring, SIGGRAPH Asia 2024 occupancy dual contouring, chunk seam example.
SVO/DAG or OpenVDB as source of truth	Empty-space skipping and sparse memory; GPU SVDAG editing shows large 3D painting can be interactive in a different system.	The world's seed/composer already is a compact source. At full 25 cm resolution, the 64 m cube alone has 17.37 M unique samples or 34.7 MB at 16 bits if fully resident; a global 6 km view volume is vastly larger. DAG sharing degrades with unique noise and edits; keep a sparse cache/hierarchy, not a required full-world DAG. The cited GPU editor's code uses CUDA, so it is no cross-vendor solution. OpenVDB, SVDAG editing paper, author code.
Prebake each seasonal world in the shipped game	If seasons have a finite, known seed/layout set, local NVMe transfer could remove cold density evaluation and deterministic divergence.	For this 64 m cube, even raw 16-bit density is 34.7 MB before meshes; ~6 km horizontal radius with only an 8 m thick full-detail slab is π×6000²×8/(0.25³) ≈ 57.9 billion voxels, 116 GB raw per season. That slab is an intentionally generous lower bound for a mountainous/cave world. Sparse compressed meshes could be far smaller, but their disk, decompression, upload, and arbitrary composer/layout variants need an actual content budget. Prebake a few spawn hubs or far-field impostors, not every possible volume.
Server-streamed chunk data	Server could send already generated chunks, avoiding client generation.	A raw 34.7 MB 64 m cube in 1 s requires 278 Mb/s payload before meshes/protocol, and this contradicts the explicit requirement that only seed, layout and edits replicate. Compression helps bandwidth, but latency/server scaling and the hard protocol rule remain.
Far-field impostors, 2.5D clipmaps, Nanite	Far view can be far cheaper if represented by coarse meshes/impostors; RMC locally contains a runtime Nanite proxy path, and Voxel Plugin 2 reports experimental Nanite memory savings.	An exterior heightfield loses caves/overhangs/islands when used as the whole world. Impostors are acceptable beyond interaction range if the world returns to 3D on approach, with a continuous crossfade and occlusion policy. Nanite can help mostly static far render, but Epic's dynamic mesh guidance says UDynamicMeshComponent is not Nanite-compatible, and Nanite fallback geometry still serves collision; runtime build/edit/VR costs here are unmeasured. Geometry clipmaps, Epic dynamic mesh guidance, Nanite fallback, RMC code.

What was searched, and what was ruled out

The source sweep covered SIGGRAPH closed-form interval rendering and GPU Gems 3 volumetric marching cubes; Eurographics 2025 Lipschitz pruning, derivative-aware procedural-noise tracing, proxy/LOD SDFs and adaptive contouring; older affine-interval ray tracing; JCGT SDF-grid ray tracing, cellular noise and SurfaceNets; HPG/i3D-style GPU mesh shader and SDF work; OpenVDB, SVO, DAG and GPU SVDAG editing; FastNoise2, ISPC, Inigo Quilez's analytic noise-derivative slides and table-free hashed noise; UE 5.7 Mover/CMC source, RMC local source, Epic RDG/Nanite/dynamic mesh documentation; Voxel Plugin 2; and developer material for No Man's Sky, Astroneer, Teardown, Enshrouded, Space Engineers, Vintage Story, Dual Universe, Sebastian Lague, Nick Gildea and 0fps. Quilez's derivative formula is useful for normal or local bound construction, but a sampled derivative is not a certified maximum over a brick. The strongest transferable ideas were region-pruned expression trees, fused SIMD evaluation, sparse near-surface work, direct player field collision, and whole-region render transactions. No retrieved shipped-game account publishes a directly comparable cold 64 m, 25 cm, 3D editable, UE/VR, all-visible-and-player-collidable <1 s measurement; their performance figures must not be presented as proof of this target. Quilez noise-derivative slides, NMS GDC, Astroneer developer, Teardown developer, Space Engineers source, Vintage Story developer, 0fps smooth voxel terrain.

Specifically ruled out as a complete answer: greedy block meshing (different surface model), heightfield-only terrain, unbounded generic interval recursion (failed local control), auto-selected float SIMD noise (vendor/CPU parity risk), CUDA-only edit structures (AMD target), Nanite or another UE mesh component alone (density/cook bottlenecks), and one tile at a time crater updates. Isosurface mesher alternatives, affine arithmetic, full GPU generation, and far impostors remain research branches with explicit benchmark gates. 0fps block meshing, FastNoise2 determinism FAQ, SVDAG editor code, Epic PMC async cooking.

Revised gates and migration sequence

The consolidated seven-step plan above supersedes this round-two sequence. Its decisive change is to measure the existing collision and RMC apply stages first, then benchmark a prepared float region evaluator against the actual composer before choosing a full integer procedural ABI, Mover or render grouping. Keep the composer/content schema, route graph, multiplayer edit log and old tile evaluator as an oracle while migrating. The final numeric ABI still specifies quantization scale, rounding/saturation, zero tie, interpolation, material ID and stable op ordering; scalar/SSE parity and two-CPU hashes are release gates. A cross-vendor GPU hash is required for integer edit and mesh decisions, but the GPU does not need to reproduce float procedural noise. The round-two standalone probe remains a lower-complexity feasibility bound, not the acceptance test for production latency.

What not to do

• Do not infer a 512-tile deadline from one tile's p95, or from the synthetic 0.1 s classified benchmark. Queueing, bandwidth, upload and physics are separate clocks.
• Do not put all 512 Chaos triangle cooks on the player readiness path. The observed 0.4–1.4 s interval is submit-to-ready and may be mostly queue delay; prioritize and time the small player-support neighborhood before ruling out cooked steady-terrain collision.
• Do not assume a sparse octree/DAG or OpenVDB automatically speeds a procedural query. Their compression and hierarchy help only if the final-field signs/bounds can be computed cheaply; edits and arbitrary smooth operators can make most nodes uncertain.
• Do not rely on heightfield clipmaps, GPU float world decisions, unordered GPU atomics, or sin/CRT results as a network world ABI.
• Do not claim AVX2, dual contouring, Nanite or a different mesh component will erase the observed 97% density cost. Benchmark each in its proper stage.
• Do not publish one touched tile while its neighbors still show the old edit; do not suppress collision under a pawn before a consistent replacement exists. Those are the visible ripple, vanish and false-support failure modes in the present implementation.

The owner has clarified both contracts: collision inside one second applies to the player, while bounded digging and radius-scale spells both require atomic same-frame visuals. Immediate field-aware edit support and the transaction-wide visual path are required; Mover versus a prioritized-cook/CMC field-overlay hybrid is decided by the staged tests above. Their deadlines remain unproved until an authorized UE/VR integration gate can be run.