User clarified:
- x must decrease left to right (east at screen left, high x left)
- y must decrease in flight direction (south at front, low y in flight dir)
With no swap on canvasY (lng+halfLong+0.5 formula) and UNPACK
flip=true, canvas top -> texture top -> screen top. canvas bottom
-> screen bottom.
So:
- lng=+12 (north, ahead in N flight) -> canvasY=6272 (bottom)
-> screen bottom. User at screen bottom sees north tiles = high y
- south tiles at canvas top -> screen top. User at screen top sees
south tiles = low y. y decreases in flight direction (looking
forward = top of screen = low y).
With no swap on canvasX:
- perp=-2 (east, dx=+2) -> canvasX=128 (left)
- After WebGL (no X flip): east at screen left, west at screen right.
x decreases left to right (east at left, west at right).
User feedback: x decreasing left-to-right (matches NO swap), y
increasing in flight direction (matches swap). So the swap on
canvasY is right but the swap on canvasX was wrong direction.
With the no-swap canvasX formula:
- perp = -2 (east, dx=+2) at canvasX = 128 (left)
- perp = +2 (west, dx=-2) at canvasX = 1152 (right)
After UNPACK flip: canvasX stays as-is. User at canvas right sees
west (low x). User at canvas left sees east (high x). x decreases
left-to-right in the label content, matching what the user sees
in the satellite imagery too.
(The Y swap remains so lng=+12 -> canvasY=128 -> screen top, so
north tiles still appear at the top of the screen.)
With BUFFER_LONG = 1, refetch fires every ~1 tile of motion (every
~8 sec at default speed). With BUFFER = 1 the center shifts by
~1 tile per refetch, so only ~1 net new tile needs fetching each
time (the one at the very front of the new corridor).
Switch to partial refetch:
- Don't clear the canvas before redrawing
- Skip tiles already in groundLoadedTiles (they're still on the
canvas at the right position from a prior refetch)
- Only newly-positioned tiles are drawn (the ones in the new
front of the corridor, ahead in flight direction)
Effect: user sees tiles appearing at the front of the corridor in
the direction of travel, not the whole canvas flashing every 8 sec.
With N flight, fetch activity shows up at the top of the screen
(where lng=+12 lands after the axis swap), confirming the flight
direction is correct.
User reported 'N at close tiles' and 'NS mirrored, EW reversed'.
With the canvas axes swapped:
- lng=+12 (corridor front in N flight) at canvas top -> screen
top -> ahead in flight direction (correct)
- perp<0 (world east) at canvas right -> screen right (correct)
Verifies user expectation: north tiles ahead (screen top), east tiles
to the right (screen right). N label appears at the far-ahead tiles
along the top of the screen, pointing forward in flight direction.
User reports NS axis mirror with current swap. Try the original
formula (canvasY = (lng + halfLong + 0.5)*TILE_SIZE) without
swapping. UNPACK_FLIP_Y_WEBGL stays true so text still reads
right-side up; just see if the user's visual expectations match
this simpler arrangement.
UNPACK_FLIP_Y_WEBGL=true was correct for screen orientation but the
shader's rotated-frame math expected it false. To get both right:
- Re-enable UNPACK_FLIP_Y_WEBGL=true so canvas top maps to texture
V=1 (screen top). Text now reads right-side up.
- Invert the drawing axes: canvasY = (-lng + halfLong + 0.5)*TILE_SIZE
so lng=+12 (corridor front, ahead) lands at small canvas Y, which
after upload ends up at texture V=1, i.e. at screen top.
Same inversion for perp.
- Shader's gUv.y = rotated.x / uGroundSize.y + 0.5 is unchanged:
for offset.z=+12 (north) it samples V=0.98 -> texture row 6271
-> canvas row 128 (the new top-of-corridor row) -> lng=+12. Correct.
Effect: N labels read upright, image orientation matches world
directions, and corridor scrolls in the visible flight direction.
With the flag on, canvas row Y was uploaded to texture row (H-1-Y).
Sampling at V=0.58 then returned canvas row 2688 (in the 'south'
half of the corridor), but the shader expected row 3712 (in the
'north' half) for an offset.z=2 sample. So tiles appeared
mirrored across the NS axis — every N pointed south, every S north.
With the flag off, canvas row Y maps to texture row Y, and the
shader's expectation matches the drawing direction. Now N is at
the image's actual north, S at the image's actual south.
For verifying the corridor arrangement, draw labels on every
loaded tile (per drawTileAt):
- 'N' at the canvas top edge of the tile (= image north after UNPACK_FLIP_Y_WEBGL)
- 'S' at the canvas bottom edge (= image south)
- 'x=NNN y=NNN' at the centre with the actual ESRI tile coords
This lets you see at a glance which canvas direction maps to which
world direction. Combined with #flight=N|... and #fetch=N|... you
can describe exactly what is wrong (e.g. N pointing in screen-up
direction when it should point at the corridor front).
Computed precisely: zoom 11, lat 48.5667, lon 13.4319.
x_norm = (lon+180)/360 = 0.5373, x_tile = 1100.41 -> floor 1100
y_norm = 0.3452, y_tile = 707.07 -> floor 707
Previously had 1099/706 which placed the centre one tile west and
one tile south of Passau. User observed the tile content was
'vertauscht' — it was correct ESRI imagery of a different geographic
location (near Schärding), not Passau itself.
Old shader code with fdx/fdz still referenced window.__flightDir,
which GLSL can't parse. Removed those lines. Now shader uses only
uFlightDir uniform passed from JS.
The shader had the JS code 'window.__flightDir.dx' baked into the
GLSL string, which GLSL can't parse. Added a uFlightDir uniform
(vec2) and pass the dx/dz from JS via gl.uniform2f. Shader reads
uFlightDir.x and uFlightDir.y.
Two independent URL parameters:
#flight=N|NE|E|SE|S|SW|W|NW (camera motion direction)
#fetch=N|NE|E|SE|S|SW|W|NW (tile collection direction)
Example: #flight=E&fetch=N -> camera flies east, corridor built
north (perpendicular to flight). Lets you test what happens when
the corridor orientation doesn't match the camera's flight path.
URL parsing supports & and ; as separators, plus multiple keys
in one hash. window.__flightDir and window.__fetchDir are exposed
separately so JS code can react to each.
Adds 8 compass directions for the tile-build axis. Camera position,
corridor rotation, and refetch math all read from window.__flightDir.
Test URLs:
#flight=N north (default, +Z, current behaviour)
#flight=E east (+X)
#flight=S south (-Z)
#flight=W west (-X)
#flight=NE northeast (diagonal)
#flight=SE southeast
#flight=SW southwest
#flight=NW northwest
Renders with no hash unchanged. Each direction rotates the
corridor so its long axis follows the chosen compass bearing, and
the camera drifts along that bearing.
After swapping axes so lng runs along canvas Y (corridor long
axis), canvas height was still GROUND_CORRIDOR_PERP * 256 = 1280
(only 5 tiles tall). The 25-tile-long corridor was drawn off-canvas,
so only the back 5 tiles (lng -12..-7) were visible. That made
new tiles 'disappear' off the right side and the build appear 90
deg off from flight.
Set canvas height to corridor long (25 tiles = 6400 px) and
canvas width to perp (5 tiles = 1280 px). Now the full corridor
fits on canvas and the visual depth direction matches the
camera's flight direction along canvas Y.
Previous mapping placed the corridor's long axis (flight direction
+Z) on canvas X (horizontal). User observed this as '90deg to
flight direction' because the tiles appeared to scroll sideways on
screen instead of along depth.
Swap so the long axis is on canvas Y (vertical on canvas):
- drawTileAt: canvasX = (perp + halfPerp + 0.5) * TILE_SIZE,
canvasY = (lng + halfLong + 0.5) * TILE_SIZE
- shader gUv: gUv.x = rotated.y / uGroundSize.x + 0.5 (perp axis),
gUv.y = rotated.x / uGroundSize.y + 0.5 (long axis)
- uGroundSize call: (PERP, LONG) instead of (LONG, PERP)
Now the corridor's long axis runs vertically on canvas. The screen
mapping (uv.y -> forward distance) reads the long axis as a vertical
strip, matching user expectation that 'forward' tiles scroll top-
to-bottom (or bottom-to-top) as the camera flies.
With BUFFER_LONG = 1, refetch threshold was halfLong - 1 = 11,
which meant each refetch shifted the corridor centre by ~11 tiles.
From the camera's view that looked like the corridor suddenly
jumping 11 tiles forward — described as 'tiles jump to the right'.
BUFFER_LONG = 11 -> threshold = 1, so refetch fires as soon as
the camera crosses one tile beyond centre. Each refetch shifts by
~1 tile, which the user perceives as a smooth scroll rather than
a jump. Refetches now happen every 8 sec instead of every 92 sec,
but the load is small (only ~1 net new tile since browser caches
ESRI responses for 24h).
Shader maps world coords to UV via:
gUv = rotated / uGroundSize + 0.5
rotated = 0 -> canvas centre
But drawTileAt placed tiles at:
canvasX = (lng + halfLong) * TILE_SIZE
canvasY = (perp + halfPerp) * TILE_SIZE
With halfLong = 12 and lng iterating [-12..12], tile lng=0 lands
at canvas X = 3072 - but the shader wants gUv.x=0.5 (rotated=0)
at canvas centre X = 3200. Half a tile off.
Fix: shift drawing by +0.5 tiles so each tile CENTRE is at
(lng, perp), matching the shader's rotated-frame interpretation.
Tile centres now align with shader expectation; previous half-tile
diagonal wobble gone (which is what they meant by 'x und y
vertauscht' - the perpendicular axis was indeed offset).
Two visual issues reported: stripes from sides at tilts of view, and
tiles 'hopping' one tile per refetch.
Stripes: caused by gUv.y going OOB at sideways rays where hitPoint.x
is large; CLAMP_TO_EDGE returned the same edge colour across a wide
band, looking like a stripe. Added shader edgeFade that fades OOB
samples smoothly to uBg instead.
Hopping: each refetch shifts centerTile by many tiles (depends on
when in the cycle it fires). With BUFFER_LONG = 1 (refetch at
projLong > halfLong - 1 = 11), the centerTile only ever shifts by
about 1 tile per refetch. Refetches happen more often (~ every
8 sec instead of ~ every 96 sec) but each is tiny.
reverted partial-refetch optimisation: causes ghosting because old
tiles stay at old canvas positions but uGroundCenter moves, so
the shader samples stale content. Better to clear canvas and rely
on edgeFade to hide the brief fog state.
When I changed GROUND_TRAVEL_COS/SIN to (0, 1) (90 deg, +Z
direction) in JS, the shader still used the old (0.82, 0.57)
rotation (35 deg). The corridor was built along +Z but UVs were
computed as if the canvas were rotated 35 deg — meaning the
corridor was effectively at 35 deg from where tiles were loaded.
Tiles ended up diagonally to the flight path.
Camera speed was 0.45 units/sec which on 13km/tile tiles = ~5850
km/h = supersonic. User reported flying through tiles too fast.
- drift speed 0.45 -> 0.12 units/sec (~1500 km/h, fast plane)
- corridor 15 -> 25 tiles along travel (~3.5 min between refetches
at uSpeed=1, instead of ~12 sec)
- buffer 2 -> 3 tiles (refetch starts earlier so we always have
tiles loaded before the camera reaches the edge)
- Updated JS-side drift calculation to match the new shader speed
Camera now leisurely follows the corridor; refetch only once every
couple of minutes.
Camera was moving in (1, 0.7) but looking mostly in +Z — 55
deg between them meant tiles collected along motion weren't in
the user's forward view. Now:
- ro = (0, 2.2, drift) \u2014 motion purely in +Z
- GROUND_TRAVEL_COS/SIN = (0, 1) \u2014 corridor runs along +Z
- rd = mostly forward +Z, with downward tilt for the ground view
Everything (motion, look, tile collection) is now on the same
+Z axis. Tiles appear directly in front of the camera as it
moves forward, no more 45-55 deg offset.
Camera moves at uTime * uSpeed * 0.45 in +X with +X*0.7 in +Z.
Previous axis-aligned corridor (long in X, perp in Z) was
perpendicular to the actual travel direction, wasting tiles in
the +Z / -X corner where the camera never goes.
Now the corridor is rotated 35 deg to match travel:
- GROUND_TRAVEL_COS/SIN = 0.82/0.57 (cos/sin of 35 deg)
- GROUND_CORRIDOR_LONG = 15 (tiles along travel)
- GROUND_CORRIDOR_PERP = 5 (tiles perpendicular)
- rebuildGroundMosaic iterates (lng, perp) in rotated frame,
draws each tile at canvas position (lng, perp) but loads from
tile (dx, dz) rotated from (lng, perp) by travel angle
- Shader rotates hitPoint into corridor frame, then divides by
per-axis extent to get UV
The camera moves primarily in +X (drift = uTime * uSpeed * 0.45)
with a slight +Z component (drift * 0.7). A square 9x9 mosaic
wastes half its tiles behind the camera. A corridor shape with
13 tiles along travel (X) and 5 tiles perpendicular (Z) uses 65
tiles to cover the same useful area — and refetches happen only
when the camera approaches the forward edge, not all four sides.
- GROUND_CORRIDOR_X = 13 (≈13s of forward travel at uSpeed=1)
- GROUND_CORRIDOR_Z = 5
- GROUND_BUFFER_X = 2, GROUND_BUFFER_Z = 1
- Shader uniform uGroundSize is now vec2 (sizeX, sizeZ)
- UV mapping: gUv = (hitPoint - centre) / size + 0.5 with per-axis size
Tile coords were wrong — Passau at zoom 11 is (1099, 706), not
(1102, 710). My earlier hand-calc (1100/706) was close but
rounded in the wrong direction.
Mosaic 16x16 = 256 tiles took 5-10s to load due to browser
6-connection limit. Reduced to 9x9 = 81 tiles (~2s). Camera
already looks down enough that visible ground fits in 9 units.
Previous look direction had rd.y from -0.05 to -0.40 across
the screen, so most rays hit ground at tGround in [9, 44] — way
beyond the 16-unit mosaic. Those OOB pixels came back as solid
edge colour, creating the striped band of texture-then-edge
transitions.
New look: rd.y from -1.10 (bottom) to 0.20 (top). At uv.y=0
rd.y=-0.45 (26° below horizon) so the visible ground sits at
tGround < 6 — all within the 16-unit mosaic. Ground mask
threshold also tightened from -0.30 to -0.10 so the ground
fades to sky higher in the image (looks like atmospheric haze).
Fog distance 14 → matches the new closer-ground regime.
- GROUND_MOSAIC_SIZE 9 -> 16 (16x16 = 256 tiles, covers 16 world
units instead of 9 — wider safety margin at the mosaic edge)
- Fog: tGround / 30 -> tGround / 12 with full mix (was 75% mix)
so distant ground fully fades to sky instead of staying visible
with wrong UVs (which was the source of the striped look)
- Result: visible ground content matches mosaic; far ground
cleanly fades to sky, close ground shows clear satellite tiles
Last commit fixed gl calls inside the .then() but missed the
calls in the body of initGroundSystem itself. Replaced every
gl.X reference with groundGl.X in the new code.
The function used bare 'gl' but it's a module-level closure, so
gl wasn't defined inside the .then() callback. Added groundGl
module variable, set it in initGroundSystem, used it everywhere
in rebuildGroundMosaic instead of bare 'gl'.
Replace static ground.jpg with a dynamic tile-based system that
fetches new tiles from ESRI World Imagery as the camera moves
through the world.
- GROUND_TILE_Z = 11 (~13 km per tile)
- GROUND_MOSAIC_SIZE = 9 (9x9 = 81 tiles, 2304x2304 canvas)
- GROUND_BUFFER_TILES = 2 (refetch when within 2 tiles of edge)
- Passau tile at zoom 11: x=1102, y=710
Shader:
- Two new uniforms: uGroundCenter (mosaic centre in world units),
uGroundSize (mosaic side length = 9)
- gUv = (hitPoint - uGroundCenter) / uGroundSize + 0.5 so the
mosaic centre stays at UV (0.5, 0.5) as the camera drifts
Runtime:
- maybeRefetchGround() called every 1.5s with current camera
position; if camera is in the buffer zone, mosaic centre is
shifted and missing tiles re-fetched in parallel
- Canvas re-uploaded to GPU after each rebuild
Camera can now roam indefinitely — every time we approach the
mosaic edge, a fresh 9x9 of tiles is fetched.
gmask smoothstep end -0.10 -> -0.30: ground only fully fills when
ray Y is below -0.30 (about 17° below horizon). The horizon line
sits higher in the frame, more sky visible above.
Wrapped the multi-line horizon comment into a single quoted
string. Same bug as the earlier fix but in the new ground code.
Going forward I'll make sure all multi-line comments inside
FRAG_SRC are wrapped in quotes.
Instead of mapping rd.x/rd.y to UV directly (which gave a flat
orthographic look), compute where the ray actually intersects
the ground plane and sample the satellite texture at that world
(x,z) coordinate. As the camera drifts forward (uTime), the
ground scrolls, giving the illusion of flight over real terrain.
- tGround = -ro.y / rd.y (with rd.y < 0 guard)
- gUv = (hitPoint.x, hitPoint.z) * 0.04 + 0.5
- Atmospheric perspective: ground fades toward sky with distance
(fog starts at hit-distance 0, full at 30 world units)
- gmask 1.0 only when tGround > 0 (camera above ground AND ray
pointing down), 0 otherwise
loadImageTexture(s.gl, ...) referenced 's' before its 'var s =
canvas.__state' declaration later in the function. Used
canvas.__state.gl directly since __state was just assigned.
When I added the ground-texture code I left the comment as
multiple JS-line-comments ('// Horizon...') between strings.
Those are NOT inside any string, so JS sees:
'// Horizon: ... satellite <- opens string, never closes
// ground texture ... <- JS thinks these are line comments
...
The string stays open until the next ',, then the next string
line parses as a continuation of an unterminated string and the
whole file is rejected. Wrap the comment into one quoted string.
Pulled a 5x4 tile mosaic of the Passau region (zoom 10) from
ESRI's free ArcGIS World Imagery service, stitched + resized to
1024x768 JPEG (277 KB). Added to Dockerfile as ground.jpg.
Shader side:
- New uniform uGround (texture unit 1)
- horizonMask: rd.y in [-0.20, -0.02] -> ground fades in from 0
to 1 as we look further down
- gUv derived from rd.xz so looking forward/down scrolls across
the satellite image (parallax-like feel)
- Distant ground fades toward uBg via a 'fog' factor so the horizon
blends naturally with the sky gradient
Loading is async — clouds render before ground texture arrives.
Falls back to a black sample if ground.jpg fails to load.
- skyDarkness 0.85 -> 0.55 so night sky is deep but not pitch
black, leaving room for stars to show through
- skyMask widened (-0.10 -> -0.20 lower bound, 0.30 -> 0.40 upper)
so stars appear closer to the horizon in the cockpit view
- Star tint multiplier 0.9 -> 1.0 (full bright) for clearer dots
- fbm3: 4 -> 3 octaves
- cloudDensity: 4 layers (base + mid + fine1 + fine2) -> 2 layers
(base + mid at 20%)
Cost per pixel: 16 noise3 -> 6 noise3 per step, ~62% cheaper.
Visual: clouds still have secondary detail but the fine wispy
edges are gone — back to the cleaner silhouette.
'cloud' was referenced outside the for-loop where it was
defined. Use 1.0 - trans (transmittance) as a cloud mask
instead — same information, properly scoped.
clouds3d:
- Star twinkle: 3 Hz ±45% -> 0.5 Hz ±15% (gentle scintillation
instead of static-like flickering)
- Night darkening: applied only to sky pixels via the cloud mask,
not to clouds. The darkening factor jumped 0.45 -> 0.85 so the
night sky really does go black around moonlit clouds. Clouds
keep their uLight-tinted colour so they remain visible.
clouds2d:
- Same darkening approach but via multiplicative factor (no cloud
mask in the 2D shader): col *= 1 - nightFactor * 0.7
- Remove dive component from camY. Was mix(2.0, 1.2, diveT)
(occasional dips into cloud top); now fixed at 2.2, always above
the y=1.5 cloud ceiling. Cloud deck always visible below.
- WEATHER_DENSITY bumped again: sunny 0.55->0.65, cloudy 0.85->0.90,
night 0.65->0.75. Even 'sunny' is now a partly-cloudy sky.
- clouds3d: third fBm detail layer at 3.2x frequency (was 2 layers).
Contributions: base 1.0, mid 0.30, fine 0.12. Combined with the
tighter smoothstep (0.18 -> 0.16) the silhouettes have wispier,
more interesting edges instead of soft blobs.
- Same density bump in clouds2d for consistency.
- WEATHER_DENSITY bumped: sunny 0.20->0.55, cloudy 0.70->0.85,
night 0.45->0.65. Stormy stays at 1.0 (already maxed).
Even 'sunny' now has visible cloud structure, not just clear sky.
- clouds3d: add a second fBm layer at 4x frequency for fine detail,
blended at 18% into the base. Combined with the tighter smoothstep
(0.24 -> 0.18) the cloud silhouettes have more interesting edges
instead of soft blob shapes.
- Same density bump applied to clouds2d so swapping renderers
doesn't change the visual weather.
- config.renderer: clouds2d -> clouds3d (user request)
Three coordinated changes:
1. nightPaletteNew.cloud: void -> raised (slightly lighter than
sky) so clouds have contrast against the new-moon sky
2. nightPaletteFull.cloudShadow: panel -> void so cloud undersides
fade into the night sky, while the lit topsides (border) stand
out clearly
3. getNightColor() now keeps 'light' (moonlight) bright and only
partially darkens sky/bg. The previous version squashed
everything toward black, killing cloud structure.
Shader side:
- max(0.15, uDayProgress) keeps a baseline moonlight tint on the
lit side of clouds even when uDayProgress happens to be 0
- The final darken pass is now driven by nightFactor (sunAlt-based)
instead of the unreliable uDayProgress
The cloud horizon flickered when the camera was far from the
deck because the regular raymarch steps aligned with the cloud
boundary. Two cheap fixes:
- Per-pixel jitter (hash21 of gl_FragCoord + uTime) shifts each
ray's start by up to one stepSize; the brain averages the
random offsets into a smooth edge
- Wider smoothstep (0.18 -> 0.24) softens the binary cloud/no-cloud
boundary the jitter is now dithering across
- Cruise altitude 2.6 -> 2.0 (just above cloud ceiling y=1.5,
gives the 'just above the clouds' airliner feel)
- Expose __currentSunAlt (radians) from animate() so the
renderer can tell night from day without misreading
realDayProgress (which mixes pre-dawn + post-sunset hours)
- Replace (1 - uDayProgress) star gate by smoothstep over uSunAlt:
nightFactor = 1 when sun is well below horizon, 0 when above
- Widen sky band so stars are visible from the horizon upward
(cockpit-perspective frame is mostly below rd.y=0.3)
- Cloud ceiling lowered from y=1.8 to y=1.5 (thinner deck)
- Cruise raised from y=2.0 to y=2.6 (clear margin above clouds)
- Dive endpoint raised from y=0.9 to y=1.2 (skims top, never deep)
- Dive exponent 5 -> 8 (much rarer dives)
- Early-out and ceiling bounds updated to match new y=1.5
Richard Zink