What works, what fails, and what is missing
Overview
Open a browser. Navigate to a website. A mountain appears — not as a photograph, not as a painting, but as something you can touch. Drag your finger across the trackpad and the mountain rotates. Scroll and it zooms. Click and a label appears: the name of a peak, the elevation of a pass, the date of a first ascent. This is an interactive mountain web experience: a browser-based application that lets you explore mountain terrain through gesture and response, through the continuous loop of human input and computed output that we call interactivity.
The spectrum is wide. At the utilitarian end sits Google Maps in terrain mode — a tool for getting directions that happens to render topography. You use it to plan a drive; the mountains are incidental. Nearby sit specialised terrain tools: Swisstopo’s 3D viewer, which lets you fly over Switzerland’s mountains with the precision and visual care inherited from two centuries of Swiss cartographic tradition; Peakfinder, which identifies mountain summits from any viewpoint on Earth; Fatmap (now absorbed into Strava), which rendered 3D terrain for trail runners and ski tourers. These are instruments. They do their jobs well. They are not trying to move you.
At the other end of the spectrum — sparsely populated, poorly mapped — lie experiences that aspire to something beyond utility. A scrollytelling piece in the New York Times that uses 3D terrain to tell the story of a glacier’s retreat. A data artist’s experiment that paints elevation data with custom shaders, turning a mountain range into a luminous abstraction. A researcher’s prototype that drapes historical photographs onto a terrain model, so you can see how the Matterhorn looked in 1865 and how it looks now, the glacier retreating like a tide going out. These are rare, and most of them are imperfect, but they gesture toward something important: the possibility that an interactive mountain experience could be not just a tool for looking at terrain but a genuine encounter with place.
The technology stack behind all of this rests on a single foundation: WebGL, the browser’s interface to the graphics processing unit (GPU — the chip in your computer designed for rendering images very fast). WebGL arrived in browsers around 2011, and it changed everything. Before WebGL, rendering 3D terrain in a browser required plugins — Flash, Java applets, dedicated software. After WebGL, the browser itself became a 3D rendering engine. Three.js, a JavaScript library that wraps WebGL in a friendlier interface, made it accessible to developers who were not graphics programmers. Mapbox GL JS provided a complete map rendering pipeline with terrain support. Cesium offered a virtual globe with time-dynamic data. Deck.gl, from Uber’s visualisation team, added high-performance data overlays. Custom GLSL shaders — small programs that run directly on the GPU, colouring each pixel according to mathematical rules — gave designers per-pixel control over the visual output.
The current state: most interactive mountain web experiences fall into one of two categories. They are either utilitarian tools (maps, route planners, peak identifiers) that happen to render terrain, or they are technology demonstrations — “look what WebGL can do” — that dazzle for thirty seconds and then leave you with nothing. The space between these poles — where a mountain web experience might achieve the emotional weight of a painting, the narrative coherence of a film, or the immersive presence of standing on a ridge at dawn — is almost entirely vacant. This is the space that himalaya-darshan must occupy, and the purpose of this report is to map the territory so that it can be occupied with knowledge rather than naivety.
Note on method: this report is written from training knowledge. Web resources were not consulted in real time. URLs in the final sections are provided from known-good sources but should be verified before use, as web addresses change and projects are sometimes retired.
Origins and evolution
The story begins with flat maps on screens. MapQuest launched in 1996; Google Maps followed in 2005. Both showed terrain as a flat image — a raster tile, pre-rendered on a server, delivered to your browser as a JPEG or PNG. You could pan and zoom, but the mountain was always flat. The terrain view in Google Maps added hill-shading, but it was painted onto the tile before it reached you: a picture of shadows, not shadows cast in real time. You were looking at a photograph of a relief model, not at a relief model.
The first genuine 3D terrain in the browser required plugins. Google Earth launched as a desktop application in 2005, then migrated to a browser plugin, and finally — in 2017 — to a fully web-based application running on WebGL. That migration is the key date. When Google Earth ran in a browser without a plugin, it proved that real-time 3D terrain rendering at planetary scale was possible in a standard web page. The technology was mature enough. Everything that followed is a consequence of that proof.
Between the flat-map era and the WebGL era, several innovations laid the groundwork. Mapbox, founded in 2010, built an open-source map rendering stack that gave designers unprecedented control over map appearance. Their style specification — a JSON document that describes how every feature on a map should be drawn — meant that for the first time, a designer could change the colour of mountains, the weight of contour lines, the typography of peak labels, without being a cartographer or a programmer. Mapbox GL JS, released in 2015, moved this rendering to the GPU and added terrain extrusion, turning flat maps into 3D landscapes.
Cesium, originally developed at Analytical Graphics Inc. around 2011-2012, took a different approach: a virtual globe, like Google Earth, but open-source and designed for time-dynamic geospatial data. Cesium renders the entire planet in 3D, streams terrain tiles on demand, and supports overlays of satellite imagery, 3D buildings, and temporal datasets. It is the tool of choice for scientific visualisation — tracking satellites, visualising climate data, simulating flight paths — and its terrain rendering is technically excellent, if visually austere.
Three.js, created by Ricardo Cabello (known as Mr.doob) and released in 2010, democratised WebGL itself. It provided a scene graph, a camera system, lights, materials, and geometry primitives — all the apparatus of 3D graphics — in a JavaScript library that a web developer could learn in weeks rather than years. Three.js is not a mapping library. It knows nothing about latitude, longitude, or map projections. But it gives you complete control over every polygon, every pixel, every frame. The most visually inventive mountain web experiences — the ones that break away from the cartographic default — are almost always built on three.js or raw WebGL, because only there do you have the freedom to treat terrain as a sculptural and painterly medium rather than a geographic dataset.
The scrollytelling revolution arrived in parallel. The New York Times published “Snow Fall: The Avalanche at Tunnel Creek” in 2012 — a long-form article about an avalanche in the Cascades that integrated text, photographs, video, maps, and animated graphics into a single scrolling narrative. It won a Pulitzer Prize and launched a genre. The Washington Post, the Guardian, Bloomberg, and Reuters all followed with their own scrollytelling pieces, many of them about landscapes, climate, and terrain. The best of these — the Times’s pieces on glacier retreat, the Post’s climate visualisations — demonstrated that the browser could be a storytelling medium as powerful as film, with the added dimension of reader agency. You scroll at your own pace. You pause where you are interested. The narrative unfolds in response to your attention.
The current frontier is photogrammetry in the browser — reconstructing real-world geometry from photographs using structure-from-motion algorithms, then rendering the resulting 3D models in WebGL. This allows terrain that is not derived from satellite radar (which gives you 30-metre resolution at best) but from drone photography (which can give you centimetre resolution). A few experimental projects have demonstrated photogrammetric mountain terrain in the browser — individual peaks or cliff faces rendered at extraordinary detail. Real-time weather integration (draping live cloud cover, snow depth, or wind data onto terrain models) is another active frontier. And machine learning is beginning to enhance terrain data — super-resolving coarse elevation models, generating realistic rock textures from sparse data, predicting snow cover from satellite imagery.
Colour
Begin with what most interactive mountain experiences actually look like, and the honest answer is: not good. The default appearance of a 3D terrain viewer is satellite imagery draped onto an elevation mesh. This means that the visual surface of the mountain is a patchwork of satellite photographs — taken on different days, in different seasons, under different atmospheric conditions, by different sensors — stitched together and projected onto triangulated geometry. The result has a characteristic ugliness that anyone who has used Google Earth will recognise: abrupt colour shifts at tile boundaries (one tile captured in summer green, the adjacent in autumn brown), cloud shadows baked permanently into the terrain (a dark smear across a valley that is not a forest but a cumulus shadow frozen in time), snow that appears and disappears as you zoom across tiles from different dates, and a general haziness that comes from atmospheric scatter in the original photographs. It is photorealistic in the worst sense — it reproduces reality’s visual noise without any of reality’s visual coherence.
This is the default, and most interactive mountain experiences never move beyond it. They drape satellite tiles on terrain and call it done. The result is the visual equivalent of a synthesiser set to its factory preset — recognisably a piano, technically functional, but lifeless.
The alternative approaches are more interesting. Mapbox pioneered vector-styled terrain: instead of draping photographs, you paint the terrain according to rules. Elevation determines colour — lowlands green, mid-altitudes brown, high peaks white — but the palette is designed, not photographed. The designer chooses the exact green, the exact brown, the curve of the transition. The result is an abstraction, like a well-designed map, and it inherits the legibility and aesthetic coherence of the cartographic tradition. Swisstopo’s web viewer takes this further: its colour palette descends from Eduard Imhof’s hand-painted relief maps, in which every tonal value was chosen with a painter’s care. The digital Swisstopo viewer does not look like a satellite photograph. It looks like a painting — because, in a real sense, it is one, the product of a colour tradition refined over more than a century.
Custom shader approaches offer the most creative freedom. A shader is a small program that runs on the GPU and determines the colour of each pixel on screen. A terrain shader can compute colour from elevation (hypsometric tinting), from slope (steep rock faces in grey, gentle meadows in green), from aspect (south-facing slopes warmer, north-facing cooler — reproducing the real asymmetry of vegetation in mountain landscapes), or from any combination of these. The designer is painting the mountain with data, and the palette is entirely under their control. The Shadertoy community has produced extraordinary procedural mountain renderings — terrain generated and coloured entirely by mathematical functions, with no satellite data at all — that achieve a strange, luminous beauty precisely because they are unconstrained by the noise of real-world photography.
The problem of time and season is largely unsolved. Most terrain viewers show a single frozen moment — whatever the satellite happened to capture. A few projects have experimented with seasonal variation (cycling through satellite imagery from different months) or time-of-day lighting (moving the virtual sun across the sky to cast realistic shadows), but these remain rare. Night mode — rendering terrain in darkness, with village lights or moonlight — is almost never attempted, despite the obvious atmospheric potential.
What himalaya-darshan should learn from all of this: colour must be designed, not defaulted. The Western Himalaya has a particular palette — the grey-blue of Ladakhi rock, the ochre-gold of autumn willows along the Indus, the impossible turquoise of glacial meltwater, the deep green-black of deodar forests on north-facing slopes, the white that is not one white but twenty whites (fresh snow, old snow, glacial ice, limestone cliff, cloud). A satellite tile will not capture this. It will give you a muddy composite that looks like every other mountain range on Earth. The colour must be composed, as a painter composes — chosen, tested, adjusted, layered — until it speaks specifically of this place and no other.
Composition and spatial logic
How do you move through a mountain that exists inside a screen? This is the fundamental compositional question of interactive terrain, and the answer determines everything about the experience.
The simplest approach is the free camera: the user controls position, direction, tilt, and zoom with mouse or trackpad, and can fly anywhere — over the summit, down into the valley, along a ridge, underneath the terrain if the software permits it. This is what Google Earth offers, and it is powerful. You can go anywhere. The problem is that you go nowhere in particular. Free-camera navigation of mountain terrain is inherently disorienting. Without a path, without a narrative, without a reason to look here rather than there, the user flails — zooming in until the terrain mesh is visible as individual triangles, zooming out until the mountain is a bump on the globe, rotating until they lose their sense of direction entirely. Freedom without structure is not liberation. It is bewilderment.
Guided camera solves this by controlling the path and letting the user control the pace. This is the scrollytelling model: as you scroll down the page, the camera moves along a predetermined trajectory — rising from the valley floor, cresting a ridge, descending into a cirque. The story unfolds with the movement. Text appears at key moments. Data overlays fade in and out. The user has agency (they control the speed; they can scroll back) but the experience has shape. The best scrollytelling terrain pieces — the New York Times’s glacier stories, some of the Mapbox studio examples — demonstrate that this model can achieve genuine narrative power. The mountain is not just shown; it is told.
Fixed viewpoints are the simplest and sometimes the most effective approach: a curated set of perspectives, like paintings hung in a gallery. Click a button and you see the mountain from the south. Click another and you see it from the northeast, in morning light. Each viewpoint is composed — the designer chose the camera position, the field of view, the angle of tilt, as carefully as a photographer chooses where to stand and which lens to use. This approach sacrifices the thrill of exploration but gains compositional control. Every frame is intentional.
The problem of scale haunts all interactive terrain. Mountains are enormous, but on a screen they look small — and worse, they look flat. The vertical relief of even the most dramatic peak is tiny relative to its horizontal extent. Nanga Parbat’s Rupal Face, the highest rock wall on Earth, rises 4,600 metres — but it spans roughly 12 kilometres horizontally. On screen, without vertical exaggeration, it is a gentle slope. Most terrain viewers apply vertical exaggeration — multiplying elevation values by 1.5 or 2.0 — to make mountains look like mountains. But exaggeration distorts: ridges become knife-edges, valleys become canyons, gentle hillsides become cliffs. The terrain looks dramatic but false. A few sophisticated viewers allow the user to adjust exaggeration interactively, finding their own balance between truth and drama. This is a good solution but an incomplete one. The real answer may be not to exaggerate the geometry but to use atmospheric and lighting effects — fog in the valleys, warm light on the summits, aerial perspective fading distant ranges to blue — to convey depth and height without distorting shape. This is what painters have always done. Shan-shui painting does not exaggerate the vertical; it uses mist to separate near and far, and ink density to convey mass.
Level of detail (LOD) is the technical mechanism that creates visual hierarchy in interactive terrain. Close to the camera, the terrain mesh is dense — many small triangles, fine texture, sharp detail. Far from the camera, the mesh is coarse — few large triangles, blurred texture, simplified form. The transition between levels, if handled poorly, produces visible “popping” — distant terrain suddenly sharpening as you zoom in, like a photograph coming into focus. If handled well, the LOD transition is imperceptible, and the effect is a natural sense of depth: sharp foreground, soft background, the digital equivalent of the aerial perspective that has been a tool of landscape painters since Leonardo.
Fog and atmosphere deserve special attention. In reality, mountain landscapes are defined as much by what you cannot see as by what you can. Mist fills valleys. Haze softens distant ranges. Cloud wraps summits. The greatest shan-shui painters understood this — their use of empty silk to represent mist is the most powerful compositional device in the tradition. In interactive terrain, atmospheric effects are technically straightforward (a simple depth-based fog shader can do it) but aesthetically neglected. Most terrain viewers render clear-sky conditions by default, showing every ridge and valley with uniform clarity. The result is visually flat — paradoxically, showing everything makes nothing stand out. A few projects have experimented with volumetric fog, cloud layers, and atmospheric scattering, and the results are immediately more compelling. The mountain emerges from the mist. The valley disappears into it. Depth becomes palpable.
Pattern and geometry
The geometry of a digital mountain is, at its foundation, a mesh of triangles. The elevation data — typically from radar missions like SRTM or optical satellites like ASTER — arrives as a grid of numbers: one elevation value for each cell in a regular grid, spaced at 30 metres, or 90 metres, or 12.5 metres depending on the dataset. This grid is converted into a mesh of triangles (two triangles per grid cell, forming a surface), and the triangles are sent to the GPU for rendering. This is a regular grid, and it has the virtue of simplicity and the vice of uniformity: the same triangle density on a featureless plateau as on a jagged arrete, the same resolution in a flat valley as on a vertical cliff.
More sophisticated approaches use triangulated irregular networks (TIN) or adaptive meshes that concentrate triangles where the terrain is complex and spread them thin where it is simple. The visual result is subtler than you might expect: the mesh itself is usually invisible (it is covered by texture and lighting), but its resolution determines what the terrain can show. On a 90-metre mesh, individual rock faces, moraines, and stream channels are invisible — the mountain is a smooth approximation, like a clay model viewed from across a room. On a 12.5-metre mesh, these features begin to emerge. On a photogrammetric mesh derived from drone imagery, individual boulders are visible. The resolution of the mesh determines what patterns are possible.
Contour lines, when overlaid on a 3D terrain view, connect the interactive experience to the cartographic tradition. A thin brown line tracing a path of constant elevation across the textured surface is immediately legible to anyone who has read a topographic map, and it adds information that the terrain surface alone does not convey: the precise elevation, the exact shape of the slope, the relationship between one contour interval and the next. A few terrain viewers — notably Swisstopo — overlay contour lines on their 3D terrain, and the effect is beautiful: the lines drape over the mountain surface like threads laid on a sculpture, revealing its form with graphic precision.
Satellite and aerial imagery, when draped as texture on the terrain mesh, reveals pattern at every scale. Zoom out and you see the continental-scale drainage pattern — the great rivers of the Himalaya gathering their tributaries into dendritic fans, the rain shadow visible as a colour boundary between green and brown. Zoom in and you see individual fields, forest clearings, the braided channels of glacial rivers. The act of zooming is itself a revelation of pattern: the same mountain presents different visual structures at different scales, and the interactive medium — which allows seamless, continuous zooming — makes this multi-scale patterning experientially available in a way that no fixed image can.
Procedural texturing — generating surface detail from algorithms rather than photographs — is an underexplored frontier. A shader can compute snow cover from elevation and slope (snow accumulates on gentle slopes above the snowline), rock texture from aspect and steepness (steep south-facing rock in grey-brown, weathered north-facing rock in darker tones), vegetation from elevation and rainfall (forest below the treeline, alpine meadow above, bare rock above that). The result is not photorealistic but it is legible, consistent, and designable — the creator controls the rules, and the rules produce pattern that is both geographically plausible and aesthetically intentional. The Shadertoy community has pushed this to remarkable levels of sophistication, generating entire mountain landscapes from pure mathematics — and the patterns that emerge (fractal ridgelines, dendritic erosion channels, stratified rock layers) are visually rich precisely because they derive from the same physical processes that shape real mountains.
Local legends and iconography
Here is the greatest failure of interactive mountain web experiences, and it is nearly universal: they have no cultural layer. The mountain is terrain. It is geometry and texture and elevation data. It is latitude and longitude. It is not a place where anyone lives, prays, grazes yaks, tells stories, buries the dead, or fears the gods.
Most interactive terrain viewers treat the mountain as a natural object — a formation of rock and ice to be measured, visualised, and navigated. Place names, where they appear, are labels imported from a geographic database: “Nanga Parbat, 8126m.” The name floats above the peak like a museum label. There is no indication that Nanga Parbat means “Naked Mountain” in the languages of the region, or that the peak is called Diamir (“King of the Mountains”) by the people who live at its feet, or that the Rupal valley below it is populated by communities whose relationship with the mountain is structured by centuries of reverence, fear, and economic dependence.
The exceptions are few and mostly peripheral. Some mapping projects overlay cultural heritage points — temples, archaeological sites, historical routes — as clickable markers on terrain. Community mapping initiatives, particularly those supported by organisations like the Humanitarian OpenStreetMap Team, have documented indigenous place names and culturally significant sites. The Aga Khan Trust for Culture has produced digital documentation of cultural landscapes in the Hunza valley and elsewhere. But these remain data overlays on an otherwise cultureless terrain — pins on a map, not integrated cultural experiences.
What is missing — and what himalaya-darshan has the opportunity to build — is a mountain web experience that integrates cultural content not as an overlay but as a structural principle. Consider what a traditional Pahari miniature painting does with a mountain landscape: the peaks are not just terrain but the abode of Shiva. The river is not just hydrology but the goddess Ganga. The forest is not just vegetation but the domain of specific spirits. The path is not just a route but a pilgrim’s journey, marked by shrines, regulated by seasonal calendars, narrated by local tradition. The painting does not separate “terrain” from “culture” — the terrain is cultural, through and through.
An interactive experience could do this. Imagine flying over a 3D terrain model of the Pir Panjal range and seeing, not just satellite imagery, but a layer of sacred geography: the devi’s peak marked not with a database label but with iconography drawn from the local tradition; the naga’s spring rendered with the turquoise glow that local belief attributes to it; the pilgrim’s path traced as an animated line that follows the actual route, with halting points and resting shrines marked. Imagine scrolling through a guided narrative that tells the mountain’s story not in the language of geomorphology (“this peak was formed by the collision of the Indian and Eurasian plates”) but in the language of the people who live there (“this is where the devi struck the rock and water flowed”).
No existing interactive mountain experience does this. Not because the technology is insufficient — the technology is more than adequate — but because the designers are, overwhelmingly, technologists rather than storytellers, geographers rather than humanists, engineers rather than artists. They build what they know how to measure. The mountain’s sacred geography, its narrative strata, its lived meaning — these require a different kind of knowledge and a different kind of design. This is the territory that himalaya-darshan can claim: not just terrain but territory, not just geography but meaning.
Key works and where to see them
What follows are specific interactive mountain web experiences, described in enough detail to be useful even if the URLs have changed by the time you read this. Verify all links before relying on them.
Swisstopo 3D Viewer (map.geo.admin.ch) — The Swiss Federal Office of Topography’s web-based 3D terrain viewer. This is the gold standard for cartographic quality in interactive terrain. The colour palette, the contour line rendering, the hill-shading, the typography — all inherit two centuries of Swiss cartographic tradition. The terrain data is high-resolution. The viewer allows free navigation but also provides curated viewpoints. Limitation: it covers only Switzerland. Strength: it demonstrates what is possible when cartographic design, not satellite photography, drives the visual output.
Google Earth Web (earth.google.com) — The planetary-scale 3D terrain viewer, now running entirely in the browser. Technically impressive: it streams terrain tiles and satellite imagery for the entire planet, with seamless transitions from space to street level. Culturally and aesthetically, it is neutral to the point of blankness — a tool for looking, not an experience of seeing. The Voyager feature offers guided narratives (curated tours of specific regions or themes), and some of these achieve genuine storytelling quality. The terrain is draped with default satellite imagery, with all the patchwork-quilt problems described above.
Peakfinder (peakfinder.com) — A web and mobile application that renders a panoramic mountain view from any point on Earth, identifying every visible summit. The rendering is deliberately stylised: the terrain is drawn in a single colour (configurable), with peak names and elevations labelled. It looks like a pen drawing, not a photograph, and this abstraction is its strength. You see the structure of the mountain landscape — ridge, valley, summit, pass — without the visual noise of satellite imagery. A model for how restraint can produce clarity.
Fatmap / Strava 3D — Fatmap was a dedicated 3D terrain platform for outdoor sports (skiing, trail running, climbing), acquired by Strava in 2022. Its terrain rendering was exceptionally good: high-resolution, with slope-angle shading (terrain coloured by steepness, a tool used in avalanche assessment) and curated route overlays. Its integration into Strava has changed its form, but the core idea — terrain rendered for a specific community of practice, with data overlays that serve that community’s needs — remains instructive.
The New York Times “Glacier” pieces — The Times has published several scrollytelling pieces about glaciers and mountain terrain, including work on retreating Alpine glaciers and Himalayan ice loss. These use a combination of Mapbox GL terrain, custom 3D rendering, and photographic overlays to guide the reader through a narrative about landscape change. The camera moves in response to scrolling; data fades in and out; the text and the terrain work together. These are among the best examples of terrain-as-narrative in the browser.
The Washington Post climate visualisations — Similarly, the Post has published interactive pieces on sea-level rise, wildfire terrain, and mountain snowpack that use 3D terrain rendering as a storytelling medium. Their engineering team has built custom WebGL renderers for some of these, and the results demonstrate that terrain visualisation can be journalism, not just cartography.
Cesium demo applications (cesium.com/platform/cesiumjs) — Cesium’s showcase demos demonstrate the platform’s capabilities: global terrain with 3D building models, time-dynamic satellite tracking, terrain analysis tools. The visual style is functional rather than beautiful — Cesium is an engineering platform, not a design tool — but the technical capabilities (terrain streaming, temporal data, massive point cloud rendering) are unmatched.
The Glaciers of Switzerland (glamos.ch or related ETH Zurich projects) — Research-grade visualisations of Swiss glacier change over time, sometimes presented as interactive web experiences with terrain models showing glacier extent at different dates. These demonstrate how terrain can be a medium for communicating scientific data about mountain change.
Mapbox terrain demos (docs.mapbox.com) — Mapbox’s documentation includes numerous terrain visualisation examples that demonstrate the capabilities of their GL JS platform: custom colour ramps, hillshade layers, sky rendering, fog effects, and 3D terrain extrusion. These are technical demos, not finished experiences, but they show what the toolkit can do and serve as a starting point for custom work.
Relief Shading examples (reliefshading.com) — A web resource dedicated to the art and technique of terrain representation, maintained by practitioners in the cartographic community. While not itself an interactive 3D experience, it catalogues techniques of terrain visualisation that are directly relevant to anyone designing an interactive mountain experience.
Further exploration
The following resources, annotated for a reader new to the field, provide entry points into the technical, artistic, and conceptual landscape of interactive terrain on the web.
Mapbox GL JS documentation and examples (docs.mapbox.com/mapbox-gl-js) — The most accessible entry point for building custom interactive terrain in the browser. The documentation is well-written, the examples are numerous, and the platform handles the hard problems (tile streaming, map projections, GPU rendering) so the designer can focus on visual and narrative decisions. Start with the terrain examples and the style specification.
Three.js documentation and examples (threejs.org) — If Mapbox is the cartographer’s tool, three.js is the sculptor’s. It gives you complete control over 3D geometry, lighting, materials, and camera, but asks you to build your own terrain pipeline. The examples gallery includes several terrain-related demos. For himalaya-darshan, three.js (or a framework built on it, like React Three Fiber) may be the right choice if the goal is an experience that breaks away from the map paradigm.
Cesium documentation (cesium.com/learn) — The reference for planetary-scale terrain and geospatial data in the browser. Cesium is heavier and more complex than Mapbox or three.js, but it handles global terrain, 3D tiles, and time-dynamic data natively. Appropriate if himalaya-darshan needs to show terrain at multiple scales or integrate large geospatial datasets.
The Book of Shaders (thebookofshaders.com) by Patricio Gonzalez Vivo — A free, interactive introduction to GLSL fragment shaders: the small GPU programs that determine the colour of each pixel on screen. Essential reading for anyone who wants to move beyond default satellite imagery and design custom terrain colouring. The chapter on noise functions is directly relevant to procedural mountain texture generation.
Shadertoy (shadertoy.com) — A community platform for sharing GLSL shaders. Search for “terrain” or “mountain” to find hundreds of procedural mountain renderers — landscapes generated entirely from mathematical functions, with no satellite data at all. These are not practical tools but they are extraordinary demonstrations of what per-pixel terrain colouring can achieve. The work of Inigo Quilez (iq) on procedural terrain is particularly instructive.
Observable notebooks on terrain visualisation (observablehq.com) — Observable is a web-based notebook platform for data visualisation, and its community has produced numerous terrain-related notebooks: elevation data rendering, contour line generation, hillshade computation, terrain colour ramps. These are interactive, editable, and well-documented — an excellent way to learn the fundamentals of terrain visualisation in the browser.
Shaded Relief (shadedrelief.com) by Tom Patterson — A website dedicated to the art and science of terrain representation, maintained by a former cartographer at the US National Park Service. Patterson’s work on natural-colour terrain maps is some of the finest in the field, and the site includes tutorials, data, and examples. Essential for understanding how the cartographic tradition informs digital terrain rendering.
Terrain Party (terrain.party) — A simple web tool for extracting real-world heightmap data for any location on Earth, formatted for use in 3D applications. Useful as a source of elevation data for prototyping interactive terrain experiences. The interface itself is an example of how a utilitarian terrain tool can be well-designed.
Deck.gl terrain layer documentation (deck.gl) — Deck.gl is a WebGL-powered framework for large-scale data visualisation, originally developed by Uber. Its terrain layer supports elevation-aware rendering of geospatial data, and the documentation includes examples of 3D terrain with data overlays. Appropriate if himalaya-darshan needs to combine terrain with large datasets (weather, population, land use).
“Terrain Rendering in Games” resources — While focused on game engines rather than web browsers, the game development community’s work on terrain rendering is technically ahead of the web community’s. Resources on terrain LOD, procedural texture splatting, atmospheric scattering, and vegetation rendering in Unity and Unreal Engine contain ideas that can be adapted for WebGL. The GDC (Game Developers Conference) archives and the GPU Gems series are starting points.