VoxelForge/RESEARCH-SPEED-2026-09.md

VoxelForge speed research — 29 September 2026

Answer first

Revised recommendation: compile a deterministic integer operator plan into spatially pruned 8³-voxel bricks, mesh only uncertain bricks, and give the player direct field collision. Add a transaction-wide GPU visual edit layer for large spells; keep baked meshes and optional Chaos collision as background caches. The player collision definition supplied in round two removes the 512 simultaneous Chaos-cook requirement. The crater requirement adds a second critical path: changing 714 bricks cannot depend on 714 component uploads within one frame. Keep the 25 cm lattice, volumetric operators, walkable route graph and seed/layout/edit replication. Replace point-at-a-time feature search with a stable region-local program and conservative final-field bounds. Recent work on pruning SDF construction trees directly supports this direction, 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	Even free workers cannot meet one second with one component per tile and the current apply cap. Batch approximately 64 groups of 2³ tiles, or use a single batched stream with independently editable sections. The actual game-thread time remains unmeasured.
Current collision	Owner's 0.4–1.4 s submit-to-ready per tile	A per-tile cook cannot be on the critical path. Async cooking only moves CPU work; it does not make collision available before completion. Epic BodySetup API, RMC documentation.
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.

Build cost: revise to roughly 6–12 engineer-months for a production replacement (planning estimate, not a measured rate), because the numeric ABI, custom player movement queries, batched rendering, and transaction-wide crater visual layer are separate major systems. The first falsifiable experiments are smaller. No evidence here proves the UE render path can present a cold 64 m cube in under 1 s or a radius-10 m crater in the same VR frame. If those experiments fail, the owner must accept a reduced near ring, a delayed exact crater visual, or a more radical GPU render path; none can be silently assumed away.

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 bricks + batched CPU contouring + direct player field collision	Seed/layout compile to a stable feature plan. Bin each primitive to touched bricks. Each 8³ brick stores a final-sign certificate (solid/air/uncertain), compact density band and edit version. Mesh uncertain bricks with marching cubes; group tiles for upload. Give the player field-aware movement. GPU edit transactions cover crater-scale changes.	Eliminates most repeated feature traversal, supports edits and 3D topology, removes cook from player readiness.	Conservative certificates may fail on complex stacks; player movement and same-frame crater rendering still need UE/VR proof.	Recommended 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, then implement exact local ray/shape queries against its canonical lattice or a small on-demand triangle patch. For player movement, use a purpose-built capsule sweep against the field and make support state an explicit function of the new snapshot. For arbitrary Chaos rigid bodies, test a custom FImplicitObject/geometry-query adapter; 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: Define a versioned numeric ABI: integer world coordinates; fixed-point density with specified scale, rounding, saturation, signed division and overflow; hash-keyed integer lattice noise; explicit polynomial or lookup approximations where needed; fixed op order by stable feature ID; fixed interpolation and tie-breaking at density zero; fixed material selection. Use 64-bit intermediates where 32-bit products could overflow. Brick jobs can run in any order because each writes a disjoint key and canonical shared samples have a single owner. SIMD integer lanes must produce bit-for-bit the same values as the scalar reference; run full-world and edit hashes on distinct x64 CPU models before release. An AVX2 path may accelerate independent lanes, but never change reduction order. FastNoise2 shows the potential of fused SIMD noise graphs, yet its published throughput is for its own noises and does not establish VoxelForge speed or bit parity. FastNoise2 code and benchmarks, MSVC floating-point rules.

B: Analytic shape transforms and BVH construction must use that same fixed-point ABI and stable sort; GPU raymarch output is visual only unless its field math passes bitwise parity. Floating-point sin, sqrt, FMA and different compiler choices can move zero crossings or BVH decisions. /fp:precise helps source ordering but is not a cross-build magic guarantee; the MSVC CRT selects different transcendental algorithms by CPU FMA3 support. Keep the authority in integer CPU code. 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 field immediately; optional cooked bodies are never authoritative for the player 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, but reduce component count by grouping spatial pages and separating render pages from collision. Replacing it 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. The fixed-point replacement will visibly alter worlds unless the project accepts a versioned new season or derives a compatible canonical approximation. 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.	Player collision should be a custom field-aware movement mode/adapter, most plausibly Mover, while preserving sweep checks against non-terrain actors. Simply leaving the old CMC capsule on an uncooked mesh does not fulfill “collidable.” Mover is a migration risk and must be tested 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

1. Freeze the numeric ABI and world-version rule. A new integer kernel changes the existing float-generated world's terrain. Treat it as a new season/build version, or demonstrate exact backwards parity (unlikely); keep older season serialization explicit. Specify signed division, saturation, noise hash, fade table, zero tie, interpolation, material ID and stable op ordering. Run scalar/AVX2 hashes across different CPU models and CPU/GPU hashes across AMD/NVIDIA before enabling any GPU canonical path. Integer intrinsics are promising precisely because bitwise multiplication/shift can be matched, but the round-two parity test covers only one CPU.
2. First cheap kill test (standalone, before UE): extract two real seeded composer plans including warped rooms, passages, strata boundaries and edits, record original density/sign/route references, compile regional operator programs, and benchmark a cold 259³ ring with six workers. Record classifying cost, uncertain-brick fraction, branch count, worker wall, memory, and exact sign parity at all lattice points. A plausible initial gate is ≤0.35 s worker wall for the production plan, reserving ≥0.65 s for mesh/upload/scene work; this is a budget decision, not a measured UE limit. If value compatibility with old seasons is required, benchmark that exact math separately. The existing round-two probe establishes only a lower-complexity feasibility bound.
3. UE/VR gate when implementation is authorized: measure render-thread upload and first visible frame for a cold 512-tile cube, plus Mover/field capsule sweeps under repeated underfoot edits. Implement one radius-10 m transaction with GPU direct mesh or exact local overlay and measure the same frame in PC and Quest 3 stereo, with screen captures at tile borders, occlusion and shadows. Fail the architecture if p99 edit frame exceeds the VR budget or any tile shows a different edit sequence. No standalone CPU result can substitute for this gate.
4. Port in slices: keep the composer/content schema and route graph; replace the evaluator with compiled per-region plans; add brick caches and shared lattice; move player terrain collision to canonical field queries while retaining ordinary sweeps for other actors; replace tile components with batched render pages; add transaction visual path; then optionally background Chaos bodies and far Nanite/impostors. Recheck multiplayer late join by replaying the ordered edit log and comparing region hashes.

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 another 512 Chaos triangle cooks on the readiness path. This conflicts with the observed 0.4–1.4 s per-tile completion window even if generation became free.
• 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: exact collision inside one second applies to the player, while bounded digging and radius-scale spells both require atomic same-frame visuals. The field-aware movement and transaction-wide GPU edit path above are therefore required parts of the proposed architecture. Their deadlines remain unproved until the authorized UE/VR integration gate can be run.