VoxelForge/RESEARCH-ASTRA-2026-10.md

Astra (gpt-6-astra, max): how else could we do it? — 2026-10-02

Prompt: scratchpad astra-think.md (free thinking, nothing off the table). Answer verbatim below.

I would bet on your coarse-structure/fine-surface idea, extended in two ways: generate surfaces directly wherever possible, and make edits immediately queryable without waiting for replacement meshes.

The largest opportunity is to make the ordinary cost scale with surface area, visible detail, and recent changes. Dense volumetric work should be reserved for places where complicated three-dimensional intersections actually require it.

I read the research report and use the newer timings in your prompt below. All performance estimates here are arithmetic or architectural estimates, not measurements of these proposed designs.

At 100 ns per point, 140 million points require about 2.3 seconds on six perfectly scaling workers, before anything else happens. That makes the central problem clear: further local optimization cannot carry the full burden.

There is also an important distinction inside “detail”:

What the player perceives	What must represent it
A passage, hole, thin wall, or floating island	Actual solid/air topology
A foothold, climbable edge, or projectile obstruction	Gameplay geometry
Rock relief that changes silhouettes and stereo depth	Actual rendered surface displacement or geometry
Grain, mineral variation, tiny scratches, wetness	Shading and material information

A finer lattice spends more on all four together. Your game can give each its own representation and still present one coherent world.

The difficult negotiation is whether every visible grain must also be an independently collidable, destructible object. If that is required at arbitrarily increasing resolution, the physical complexity must eventually be paid for. If the requirement is increasingly fine visible rock, there is much more room.

1. Give fine detail a surface representation. This is the strongest immediate direction.

A cave wall can have a relatively simple structural surface and an extremely detailed skin.

A useful version would contain:

• Structural geometry for chambers, passages, ledges, holes, and substantial protrusions.
• A bounded surface displacement for shallow fractures, erosion, and rock relief.
• Normal, roughness, colour, and wetness variation below that.
• Explicit small geometry for features such as thin stalactites that cannot be represented by shallow displacement.

This follows the useful idea behind film-style micropolygon rendering: keep a compact description of a surface, then subdivide and shade it according to what the image needs. Pixar’s original Reyes architecture is a foundational example.

The crucial improvement over “coarse geometry plus nicer materials” is that the surface layer should include real geometric relief where stereo or silhouette makes it necessary. Normal mapping alone will fail the owner’s close inspection. Parallax mapping has useful applications, but I would not make it responsible for rock silhouettes or convincing near-hand VR geometry.

There are two traps.

First, tessellating a coarse, faceted mesh does not automatically recover a smooth underlying shape. The refined vertices need a meaningful curved surface to follow: a procedural patch, a suitable subdivision surface, or projection onto a local structural field. Otherwise, finely tessellated facets remain facets.

Second, displacement cannot create arbitrary new topology. A six-centimetre hole through a wall needs an explicit hole or a locally finer volumetric representation. It cannot be recovered by adding surface roughness to a mesh that sealed it.

For your reference image, that distinction is favourable. Broad ledges, columns, hanging formations, and fractured slabs supply the geometry. Much of the apparent richness comes from correlated relief, material, moisture, lighting, and water.

What it gives: returning the structural lattice from 12.5 cm to 25 cm reduces the dense sample count by approximately 8×, while the rendered surface can become finer than either lattice. This is a sample-count reduction, not an 8× whole-game guarantee.

What it costs: continuous GPU work, surface refinement, coherent material coordinates, and careful boundaries between patches. At 90 Hz, the entire frame has approximately 11.1 ms; displacement and its shadows must share that budget.

What it takes away: automatic physical significance for every visible bump. You need an explicit displacement envelope and contact tolerance. Where precise hand placement or tool contact matters, the CPU can evaluate the same relief locally, rather than generating that detail throughout a 64 m cube. Robust contact queries still require more than checking a few points.

Determinism: retain canonical structural geometry and deterministic surface parameters. Any relief used for gameplay must have a canonical evaluator too. Lighting and final pixel calculations can remain device-dependent without changing the world’s gameplay answers.

A signal-processing lesson matters here: preserve the detailed surface definition, but filter its image. Trying to display every tiny frequency at every distance causes shimmer rather than fidelity. Procedural noise can be designed with controlled frequency content and filtering; Gabor noise research is one useful example. Finer detail can be inexpensive when it comes from a reusable filtered texture or compact surface function. Additional geometry, shadowing, and contact complexity are never literally free.

There is an Unreal-specific qualification. UE 5.7 documents Nanite tessellation as experimental, limited to Nanite meshes, and subject to displacement cracks at discontinuous attributes. Its standard UDynamicMeshComponent does not support Nanite. Nanite/Lumen XR support is also experimental and requires PC deferred rendering with DX12. Your PC-linked Quest fits the PC category, but this is an integration and performance risk, not a checkbox solution. Nanite tessellation, Dynamic Mesh limitations, XR support.

I would validate the surface concept independently of whether Nanite becomes its eventual implementation.

2. The radical direction: make the generator describe the cave boundary directly.

Today, the generator knows how rooms and tunnels were constructed, but the mesher largely rediscovers their boundaries by asking millions of questions about space.

I would investigate preserving that construction knowledge all the way to geometry.

A chamber could generate floor patches, ceiling patches, and connecting wall patches. A tunnel could generate a swept cross-section along a curve. Columns and stalactites could generate tapered, deformed surfaces. Ledges could follow bedding planes. Floating masses could be closed procedural objects.

These are local two-dimensional surfaces embedded in three dimensions. Multiple overlapping levels and arbitrarily oriented patches provide overhangs and stacked caves; this does not require a globally single-valued heightfield.

At complicated junctions, blends, and heavily edited regions, retain your volumetric system. Those regions become exceptions with explicit boundaries.

The result is a world recipe containing:

• A graph describing connections and traversable routes.
• Surface-producing features with conservative bounds.
• Local volumetric regions for difficult topology.
• Surface detail parameters and player edits.

This changes the generator’s responsibility. A feature should be able to supply its boundary, its bounds, and its relevant gameplay queries—not just a density value at an arbitrary position.

There is an artistic reason to consider this too. Geology produces strong correlations: bedding, fracture directions, drainage paths, erosion, and deposition. Those correlations are an excellent form of compression. One bedding description can explain thousands of related ledges and fractures.

Research on geologically coherent cave networks demonstrates useful controls through faults, horizons, permeability, and network skeletons. That paper ultimately constructs an SDF; my proposal is to retain additional boundary knowledge through the rendering pipeline.

Here is the potential dimensional advantage.

Illustrative estimate: suppose the nearby region contains 20,000 m² of rock surface. The actual area in your game must be measured.

Representation at 12.5 cm spacing	Approximate sample locations
Your full cube, including its sampling overhead	140 million
A surface band with total thickness of four cells	5.1 million
Direct surface sampling, roughly one location per (h^2)	1.3 million

The narrow-band estimate is:

[ N \approx \frac{A(4h)}{h^3}=\frac{4A}{h^2}. ]

For fixed surface area and complexity, halving spacing makes surface sampling roughly 4× larger; dense volume sampling becomes 8× larger.

These are counts, not interchangeable operation costs or promised speedups. Surface intersections, charts, normals, transitions, and acceleration structures all add work.

Most importantly, your existing uniform-brick skipping already captures some of this benefit. The table cannot be claimed as an additional 27× improvement over that implementation.

The new opportunity is to enumerate likely surface regions directly, or emit surface geometry directly, so that you avoid both expensive field evaluations and a large search through candidate bricks. If a proposed hierarchy still performs essentially the same uncertain-brick evaluations, it has not changed your problem.

For the volumetric exceptions, narrow-band storage is well established; VDB provides relevant techniques. Its data structure does not, by itself, make your procedural field cheaper. Your report’s failed generic interval experiment is a good reason to insist on cheap, construction-specific bounds.

A useful intermediate technique preserves fine detail exactly: give the coarse description a conservative envelope containing the full detailed boundary, then evaluate the complete fine function only inside that envelope. This can retain the original detail where it matters. It works only if the envelope is cheap and sufficiently tight. Sampling coarse corners alone cannot certify that a thin feature is absent.

What it gives: potentially the largest lasting reduction in generation work, faster distant representations, better artistic controls, and a natural place to construct guaranteed routes.

What it costs: a substantial generator redesign, patch stitching, solid/interior classification, and maintaining a volumetric fallback. Junctions are the hard part.

What it takes away: the convenience of expressing every shape as unrestricted noise and arbitrary field operators. You can preserve output freedom through exceptions, but a world composed almost entirely of tangled exceptions will recover the expensive behaviour.

Determinism: replicate feature IDs, parameters, graph/layout, content version, and edits. Use canonical rules for patch boundaries and gameplay queries. Each client can build different temporary caches while deriving the same defined geometry.

This also offers a better target for precomputation. Bake a reusable library of rock profiles, fracture relief, and formation families. For scale, 256 relief tiles at 256² texels and four bytes per texel occupy 64 MiB before mipmaps. That is an illustrative shared asset library, not a storage estimate for your whole art set. It can be reused across every seed and season.

3. Make a crater immediately evaluable, then rebuild its acceleration structures later.

There is a useful geometric fact behind excavation.

After subtracting a volume from rock, the resulting surface consists of:

• Surviving parts of the old rock surface.
• Parts of the excavation boundary that lie inside the old rock.

For a spherical blast, the new interior surface comes from the sphere boundary. The volume in the middle becomes known air.

That suggests treating a spell as an immediately active geometric operation, with meshes serving as cached representations of its result.

For scale, a 10 m radius sphere has approximately 1,257 m² of surface. At 12.5 cm spacing, that corresponds to roughly 80,000 surface locations, before intersections and other overhead. Its 20 m bounding cube contains approximately 4.17 million lattice locations.

This is not an 80,000-sample implementation promise. It explains why a boundary-oriented edit algorithm has a fundamentally different opportunity from rebuilding the affected volume.

A possible immediate path is:

1. Commit one canonical excavation command.
2. Make movement and terrain queries observe it immediately.
3. Clip affected old surfaces and render the newly exposed boundary through a local CSG or implicit rendering path.
4. Build the enduring mesh and collision caches in the background.
5. Replace the temporary rendering only when the replacement is complete and equivalent.

Image-based constructive solid geometry is an established family of techniques: OpenCSG renders Boolean combinations without first constructing their final mesh boundary. That establishes the possibility; it does not supply a ready-made Unreal terrain solution.

The hard parts are substantial:

• The new crater surface must be clipped correctly against existing caves and earlier excavations.
• Removing the first visible wall must reveal whatever is behind it.
• Depth, shading, shadows, and both eyes must agree.
• Independent cap and terrain tessellation need consistent intersection boundaries.
• The temporary and cached representations must describe the same surface closely enough to avoid a visible changeover.

A single regional implicit rendering path can avoid some mesh-boundary problems, but then it needs robust field traversal. Your signed density cannot automatically be treated as a safe sphere-tracing distance.

For overlapping spells, render the composed result. Independently displaying several crater shells produces internal surfaces that should not exist.

This is also where the database analogy helps. The seed/layout and ordered edits are the authoritative record. Meshes, collision bodies, and GPU pages are derived indexes. An edit can become semantically active before every index is rebuilt, provided queries correctly combine the old index with pending changes.

What it gives: a credible architecture for same-frame excavation whose latency does not depend on draining dozens of component updates.

What it costs: custom rendering and terrain-query integration, plus management of overlapping edits and temporary representations.

What it takes away: a cheap universal implementation for arbitrarily complicated edit operators. Spheres, capsules, and bounded procedural blasts are favourable. Unbounded numbers of overlapping edits still require work; the supported spell load needs a defined budget.

Determinism: distribute canonical edit parameters and ordering. Immediate queries and later meshes must implement the same composition rules. A CPU-produced canonical lattice or a specified integer GPU evaluator can provide agreement where the rendering path needs authoritative signs.

“Same frame” should mean the first submitted frame containing the accepted command. Remote machines necessarily see commands after network delivery; local prediction can hide that latency. Within each machine, the whole affected region must use the same edit state.

I would regard this as a complement to your surface-detail idea. Faster generation alone does not create atomic visual publication.

4. Reopen GPU generation specifically through defined integer arithmetic.

Rejecting ordinary cross-vendor floating-point generation was reasonable. There is still a separate option: a deliberately restricted, integer-defined world evaluator running on both CPU and GPU.

The reason to revisit fixed point would be access to GPU parallelism while preserving the numeric contract. It would not be an assumption that integers are inherently faster than your optimized CPU floats.

The contract needs explicit widths, rounding, overflow behaviour, lookup tables, coordinate decomposition, and operation ordering. Canonical decisions cannot quietly pass through vendor-dependent floating-point functions or texture filtering. Microsoft’s DXIL specification defines relevant integer operations, including full multiplication results and unfiltered data loads.

Quantizing an ordinary float result at the end is insufficient: two computations can land on opposite sides of a quantization boundary.

A practical division would be:

• GPU evaluates bulk geometry or surface refinement.
• CPU evaluates the small subset required for immediate gameplay.
• Both implement the same defined rules.
• Gameplay avoids waiting for GPU readback.

What it gives: potentially large throughput while retaining seed-and-edits networking.

What it costs: a numerical implementation project, validation across supported vendors, GPU scheduling, and less freedom in procedural operators. Integer divisions or wide arithmetic can be expensive.

What it takes away: convenient use of arbitrary floating-point shader math for authoritative geometry. It also consumes the GPU budget needed for stereo rendering.

Determinism: matching canonical outputs is a release requirement, tested across CPU and GPU implementations and supported devices. It is achievable through a carefully specified implementation; the word “integer” alone does not prove it.

For scale, 140 million 16-bit samples occupy approximately 280 MB before halos and other buffers. Storage alone is manageable on your target GPU. Producing and using those values quickly enough remains the actual question.

I would pursue this after reducing the amount of work. Otherwise, every future resolution increase retains the same cubic growth.

There are three requirements that deserve independent treatment regardless of the representation.

Player readiness should depend on the player’s reachable surroundings. A 4 m cube at 12.5 cm spacing contains about 36,000 lattice points. At your stated evaluator rate, that is roughly 3–5 ms of aggregate evaluation work, excluding setup, meshing, and collision installation. It is an illustration of the scale difference, not a proposed universal collision neighbourhood.

A moving or falling player needs a region covering the swept capsule and its near-future motion, including walls and ceilings. A cold teleport needs a valid destination and immediate terrain queries or a small ready collision patch. None of that inherently requires the complete 64 m visual neighbourhood.

The engineering challenge is reliable swept contact and edit-aware support. Your measured cook queue problem reinforces the need to keep that deadline independent. Retaining an obsolete floor after excavation is as incorrect as temporarily losing a floor that still exists.

Kilometres of visibility should be served by compact distant surfaces and conservative visibility. Underground occlusion can eliminate large amounts of rendering work, while a vast open chamber still needs a cheap distant representation.

However, generating only currently visible surfaces is incompatible with guaranteed immediate revelation by blasting. Keep inexpensive distant representations available and detailed geometry within the region that nearby edits can expose. Destruction also needs to update any portal or occlusion assumptions.

Walking connectivity must include support. A connected graph of air spaces is insufficient. Construct at least one entrance-to-exit route with constrained slope, step height, capsule clearance, and continuous supporting floor. Bound later geometric decoration against that route.

If this guarantee must survive arbitrary player edits, there is a real design conflict: excavation can remove the only bridge while increasing air connectivity. Maintaining the guarantee then requires protected support, alternative routes, or repair. That is a gameplay rule that no representation can avoid.

I would spend the next experimental effort on a deterministic structural world with genuinely detailed surface refinement and an immediate edit representation.

The first prototype could retain your current generator at 25 cm for ordinary structure, preserve finer volumetric regions for small holes and thin features, and add the surface layer. Your measured 25 cm result makes this a much more grounded starting point than a complete renderer replacement.

I would judge it through four demonstrations:

• Close VR inspection: silhouettes, grazing views, near-hand relief, and patch boundaries meet the owner’s quality bar.
• A cold teleport: valid support becomes available independently of the full visual region.
• A 10 m blast: the complete result appears together, including an underfoot edit and an opening into another cave.
• Cross-machine comparison: canonical geometry and terrain-query results agree.

If the surface experiment fails because the required detail is truly topological or physically interactive, preserve that fine geometry and move harder toward direct surface generation and narrow volumetric exceptions.

My longer-term bet is the second direction: a generator that retains explicit knowledge of its surfaces. It fits the geological structure of your target, gives walkability a natural foundation, and offers a route to increasing detail without repeatedly multiplying the work throughout every cubic metre of the world.

---

Round 2 (fork): shorelines, fluid-looking rock, invention — 2026-10-02

Prompt: scratchpad astra-think-2.md. Answer verbatim below.

I would now give important contacts their own geometry, and give moving rock a stable “material space” in which cuts persist. Those two additions address the new problems and strengthen the earlier surface-based direction.

The shoreline exposes a weakness in treating independently generated representations as if they will automatically agree. Moving rock exposes a different weakness: defining a world only by where its surface happens to be this frame.

Below, “proposed” means an architectural suggestion that needs testing. “Speculative” means I see a plausible mechanism, but would not plan production around it yet. Numerical estimates are arithmetic, not measured Unreal performance.

1. Make the shoreline a shared geometric boundary. Established geometry techniques; proposed terrain integration.

A flat water surface is a reasonable representation of a still cave pool. It is also an unusually effective instrument for revealing geometric error.

Consider a shallow bank whose height rises by 2 cm per horizontal metre. Locally,

[ \text{shoreline position error}\approx \frac{\text{terrain height error}}{\text{bank slope}}. ]

A 1 cm height error on that 2% slope can move the shoreline by approximately 50 cm. This explains why terrain that looks acceptable elsewhere can look conspicuously wrong at water level.

Marching cubes produces piecewise planar surfaces, so its intersection with a plane is piecewise linear. Additional stair-like appearance can come from density quantization, displacement, LOD transitions, or a water mask derived from another representation. Smooth normals can improve lighting, but cannot repair the geometric outline.

My proposal is to make the intersection an explicit curve shared by both surfaces.

For a flat pool at height (H), find the curve where the intended rock surface meets (z=H). Then:

• Make the nearby rock triangles conform to that curve.
• Make the water boundary use the same curve.
• Derive wetness, deposits, and near-bank effects from it.
• Refine the rock in a narrow surrounding strip to preserve the correct shape and normals.

The “intended rock surface” must include any displacement that materially changes the contact. Computing the curve from coarse collision geometry while rendering a substantially displaced bank simply introduces another disagreement.

This is related to boundary representation in CAD: intersections are first-class geometry. Guenter and Gavriliu’s Generative CSG Models for Real Time Graphics explicitly represents intersection curves and uses them for adaptive triangulation. Its expensive preprocessing makes it a conceptual precedent, not evidence that arbitrary cave intersections can be reconstructed instantly.

The favourable part is dimensionality. A shoreline is primarily a one-dimensional problem.

For illustration, a 100 m shoreline sampled every 2 cm has approximately 5,000 curve locations. A surrounding strip 40 cm wide, sampled at the same spacing, contains roughly 100,000 surface locations. Root finding, transitions, normals, and topology add work, but this is a very different expenditure from refining a volume.

There is a useful rendering refinement here too: maintain separate tolerances for position and normal direction. Accurate contact positions fix the outline; accurate surface normals fix the faceted reflection. One tolerance does not guarantee the other.

• Cost and loss: substantial meshing work around intersections, plus handling curve splitting and merging after edits. Near tangencies, an intersection can appear or disappear, so tracing one existing curve is insufficient to discover every component.
• Multiplayer: derive the curve from the canonical shape, water level, and edit version using specified numeric rules. Different clients can tessellate between shared boundary constraints differently for rendering. Gameplay-relevant bank geometry remains canonical.
• First cheap experiment: use one analytically defined bowl with a ledge, intersected by flat water. Render unlit colours first, then reflective materials. Shift the sampling-grid origin while holding the underlying bowl fixed. Add a conforming shoreline strip and check whether the contact becomes stable without refining the whole bowl. Also raise the water through the ledge to expose topology failures.

2. Generate pools from their shorelines and geological history. Proposed construction method, with strong natural precedents.

For generated pools, there is an even cheaper possibility: choose the shoreline before constructing the surrounding bank.

The recipe could start with:

• Water elevation and an irregular closed boundary.
• A bank profile along that boundary: steep fracture, shallow shelf, undercut, sediment apron, or mineral lip.
• A basin interior.
• A transition into the surrounding cave surfaces.

The rock is then constructed to meet the water deliberately. Noise modifies that construction within limits that preserve the intended contact.

This is particularly suitable for your visual target because natural caves already provide expressive shoreline structures. Flowstone forms through mineral deposition by flowing films; rimstone dams hold pools and grow through deposition where water passes over them. The National Park Service’s cave geology account describes these processes and formations.

A pool could therefore have a fine scalloped mineral lip, a darker wet band, submerged sediment, and occasional fractured interruptions. Those features explain the contact visually and give the generator meaningful parameters.

Recent research also supports treating contours as primary terrain descriptions. Huftier and colleagues’ 2026 contour-based terrain work generates and edits terrain through elevation contours. It addresses heightfield terrain, so extending it to cave overhangs and intersecting chambers remains a separate problem. I would apply the idea locally around pools.

The water itself can contribute appropriate detail:

• Small waves whose behaviour changes near banks.
• A restrained meniscus.
• Wetness and sediment colour gradients.
• Refraction that reveals the submerged bank.
• Foam where there is actual agitation.

However, a meniscus is a small-scale effect. Water’s capillary length is approximately 2.7 mm, so it should not be expected to conceal decimetre-scale geometric problems in a broad pool. MIT’s capillarity notes give that scale. Similarly, a wide foam outline around every still cave pool would become its own procedural signature.

I would distinguish current contact from historical deposits. Lowering the water should reveal old mineral marks. Blasting a rim should remove it; the generator should not immediately grow a replacement decorative lip around the crater.

• Cost and loss: more authoring logic and a preference for pools with intentional bank structure. Freely changing water levels still require fresh intersection handling outside the originally constructed contact.
• Multiplayer: pool outlines, profiles, historical water levels, and structural deposits belong to the seeded recipe. Current water levels must be authoritative wherever swimming, drainage, or access depends on them. Tiny ripples and wet highlights can be cosmetic.
• First cheap experiment: generate one pool with three bank styles from a shared curve. Lower its water, then cut through its rim. The experiment succeeds only if the bank remains convincing, the old watermark stays put, and the excavation does not trigger decorative “healing.”

3. Give stone the visual language of flowing material before moving its bulk. Established rendering techniques; artistic hypothesis.

There are several distinct ways for rock to look fluid:

Appearance	What actually changes
Frozen waves, folds, or drapery	Static geometry
Veins and surface patterns flowing over stone	Material coordinates and shading
Ripples crossing a wall	Shading plus shallow displacement
A wall visibly bulging into a passage	Gameplay geometry, if reachable
Stone pouring, splitting, or merging	Material transport and topology

The first three can provide a large part of the desired effect at much lower cost than the last two.

For a living wall, I would try a combination of stationary large fractures and slowly travelling mineral ridges. The motion would have a direction and coherent scale: sweeping upward, curling around columns, spreading from impacts, or descending into basins.

A flow map supplies local direction and speed. Valve demonstrated this approach for animated normal and colour textures in Water Flow in Portal 2. Applied to stone, it could transport veins, roughness variation, and shallow relief.

For more organic motion, curl noise supplies procedural fluid-like velocity fields with mechanisms for respecting boundaries. It does not require running a full fluid simulation. Transporting textures or particles through that field still needs an appropriate animation scheme; an attractive velocity field alone does not solve stretching, looping, or temporal consistency.

My artistic hypothesis is that coherent folds and motion at a few scales will read as flowing stone more convincingly than many animated noise octaves. Keep the reflectance recognizably mineral unless the intention is explicitly wet or molten material.

Frozen waves deserve their own inexpensive approach: run an expensive viscous simulation during asset creation, select compelling states, then turn them into reusable surface motifs. Research on viscous buckling, folding, and coiling demonstrates precisely the kinds of shapes that could become stone draperies and frozen cascades. Runtime generation would place and deform the resulting recipes or assets; it would not reproduce the fluid simulation.

• Cost and loss: shader sampling, texture transport, and possibly fine surface geometry. Flowing shading has limited power at silhouettes and under close VR inspection. Frozen motifs need enough variation to avoid repetition.
• Multiplayer: fixed structural geometry remains the authority. Shared assets and seeds define frozen forms. Cosmetic motion can use a common phase without requiring identical pixels. Any displacement large enough to alter cover, contact, or digging must move into the authoritative category.
• First cheap experiment: use one static wall and compare three versions: flowing material only, material plus shallow relief, and a frozen folded surface. Inspect them in VR from the side and with a stationary hand or tool nearby. This quickly reveals how much physical movement the desired effect actually needs.

4. Animate a few controlled deformation patterns. Established animation mathematics; proposed gameplay integration.

For actual breathing geometry, I would begin with a small set of motion patterns:

[ S(u,v,t)=S_0(u,v)+\sum_k a_k(t),B_k(u,v). ]

Here, (S_0) is the resting surface. Each (B_k) is a pattern such as a bulge, travelling ridge, or twist. The coefficient (a_k(t)) controls its strength.

The useful property is that the shape can be evaluated directly at a requested time. A client arriving late does not have to simulate every previous frame.

Patterns can be designed to vanish along protected boundaries: the floor, a doorway, a pool edge, or the edges of an animated region. Where reflections reveal changes in slope, make the deformation’s first derivative vanish there too.

Impact-driven motion has a particularly relevant precedent: Dynamic Kelvinlets. These provide analytical elastic responses such as ripples and waves from localized forces, avoiding a conventional volumetric simulation. They are models of elastic secondary motion, not complete fluid or fracture simulation.

A spell could therefore produce two effects:

1. A permanent excavation command.
2. A temporary elastic wave, defined by its origin, start time, strength, and decay.

For an initial version, I would keep the walkable floor stationary while nearby walls respond. Later, genuinely moving floors can use the same evaluator for geometry and terrain contacts.

Motion speed and acceleration matter as much as displacement amplitude. For a sinusoidal movement:

• An amplitude of 3 cm at 0.5 Hz gives peak acceleration of approximately 0.30 m/s².
• An amplitude of 20 cm at 2 Hz gives approximately 32 m/s², over three times gravity.

The latter is not a gently breathing floor. Correct physics would make it a powerful moving platform.

A rough work estimate: a 10 m square patch sampled every 5 cm has about 40,000 vertices. Eight patterns require approximately 320,000 pattern contributions per geometry pass. Stereo, shadows, normals, and shading increase that work. This is an operation count, not a frame-time prediction, but it shows why surface animation can be much cheaper than regenerating a density volume every frame.

• Cost and loss: deformation evaluation, updated normals and bounds, correct shadows and previous-frame positions, and custom terrain contact handling for substantial movement. Ordinary shader vertex displacement does not automatically update collision. The result has a controlled motion vocabulary rather than unrestricted fluid behaviour.
• Multiplayer: use authoritative ticks and a versioned evaluator. Evaluate coefficients from time and compact events, avoiding frame-by-frame accumulation. Gameplay-relevant arithmetic needs the same determinism discipline as terrain generation; a shared sine expression alone is insufficient.
• First cheap experiment: animate one wall with four patterns, pin its lower edge, and trigger one impact wave. Evaluate the same timestamps after different frame-rate histories and a late join. Then make a small platform move and test whether contact velocity is handled correctly. Stop if it requires recooking terrain collision every frame.

A deformation also needs limits on spatial variation. Small amplitude does not prevent very short waves from folding a surface over itself.

5. Let moving stone remember cuts in material coordinates. Speculative architecture; established invertible-map mathematics.

This is the direction I find most interesting.

Imagine every piece of rock carries permanent coordinates, like markings embedded throughout a block of clay. The clay can deform, but those coordinates stay attached to its material.

Define the rock and its excavations in those coordinates. A time-dependent mapping moves the material into the visible world:

[ x=T_t(q), \qquad F_t(x)=F_{\text{edited}}!\left(T_t^{-1}(x)\right). ]

In plain terms:

• To render a point of rock, move it forward through the deformation.
• To query the rock at a world position, undo the deformation and query the stored shape.
• A hole follows the material because it is stored with the material.

Between edits, the reference geometry can remain cached. Animation changes its positions rather than repeatedly rediscovering its topology.

The difficult requirement is a cheap, reliable inverse.

One construction uses successive nonlinear shears. Shift (x) by an amount depending on (y,z); then shift (y) by an amount depending on the updated (x,z). Each step can be undone by subtraction in reverse order. Smooth additive shears preserve volume individually and remain invertible. The same mathematical construction appears as additive coupling layers in NICE; no neural network or training is required for this use.

My speculative application is a collection of such maps producing slow eddies, waves, and folds inside selected rock regions.

An additional experiment would be:

Apply an x-shear, then a y-shear, then undo the x-shear, then undo the y-shear.

Because the operations act on already changed coordinates, they generally leave a deformation inside their interaction region. With appropriately localized shear functions, their effects can cancel outside a bounded surrounding region. That suggests a localized, invertible “stone eddy.” The support bounds and resulting distortion would need to be verified.

The digging rule is essential.

If a spherical blast occurs while the rock is bent, pull the entire blast shape back into material coordinates. Transforming only the sphere’s centre and keeping its radius would usually be wrong: a nonlinear deformation turns its inverse image into a more complicated shape.

A compact edit can retain the blast parameters and the frozen deformation parameters from the instant of impact. The cut then remains attached to the removed material as the rock continues moving.

A permanently world-fixed exclusion volume is another possible game mechanic, but it has different semantics. It continually clips whatever material enters it. I would make that distinction explicit rather than accidentally letting craters slide or appear to heal.

There are several important limits:

• Invertibility preserves topology during deformation; it does not preserve walkable slope or clearance.
• A deformed signed field is generally no longer a true distance field.
• Inverse-transforming a capsule does not leave an ordinary capsule under a nonlinear map.
• The exact smooth surface may remain valid while an insufficiently subdivided triangle approximation develops artifacts.

Consequently, this does not make collision trivial. It makes the shape and edit history compact and queryable.

• Cost and loss: a significant research and physics-integration effort, inverse mappings on queries, distortion bounds, and material-space edit evaluation. Deformation alone cannot reproduce fluid breakup or merging; those require separate topology operations.
• Multiplayer: canonical mapping parameters, simulation time, and material-space edits define the same world. Carefully defined fixed-point shears can even have exactly reversible coordinate updates when overflow is excluded, although that does not by itself prove the whole collision system correct.
• First cheap experiment: one deforming slab, one spherical excavation, and a few ray/contact queries. Cut it at maximum deformation, return to rest, then deform it again. Check that the same material stays missing. Replay at different frame rates and test forward/inverse round trips. This should be settled before attempting a whole animated chamber.

6. Make contacts and protected routes part of the generator’s input. Speculative unifying design.

The broader architectural change I would now investigate is to give a region an explicit collection of important geometric constraints:

• A pool’s contact boundary.
• A doorway’s edge.
• A continuously supported walking route.
• The attachment of a column.
• The boundary between stationary and moving rock.
• The rim created by a recent excavation.

Surface patches are then generated and refined around those constraints. Detail and motion have budgets relative to them.

For example, a chamber could contain a still pool and a stationary path beside it. The rock higher on the wall could ripple strongly. Its deformation would fade smoothly to zero at the protected boundaries. Fine mineral patterns could continue flowing through those zones because they do not alter support.

That permits visibly dramatic motion without moving every gameplay-critical surface.

It also suggests a better refinement policy. Allocate geometry according to the error that matters locally:

Location	Important error
Water contact	Position of the intersection
Reflective rock	Surface-normal direction
Narrow passage	Minimum capsule clearance
Animated floor	Contact position and velocity
Ordinary distant wall	Projected image error

A uniform spatial resolution is a poor proxy for these different requirements.

Motion envelopes help here. A generator can prove that a wall moving within a known envelope cannot enter a protected corridor. But that envelope is a clearance or broad-phase tool: it cannot replace the actual surface for close player contact without creating visible collision discrepancies.

I would also keep these constraints independent of each client’s camera. Freezing a wall only when the local player approaches is liable to create conflicting worlds. Use fixed protected zones or an explicit authoritative state change.

• Cost and loss: more information in the world recipe, coupled generation rules, and resolving conflicting constraints. Some combinations of motion, thin walls, and route clearance must be rejected or altered.
• Multiplayer: the constraints and motion limits belong to the canonical layout. Rendering can vary its subdivision while respecting the same boundaries and gameplay surface.
• First cheap experiment: construct one chamber containing a pool, a door, a walking strip, and an animated wall. Keep those contacts stable while varying the surrounding shape and motion. If this requires special-case fixes at every junction, the representation needs simplifying before expansion.

The division I would use for moving rock is therefore:

Feature	May be cosmetic?
Colour, roughness, veins, fine normal variation	Yes, unless used to communicate gameplay state
Very small relief	Yes, within a tested visual/contact tolerance
Large movement in an unreachable region	Potentially; still needs appropriate bounds and visual interactions
Reachable bulges, footholds, cover, passage clearance	Requires authoritative geometry and queries
Excavation and material removal	Requires authoritative edit semantics

For implementation research, the shared shoreline curve is my strongest near-term bet. It concentrates precision where the image is unusually sensitive and can be tested without replacing the whole terrain system.

For invention, the invertible material-space wall is the experiment I would fund. It offers a plausible way to combine motion, persistent digging, compact networking, and cached geometry. Its first success criterion should be modest and strict: one moving slab whose hole, visible surface, and contact queries continue to agree.

I would revise the earlier surface-first recommendation accordingly: retain explicit knowledge of the surfaces, their important intersections, and the material coordinates that survive animation. Those are useful facts the generator can provide once and reuse throughout rendering, editing, and gameplay.

---

Round 3 (fork): performance only, unrealistic goal (whole view < 1 s) — 2026-10-02

Prompt: scratchpad astra-think-3.md. Answer verbatim below.

I would bet on a generator that emits boundaries and solid intervals directly. The distant world would come from a hierarchy of surface pieces. Nearby Boolean operations—joining caves, digging, blasting—would operate on intervals and packed bits. A density function could remain available for queries, but generating a view would no longer mean filling its volume with density samples.

I can construct a 900 ms engineering budget for this design. That is a target to test, not a measured prediction. Its essential condition is that the world’s composition limits the amount of surface work required. An arbitrary field can contain arbitrarily much geometry; no representation can guarantee a second without some complexity contract.

The proposed architecture combines established techniques. The particular composition rules, division of work, and budget below are my proposal.

There is a larger opportunity in your current far field than the word “clipmap” suggests.

Your source supports expanding the outermost ring at a fixed maximum LOD. The checked-in settings use RenderDistanceChunks=1536 and MaxClipLevel=5: that gives an outer radius of 48 tiles, approximately 97 × 97 horizontal positions per vertical slice, before exclusions. Those are defaults, not a census of your running world. Nevertheless, this can turn the horizon into a large fixed-resolution grid. The settings explain why: coarser volume sampling can miss thin strata. Settings, outer-ring calculation.

That is a representation problem with a performance consequence. A distant floor should survive because it is explicitly a floor, rather than because a coarse lattice happens to intersect it.

There is a similarly useful distinction nearby: your column evaluator already shares setup across heights, but still loops through every Z sample. The opportunity below is to remove that loop by solving where the column enters and leaves rock. Column evaluator.

First, make each world piece know how to produce its surface.

A room, tunnel segment, shelf, shaft, pillar or floating mass would carry a small description with:

• Its bounds and connections.
• A way to emit its surface at several resolutions.
• A way to intersect an axis-aligned line with its solid.
• Shared boundary curves for joining neighbouring pieces.
• A limit on how much refinement and Boolean work it can require.

An untouched tunnel would emit a swept surface. A chamber would emit patches with explicitly constructed openings. A floating mass would emit a closed surface. These operations evaluate positions on the surface, without searching a surrounding volume for it.

The difficult part is junctions. Drawing overlapping closed room and tunnel meshes leaves unwanted internal walls. I would begin with a bounded family of junction constructions whose openings, trimming and transitions are already defined. More unusual intersections would use the local interval compiler described below.

This is a substantial generator redesign. Its advantage is that it makes the cost of a feature predictable.

The hierarchy must also be constructed from coarse to fine. A parent knows the major chamber boundaries, floor sheets and passages before its children exist. Children add bounded shape variation and smaller features. A distant parent can therefore be rendered without generating and simplifying all its descendants.

That does not make a coarse mesh an exact copy of every fine surface. What can be exact is the parent’s enclosure, connection information and refinement contract. The visible surface remains an approximation with a specified error.

For deterministic connections, neighbouring pieces can derive their shared opening from the same integer face key. Each side then receives identical opening geometry. Matching-boundary composition has a precedent in Wang tiles; extending it to a hierarchical cave grammar with guaranteed connectors is my proposed adaptation. It needs a constructive connector for every allowed boundary configuration, otherwise a search problem returns. Cohen et al., Wang Tiles for Image and Texture Generation.

Build the initial walkable route into this hierarchy, with enforced clearance and floor slope. Its existence then follows from construction; discovering it does not require generating the whole cave and running navigation over it.

The far field would contain selected surface patches, including explicit thin strata. It would contain no density tiles.

All selected LODs must be ready by the deadline. Showing a coarse preview while the requested near surface is still missing would not count.

Second, replace point evaluation with interval algebra wherever Boolean composition is necessary.

Consider a spherical cavity. At a fixed horizontal position ((x,y)), define

[ d=r^2-(x-c_x)^2-(y-c_y)^2. ]

If (d<0), that column misses the cavity. Otherwise its entire air interval is

[ [c_z-\sqrt d,;c_z+\sqrt d]. ]

One calculation has answered every height in that column.

Multiple rooms and tunnels produce lists of intervals. Joining cavities becomes interval union. Adding a pillar removes an interval from air. A crater adds an air interval. There is no need to evaluate the composed function at every Z coordinate.

This is related to dexel representations, used in machining and virtual sculpting: solids are represented by entry and exit depths along parallel lines, and cutting becomes interval operations. This is established machinery, not a new claim about solid modelling. Peng et al., Surface Reconstruction from Dexel Data for Virtual Sculpting.

For your world, I would use:

• Quadrics for ellipsoids, cones and suitable chamber shapes.
• Piecewise analytic segments for tunnels.
• Explicit floor/ceiling intervals for shelves and room interiors.
• Bounded local exceptions for shapes outside that family.

Using line families along all three axes provides boundary intersections in each direction, including on vertical walls. A 256-cell cube has approximately 198,000 lattice lines across the three directions, versus roughly 17 million lattice points. If each line encounters an average of 12 candidate primitives, that is about 2.4 million primitive-line tests.

That is an operation-count estimate, not a speedup measurement: root solving and interval merging cost more than a single comparison. However, each test can replace many expensive calls to your complete density evaluator.

This method becomes unattractive if every line crosses hundreds of tiny features. The generator must keep that complexity bounded, or represent those features directly as surfaces.

There are two useful ways to exploit 64-bit words here.

The first is to represent which primitives are active while sweeping through sorted interval endpoints. With at most 64 local primitives, their membership fits in one word. At a crossing, update the corresponding bit. Between crossings, membership is constant, so the local Boolean expression has one answer for the entire span.

For a restricted construction such as “rock minus rooms and tunnels, plus pillars, minus craters,” the answer needs only a few tests of those membership masks. Arbitrary CSG trees require more work; the simple expression is a deliberate composition rule.

The second is to store 64 consecutive rock/air signs in one word:

• Union, intersection and subtraction become OR, AND and AND-NOT.
• A long uniform span writes whole words.
• XOR with a neighbouring column identifies changed signs along X or Y.
• XOR with a shifted word identifies changed signs along Z.
• Bit scans enumerate only the interesting locations.

For marching cubes, align the eight corner-sign words for 64 cells. Then

[ \text{active}=\operatorname{OR}(\text{eight words}) ;\land; \neg\operatorname{AND}(\text{eight words}). ]

That identifies 64 potentially intersected cells using word operations. std::countr_zero and clearing the lowest set bit can enumerate the survivors. Binary greedy meshers demonstrate the usefulness of processing occupancy and face masks this way. Their block-shaped output is not what I propose using for cave surfaces. Binary Greedy Meshing.

The smooth surface comes from the actual boundary crossings, with quantized positions and normals, not from placing vertices halfway between binary samples.

Two qualifications matter:

1. Packing an arbitrary field into bits does not make generating those bits cheap. The interval construction is what removes the evaluations.
2. Equal corner signs can hide a thin feature entirely inside a cell. Such features need explicit primitive-intersection tags, refinement, or direct surface geometry. Binary signs alone cannot preserve them.

A near ring with 17.4 million signs needs approximately 2.2 MB, compared with approximately 69.6 MB for float densities. Boundary data and meshes are additional, but the interior representation becomes small.

There is a particularly interesting mathematical family to investigate: piecewise triquadratic fields.

This is an optional extension, not something the first prototype must depend on.

A polynomial that is quadratic separately in X, Y and Z has 27 coefficients. It offers two useful properties:

• Restrict it to any axis-aligned line, and it becomes a quadratic: at most two isolated crossings unless the polynomial degenerates.
• Express it in the Bernstein basis over a box, and its value lies between the smallest and largest coefficients.

Consequently, one small coefficient block supplies both cheap line intersections and conservative whole-box sign bounds. All coefficients positive means the entire box is air; all negative means rock. Subdivision can tighten the bounds.

Bernstein bounds and subdivision are established mathematics used in implicit-surface research. My speculative proposal is to make this restricted polynomial family part of the cave’s native construction language, rather than fit it to an already expensive noise field. Bán and Valasek, Generalized Lipschitz Tracing of Implicit Surfaces.

This distinction matters: fitting an arbitrary existing field would reintroduce sampling and approximation problems.

Bounded detail can be handled similarly. If a parent function has a known range ([L,U]), and all omitted detail together is bounded by (R), then

[ F_{\text{complete}}\in[L-R,;U+R]. ]

Whenever that interval excludes zero, all descendants are irrelevant to occupancy there. The amplitude bound must come from the construction rules; estimating it from a few samples would not be a proof.

This approach spends a small, predictable amount on bounds supplied by each primitive. Your report’s failed generic interval experiment is good evidence against wrapping the existing entire evaluator in a more expensive arithmetic system.

The most radical version would upload surface instructions instead of most vertices.

An untouched surface patch can be described by its type, coefficients, transform, boundary identifiers and tessellation level. The GPU can draw a shared index pattern and calculate vertex positions from that description. This is ordinary rasterized geometry; it does not require raymarching the whole world each frame.

As an illustrative estimate:

• 20,000 patch descriptions × 128 bytes = 2.56 MB.
• A conventional mesh with 1.2 million vertices and 2.4 million triangles, using 24-byte vertices and 32-bit indices, is 57.6 MB.

Both still produce geometry for the GPU to process. The saving is CPU generation, storage, transfer and object setup.

Edited regions would switch to explicit generated patches. Untouched regions could remain compact procedural instances indefinitely.

The costs are a custom rendering path, restricted patch families, careful transitions, and GPU arithmetic repeated in depth and shadow passes. Some patches should therefore be expanded once into GPU buffers and retained. This is a credible research direction, but I would not require it to pass the first CPU experiment.

The rest of the pipeline needs to be designed around bulk work.

Your recorded 639 mesh applies per second is sufficient to make thousands of separate publications a problem even if generation becomes free. Your report also separates fast collision cooking from multi-second queue delays. Those are measured reasons to change the publication and support paths for this larger objective. Recorded results.

I would use pooled geometry buffers and a small number of spatial render pages. Tiles or patches retain their own bounds and update ranges inside those pages. A small edit must update its ranges rather than rebuild a large page.

GPU culling and indirect drawing can reduce CPU submission work while retaining many independently culled pieces. Direct3D provides the necessary indirect command mechanism; integrating it into Unreal’s scene, material and shadow paths is real implementation work. Microsoft, Indirect Drawing.

Only the player’s immediate support neighbourhood belongs on the initial collision deadline. Give it a priority path through generation, cooking and installation. Treat “physics state installed and a capsule sweep succeeds” as completion, rather than “cook task submitted.”

Boundary ownership must also be explicit. Adjacent patches use identical quantized border samples and defined transition strips. Edited replacement patches meet those shared borders. This work belongs in the meshing budget; overlapping skirts are not a general proof of a watertight result.

Here is where I would allocate the second.

These are proposed acceptance budgets, not benchmark results. The workload assumed is:

• A 64 m near region at roughly 25 cm structural resolution, with finer appearance handled without a finer volume lattice.
• All selected distant surfaces to the requested horizon, including stacked layers.
• At most about 50,000 hierarchy records, 2–4 million nearby primitive-line tests, and 2.4 million output triangles.
• Six generation workers.
• No seed-dependent geometry or field cache.

The structural resolution and triangle count are explicit concessions. This budget does not establish the same result for every geometric feature in the current 12.5 cm field.

Stage	Work assumption	Principal data	Wall-time budget
Generate/select hierarchy and connections	Up to 50,000 records; order of 10–20 M simple operations	3–8 MB	30 ms
Solve and compose nearby intervals	2–4 M primitive-line tests; order of 100–300 M arithmetic/comparison operations, plus roots	Paged scratch, target ≤24 MB	150 ms
Produce sign masks and active cells	Up to roughly 1 M word groups; tens of millions of bit operations	2–8 MB	30 ms
Emit all near/far meshes and transitions	1.2 M vertices, 2.4 M triangles; order of 100–250 M geometry operations	57.6 MB output	220 ms
Cook and install immediate support collision	Approximately the current small support neighbourhood	A few MB	65 ms
Bulk GPU upload and scene publication	At most roughly 64 page publications	Approximately 60 MB	100 ms
Final fence and first completed frame	Includes frame scheduling	—	25 ms
Allocation, imbalance and integration contingency	—	—	280 ms
Total			900 ms

The budgets are added conservatively; I have not counted overlapping stages as an extra saving.

At an assumed effective upload rate of 10 GB/s, 60 MB takes approximately 6 ms of transfer time. That illustrates why publication, allocation and synchronization could matter more than raw bytes. It is not a measurement of your Unreal path.

Likewise, the operation counts do not automatically imply the listed milliseconds. Roots, unpredictable branches and cache misses differ enormously in cost. The experiment must measure them.

The largest unknown is the required output complexity. If a representative complete view needs 20 million triangles under the chosen surface error, this particular budget fails. The remedy would have to be better surface construction, instancing or approximation—not a claim that packed occupancy removed the output cost.

“Cold” here means the application is running, shaders are available, and the seed/layout/edit data have arrived, but no world-specific result exists. Starting Unreal, compiling shaders or downloading an unbounded edit history requires a separate budget.

The 5800X3D makes a compact implementation particularly attractive.

AMD specifies eight cores, sixteen threads, 96 MB of L3, AVX2 and dual-channel DDR4-3200 for this processor. Its theoretical dual-channel memory rate is 51.2 GB/s; actual application bandwidth must be measured. AMD specifications.

I would organize the implementation as follows:

• Keep repeatedly accessed data around 40–60 MB. The 96 MB is shared with the rest of the application. Stream finished mesh output rather than keeping every intermediate alive.
• Process local pages with worker-owned scratch. A 64³ sign block is only 32 KiB before borders. Finish its interval, boundary and mesh work while the relevant data are close.
• Use arrays of primitive coefficients grouped by type. AVX2 should process similar intersections together, without virtual dispatch or scattered feature lookups inside the loop.
• Use AVX2 for batches, ordinary words for bitsets. One vector handles four 64-bit masks. This is useful after the representation has removed most work; it is not a claimed 256-fold generator acceleration.
• Exploit forward differences. Along an integer scanline, ((x+1)^2-x^2=2x+1). Quadratic terms can advance with additions; hash and coefficient setup happen once per feature or row.
• Use Morton order between pages and simple linear order inside them. This preserves spatial locality without expensive addressing in every inner iteration.
• Measure six versus eight physical workers before using extra SMT workers. Leave capacity for the game thread, renderer and collision path. Sixteen hardware threads do not supply sixteen independent cores.

Avoid per-column allocation, shared append locks and global vertex hash tables. Count locally, assign deterministic output ranges, and write disjoint buffers.

Multiplayer agreement would come from a small, explicit numerical contract.

Use integer world keys, a versioned hash, fixed parameter quantization and stable feature identifiers. Define:

• Rounding and sign-at-zero rules.
• Endpoint inclusion and coincident-crossing rules.
• Boolean operation order and material priority.
• Shared edge ownership and vertex quantization.
• Arithmetic ranges, widening and overflow behaviour.

For quadrics, an integer square root or an exact predicate can determine the canonical crossing bracket. A floating-point estimate may accelerate the search only if exact arithmetic verifies and corrects the result.

GPU floating-point surface shading can vary without changing gameplay. If GPU-generated geometry itself makes authoritative decisions, its integer decisions must match the CPU reference. Merely changing the language’s numeric type does not establish determinism.

Clients independently generate the same descriptions and process the same ordered edits. Physics simulation need not become deterministic lockstep merely because world geometry is deterministic.

For a 10 m spherical crater at 25 cm spacing, its projected footprint covers approximately

[ \pi(10/0.25)^2 \approx 5{,}000 ]

columns per axis. That is roughly 15,000 affected lines across three directions, rather than evaluating the whole 20 m bounding cube.

That makes immediate editing much more promising. It does not prove same-frame publication. The replacement surfaces must still be generated and switched together across every affected page and LOD. CPU support queries must observe the new edit immediately, even while replacement collision bodies are pending.

What this design gives up is mathematical generality, rather than three-dimensionality.

Overhangs, stacked chambers, floating masses, shafts and craters remain possible. The restrictions are on how they are composed:

Restriction	Performance obtained
A bounded primitive and junction family	Predictable surface emission and intersection cost
Limited overlap and crossings per local region	Short interval lists and cheap Boolean composition
Coarse structure constrains later refinement	Far geometry exists without generating descendants
Fine appearance does not all become collision topology	Surface work avoids growing with microscopic detail
Edited regions become local exceptions	The untouched majority keeps its compact representation
Finite supported scene and edit complexity	A meaningful loading-time target

The long-term risk is that edits accumulate until most regions become expensive exceptions. Local edit histories therefore need deterministic pruning or compaction into a bounded replacement representation. An unlimited edit log cannot have a fixed cold-load guarantee.

A full-view raymarcher would remove mesh construction but move substantial work into every stereo frame. Global FFTs and tensor decompositions can be excellent for suitable restricted functions, but do not automatically survive arbitrary local cuts cheaply. I would pursue those after the boundary-producing construction has been tested.

The first experiment should test the interval compiler and count the output—not attempt a new renderer.

A one-day standalone C++ spike could answer the central question:

1. Build a representative geometric corpus. Use room and tunnel records resembling your actual parameter ranges, plus pillars, shelves, floating solids, thin strata, rotated shapes and intersecting craters. Include crowded junctions. A sparse collection of spheres is insufficient.

2. Implement two versions of the same restricted world. One evaluates occupancy point by point as a reference. The other generates intervals, composes them, fills sign words and extracts boundaries. They must describe the same new geometry; matching every detail of the old noise field is not the experiment.

3. Produce real mesh buffers. Include boundary positions, indices, borders and deterministic ownership. A fast occupancy-only result can conceal an expensive reconstruction stage.

4. Exercise the far-world rule separately. Generate the complete selected hierarchy and its coarse surface buffers without constructing fine descendants. Record nodes, patches, vertices and bytes. If implementing the full hierarchy exceeds the day, this part remains explicitly unproved.

5. Measure fresh-process runs on the 5800X3D. Include allocation and first-touch costs. Test one, six and eight workers; report median, p95 and worst across seeds. Validate outside the timed region against the pointwise reference, including negative coordinates, page borders, tangencies, thin features and coincident edits.

I would use these initial decision gates:

Result	Decision
All CPU geometry fits approximately 430 ms, with output around 60 MB	Proceed to the Unreal publication and collision test
Interval work fits its 150 ms allocation, but meshing exceeds the budget	Investigate direct patches, reconstruction and output size
Only the simple cases pass; representative junctions produce huge interval lists	Reject or restrict that composition family
Far geometry requires fine descendants or dense strata sampling	The proposed hierarchy has not removed the principal cost
Any missing thin feature or inconsistent shared boundary	Correctness fails regardless of speed

The standalone test can establish whether the computational core deserves investment. The final proof is an Unreal run timed through the first complete visible frame and successful player-support collision, followed by a separate check that steady rendering meets the VR frame budget.

I would spend the first day on analytic intervals plus direct far surfaces. They attack both sources of unnecessary work: repeatedly discovering nearby boundaries, and reconstructing distant surfaces from a volume that the player will never interact with.