The seam is shared spatial meaning, not shared ownership #18MPLA

Luvcraft now has the right evidence for a spatial vocabulary to become more than an attractive analogy. Block content, derived light, live meshing neighborhoods, immutable worker snapshots, collision, and streaming all inhabit the same chunked voxel world. They should not become one object, but neither should each of them reconstruct what a cell address, local offset, neighbor, face, and chunk crossing mean.

The duplicated arrays are not the deepest problem. Separate fields often should be separate because they have different producers, owners, revisions, and storage. The architectural seam is that several such products currently rebuild the spatial substrate beneath those differences.

This is the first concrete client of the more general domain/bundle account in #D5M8BZ. It also sharpens that account: Bundle is not the whole missing abstraction. The useful decomposition is:

voxel space       how cell addresses and physical positions relate
finite domain     which local sites and storage offsets belong to one patch
field product     which distributed fact is materialized over those sites
chunk window      how a local query continues into other materializations
provenance        which incarnations and revisions justify the result

The aim is not to make the engine advertise advanced mathematics. It is to let lighting code speak about lighting, meshing code speak about surfaces, and physics code speak about bodies while sharing one honest account of where their data lives.

Mentioned in: The first Lisp atelier should stay ordinary

Mathematical ideas should improve the questions, not burden the names #EQ6GLY

Affine lattices, combinatorial topology, covers, sheaves, order-theoretic lattices, and discrete exterior calculus are useful sources of distinctions. They draw attention to placement, adjacency, incidence, locality, overlap, restriction, partial knowledge, and values associated with cells or faces. That does not yet earn those terms as source-level abstractions.

The implementation vocabulary can remain ordinary:

voxel-space
chunk-domain
chunk-window
neighbor
boundary-crossing
voxel-field
field-materialization
field-kernel

"Chunk window" is a particularly useful hacker-facing name for the part that resembles a cover or atlas. It says that an operation has a finite local view onto a larger chunked world without claiming a precise mathematical structure the implementation does not provide.

Likewise, today's cells and six-neighbor steps do not justify a general topological-space protocol. If future fluid or geometry work places values on faces, edges, and vertices and consumes explicit incidence operations, a cell complex or cochain vocabulary may then be earned by a real calculation.

Mentioned in: The repository became clearer by becoming less grand

Addressing and metric are two sides of voxel space #KV001P

The voxel world has a discrete addressing side:

• an integer triple names a cell;
• primitive directions identify face neighbors;
• a world address decomposes into chunk address plus local address; and
• a finite chunk maps local addresses to dense offsets.

It also has a physical metric side:

• a cell has an extent;
• a cell address maps to a physical point;
• an address difference maps to a physical displacement; and
• face area, cell volume, and step length follow from the extent.

voxel-space already contains both a chunk shape and a cell-extent, and world-coordinate-cell-origin performs the first explicit address-to-position map. The distinction should become more pervasive rather than disappear into one universal kind of neighborhood.

Voxel light is step-based: an ordinary six-neighbor move loses a gameplay light level regardless of how many metres one cell represents. Physics is metric: velocity, acceleration, collision extents, and timestep require physical quantities. A diffusion stencil may need both adjacency and a spacing-dependent influence. Moppe's TerrainDomain is useful evidence: its four neighbors carry inverse-area influences, so a generic Laplacian derives the right physical dimension without knowing the grid spacing itself.

The shared concepts should therefore remain distinct:

The current mesher and player simulation appear to treat one cell as one metre even though voxel-space admits another extent. That is a hypothesis to verify during the bridge work, not a settled bug claim. The durable rule is that a discrete cell address is not itself a metre-valued world position; the space performs that interpretation explicitly. #M8W6RP already records the corresponding quantity distinction.

Vec3 is a representation, not one spatial meaning #7K8UBF

The luvcraft source contains several visibly three-component families, but an audit shows that they should not all become the same abstraction:

The vec3 structure in LUV.ARITHMETIC.LISP.VEC3 is therefore deliberately modest. It bundles continuous CPU components, supplies component, scale, dot, cross, length, and normalization operations, and extends the open Lisp arithmetic protocol without making that protocol name the representation. LUVCRAFT.WORLD imports it but does not own or re-export it. The representation does not claim that a point is a velocity, that either is already measured in metres, or that an RGB triple belongs to spatial algebra. camera-position and player-velocity name different semantic owners even though both use the same transparent representation.

That distinction gives the readable code the useful part of structification: camera and player objects no longer maintain parallel x, y, and z slots; rays no longer accept arbitrary sequences; camera basis and shadow calculations no longer duplicate positional list arithmetic; persistence converts a vec3 to an external list only at the file boundary. Axis-specific collision and voxel traversal still use component accessors where the axis is the algorithm.

This also keeps the allocation claim narrow. A retained camera position or velocity naturally has indefinite extent. A short-lived vec3 may use the same inline-constructor and dynamic-extent technique documented in #B3UEVE, but the migration does not require every vector calculation to prove zero allocation before earning a readable value type.

Mentioned in: Bundle continuous spatial triples

A chunk domain owns local traversal, not world truth #E4T0PD

A chunk-domain should be the one place that knows the finite patch's local shape and storage order. Its useful operational vocabulary is approximately:

domain-cardinality
domain-index / domain-offset
do-domain-sites
step-domain-site
do-domain-face

step-domain-site should report either another local site or a boundary crossing. It should not decide that crossing the east face reaches air, stone, open sky, an unloaded chunk, or an error. Those are facts or policies of the environment in which the domain is being used.

Nor should one neighborhood become intrinsic to every chunk calculation. Lighting wants six face neighbors; ambient occlusion wants side and diagonal samples; meshing wants a face neighbor plus corner stencils; collision wants the cells intersecting a volume. The domain supplies primitive traversal and boundary facts. Explicit policies assemble the neighborhoods algorithms actually mean, following the separation that survived in Moppe's bundle_operations.hh (#E4N7PX).

Coordinates should be ordinary nominal values throughout the code, including dense traversal. The distinction worth preserving is not "objects outside, components inside" but lifetime: a queue or hash key needs an indefinite-extent coordinate, while a loop-local coordinate can have dynamic extent. Compiler-visible iteration macros can provide the latter without a heap allocation or a per-cell call across a compilation-unit boundary.

That requirement applies to adjacency as well as whole-domain and face iteration. A function which returns a fresh neighboring coordinate has to give it indefinite extent before its caller can decide whether to retain it. The useful hot-path shape is therefore a macro which binds one dynamic-extent destination around the consumer body; only a consumer which actually enqueues the destination copies it. Crossing arithmetic remains the domain's job, window lookup still occurs only for a crossing, and the caller still supplies the neighborhood policy.

Mentioned in: Minecraft contains several families of frontier work, Keep rejected neighbors at dynamic extent

Coordinate values can be stack-temporary #B3UEVE

SBCL's stack-allocation rules make defstruct a good fit for the small spatial values in this layer. A user-defined structure can be stack allocated when its defstruct constructor was declared inline before the definition and the receiving binding is declared dynamic-extent. The declaration is a lifetime promise, not an analysis result: the value must not escape through a queue, hash table, closure, return value, or retained callback argument.

The manual's x86/x86-64 limitation concerns structures with raw slots. SBCL defines those as particular unboxed float, complex-float, or word slots, and explicitly excludes fixnums from the category. The coordinate structures use ordinary tagged integer slots, so this limitation does not apply on the current ARM64 target.

The live SBCL 2.6.7 image confirms the distinction under the project's ordinary compiler policy (all qualities at 1). In otherwise identical one-million-iteration loops, an ordinary three-integer coordinate structure reported 48,182,016 bytes through sb-ext:get-bytes-consed, while the dynamic-extent structure reported 0. A three-element Common Lisp vector declared dynamic extent likewise reported 0. After warm-up, the actual do-chunk-domain-sites macro traversed 4,096,000 coordinate values and reported 0 bytes consed.

A three-dimensional coordinate certainly has vector-shaped representation, but not every such value has vector semantics. A world coordinate is an affine cell address, a chunk coordinate names another lattice, a local coordinate is bounded by a domain, and a voxel direction is a displacement. Using four defstruct types retains those distinctions and named accessors; using bare Common Lisp vectors would collapse them back into positional components. Dense storage remains in specialized arrays. These structures name the small values used to address that storage, and dynamic extent makes their short lifetime explicit where it matters.

Mentioned in: Vec3 is a representation, not one spatial meaning, Give dense traversal coordinate values

A chunk window continues a local domain #YUBB7X

A local domain can say that a step crossed its boundary. A chunk window answers what spatial materialization, if any, can continue the query:

flowchart LR
  A["local site"] --> B["domain step"]
  B -->|"stays local"| C["local offset"]
  B -->|"crosses a face"| D["chunk window"]
  D --> E["neighbor materialization"]
  D --> F["open / closed / unknown"]
  D --> G["unavailable"]

The window reports availability; the subsystem interprets it. Lighting may distinguish open sky, closed world, and unknown terrain. Meshing may treat an absent sample as air, solid, or an error. Physics may treat unknown support as solid or suspend a body. Ecology may call the reading unavailable rather than zero. Moving those choices into the domain would turn streaming state into terrain truth.

Different windows need not share one representation. They need a small aggregate protocol for operations such as locating a cell, resolving a boundary crossing, and borrowing a requested field product. Field-specific facades such as sample-block-at and sample-light-at can remain readable interfaces above that mechanism.

Mentioned in: A glance is an image and the small truth that frames it

The current program already contains four windows #WUB581

The proposed vocabulary names structures that already work:

The duplication is visible in current source rather than inferred from equal array lengths. light-region-locate remains the cold adapter from retained world coordinates, but propagation and unlighting retain an entry and local site, then use continue-chunk-window-site so interior neighbors stay in domain arithmetic. map-entry-face-sites delegates face offsets to do-chunk-domain-face. In luvcraft/mesher.lisp, block and light access through the resolved neighborhood share relative decomposition and offset arithmetic, while the immutable snapshot shares one block-mesh-halo-domain and generated columnar materialization across content-code, sky-level, and block-level storage (#LC5ULQ).

This is an unusually good refactoring target because the algorithms around the arithmetic are already distinct and tested. The work can remove spatial duplication while leaving light propagation, AO sampling, face visibility, snapshot ownership, and stale-result rejection recognizable.

Mentioned in: Phase 2: make voxel light an explicit derived field

Field identity, value meaning, and representation are independent #FKAV5Y

A field definition says which distributed fact one column represents. Its value quantity says what a reading at one site means. Its representation says how those readings are stored. These are three different identities.

For example, sky light and block light are different fields: they have different sources and may have different invalidation rules. They may also use distinct named quantity specifications. Both currently occupy u8 arrays, but equal representation makes neither the fields nor their values interchangeable.

Conversely, two field roles may deliberately carry the same quantity specification while remaining separate columns. One semantic light value could also be represented as constant zero, a packed nibble, u8 levels, normalized float, SIMD-expanded floats, or a GPU lane without changing the field's meaning.

A first field definition might need only:

field identity
site kind
value quantity specification
default or missing-value meaning
legal range or encoding
representation policy

A field materialization then binds that definition to a finite domain and actual storage. Product-wide revisions, boundary revisions, and stability state belong to the materialization or its owning derived product, not to every site value.

Block opacity exposes why these distinctions matter. The atlas's normalized :opacity is a rendering proportion. block-light-opacity is documented as a 0..15 propagation cost. Calling both opacity does not make them one quantity. A field experiment should probably rename the latter meaning to something like propagation loss or light-step cost before using arithmetic typing to bless an accidental equivalence.

Domain, materialization, and revision have different identities #HAUW7L

A chunk removed and reinstalled at the same chunk coordinate covers the same spatial domain, but it is not the same resident materialization. A field can then change several times within that incarnation. Luvcraft's same-key replacement tests already rely on this distinction when withdrawing the old chunk's propagated light.

At least three identities must therefore remain visible:

domain identity           which sites these are
materialization identity  which resident incarnation supplies them
revision identity         which version of its fields was observed

Bundle compatibility checks domain identity rather than equal cardinality. A mesh, collider, or light publication proof additionally records the materialization incarnations and field revisions it observed. Folding all three into one "domain version" would erase the correctness property the current stale-result machinery carefully preserves.

This is also why one universal voxel bundle is the wrong endpoint. Block content, voxel light, fluids, and ecological readings can be sibling materializations over compatible domains while retaining their own owners and validity conditions (#A6X2RT).

Field kernels bridge domains to semantic arithmetic #ADR040

Luv's arithmetic work already has the layers this design needs:

• luv.arithmetic owns dimensions, units, named quantity meanings, tensor order, and point/absolute/difference character;
• luv.arithmetic.language owns backend-neutral checked definitions and expression graphs;
• luv.arithmetic.lisp lowers one such definition to an ordinary compiled Lisp function over raw numbers and vectors; and
• the shader language adds GPU interfaces, resources, and target lowering around that same arithmetic substrate.

Shaders therefore do not own meaningful arithmetic. They are one realization of it. The missing bridge says:

This field carries this value meaning over these sites in this
representation; choose one checked operation and run it over borrowed storage.

A field kernel should connect field definitions to a checked arithmetic definition, select a scalar or wide realization once, borrow the arrays, and then run an ordinary loop or worklist without per-cell CLOS dispatch.

flowchart TB
  A["field definitions + finite domains"] --> B["checked kernel boundary"]
  C["arithmetic definition"] --> B
  B --> D["borrowed raw arrays"]
  B --> E["scalar / SIMD / GPU realization"]
  D --> F["closed loop or worklist"]
  E --> F

This is the Lisp analogue of Moppe storing mp-units values in typed Bundle columns, but it need not copy the C++ technique. Inspectable definitions and aggregate checks can keep the semantic information outside unboxed runtime lanes, as #B5L7VG anticipates.

Physics is the obvious next numerical client, but not another reason to add columns to a universal voxel record. Collision traversal should remain domain/window code which enumerates occupied cells and constructs contacts; integration, acceleration, and eventual impulse laws can be checked arithmetic over body fields. Bodies and contacts then retain their own finite domains as #Y5H8KC describes, while the block world remains the static environment they query.

Mentioned in: Declarations keep representation and quantity parallel, Share one production computation between CPU and GPU, Frontier programs are compiled sparse kernels

Lighting should use a checked local law, not become an arithmetic graph #WEE8P5

The light solver is the best first proof because it already separates block content, two light fields, palette-derived attenuation and emission tables, boundary availability, fixed-point work, publication, and revision tracking.

The arithmetic DSL should describe a local transfer law, not the entire algorithm. In rough form one edge computes:

candidate = attenuate(source level, propagation loss, direction)
destination = max(destination, candidate)

Chunk lookup, residency, queues, removal waves, scheduling, publication, and revision tracking remain lighting control structure. The chunk window supplies the destination site; field materializations supply typed storage; the checked local law computes one influence; the worklist decides when to visit again.

There is an open semantic choice at the CPU/mesh boundary. The stored 0..15 level may be only an encoding of a normalized light proportion, making division by 15 a representation conversion. Or one gameplay light step may be a meaningful scaled dimensionless unit, making the propagation rule and conversion to :one explicit arithmetic. "Lose one level per ordinary step" is currently a game rule, so the second reading is plausible, but the first field experiment should force and record the decision rather than hide it in u8 storage.

If ordinary subtraction cannot truthfully express attenuation, add a named operation such as attenuate-light through the open EQL-specialized operator protocol. Do not weaken - until two differently named integers happen to type-check.

Mentioned in: Frontier programs are compiled sparse kernels

The fixed-point algebra should wait for a second client #BA9MCA

Light has two lattice-like structures. Its sites form a spatial lattice under six-neighbor adjacency. Its levels form a finite order in which max is the join. From-scratch propagation repeatedly joins attenuated neighbor contributions until it reaches a fixed point. Incremental removal first over-removes a region, then rebuilds the monotone closure from surviving sources.

That suggests a later reusable shape:

worklist fixed point
  domain and window
  input and output fields
  sources
  neighborhood policy
  edge transfer
  join

Distance transforms, reachability, influence propagation, or ecological fields might eventually share it. Extracting this solver before a second client would be a framework searching for evidence. Domain stepping, window resolution, field meaning, and kernel boundaries already have multiple real clients and should come first.

The sheaf-like interpretation should remain similarly informal. Chunks are local patches, halos resemble restrictions, and snapshots collect compatible local readings. But core chunk domains do not overlap, residency introduces unknown values, and lighting solves a nonlocal equation rather than merely gluing existing answers. "Field materialization" and "chunk window" are more operationally exact today.

The later source study #NXXOQT supplies another kind of evidence: a small Haskell engine in which BFS, A*, and Cheney collection share explicit frontier, memo, admission, and two-phase materialization roles. The terminal-wall component in #K3PCP3 is now a deliberately simpler adjacency client beside lighting. Together they narrow the reusable target to packed frontier storage and iteration laws while leaving fixed-point relaxation as one client-owned policy.

Mentioned in: Columnar layout, materialization, and policy are separate, Discover, relax, and invalidate are three different dynamics, Pack the lighting worklist, then test level scheduling

Chunk hierarchy and level of detail are related but not identical #TDEVBM

A residency hierarchy groups the same underlying cells into chunks, regions, or superchunks for lookup, persistence, scheduling, and invalidation. It does not necessarily make the world coarser.

Level of detail introduces different sites or different field meanings. A coarse site may carry occupancy fraction, dominant material, surface bounds, average radiance, or conservative collision information rather than one categorical block state. #O3P8NV develops why its schema may differ as well as its spacing.

An octree can host either concern, which is why they are easy to conflate. The semantic test is:

• same cells grouped into larger administrative regions means hierarchy;
• different sites carrying a coarser description means level of detail.

A later hierarchical window may resolve a request from an ordinary resident chunk, an ancestor cache, or a coarse materialization. Local algorithms need not know the lookup structure, but the returned field meaning, resolution, and confidence must remain honest.

Not everything spatial is a voxel field either. Moisture, temperature, smell, or habitat suitability may be cell fields. A critter is more likely a persistent entity carrying a position, perhaps indexed by spatial buckets. Vegetation can have both density fields and individual nearby plants. These systems can share voxel-space and chunk-window protocols without sharing one storage abstraction.

The Lisp shape is semantic objects around dense data #M0REWV

The idiomatic arrangement follows the project's existing CLOS practice:

• EQL-specialized symbols name field definitions, quantity definitions, and arithmetic operations;
• CLOS instances represent voxel spaces, chunk domains, chunk windows, materializations, policies, and derived products;
• generic dispatch selects a representation or kernel at a chunk or phase boundary;
• specialized arrays and closed loops remain visible inside that selection; and
• thin definition macros appear only when repeated ordinary methods reveal a pleasant definition site.

The first experiment should not begin with bundle-class. Ordinary inspectable field definitions attached to the existing block-content and light columns can reveal what metadata and redefinition behavior are actually needed. A metaclass becomes useful only if real definitions repeatedly want class-level schema, allocation, migration, and inspector support.

Live redefinition adds one requirement that Moppe gets from C++ compilation: a materialization must know which field-definition revision made its bytes meaningful. Redefining :sky-light must either remain representation compatible, visibly invalidate existing arrays, or migrate them. It must not silently reinterpret live storage. Compiled kernels likewise need dependency revisions and last-known-good replacement, following the existing shader discipline.

A staged concretization #BA1QCS

The following is a sequence to refine from evidence, not a Gantt chart.

1. State the value vocabulary. Complete #9ZK7Q7 so luvcraft's existing amounts and points stop relying on use-site annotations. Decide whether a gameplay light step is a unit or a storage encoding; distinguish propagation loss from texture opacity.

1. Extract local spatial operations. Give chunk-domain heap-allocation-free world/chunk/local decomposition, primitive stepping with boundary results, storage-order traversal, and face enumeration. Migrate light-region and meshing paths without changing their algorithms.

1. Name the window protocol. Let the live world, resolved meshing neighborhood, immutable halo, and light-region atlas resolve locations or crossings through their existing representations. Preserve semantic facades such as sample-block-at and sample-light-at.

1. Attach ordinary field definitions. Describe the existing block-content, sky-light, and block-light columns without changing their arrays. Keep field identity, value quantity, representation, product state, and provenance distinct.

1. Share one production calculation. Refine #D1R2NK with a domain-shaped client. Light decoding or a named light-response law is modest; a transfer law is more revealing if both CPU tooling and a shader genuinely use it.

1. Earn a field kernel. Once one scalar field operation is stable, select its representation once and run it over borrowed arrays. A native SIMD realization follows a real measured kernel (#VKLLPR), not the vocabulary design.

Each step should delete a concrete duplication or make a concrete mistake unrepresentable. None requires a universal bundle, a generalized fixed-point solver, a sheaf API, per-cell objects, or a broad rewrite of the working light system.