User clarified: the X-swap should be in the ARRANGEMENT (east
tiles on screen right), NOT in the image (so map content is
readable). Previous attempts had it the other way around.
Combined state:
- canvasX = -perp + ... (X-swap): east (1102) on screen right,
west (1098) on screen left. x increases left to right.
- drawImage with positive width: no image X-flip. Map content
reads normally, place names not mirrored.
- Labels in normal orientation.
So the X mirror is in the corridor arrangement, not in the
satellite image content. The user can read the map normally.
Final state per user request (KEIN X-Swap, KEIN X-Flip):
- canvasX = (perp + halfPerp + 0.5) * TILE_SIZE: east (1102)
at canvasX 128 (left), west (1098) at canvasX 1152 (right).
Natural order with no swap.
- drawImage with positive width and height: map content reads
normally, no X-flip on the image.
- Labels in normal orientation (no mirrorLabel).
Map is now fully natural: no X swap, no X flip, no mirror label.
Both the arrangement and image content are in standard orientation.
The user wants:
- Natural order arrangement (canvasX = perp + ...): east (1102)
on left, west (1098) on right
- X-mirrored image (NS-mirror): within each tile, the image east
appears on the left of the tile (natural map orientation)
Combined state:
- canvasX = (perp + halfPerp + 0.5) * 256: natural order
- drawImage with negative width: X-flip (NS-mirror)
- All labels in normal orientation (no mirrorLabel)
This matches the user's description: 'die anordnung passt' (arrangement
correct) and 'der x-flip ist immer noch falsch' (image was still
mirrored, now correctly mirrored).
User wanted NO X-swap and NO image X-flip:
- canvasX = (perp + 2.5) * 256 (no negation): east (perp=-2)
at canvasX 128 (left), west (perp=+2) at canvasX 1152 (right)
- Image drawn with positive width (no X-flip): map content
reads normally (place names, street names not mirrored)
The X coordinates read in their natural geographic order:
- left = high x (east), right = low x (west)
If the user is observing from a south-facing view (cockpit facing
back), their right is the world's left (east), so they see
high x on their right (world's left). x still reads correctly
when facing the same direction as the flight.
The arrangement is now back to the natural order with no
swapping in either direction.
Add explicit X-swap marker comment so the user can verify they're
seeing the new build. Bump canvas width by 2*256 padding so the
X labels (drawn at canvasX + 244) are within the canvas even for
the rightmost drawn tile (east, perp=-2 -> canvasX 1152, label
at 1396). With wider canvas (1792 vs 1280), labels are visible
and the corridor is centred.
The user wants the original tile content (map) to be readable
normally, not X-mirrored. The X-swap arrangement (canvasX = -perp
+ ...) places east tiles on the right of the screen, so X coordinates
read naturally left to right when scanning the corridor.
Combined state:
- Map content (image): drawn with normal orientation (no X-flip)
- Arrangement: east on right, west on left (X-swap)
- Labels: drawn in normal orientation in the corners
- Y-swap: north tiles (lng=+12) at canvas top -> screen top
The user wanted the tile content to be NS-mirrored (X-flip
on the image) so the corridor orientation matches. The labels
are drawn separately in normal orientation, so they read
normally. Now the arrangement has:
- canvasX = -perp + ... (X-swap): east tiles on screen right
- Image X-flipped (NS-mirror): image east at left of tile
- Labels in corners drawn normally: x=1102, y=707 readable
Combining these, the user looking at the screen sees:
- screen left: west tiles (low x), with image west on the right
- screen right: east tiles (high x), with image east on the left
- All labels readable
So the X coordinates read correctly when the eye scans left
to right across the corridor, and the image content is
NS-mirrored to match the corridor's direction of travel.
The user wanted the image content to be readable (not X-flipped).
The X-swap arrangement (canvasX = -perp + ...) already places east
tiles on the right side of the screen, so the X arrangement
reads naturally left to right without needing the image to be
flipped.
The image is now drawn with positive width and height, so
place names, street names, and the coordinates labels (x=NNN,
y=NNN) are all readable. The X-swap arrangement positions the
tiles so that:
- west tiles (low x) drawn at canvas left
- east tiles (high x) drawn at canvas right
So the X coordinates increase left to right when reading the
corridor from screen left to screen right.
User wanted the image to be X-mirrored (NS-mirror, so place
names on a map are correctly mirrored for the corridor
orientation), but the text labels to be readable normally.
Now labels are drawn in normal orientation:
- N at top-left
- S at bottom-left
- y at top-right
- x at bottom-right
The text is no longer reversed. With the corridor's X-swap
arrangement, this means:
- screen left = west tiles (low x)
- screen right = east tiles (high x)
- within each tile, the image is X-mirrored, but the text
inside is readable
The drawImage call uses width=-TILE, height=+TILE, which is an
X-only horizontal mirror. The old comment said '180 degrees'
which implied both axes flipped; the code is only horizontal.
NS axis = vertical axis, mirror across it = horizontal mirror.
Current state matches the user's observation: tile content
is NS-mirrored, X arrangement goes low->high left to right.
Carto Voyager was returning 'API Key required' content for the
user (likely rate-limited or IP-blocked by Carto). Switched to
ESRI World_Street_Map which has CORS-friendly tiles with plenty
of place names and street labels.
URL format is different from Carto: {z}/{y}/{x}.jpg (y before x,
jpg not png). Updated the build to match. The local /esri/
proxy in default.conf handles the upstream CORS-incompatibility
by adding permissive CORS headers and a proper User-Agent.
Direct fetching from a.basemaps.cartocdn.com was returning
stripped/missing CORS headers in the user's browser, blocking
the img.src load. Even with cache-busters the failure persisted.
Solution: local nginx proxy at /carto/ that forwards to the
upstream and always adds Access-Control-Allow-Origin: *.
Key detail: the 'resolver' directive is required inside the
proxy_pass location block so nginx can resolve the upstream
hostname. Without it, the location block silently fails (the
'/' location falls through to try_files ... =404, and the
~*\.(png|jpg)$ regex also matches and silently fails for GETs).
Also added 'location ^~ /carto/' to give prefix matching strict
priority over the .png regex match that was stealing the request.
JS now uses /carto/voyager/ (relative URL through the same
origin) so CORS preflight is not even needed.
User's browser showed 404 and CORS errors for Carto tiles
even though curl shows the URLs return 200 with CORS headers.
Most likely the browser had cached earlier failed attempts.
Added a per-tile cache-buster (?v=Date.now()+random) to the
fetch URL so every tile request bypasses the browser's HTTP
cache. Removed the diagnostic console.log lines since the
issue is identified (browser cache).
User wants tiles with place names (Stadt-/Strassennamen) for
orientation while flying. ESRI World Imagery is satellite (no
labels); OSM rejects browser requests without a proper User-Agent
header (which browsers cannot set for img.src).
Carto basemaps is the right alternative:
- Free, no API key required
- CORS enabled (works directly in browser via img.src)
- OSM-derived data, so it has all the same place names
- URL format: {z}/{x}/{y}.png (x before y, unlike ESRI's {z}/{y}/{x})
Voyager style chosen for good legibility of place names and
streets. Other Carto styles (light_all, dry_lite, etc.) are also
available; just change the URL path.
Swapped tileX/tileY in the fetch URL to match Carto's {x}/{y}
order (ESRI used {y}/{x}).
Attribution: (c) OpenStreetMap contributors (c) CARTO.
User feedback: text on the left edge ('left' align) was getting
cut off because the text extended to negative X (off the left
edge of the canvas). Same problem on the right.
Fix: swap the textAlign so each side's text extends INTO the tile,
not OFF the edge:
- Left-side labels (S, N) now use textAlign 'right'. Anchor at
the left edge of the tile area; the text's right edge is at
the anchor and it extends rightward into the tile.
- Right-side labels (y, x) use textAlign 'left'. Anchor at the
right edge; the text's left edge is at the anchor and extends
leftward into the tile.
Mirror (scale -1, 1) is still applied so the text content is
flipped.
Each label is now drawn inside a save/translate/scale(-1, 1)/
restore context, so the actual text appears horizontally
mirrored in the canvas. This is the user-requested 'NS
axis mirror' for the labels.
N/S characters are symmetric so they look the same mirrored
or not. But 'x=1100' and 'y=1100' now appear reversed (1011 etc.),
confirming the horizontal flip is in effect.
User wants:
- Border around each tile so they can see where one ends
- Labels in the four corners, NS-mirrored (so N is at the
bottom and S at the top, matching the tile's own NS axis)
- Labels burned in to the canvas so they always show the tile
identity during flight (not just a live overlay)
Implementation:
- Thin dark border (rgba(0,0,0,0.55), 2px) via strokeRect just
inside the tile bounds
- S at top-left, N at bottom-left (NS mirrored) in large bold
text with white fill + black stroke for contrast
- y=NNN at top-right, x=NNN at bottom-right in smaller monospace
- All labels drawn directly on the canvas before texImage2D
upload, so they're part of the texture the shader samples
User wants only the O/W arrangement mirrored (image X-flip
stays as it was). The drawing formula for canvasX now uses
(-perp + halfPerp + 0.5) instead of (perp + halfPerp + 0.5),
so tiles with perp<0 (world east, dx>0) land at large canvasX
(right side of canvas). Y axis (forward direction in N flight)
stays unchanged.
User wants the tile texture mirrored across the NS axis only
(no 180 rotation). drawImage with width=-TILE, height=+TILE
flips only the X axis:
- Image top (north) stays at canvas top
- Image bottom (south) stays at canvas bottom
- Image left (west) -> canvas right
- Image right (east) -> canvas left
Labels N/S moved to match the new (un-Y-flipped) orientation:
N at canvas top, S at canvas bottom. The tile arrangement in
the corridor is unchanged.
User wants the O/W axis mirrored within each tile. With
the previous Y-only flip, East was still on the right and West
on the left. Adding an X-flip makes it 180° rotation:
- Image North -> canvas bottom, South -> canvas top
- Image East -> canvas left, West -> canvas right
Labels N/S were already positioned at canvas bottom/top to match
the Y-flipped image, so they stay where they are. Tile arrangement
in the corridor is unchanged (still controlled by canvasX/canvasY
formulas with no swap on either axis).
User feedback: the corridor arrangement is correct (lng=+12
at screen top in N flight), but the per-tile image and labels
were upside down relative to expectations.
- Image drawing: changed from 180° rotation (-TILE, -TILE on
both axes) to Y-only flip (TILE, -TILE on Y). Image top
(north) now lands at canvas bottom; image bottom (south) at
canvas top. X axis is preserved so image east is still on the
right within each tile.
- N/S labels: swapped so N is at canvas bottom (= image north)
and S at canvas top (= image south).
The per-frame redraw caused texImage2D upload of 8MB every frame,
which the browser couldn't keep up with -> tiles disappeared.
Reverted to refetch-based updates but with two key changes:
- Corridor 25 -> 50 tiles long (~6 min of flight at uSpeed=1
before refetch)
- Tiles redraw with fractional camera position, so the corridor
tracks the camera smoothly within the loaded content
The 50-tile corridor covers enough flight time that refetches
happen rarely (~6 min), but the camera's continuous position
is still reflected in the mosaic's center. So between refetches
the visible content scrolls smoothly.
Replaced refetch-based updates with continuous per-frame redraw.
The corridor now tracks the camera's continuous world position
(floating point, not floored to a tile) so the tile content
scrolls smoothly underneath the camera. No more 'jump by 1 tile'
at every refetch boundary.
Tradeoff: every frame draws ~65 images and does one texImage2D
upload. Browser caches the Image elements, so the cost is mainly
compositing + upload (~5MB at 6400x1280). Should still hit 30+ fps.
This is closer to how real flight sims work: the world content
scrolls continuously, not in tile-size jumps.
drawImage(img, canvasX + TILE, canvasY + TILE, -TILE, -TILE)
flips the image both horizontally and vertically, so:
- Image north (high lat) ends up at canvas bottom (was top)
- Image south (low lat) ends up at canvas top
- Image east (high lon) ends up at canvas right
- Image west (low lon) ends up at canvas left
Combined with NO canvasY swap and the WebGL flip:
- North tiles drawn at canvas bottom -> after WebGL flip, still
at screen bottom. Screen bottom has image north = high y. So
y at screen bottom = high.
- Looking forward (close ground = screen bottom in cockpit) =
high y. y increases in flight direction.
With NO canvasX swap:
- East tiles (high x) drawn at canvas left
- Image east at canvas right within each tile (high x)
- Image west at canvas left within each tile (low x)
So at screen left: east tiles with image x increasing left to
right (low to high within tile). At screen right: west tiles with
image x decreasing left to right. Overall: x at screen right (west
tiles, low x label) lower than at screen left (east tiles, high x
label). x decreases left to right.
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.
Richard Zink