Vulcanus cliffs: the 2.4% remaining after the multisample grid fix

[wormeyman]

Follow-up to #18, which is resolved: multisample's offsets are in the calling noise program's grid units, so vulcanus_basalt_lakes_multisample's min-filter spans 4 tiles for cliffs and 1 for per-tile consumers (PR #83, test/multisampleGrid.spec.ts).

That took the Vulcanus cliff port from recall 0.806/0.938/0.853 with 12.5% wrong orientations to recall 1.000/0.973/0.965 with 2.4%. This issue tracks what is left.

1. The residual itself

37 of 1531 matched cells still carry a wrong orientation, and precision is 0.872 (1756 placed vs 1569 real) without the lava-collision rejection, which the shipping renderer applies and this measurement does not. Per region:

region	game	ours	matched	wrong	recall
[0,0]	283	292	283	7 = 2.5%	1.000
[1500,1500]	885	1070	861	26 = 3.0%	0.973
[-1200,800]	401	394	387	4 = 1.0%	0.965

Almost all the surviving over-placement is [1500,1500] (~209 cells; [0,0] is down to 9). First step is to re-measure with the lava rejection applied, which is how the renderer actually runs - it may account for much of the 187-cell excess.

2. A small regime split survives, with the same shape as the bug just fixed

test/vulcanusElevationLevels.spec.ts sweeps cliff_elevation_0 and inverts the generator's own elevation. Before the fix the over-placement ratio was 1.20-1.49 below elevation 120 and 1.00-1.04 above - a clean edge at exactly where 120 * vulcanus_basalt_lakes_multisample saturates. After the fix it is 1.000-1.085 everywhere, but the split has not gone to zero:

• worst ratio below 120: 1.085
• worst ratio above 120: 1.018
• gap 0.067, down from 0.16 but still positive, and the spec asserts it is > 0

Excess placement is still concentrated in the basalt-lakes elevation range. That is suggestive of a small remaining error in the same term - a second-order detail of the multisample sub-program (its own grid? its phase? the order of min against the clamp?) rather than a new mechanism.

3. Perf: the two elevation channels can no longer share a memo

VulcanusElevation now exposes cliffElevation beside elevation. They share every sub-expression below the multisample, so the extra cost is one memo table rather than a second DAG (a private DAG was tried first and is much dearer). Measured ~5% on the view:'all' Vulcanus composite, but that was taken on a loaded machine and deserves a proper pnpm perf run.

Worth checking whether the cliff pass can be given a cheaper working set, since it only ever samples the 4-tile corner lattice.

4. Audit other consumers for the same channel mistake

This is the generalisable part. Any consumer that reads a multisample-bearing field on a grid other than 1 tile needs its own variant, and nothing currently checks that. vulcanus_elevation feeds tiles, rocks, resources and cliffs; cliffs are the only one known to walk a coarser grid, but that was an assumption until it was measured for cliffs, and the same assumption is currently unexamined for the rest.

Related: docs/noise/vulcanus-multisample-NOTES.md is amended with the corrected rule and the reason its original 150/150 measurement supported a false generalisation - every comparison came through one channel.

5. Also still open, unchanged by this

• Vulcanus cliffs sit on ore at the chance rate (16.7%); the game separates them to 0.2% #24 cliff/ore separation - the enrichment of our over-placement on ore the game kept clear is now only measurable in [1500,1500], since [0,0]'s false-positive population collapsed from 103 to 9.
• Register: known approximations and unpinned semantics in the placement/cliff port (2 of 6 open; #5 and #3 closed 2026-08-10) #22 approximations register, Cross-overlay occupancy: earlier autoplacers block later ones (enemy bases are 47% over in region 0) #16 cross-overlay occupancy.

[wormeyman]

Items 1 and 2 are closed by #86 - and they were the same measurement error

Both arms compared our placement, which did not run tryToAddCliff's lava-collision rejection, against the game's, which always does. On Vulcanus the lava is the basalt lakes, so the missing deletion rule's effect lands exactly in the low-elevation range where the residual sat.

Item 1 - the 187-cell excess was 185 cells of a rule the measurement was not applying

	game	ours	matched	recall	precision	wrong orientation
no rejection (this issue's figures)	1569	1756	1531	0.9758	0.8719	37 = 2.42%
with rejection (what ships)	1569	1558	1518	0.9675	0.9743	31 = 2.04%

The rejection removes 198 cells: 185 false positives against 13 true. Per region with it on, [0,0] 283/277 precision exactly 1.000; [1500,1500] 885/895 precision 0.9564; [-1200,800] 401/386 precision 0.9974. The port goes from over-placing 12% to under-placing 0.7%.

Item 2 - no second multisample defect exists

cliff_elevation_0	no rejection	with rejection
20	1.085	0.988
40	1.048	1.022
60	1.044	1.027
90 - 130	1.008 - 1.018	0.991 - 1.000
140 - 200	1.000 - 1.009	1.000 - 1.009

Gap 0.067 -> 0.018, and the low regime straddles 1.0 rather than sitting above it. The suspicion that this was "a second-order detail of the same multisample term" is refuted.

What is left, restated: a TILE boundary, not a cliff field

The rejection costs recall in the same regime - 0.951 at level 20 rising to 1.000 at 140 and above. Each real cliff is a negative-space oracle (the game ran this rejection and kept it), and every contradiction sits at Chebyshev depth 1 in our lava, our own perimeter, never deeper: 32/32 at level 20, 52/52 across the sweep, 13/13 at default settings.

Stated carefully, because depth discriminates in one of the two places it was checked and not the other: at default settings region [1500,1500]'s 170 correct rejections span depth 1 to 9 with 45 bottomed out deep in lava, against wrong rejections that are 100% perimeter; at level 20 the correct rejections are 32/32 perimeter too. So the errors are boundary-sited in both directions - not proof the perimeter is one tile fat.

Note the resolver's binary lava/not call is already exact on all 381 oracle positions, including 42 directly on a lava boundary (vulcanusTiles.spec.ts). Whatever is off is finer than the sample that pinned it, so narrowing it needs a new capture, and it is a vulcanusCatalog question rather than a cliff one.

Remaining scope of this issue

• 1. Re-measure with the lava rejection - done.
• 2. The regime split - done, attributed.
• 3. Perf - still open and untouched. The ~5% on the view:'all' Vulcanus composite was taken on a loaded machine and wants a real run.
• 4. Audit other consumers for the same channel mistake - still open, and now the most valuable item here. vulcanus_elevation feeds tiles, rocks, resources and cliffs; only cliffs were measured to walk a coarser grid, and the same assumption is unexamined for the rest.
• New: the lava perimeter. 13 of the 51 missing cliffs at default settings, and the whole low-level recall deficit. Belongs to the tile resolver.

The residual on the shipping path is now 51 missing and 40 spurious out of 1569, with 31 wrong orientations - against Nauvis's 1.0000/1.0000/0.

[wormeyman]

Item 4 done - cliffs really are the only coarse-grid consumer (#87)

The assumption is now measured. The audit surface is much smaller than the item implied, and that is the first finding: multisample appears in factorio-data @ 2.1.12 in exactly one place - vulcanus_basalt_lakes_multisample, used only by vulcanus_elev. No other planet uses the primitive at all. So this reduces to "who consumes Vulcanus elevation":

consumer	reads elevation?	grid	how established
cliff generator	yes	4	measured, #83
tile generator (19 *_range)	yes, via vulcanus_elev	1	measured, #87
vulcanus_temperature	yes	1	same program as tiles
tungsten / coal / calcite / sulfuric acid	no	n/a	read the Lua
rocks, geyser	no	n/a	read the Lua

The resource row had to be checked rather than assumed, because the generic path does couple to elevation - starting_resources_lake_mask = clamp((elevation - 1) / 10, 0, 1) feeds starting_patches' favorability, and CLAUDE.md flags that coupling as exactly what changed at 2.1.9. Vulcanus does not take that path: each resource uses its own vulcanus_*_region expression, and those four definitions contain 0 references to elevation.

The tile generator reads grid 1

Substituting the cliff generator's 4-tile elevation into the tile resolver, against the game's own get_tile over 381 oracle positions:

	grid 1 (ships)	grid 4
tile-name agreement	0.9816	0.8609
lava misclassifications	0 / 381	27 / 381

Both arms carry an explicit sensitivity guard, because #57's substitution failed precisely by not being able to distinguish "nothing changed" from "the substitution never ran".

Side result: this clears the lava perimeter that costs 13 real cliffs their placement. Reading the other channel makes lava dramatically worse, not better - so the perimeter error is not a channel mistake, it is elsewhere in vulcanusCatalog.

Remaining scope

• 1. Re-measure with the lava rejection (test(cliffs): the "excess" was the lava rejection, not a second defect (#84) #86)
• 2. The regime split (test(cliffs): the "excess" was the lava rejection, not a second defect (#84) #86)
• 4. Channel audit (test(noise): channel audit - cliffs ARE the only coarse-grid consumer (#84) #87)
• 3. Perf - the only original item left. Real pnpm perf run on the two-channel cost.
• The lava perimeter - 13 of the 51 missing cliffs, and the whole low-level recall deficit. A vulcanusCatalog question, now with the channel explanation ruled out.

[wormeyman]

The lava perimeter was the COLLISION BOX, not the mask (#88)

The 13 real cliffs being dropped were never a tile-resolver problem. rotbb(x, y, size, intersect) (entity-util.lua:9) returns {{cx-x_dist, cy-y_dist}, {cx+x_dist, cy+y_dist}, 1/8} — a rectangle plus a 45° orientation. Sixteen of the twenty cliff orientations use it; the port kept only the bounding box, which overruns the rotated rectangle at all four corners, so it rejected cliffs on lava the game never tests.

	AABB (before)	oriented (after)
recall	0.9675	0.9758
precision	0.9743	0.9727
[0,0] recall	0.9788	1.0000
level-sweep recall	0.951 at level 20	~1.000 at every level

Clears 13 of 13 false rejections while keeping 182 of the 185 that remove genuine false positives.

The mask was exonerated by a capture built to convict it

oracle-vulcanus-lava-boundary samples radius-4 neighbourhoods around the 35 accusing tiles: 0 lava mismatches over 994 positions, 35/35 at the accusing tiles. Worth capturing because the existing 381-position survey structurally could not answer it — its sensitivity was measured by planting scale factors on lava's probability, and 1.02 and 1.2 both still pass.

Two corrections

• My own test(cliffs): the "excess" was the lava rejection, not a second defect (#84) #86 figure was wrong. The gap goes 0.067 → 0.024, not 0.018. That was measured with the over-aggressive AABB rejection, which deletes cells the game keeps and so flattered the ratio it reported. A too-strong correction hides the thing it is correcting.
• "All 13 sit at Chebyshev depth 1 in our lava" pointed at the wrong suspect. True measurement; the box's corners are its perimeter, so a corner-shaped box error has the same fingerprint as a one-tile-fat mask. A statistic only rules a suspect out if it would come out differently for each candidate.

Cleared en route

• The inclusive-floor fringe is real engine behaviour ((box+position) >> 8, from disassembly) — not our bug.
• Chunk ordering is not it: 2 of 13 cross a chunk boundary against 50 of 185 in the control, i.e. below baseline.
• 6 of the 13 also carry a wrong orientation (~23x enrichment over the 2.0% base rate), always a smaller -to-none variant of ours — the two defects compound. Those belong to the standing orientation residual.

Remaining scope of #84

• 1. Re-measure with the lava rejection (test(cliffs): the "excess" was the lava rejection, not a second defect (#84) #86) · 2. Regime split (test(cliffs): the "excess" was the lava rejection, not a second defect (#84) #86, figure corrected here) · 4. Channel audit (test(noise): channel audit - cliffs ARE the only coarse-grid consumer (#84) #87) · lava perimeter (fix(cliffs): rotbb collision boxes are ROTATED, not their bounding box (#84) #88)
• 3. Perf — the only item left, and untouched. Needs a quiet machine; it is wall-clock render timing, so it must not run alongside other work.
• Still open, smaller and cleaner than before: over-placement below elevation 120 (gap 0.024, no recall cost), and the 31-cell orientation residual, 6 of which were shown here to have real downstream effect.

[wormeyman]

This issue stays open until Vulcanus cliffs are 100%, or until Eric says to close it (his instruction, 2026-08-01). An empty item list is not a correct port: Nauvis sits at recall = precision = 1.0000 with 0 wrong orientations, so any Vulcanus gap is a known-unexplained residual, and in this repo those have twice turned out to be a whole missing rule rather than precision noise. When the last listed item closes, re-scope rather than close.

Current remainder: over-placement below elevation 120 (level-sweep gap 0.024, no recall cost), the 37/1531 = 2.4% orientation residual, and item 3 (perf).

[wormeyman]

Reopened. This was closed automatically by PR #87's commit message, which read "Closes #84 item 4" - GitHub parses Closes #84 and ignores the trailing qualifier. The intent was to close item 4 only.

Per Eric's instruction (2026-08-01): this issue stays open until Vulcanus cliffs are 100%, or until he says to close it. An empty item list is not a correct port - Nauvis sits at recall = precision = 1.0000 with 0 wrong orientations, so any Vulcanus gap is a known-unexplained residual, and in this repo those have twice turned out to be a whole missing rule rather than precision noise. When the last listed item closes, re-scope rather than close.

Current remainder: over-placement below elevation 120 (level-sweep gap 0.024, no recall cost), the 37 / 1531 = 2.4% orientation residual, and item 3 (perf).

For future reference: write "closes item N of #84" so the keyword is not adjacent to the issue reference.

[wormeyman]

Correction: #88's collision box was wrong. Fixed in #90.

Disassembling (prompted by flagging #88 as my least-confident result) showed the engine does not rotate the box. tryToAddCliff calls wouldCollide with Direction = 0; BoundingBox(BoundingBox const&, Direction) takes its identity arm (jump-table entry 0 = 0, read at 0x102d01400), copies left_top/right_bottom verbatim and overwrites the destination's orientation with a sentinel. The 1/8 tag never reaches the tile scan. Corroborated by the API mirror: BoundingBox.orientation is documented optional and OrientedCliffPrototype::collision_bounding_box is a plain BoundingBox.

box	false rejections	recall	precision	evidence
AABB (until #88)	13	0.9675	0.9743	an assumption
45° oriented rect (#88)	0	0.9758	0.9727	empirical fit only
raw stored rect (#90)	6	0.9720	0.9713	disassembly + docs

The best-scoring model was the wrong one. #88 hit 13/13 by shrinking past the engine, and the excess shrinkage also absorbed an unrelated defect — 4 of the 6 cliffs the correct box still rejects are cells whose orientation we get wrong, so we load the wrong box entirely.

Current shipping accuracy: recall 0.9720, precision 0.9713, ratio 1.001. Nauvis remains 1.0000/1.0000/0-wrong.

---

New: the orientation residual is ONE EDGE, and one-directional

Characterised the 37 wrong orientations tonight. This is much sharper than it was:

• All 37 differ in exactly ONE edge. Not a single two-edge difference. (Before fix(cliffs): multisample offsets are in GRID UNITS - #18 root cause #83 it was 125 of 175 at two edges.)
• Every one runs the same direction: the game says -to-none, we say a crossing. Sample transitions — south-to-north -> none-to-north (4x), north-to-south -> north-to-none (4x), west-to-east -> none-to-east (3x), south-to-west -> none-to-west (3x).
• So crossesCliff returns non-zero where the game returns zero, on one edge, 37 times in ~6100 edge evaluations (0.6%) — and never the other way.
• Per region: 7 / 26 / 4. Which edge: L11 / R6 / T7 / B13 — no strong directional bias.

Lead for next session: a strictly one-directional over-detection smells like a comparison boundary, not a field error — e.g. >= vs > in the band-crossing test, or the cliffiness gate's average >= 0.5. CliffGenerator::crossesCliff is at 0x101606d08 per the notes (re-derive the VA from nm, it has moved before). Reading the two comparisons out of the binary is the cheap move, and tonight's lesson is precisely that the binary beats tuning models against a metric.

Both remaining Vulcanus items are now well-characterised:

1. Orientation — 37 cells, one edge each, always over-detecting.
2. Over-placement below elevation 120 — level-sweep gap 0.024, no recall cost.

[wormeyman]

crossesCliff is EXACT — the orientation residual is in its inputs

Disassembled CliffGenerator::crossesCliff (0x10160c914 under 2.1.12; the notes' 0x101606d08 has moved, as warned). Decoded:

crossesCliff(a, b, cliffinessAvg, e0, interval):
  if (a < 0) return 0
  if (b < 0) return 0                      // early-out on EITHER corner
  band = floor((max(a,b) - e0)/interval)*interval + e0
  if (band < e0) return 0
  if (cliffinessAvg > 0.5):                // STRICT
     if (a-band <  0 && b-band >  0) return +1     // STRICT, ties don't cross
     if (a-band >  0 && b-band <  0) return -1
  return 0

src/noise/cliffs/cliffPlacement.ts reproduces this line for line — the negative guard, the band, the boundary < e0 check, the strict gate and the strict comparisons all match. So the boundary-comparison hypothesis from my previous comment is refuted: there is no >= vs > slip to find, and the whole function is ruled out.

That relocates the 37 to the inputs: the corner cliff_elevation values (the grid-4 channel) or cliffiness_basic, differing marginally at those corners. Since every one of the 37 is a single-edge over-detection, our value is landing on the crossing side of a band where the game's does not — consistent with a small field offset rather than a rule error.

Worth noting what has and has not been validated: cliffiness_basic is oracle-checked to <5e-6, but the grid-4 cliff elevation channel has never been sampled directly at the corner lattice — #83 established it via a contour-shift experiment, not a per-corner comparison. That is the obvious next capture (probeExpression + probeProperty onto cliff_elevation, sampled at the 4-tile corner lattice of the disputed cells).