test(cliffs): falsify the water-rejection cause too, and attribute Nauvis's residual to field precision - #33
Merged
Conversation
…uvis's residual to field precision Second and last of the two causes `cliffs-NOTES.md` named for Nauvis's ~6% cliff residual on 2026-07-20. `fixImpossibleCells` fell yesterday's way (PR #32, no change to Nauvis at all). `tryToAddCliff`'s `wouldCollide` rejection falls here. ## Why wouldCollide cannot be it - Existing entities are not there yet. `computeInternal` runs `generateCliffs()` BEFORE `generateEntities()`, so the per-tile mask grid the check consults holds only the tiles' masks. There is nothing else to hit. - The only tile layer the cliff mask intersects is `water_tile`, so the whole rejection reduces to "no cliffs on water" here. - And that can never fire. Over [512,1024)^2 at both oracle seeds, NOT ONE cliff cell touches water - not ours, not the game's, not matched, not mismatched. `cliff_elevation_nauvis` is `10 + 30 * (...)` and `crossesCliff` needs both corners non-negative with max >= elevation_0, so the geometry already excludes everywhere water can be. The regions are 21.1% and 71.9% water, so that is a real exclusion rather than a dry test window - asserted separately, because "no cliff touches water" would pass just as happily against a resolver that never returned water at all. ## What the residual actually is Distance from the nearest band boundary (10 + 40k), minimised over each cell's four corners: | seed | matched p10/p50/p90 | mismatched p10/p50/p90 | | --- | --- | --- | | 123456 | 0.04 / 0.24 / 0.60 (n=266) | 0.02 / 0.07 / 0.25 (n=16) | | 777771 | 0.06 / 0.26 / 0.53 (n=49) | 0.04 / 0.06 / 0.06 (n=3) | The cells we get wrong sit 3-4x closer to a band edge than the ones we get right. That is what a small field difference looks like: our cliff elevation and the game's disagree by enough to flip a corner across a boundary, but only where the corner was already sitting on one. A structural rule we had failed to port would not select for boundary proximity like that. So the follow-up is FIELD PRECISION (f32 vs f64, the fastapprox floor compounding through the hills chain), not a missing pass - a materially different piece of work from the two that were assumed for eight days. Vulcanus: `wouldCollide` cannot apply there either, since the planet has no water tile. Its residual is much larger than Nauvis's and has not been characterised the same way yet; the Nauvis result says to look at field accuracy first. Refs #18, #22. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_016vZjgASLZyxUfXx1dsq2HX
wormeyman
added a commit
that referenced
this pull request
Jul 28, 2026
…uvis's is (#34) Follow-up to #33, which attributed Nauvis's ~6% cliff residual to threshold sensitivity in the field. The obvious next move is to assume the same of Vulcanus's much larger gap. Measured instead, and it does not hold. Same boundary-proximity test, run against the smoothed field the gate actually sees, normalised by each planet's own interval so the 40-vs-120 difference does not do the talking: | | matched, median / interval | mismatched | separation | | --- | --- | --- | --- | | Nauvis 123456 | 0.60% | 0.18% | 3.4x | | Vulcanus [0,0] | 3.7% | 1.5% | 2.4x | | Vulcanus [1500,1500] | 5.4% | 3.9% | 1.4x | | Vulcanus [-1200,800] | 5.3% | 2.2% | 2.4x | The effect is present on Vulcanus - wrong cells are consistently nearer a boundary than right ones - but far weaker, and they are NOT knife-edge: 1.5-3.9% of an interval against Nauvis's 0.18%, an order of magnitude out. **A field-precision fix would not close Vulcanus's residual.** Whatever is left there is structural and still unidentified. Pinned deliberately rather than left as a note: generalising a Nauvis result to both planets is the exact mistake that made `cliff_smoothing` cost two months ("a no-op in this path" - true of Nauvis only). Also pins Nauvis's own knife-edge figure (< 0.5% of an interval) so the two assertions read as a matched pair. Refs #18, #22. Claude-Session: https://claude.ai/code/session_016vZjgASLZyxUfXx1dsq2HX Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second and last of the two causes
cliffs-NOTES.mdnamed for Nauvis's ~6% cliff residual on 2026-07-20.fixImpossibleCellsfell in #32 (no change to Nauvis at all).tryToAddCliff'swouldColliderejection falls here.Why
wouldCollidecannot be itcomputeInternalrunsgenerateCliffs()beforegenerateEntities(), so the per-tile mask grid the check consults holds only the tiles' masks. Nothing else to hit.water_tile, so the whole rejection reduces to "no cliffs on water" here.[512,1024)^2at both oracle seeds, not one cliff cell touches water - not ours, not the game's, not the matched ones, not the mismatched ones.cliff_elevation_nauvisis10 + 30 * (...)andcrossesCliffneeds both corners non-negative withmax >= elevation_0, so the geometry already excludes everywhere water can be.The regions are 21.1% and 71.9% water, asserted separately - because "no cliff touches water" would pass just as happily against a tile resolver that never returned water at all, or a substring match that never hit. That non-vacuity check is the part I'd want reviewed.
What the residual actually is
Distance from the nearest band boundary (
10 + 40k), minimised over each cell's four corners:The cells we get wrong sit 3-4x closer to a band edge than the ones we get right. That is what a small field difference looks like: our cliff elevation and the game's disagree by enough to flip a corner across a boundary, but only where the corner was already sitting on one. A structural rule we had failed to port would not select for boundary proximity like that.
So the follow-up is field precision (f32 vs f64, the fastapprox floor compounding through the hills chain), not a missing pass - a materially different piece of work from the two that were assumed for eight days.
Vulcanus
wouldCollidecannot apply there either: the planet has no water tile. Its residual is much larger than Nauvis's and has not been characterised the same way yet - the Nauvis result says to look at field accuracy first rather than hunt for another pass.pnpm run verify: 1181 passed, 0 failed.🤖 Generated with Claude Code
https://claude.ai/code/session_016vZjgASLZyxUfXx1dsq2HX