SVS: Photorealistic terrain texture via satellite imagery tiles

[billmallard]

Overview

The current SVS renderer draws terrain using solid color fills (green/brown by elevation band). Photorealistic SVS — like NightHawk Guardian, Garmin G3X Touch, and X-Plane — drapes aerial/satellite imagery as a texture over the terrain elevation mesh, producing near-photographic ground detail.

How It Works

The core technique is identical to what pyEfis SVS already does for terrain geometry: triangulate an elevation mesh from SRTM data, then render it via GPU. The visual upgrade replaces solid fill colors with satellite imagery texture-mapped onto that same mesh.

Elevation data: unchanged — SRTM (already in use).

Imagery layer: standard XYZ/TMS raster tiles at zoom ~14–15 (2–4 m/px for CONUS), fetched from a tile provider and applied as OpenGL textures.

Candidate Data Sources

Source	Cost	Resolution	Licensing
Mapbox Satellite	Free ≤ 50k tiles/mo	~0.5 m CONUS	Attribution required; compatible with OSS
USGS National Map (TNM)	Free, public domain	1 m lidar CONUS	Best free option for US
NASA GIBS / Worldview	Free, public domain	250 m – 15 m	Lower res but no strings
Bing Maps Aerial	Pay-per-use (free tier)	~0.3 m CONUS	Used by Garmin / ForeFlight
Google Photorealistic 3D Tiles	Pay-per-use	Sub-meter + 3D buildings	Requires Google Maps Platform key + Cesium SDK

Recommended starting point: Mapbox Satellite — standard XYZ tile URL, free tier is ample for flight use, attribution-compatible with GPL.

Implementation Sketch

1. Tile fetch module: given a lat/lon bounding box and zoom level, compute the XYZ tile coordinates, download PNGs (with caching to disk), and stitch into a texture atlas.
2. UV mapping: for each terrain mesh vertex, compute the corresponding texture coordinate from its geographic position.
3. Renderer integration: bind the texture atlas in the OpenGL render pass; replace the elevation-band color shader with a texture lookup.
4. Cache management: pre-fetch tiles for the visible area on startup / position change; evict old tiles to bound disk usage.

The elevation mesh geometry work is already done in the SVS renderer — this is purely an additive texture layer.

Priority / Complexity

• Priority: Low — current SVS is functional and useful without this.
• Complexity: Medium — requires OpenGL texture management and a tile-fetch/cache subsystem.
• Dependencies: Mapbox account (free tier), requests or httpx for tile fetch.

Related

• Upstream SVS renderer PR (in progress on svs-renderer branch of billmallard/pyEfis)
• Color Theme for Display #25 – Add hooks for autopilot and flight director #31 (pending SVS enhancements: pitch ladder z-order, obstacle DB, runway DB, terrain tile gaps, water mask)

[billmallard]

Hardware & Architecture Note

Hardware bar is lower than expected

A Raspberry Pi 4 (VideoCore VI, OpenGL ES 3.1) can render a textured 3D terrain mesh at typical EFIS resolutions (800×480, 1024×600) at 15–30 fps. RPi 5 is meaningfully faster. An EFIS SVS showing terrain ahead of the aircraft is a far simpler scene than flight-sim scenery — the hardware is not the bottleneck.

The real constraint: software architecture

The current SVS renderer uses QPainter — Qt's 2D software renderer, CPU-based. Adding per-pixel texture mapping to a CPU software renderer would be very slow on RPi. The proper path is migrating the SVS render pass to QOpenGLWidget, which is a significant but well-defined refactor.

Middle path (no OpenGL required): pre-composite satellite imagery with terrain geometry offline (similar to how FAA chart tiles are pre-tiled), then display via the existing QPainter pipeline. Simpler to implement, slower to update on position change.

What commercial EFIS units run on

Products like NightHawk Guardian target experimental/LSA builders and almost certainly run on embedded x86 (Intel Atom/Celeron class with integrated GPU, full OpenGL 3.3). That's why they can afford a full GPU pipeline.

Feasibility by target hardware

Hardware	Photorealistic SVS
RPi 4 / RPi 5	Feasible with QOpenGLWidget refactor; not viable with QPainter alone
x86 NUC / Atom SBC	Straightforward — full OpenGL available
RPi Zero / Zero 2W	Not realistic
Laptop / desktop	Trivial

Conclusion: this is a medium-complexity software architecture task, not a hardware limitation for any reasonable modern EFIS build target.

[e100]

If we can display the terrain and the runways, I think this should replace virtualVFR, not be some new feature.

The tiles are likely too large to distribute as snaps like I did with faa-cifp-data.
If having other FAA data sets included in the fss-cifp-data snap would be useful let me know and I can try to make that happen.

[billmallard]

I was wrestling with just this issue today. Virtual VFR runs a different projection model than what I started synthetic vision with. It’s a more computationally intensive approach with virtual VFR. Synthetic vision is using flat earth. Also the  issue you commented on is the photorealistic progression. There’s no way this happens without GPU based hardware.  Much to discuss. Sent from my iPhoneOn May 2, 2026, at 4:21 PM, Eric Blevins ***@***.***> wrote:e100 left a comment (makerplane/pyEfis#266) If we can display the terrain and the runways, I think this should replace virtualVFR, not be some new feature. The tiles are likely too large to distribute as snaps like I did with faa-cifp-data. If having other FAA data sets included in the fss-cifp-data snap would be useful let me know and I can try to make that happen. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: ***@***.***>