docs(research): Astra round 2 -- shared shoreline curves, flowing stone, material-space deformation

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MmSoF64BbRFmk9C3p1VsBJ

RESEARCH-ASTRA-2026-10.md

@@ -235,3 +235,262 @@ I would judge it through four demonstrations:
 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](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2005-43.pdf) 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](https://www.nps.gov/grba/planyourvisit/cave-geology-in-depth.htm) 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](https://perso.liris.cnrs.fr/apeytavi/website/publication/hal-05608822/) 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](https://web.mit.edu/nnf/education/wettability/gravity.html) 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](https://advances.realtimerendering.com/s2010/index.html#Water%20Flow%20in%20Portal%202). Applied to stone, it could transport veins, roughness variation, and shallow relief.
+
+For more organic motion, [curl noise](https://www.cs.ubc.ca/~rbridson/docs/bridson-siggraph2007-curlnoise.pdf) 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](https://www.cs.ubc.ca/labs/imager/tr/2008/Batty_ViscousFluids/) 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](https://graphics.stanford.edu/~djames/publication/dynamic-kelvinlets-secondary-motions-based-on-fundamental-solutions-of-elastodynamics/). 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](https://arxiv.org/html/1410.8516v6); 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.