The water-coverage slider does not reach the Nauvis tile argmax

[wormeyman]

Found while porting the Nauvis tile catalog to Rust (#226). Not fixed in that port, per the standing rule: a unilateral fix on the Rust side reads as a port bug in tier 2.

What is wrong

TileResolverParams in src/noise/tiles/resolve.ts has no waterLevel field, so makeTileResolver builds its elevation tree with the default:

const elevationAt = makeElevationNauvis({ seed0, segmentationMultiplier, startingPositions });

makeElevationNauvis does accept waterLevel (elevationNauvis.ts:19, used at line 146 as max(nauvisMain - waterLevel * 2, startingIsland)). It just never gets one from here.

The call site confirms it is not supplied further up either. elevationRenderRequest.ts:570 builds renderTerrain's ctx from eight request fields and waterLevel is not among them - and it could not be, because RenderTerrainOptions.ctx is typed Omit<TileResolverParams, "seed0">. renderTerrain then builds its own early-out elevationAt the same way, so both halves are consistently at water level 0.

renderElevation on the same dispatch does receive waterLevel (elevationRenderRequest.ts:695), so the elevation view responds to the slider and the terrain view does not.

How much it costs

Measured at seed 123456 over a 2,401-point grid (x, y in -600..600 step 25), comparing waterLevel 0 against 5:

quantity	differs at
elevation_nauvis	1,144 of 2,401
resolved tile	322 of 2,401 (13.4%)

So this is not a rounding-scale difference. Moving the water-coverage slider should redraw the coastline and, on the Nauvis terrain view, it does nothing.

Why no test caught it

test/resolveTile.spec.ts grades against oracle-tile-names, which is captured on the DEFAULT preset - water level 0 - so the parameter it fails to thread is at its default in every fixture. Its Task 12b block does test that climate params thread through, and waterLevel is simply not in the list.

Scope of the fix

Add waterLevel to TileResolverParams, pass it into makeElevationNauvis in both resolve.ts and renderTerrain.ts's early-out tree, and add it to the ctx block at elevationRenderRequest.ts:570. Worth checking the other three makeTileResolver callers at the same time - renderEnemies.ts:259, renderRocks.ts:189 and renderResources.ts:247 - since a rock or enemy placement gated on a tile would inherit the same blind spot.

A fix will move rendered pixels, so it needs re-scoring rather than a green gate: test/previewAgreement.spec.ts and the tier-3 Nauvis comparisons should be read before and after.

Rust side

crates/fmw-noise carries water_level correctly through NauvisCtx into elevation_nauvis, so the port has no equivalent gap. Tier 2 (test/wasmNauvisParity.spec.ts) builds its tile env from the shipped expression trees rather than from makeTileResolver, precisely so it grades the tile FORMULAS and leaves this plumbing gap visible here instead of hiding it in a checksum. One of its three cases runs at waterLevel = 5.

🤖 Generated with Claude Code

https://claude.ai/code/session_017hVzDgUq6g7LATfczGxUrE

[wormeyman]

Folding in #326, which is a duplicate of this issue. It was filed a day later
from the Nauvis render port (#328) without noticing this one existed - same root
cause, same file, same mechanism. #326 is closed in favour of this issue; its
measurement is stronger, so it is reproduced here in full.

The cost is much larger than the 13.4% measured above

waterLevel is 10 * log2(control:water:size). Resolving the Nauvis tile
argmax over a 162 x 162 grid at step 37 spanning +/-3000 tiles, seed 123456,
against the same grid at waterLevel = 0:

control:water:size	waterLevel	tiles that differ
0.125	-30	6,373 of 26,244 (24.3%)
0.25	-20	6,187 of 26,244 (23.6%)
0.5	-10	5,516 of 26,244 (21.0%)
2	+10	12,471 of 26,244 (47.5%)
8	+30	19,531 of 26,244 (74.4%)

So one notch up on the water-size slider changes almost half the tile map, and
the terrain view shows none of it. renderElevation, renderResources and
renderCliffs all honour the same lever in the same panel, which is what makes
this read as an inconsistency rather than as "the slider does nothing".

A near-spawn window hides it completely

This is the part worth keeping. The first measurement used an 80 x 80 grid at
step 7 spanning +/-280 tiles and reported 0 of 6,400 tiles differing at every
water level tried, with an elevation_nauvis mean that did not move at all
above 0. That window sits inside the starting area, where the tree's
starting-lake and starting-island terms dominate and the water-level term is
masked. Widening to +/-3000 reverses the answer entirely.

A near-spawn window is not a sample of this lever. The same trap set three of
the tier-3 spec's windows in #328, where a 64 x 64 window at 1 tile/px came back
with only two distinct colours and auxFrequency moved nothing across it.

Still not fixed in the Rust port, deliberately

The Rust render path landed in #328 reproducing the omission, so tier 3 stays
byte-identical and the fix lands as its own graded change. The fix itself is
small - thread waterLevel through TileResolverParams and
RenderTerrainOptions - but it moves pixels, so it wants its own before/after
against the game's preview PNG rather than riding along inside a port.

Check renderRocks, renderEnemies and renderTrees at the same time: none of
them threads waterLevel either, but none of them reads elevation, so those
look correct rather than merely untested.