Fix high zoom distortions

[Shane98c]

Follow up that supersedes #63. This one preserves pole rendering (and is compatible with latest main).

@james-willis this seems to fix the distortions and jittering from what I can see using your example data from #62. Thanks for tracking this down and providing the test data!

All untiled CRSes now encode vertices as normalized-Mercator deltas, and the flat path projects them with a render-relative-to-eye decomposition: gl_Position = u_anchor_clip + matrix * delta instead of forming an absolute world coordinate in Float32 (the source of the jitter). The per-region anchor_clip is computed from the renderer's native-precision (Float64) flat matrix and only the small delta goes through the Float32 GPU matrix, so high-zoom rendering stays stable under pan/zoom. The ECEF globe shaders invert mercator to lat (with a near-pole clamp), so polar datasets keep full coverage on the globe.

closes #62

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
zarr-layer	Ready	Preview, Comment	Jun 16, 2026 6:44pm

[james-willis]

Ill test this in a bit: this might solve another user reported bug that I haven't addressed yet about some high zoom "wiggling" while zooming.

mosaic_jitter.mov

[Shane98c]

I think it does! that one has been bothering us too!

[james-willis]

Working really nice! great work. Ill do a little code review as well.

[james-willis]

The only thing about this PR is that it does reintroduce seams in some cases, but they're pretty extreme. Like zooming into z=20 on HRRR (LCC projection) datasets.

Claude summary of how we created this case:

What the fixture is (and why it's contrived):
public/seam-lcc.zarr — a 6×6 grid, 1 pixel per chunk, each chunk spanning 2000 km in a spherical LCC CRS (the HRRR WKT2, so it takes the proj4 eye-coords path), checkerboard values through viridis. Two deliberate choices maximize the seam:

• Huge per-region mercator extent (2000 km/chunk → halfX_merc ≈ 0.05), which is the multiplier in seam ≈ region_merc_extent × 2^z.
• Sharp color edge exactly on every region boundary, so a few-pixel vertex mismatch is glaring instead of hidden inside smooth data.
• The 6×6-centered-on-origin trick puts the junction at exactly (lat0, lon0) = (38.5, −97.5), so the URL needs no projection math.

This is the corner I described, made real: coarse, large-chunk, custom-CRS data at extreme zoom. It confirms the regression risk is genuine on #69 — but it took a 2000 km/pixel dataset zoomed to z24 to make it visible. The target (sub-meter, 512px chunks) measured ~0.0002 px, i.e. nothing.

probably not worth fixing. 2 proposals from Claude worth considering:

1. leave a comment near encodeMercDelta: "seam_px ≈ 6e-8 × chunk_onscreen_px, unreachable below ~thousands of screen-widths of over-zoom."
2. Cap per-region on-screen extent via subdivision.

Since seam = 6e-8 × region_onscreen_px, subdividing any region whose rendered size exceeds ~8M px keeps every boundary < 0.5px at all zooms. The renderer already has the machinery — updateGeometryForProjection sets targetSubdivisions = isGlobe ? TILE_SUBDIVISIONS : 1; this is just extending the flat path to subdivide based on on-screen size instead of hardcoding 1. Cost lands exactly where you can afford it: massive over-zoom means very few regions on screen, so more triangles per region is free. This is the proportionate fix if anyone ever cares.