VoxelForge/Standalone/Research/WorldAssemblerM3/Linux76/R40-researcher-notes.md

Revised ranked list

Ranked by opportunity, not measured speedup. Changed: I retract R40’s ranking of the per-column detail context as the clearest next win. The line-based detail pass already has that context, while L73 reports large repeated passage-composer workloads. L73 does not time individual terms, so none of these ranks predicts seconds saved.

1. [INFERENCE] [CODE] Reuse passage relief fields within one sample. When multiple passages reach the relief calculation at the same (X,Y,Z), they call the same three functions with the same inputs: passage-wall relief and two surface-relief fields. Each function evaluates three 3D value-noise fields, so its result depends on Z; it cannot be reused across a column’s different Z samples. A sample-scoped cache could reuse each result across qualifying passages while leaving their density-composition order intact. [REPORT] L73 counted 54.5M FI / 46.9M TN passage relief-field calls, but did not time them separately. Relief calls in the passage loop, noise definitions, L73 counts and their limitation

   Falsifier: term-level timing shows these calls are a small part of composer time, or the hot samples rarely reach more than one qualifying passage.

2. [INFERENCE] [CODE] Make tile passage and crossing candidates drive the sample loops. Tile scope already builds passage features, but turns route and column features into per-passage flags. The sample path still checks every passage for upper-mouth proximity, loops over every passage for carves, and scans all void crossings inside that loop. An ordered per-tile list could avoid those visits while preserving passage order and retaining the existing sample-level tests. Mouth-support segments already have a per-tile candidate list and are filtered by sample bounds. [REPORT] L73 counted 63.4M FI / 54.2M TN carve visits, 20.4M / 15.5M support visits, and 24.6M / 20.4M mouth-route checks; these are counts, not time shares. Tile scope, upper-mouth scan, passage and crossing loops, per-tile support segments

   Falsifier: most tiles retain nearly every passage, or direct timing shows the remaining loop and crossing checks are cheap beside route-distance work.

3. [INFERENCE] [CODE] Extend Z-line reuse only where scalar sampling still pays for it. The scalar analytic path calls DetailNoise, which creates a fresh owner-noise context per sample. Its surface relief has three 3D value-noise fields; owner roughness may add 3D Perlin calls, domain warps, or cellular searches. However, ApplyDetailBand already creates a detail context per column, reuses value-noise planes and owner endpoint cores, and passes its macro value from fade into detail. So this is a candidate only for hot callers that still use the scalar path, not a general missing optimization. Scalar detail path, existing per-column detail context, macro reuse in that pass, owner noise and Z-dependent warp inputs

   Falsifier: the scalar path contributes little to L73’s field time, or owner roughness is rarely active. The current report does not separate those costs.

4. [INFERENCE] [CODE] Cache selected XY subterms, with strict scope. FloorAt(P,X,Y) is XY-only for a fixed primitive, and cavern-edge closest-point parameter search uses X and Y. But primitive selection and bounds checks depend on Z; cavern floor distances, caps, noise, and feature eligibility also depend on Z. In addition, the batched primitive path already computes a primitive’s floor once for its Z lanes. These are narrower opportunities than R40 implied. XY-only floor function, batched floor reuse, cavern XY projection, Z-dependent cavern distance

   Falsifier: those XY subterms are a small share of time, or few features pass the per-sample bounds checks.

Dependency and exactness audit

Term	What the code verifies
StrataDistance(Z), FindLayerField(Z), bound-stratum lookup	[CODE] Verified Z-only selectors/values. They can be shared across X/Y samples on the same Z plane. The selected field can change when Z crosses a layer or stratum boundary. Strata and layer lookup
FloorAt(P,X,Y)	[CODE] Verified XY-only for fixed P. This does not make floor blending XY-only: the primitive’s per-sample selection, Floor-Z, and floor blend tests still depend on Z. Floor function, Z-dependent blend
3D value noise and relief	[CODE] Verified partial XY reuse only. X0, Y0, TX, and TY use X/Y; Z0, TZ, the corner planes, and the final nested lerp use Z. Owner roughness also puts effective Z into its main and fine coordinates and into domain-warp Perlin inputs. Value-noise interpolation, owner domain warp, owner core
Primitive selection	[CODE] Verified Z-dependent. PointBin includes Z, and the sample checks primitive Z bounds before evaluating distances. Only the X/Y parts of the bin lookup are column-stable. 3D bin key, per-sample primitive scan
Cavern and mouth-support projections	[CODE] Verified XY-only for the projection parameter in these paths. Their full results are not XY-only: cavern floor height/caps and mouth-support distances use Z. Feature and primitive selection also still use per-sample bounds. Cavern projection and floor, mouth-support projection and Z distance
Tile candidates and boundary flags	[CODE] Verified tile-constant candidate data. Passage, stamp, and cavern candidate sets are built from tile bounds. The boundary and transition entries are conservative tile flags, not exact per-sample eligibility; the boundary calculation still uses X, Y, and Z. Tile scope and flags, boundary calculation

Bit identity: I cannot certify any proposed code motion as bit-identical from source inspection alone. The safest candidates are memoization that calls the same helper with exactly the same inputs, or reuses its returned value without rearranging density arithmetic. The existing line-context value-noise code preserves the visible nested lerp order, but moving work into another context can change inlining or floating-point contraction. I did not verify compiler FP settings or generated code, so FMA/reassociation parity remains inferred, not verified. Reordering composer features is especially risky because the density updates are sequential. Value-noise line context, composition order

Candidate-list correction: primitive queries use 32-voxel spatial bins, not a per-tile primitive list; each sample scans the references in its selected 3D bin. Mouth-support segments do have per-tile candidates. The active legacy FI has no matching native IslandPlan, so native island feature lists and the native island column cache do not serve these FI samples. Bin size, FI plan guard, L73 path finding

Dropping detail octaves or changing float/double arithmetic remains [INFERENCE] [WORLD-CHANGING]: even if visually similar, those changes alter field bits and may alter signs near zero.

Read-only source/report inspection only; no program, build, or tests were run.