A Catalogue of Alien Worlds

Abstract

More than four thousand planetary systems beyond the Sun have been confirmed, and none have ever been seen. The observational record of an exoplanet is a handful of numbers, a period, a radius or a minimum mass, an orbital distance, the temperature and size of its star, and the public encounters that record either as a table or as an artist's impression whose relationship to the data is undisclosed.

This paper describes a web interface to the Open Exoplanet Catalogue that takes a third route: every one of the catalogue's 4,081 systems is rendered as an explorable three-dimensional scene, with each planet's appearance derived from its recorded physical parameters through an explicit classification pipeline and a procedural shader, rather than painted by hand. The system comprises three surfaces, a curated catalogue of featured systems, a per-system orbital viewer with Keplerian propagation, and a galactic star map of every catalogued system positioned by right ascension, declination and distance, over a build-time pipeline that converts the catalogue's XML into JSON and a bake pipeline that pre-renders thumbnails with the same shaders used live.

Two threads of engineering carry the account. The first is scale: the viewer holds a star, planets a hundredth of its size, and orbits at seventy-nine thousand scene units within 32-bit GPU arithmetic, which calls for relative-to-eye orbit rendering with split-precision camera arithmetic. The second is derivation: star colour is computed from effective temperature as blackbody colour rather than assigned by class, and the star map places the whole catalogue by its own archival astrometry at one parsec per scene unit. Planet appearance is the subject of the companion paper on procedural rendering; a third companion paper situates the system within the wider landscape of exoplanet visualisation. No user study has yet been run; the evaluation section specifies one.

1. Introduction

The first planet found orbiting a Sun-like star was announced in 1995 (Mayor & Queloz 1995); three decades later the confirmed count is in the thousands, and grows weekly. Yet the exoplanet is a peculiar object of public fascination: it is almost always invisible. Nearly every known exoplanet was detected indirectly, as a periodic dimming of its star's light or a periodic wobble in its star's spectrum, and even the few dozen imaged directly appear as unresolved points of light (Marois et al. 2008). There is no photograph of an exoplanet's surface, and there will be none for the foreseeable future.

What exists instead is a catalogue: for each system, a set of measured and inferred quantities, with uncertainties, maintained in public databases (Akeson et al. 2013; Schneider et al. 2011; Rein 2012). The catalogue is open, machine-readable, and hard to see. A table of periods and radii does not communicate that TRAPPIST-1's seven worlds huddle closer to their star than Mercury does to the Sun, or that a hot Jupiter's year lasts four days, or what it means for a planet to be tidally locked. The gap this project addresses is between the availability of the data and its legibility as a set of places.

The system described here renders the entire Open Exoplanet Catalogue, 4,081 system records vendored as XML and synchronised weekly with the upstream repository, as an interactive site: a catalogue page of featured systems, a three-dimensional viewer for any system, and a star map of the whole catalogue. Its central design commitment, developed at length in the companion paper Plausible Worlds from Sparse Parameters, is that a planet's rendered appearance is a deterministic function of its recorded parameters: a classification pipeline assigns each planet one of sixteen physically motivated types, and a procedural shader renders that type. Nothing is hand-painted, and nothing is random between visits.

Contributions

The underlying technologies, a React application, a WebGL scene graph, procedural noise shaders, are established practice and are not claimed as contributions. The contributions are the application and the engineering record.

1. A worked, whole-catalogue application of parameter-derived rendering. Not a curated dozen showpieces but every system in the catalogue, including the sparse majority for which only two or three parameters are recorded, with documented fallbacks for every missing quantity. The derivation extends beyond the planets: star colour is computed from temperature, and system positions from archival astrometry.
2. Precision rendering at catalogue scale. The viewer holds bodies from 0.08 to thousands of scene units across orbits up to ~10⁵ units in 32-bit GPU arithmetic, using relative-to-eye orbit rendering with high/low float splitting, periapsis clearance for close-in planets, and unit disambiguation for binary separations.
3. A reproducible bake pipeline, in which the same GLSL shaders that render planets live also pre-render the catalogue's thumbnails through a headless browser, so that the still and the interactive views cannot drift apart.
4. A whole-catalogue star map from archival astrometry: right ascension, declination and distance parsed at build time into a Cartesian index and drawn as a single point cloud at true parsec scale, with the zodiac constellations projected through the same transform for orientation.

2. Background: what the catalogue contains

2.1 The Open Exoplanet Catalogue

The Open Exoplanet Catalogue (OEC) is a community-maintained, decentralised database of exoplanet discoveries, stored as one XML file per system under version control (Rein 2012). It was chosen over the institutional alternatives (the NASA Exoplanet Archive, exoplanet.eu) for two properties that suit a self-contained web application: the entire catalogue is a directory of files that can be vendored into the repository, and its hierarchical schema represents multiple-star systems natively. A <binary> element contains stars, planets, or further binaries, so a hierarchical triple like 16 Cygni, two stars in a close pair with a third carrying the planet, is a tree, not a footnote.

The trade-off is currency. Community maintenance has slowed relative to the institutional archives, and the vendored copy's 4,081 system files should be read as the OEC's coverage, not the field's: the NASA Exoplanet Archive's confirmed-planet count is substantially higher. The repository syncs with upstream weekly (a scheduled job, Mondays 06:00 UTC), so the gap is upstream, not local. The figures the site shows are the catalogue's.

2.2 The anatomy of a system record

A system record contains, at most: a name and aliases; right ascension, declination, and distance (parsecs, with error bounds); for each star, mass, radius, effective temperature, spectral type, metallicity, magnitudes, and age; for each planet, mass (sometimes only m sin i), radius, period, semi-major axis, eccentricity, inclination, periastron, discovery method and year, and a prose description. Binary systems add separations (in arcseconds and/or AU) and position angles.

The operative phrase is at most. The catalogue's sparsity is structural, not incidental: transit surveys yield radii but often no mass; radial-velocity detections yield minimum masses but no radius; many entries record little more than a period and a host star. Every downstream stage of the system, classification, scaling, orbit propagation, therefore begins from the premise that any field may be absent, and the fallback chain for each quantity is part of the design (Section 3.5, and the companion paper §3).

3. The system

3.1 Design principles

Five tenets served as tiebreakers throughout.

1. Derive, don't decorate. A planet's look must be a function of its data. The same record renders the same world on every visit (appearance is seeded deterministically); a different record renders a different world. The same rule covers the stars (colour from temperature, §3.5) and the map (position from astrometry, §3.6).
2. Legibility over literal scale. Bodies are enlarged relative to their orbits, close orbits are kept clear of the star's surface, and time is compressed, while the relative quantities within a system, orbital rates, size orderings, positions on the sky, are preserved.
3. The catalogue is the interface. Browse views, featured cards, and the star map all resolve to the same underlying records; there is no separate "content" layer that could drift from the data.
4. Live and baked must agree. Pre-rendered imagery is produced by the same shaders as the interactive scene, through the bake pipeline, so a thumbnail is a genuine still of the world the viewer will show.
5. Dark, editorial, quiet. The visual register is a black-background editorial catalogue, closer to a printed atlas than to an application, so that the procedural worlds, not the chrome, carry the interest.

3.2 Architecture and stack

The application is a server-rendered React Router site with a three.js scene graph mounted per route.

Three routes carry the experience: the catalogue index (/), the system viewer (/system/:filename), and the star map (/galaxy). A fourth route (/planet-bake) exists only as the bake pipeline's render target.

3.3 The data pipeline

A prebuild script (scripts/prebuild-data.js) runs before every build and converts the 4,081 XML files once, so that no XML is parsed at request time.

• Per-system JSON. Each system file is parsed (xml2js, attributes discarded) and written to data-json/<name>.json. The system viewer's loader reads this JSON from disk (or, client-side, over HTTP); a missing file is a 404, not a crash.
• The galaxy index. For every system with usable coordinates, the script extracts right ascension, declination and distance, converts them to radians and parsecs, and projects to Cartesian coordinates (§3.6). Each index record carries name, filename, position, distance, and planet count. Systems without coordinates are skipped and counted; the script reports parsed, skipped and indexed totals on every run.

The generated data-json/ directory is gitignored and rebuilt per checkout; the vendored XML is the only checked-in data artefact.

3.4 The catalogue surface

The index page presents a masthead, a stats strip, and a grid of systems. Twenty-one systems are editorially selected (catalogueSystems.ts): TRAPPIST-1, Proxima Centauri, 51 Pegasi, Kepler-442, HR 8799, 55 Cancri, the Solar System as reference, and others, each with a blurb, a featured planet, tags drawn from a fixed eight-tag vocabulary (habitable zone, rocky, gas giant, historic, nearest, exotic, multi-planet), and a seed. The cards are curated pointers: each links into the same system-viewer route as any search result, so curation adds narrative without forking the data path. Card imagery comes from the bake pipeline (§3.7).

The masthead behind the title is not an image but a live shader planet at 1300 × 1300 render resolution, cycling through nine representative types on a six-second interval, draggable with inertia. It is the first statement of the project's thesis: the artwork is the data pipeline running.

3.5 The system viewer

The viewer renders one system as a navigable scene: star (or star hierarchy), planets on animated orbits, habitable-zone annulus, orbit lines, nebula and Milky Way skybox, under cinematic post-processing.

Scale model

One astronomical unit maps to 2,000 scene units; one solar radius is then 9.30 units and one Jupiter radius 0.926 (the physical ratios, 1 AU = 215.032 R☉ and 1 R☉ = 10.045 R_Jup, are kept in code as named constants). Bodies are additionally scaled by a user-adjustable bodyScale (default ×3), since at true scale a planet at catalogue distances is subpixel; orbits keep their true relative proportions.

Keplerian propagation

Each planet's position is computed per frame from first principles: mean anomaly advances as (elapsed/period) scaled by a global time-compression factor, plus a phase offset (the recorded periastron where present, else a deterministic name-hash so that co-orbital planets do not stack); Kepler's equation M = E − e sin E is solved by Newton–Raphson (at most 30 iterations, tolerance 10⁻⁸, seeded at E = π for e > 0.8, following standard practice; Danby 1988, Colwell 1993); true anomaly and radius follow, and near-circular orbits (e < 10⁻⁶) short-circuit to the trigonometric case. Because every planet advances by elapsed/period, relative orbital rates within a system are correct even though absolute time is compressed.

Periapsis clearance

Because bodies are scaled and orbits are not, a close-in planet's rendered orbit can fall inside its star's rendered surface (WASP-12 b, at 0.023 AU around a swollen star, is the canonical case, and rendered literally it reads as an error rather than as the genuinely remarkable fact that hot Jupiters skim their stars). The viewer therefore enforces clearance: if periapsis a(1 − e) falls below the star's scene radius plus 1.6× the planet's, the semi-major axis is pushed out to clear it, and the catalogue values continue to drive everything else.

Stars from temperature

A star's whole appearance derives from two catalogue numbers, effective temperature and radius. Colour is blackbody colour, computed with chroma-js's temperature scale rather than assigned by spectral class: the point light that illuminates the system takes the blackbody value directly, and the surface shader's tint is derived from the ratio of the blue to red channels of that same blackbody colour, clamped to a working range, so that M dwarfs render deep orange, the Sun sits near the middle of the scale, and O stars run blue-white, continuously rather than in class steps. The corona and flare sprites reuse the same scale at reduced temperatures (rays at 0.85×, flares at 0.75×), so the star's fringe reads cooler than its disc. The surface itself is three rotating layers of four-dimensional simplex noise at five octaves, animated in time for granulation. Where the catalogue records only a spectral type, a lookup supplies the temperature (M 3,000 K through O 40,000 K), and the recorded visual magnitude sets the scene light's intensity within a clamped range.

Binaries

The OEC's hierarchical <binary> trees are rendered recursively: each binary node splits into two children (stars, planets, or nested binaries) placed on opposite sides of the barycentre with mass-weighted offsets and the recorded position angle. One data hazard is disambiguated explicitly. The catalogue may record separation twice, in arcseconds and in AU, and naive parsing takes the arcsecond value first, an error of three orders of magnitude; the loader takes the maximum of the numeric candidates, on the grounds that the AU figure is always the larger. Separations are further clamped to a maximum scene offset, because float32 matrix arithmetic degrades visibly beyond ~10⁶ units.

Orbit lines at distance: relative-to-eye rendering

The most instructive numerical problem was the outermost orbits. At Pluto-scale distances (~79,000 scene units) a float32 vertex position has a granularity of roughly 0.005 units, and the standard modelView transform subtracts two nearly equal large numbers (vertex − camera), so orbit lines visibly jittered and breathed as the camera moved. The fix is the relative-to-eye technique from virtual-globe rendering (Cozzi & Ring 2011): each orbit vertex is split at build time into a high part (the float32-rounded value, via Math.fround) and a low part (the residual), stored as two attributes; the camera position, transformed into the orbit's local frame each frame, is split the same way; and the vertex shader computes (pos_high − cam_high) + (pos_low − cam_low), in which the large high parts cancel exactly and the residuals carry the precision. The modelView's translation component is discarded (only its rotation is applied), so no large translation ever enters the GPU pipeline. Orbit lines additionally fade out as the camera approaches a planet, ramping over 5–20 % of the semi-major axis, so that the line never slices through a close-up view. Segment counts adapt to circumference (256–8,192).

Controls and locks

Camera control (drei CameraControls) enforces a minimum approach distance of 1.15× a selected body's rendered radius, so that one cannot dolly inside a star, and a follow mode re-targets the camera each frame without damping, because damped following visibly lags a fast hot-Jupiter. Tidally locked planets (as flagged by the classification) do not rotate; their cloud layers are slaved to surface rotation at 1.15× (super-rotation), so that clouds on a locked world correctly stand still with it rather than counter-rotating.

The habitable zone, per star

The annulus is derived in two steps from the stellar record. Luminosity comes from Stefan–Boltzmann, L/L☉ = (R/R☉)²·(T/5778 K)⁴, when temperature and radius are recorded, and from a mass–luminosity power law otherwise, with the exponent chosen by spectral type (≈5.5 for M dwarfs falling to ≈3.5 for the hottest classes). The zone's edges then follow from the effective-flux formulation of Kopparapu et al. (2013): the runaway-greenhouse and maximum-greenhouse boundaries are quartic polynomials in the star's temperature offset from the Sun's, and each boundary distance is D = √(L/S_eff) AU. The polynomials are the interesting part. A naive habitable zone just rescales the Sun's by luminosity; Kopparapu's flux thresholds themselves move with stellar temperature, because a planet responds to the spectrum and not only the wattage: redder light is absorbed more efficiently by water vapour and reflected less by ice, so the zone around an M dwarf sits at measurably lower flux than the Sun's. Around TRAPPIST-1 the entire zone lies within a twentieth of an astronomical unit.

The same derivation serves two consumers: this annulus, and the classification pipeline's positioning of temperate worlds within the zone (companion paper, §2.3), so the ring the viewer draws and the palette a temperate planet receives cannot disagree. The render is an additive, double-sided, soft-edged ring, its geometry padded 30 % beyond the computed bounds for the fade, tilted to the mean inclination of the system's planets, off by default and toggled from the toolbar.

3.6 The star map

The /galaxy route is the catalogue drawn as a place: every indexed system positioned where it actually is, at one parsec per scene unit, with Sol at the origin.

The positions are computed at build time from the catalogue's own archival astrometry. Right ascension is recorded in hours, minutes and seconds and converts at fifteen degrees per hour; declination in signed degrees, minutes and seconds; both reduce to radians and, with the distance in parsecs, project to Cartesian coordinates: x = d·cos δ·cos α, y = d·cos δ·sin α, z = d·sin δ. Systems missing any of the three values are skipped and counted, and each surviving record carries name, filename, position, distance and planet count into a single galaxy index that the route loads whole.

Rendering four thousand systems is then one draw call. Positions and colours are packed into two Float32Arrays and drawn as a single THREE.Points cloud, with the catalogue's z-up remapped to the renderer's y-up. At one parsec per unit the whole known exoplanet population sits within a few thousand units of the origin, comfortably inside float32, so the map needs none of the split-precision machinery of §3.5. An equatorial reference grid draws concentric rings at 200 to 1,000 parsecs with radial spokes every 30°, and the twelve zodiac constellations are projected through the same transform, the familiar two-dimensional sky embedded in the true three-dimensional distribution, which is what gives a newcomer their bearings. Hover and selection surface each system's name, distance and planet count, and click-through opens the system viewer: the map and the viewer are two projections of the same records.

Drawn this way, properties of the real population become legible that no table conveys: the Kepler field prints as a dense cone on one side of the sky, the survey's fixed stare made visible, and the population thins with distance because detection does, not because planets do, the geometric bias the companion survey paper discusses.

3.7 The bake pipeline

Thumbnails are not exported art; they are captured output. A Node script launches headless Chromium (Playwright), starts the site on a local port, navigates to the dedicated /planet-bake route for each of the 21 curated slugs, which classifies the featured planet from its real catalogue record and renders it with the production shaders, and screenshots a 512-pixel PNG per system into public/planet-thumbs/. Because bake and live share one shader and one classification, a change to either regenerates both looks with a single command. (The pipeline exists because the live shader at full quality is too costly to run two dozen times on a catalogue page; the masthead runs exactly one live instance.)

4. Related work

Interactive astronomy visualisation

NASA's Eyes on Exoplanets renders the known exoplanet population as navigable 3D, from institutionally curated data; OpenSpace (Bock et al. 2020) and Gaia Sky (Sagristà et al. 2019) target planetarium-grade contextualisation of astronomical catalogues, with the Gaia star catalogue as the paradigm case; Celestia and Stellarium are the long-standing open-source ancestors. This project differs in two commitments: the appearance layer is parameter-derived per planet, rather than a stock texture per class, and the whole pipeline, data, classification, shaders and bake, is a single small open codebase intended to be read. The comparative landscape is the subject of the third companion paper.

Procedural planets

Procedural planetary surfaces have a deep graphics lineage (Perlin 1985; Musgrave et al. 1989; Ebert et al. 2003) and a contemporary commercial one (Space Engine; No Man's Sky). The distinction here is the grounding: procedural technique is subordinated to a documented classification of real catalogue records. That layer is the subject of the companion paper, which carries the related work on noise and shading.

Precision rendering at planetary scale

The high/low float splitting used for orbit lines is standard in virtual-globe engines (Cozzi & Ring 2011), where Earth-sized coordinates exceed float32; the contribution here is its application to orbit polylines in a catalogue viewer, together with clamped binary offsets at extreme separations. A full floating-origin refactor is on the roadmap.

Data infrastructure

The OEC's design rationale is given by Rein (2012); the institutional archives by Akeson et al. (2013) and Schneider et al. (2011). The prebuild-to-JSON pattern follows ordinary static-site practice and claims no novelty.

5. Evaluation

No empirical results are reported; this section specifies the evaluation the system is designed to support.

Performance

Frame-time distributions (median, p95) across a stratified sample of systems: single-star single-planet, high-multiplicity (TRAPPIST-1, Kepler-90), hierarchical binaries (16 Cygni), and extreme-scale orbits, on reference hardware tiers, with and without post-processing; together with time-to-first-frame for the viewer route and bake-pipeline wall time.

Numerical fidelity

Orbit-line stability quantified as screen-space vertex displacement across camera dollies at fixed logical positions, RTE on against RTE off; propagation accuracy against a reference double-precision ephemeris over 10³ orbits (drift in phase); and an exhaustive count of the catalogue cases where clearance rules (periapsis, binary separation) adjust rendered geometry.

Classification audit

Since the appearance layer's validity rests on the classification, a sample of catalogue planets with published characterisation (confirmed hot Jupiters, the TRAPPIST-1 planets, known super-puffs) should be checked against assigned types by a domain reviewer, with disagreement rates reported per branch of the decision tree. This audit is specified in detail in the companion paper.

Readers

A task-based study with non-specialist readers, locate a system, state which of two planets is hotter and why, judge whether an orbit's speed difference is meaningful, against the same tasks on a tabular interface, measuring accuracy and self-reported understanding, with explicit probes for the misconception risks the companion papers identify as the central hazard of the genre: do participants believe they saw photographs? do they report the continents as known?

6. Limitations

Stats derivation

The stats strip's headline figure labelled "confirmed" is the live system-file count (4,081), while the "systems" (4,231), habitable-zone (62) and earth-like (147) figures are literals; deriving all four from the index at build time is scheduled work.

Orbital orientation is partial

Only inclination is applied to an orbit's plane, as a single tilt of π/90 per recorded degree (twice the physical angle); longitude of the ascending node and argument of periapsis are not represented in 3D, and periapsis enters only as a phase offset. Rendered orbital orientation is illustrative rather than to scale.

The viewer is an interpretive diagram, not a simulation

Bodies ×3 (adjustable), orbits at true relative proportion, periapses cleared of the stellar surface, binary separations capped at 20,000 units, time compressed by a global factor. Within-system comparisons (rates, orderings, ratios) are preserved; absolute measurements are not recoverable from the screen.

One catalogue, ageing

Coverage and currency are bounded by the OEC. Systems confirmed since the community catalogue's maintenance slowed are absent, and no cross-check against the NASA archive is performed. Weekly sync guarantees freshness against upstream only.

Sparse-data planets render with equal confidence

A planet known only by period and m sin i renders as vividly as TRAPPIST-1 e. The classification pipeline's fallback chain (companion paper §3) covers the derivation, but the interface does not yet surface per-planet data completeness; a "what is this picture based on?" affordance remains roadmap.

No moons; controversial entries included

Satellites in the catalogue are not rendered. Planets flagged Controversial upstream are rendered without a visual distinction.

No user study has been run

All claims about legibility are design rationale, not measured outcomes (Section 5).

7. Conclusion

This paper has described a system that renders an entire public exoplanet catalogue as explorable places: a data pipeline from vendored XML, a classification-driven appearance layer, a Keplerian viewer engineered for float32 at catalogue scale, stars whose colour is computed from their recorded temperature, and a star map built from the archive's own astrometry. The design generalises beyond astronomy: derive rather than decorate, and let the record be the single source of every rendered property, from a planet's cloud cover to a star's hue to a system's position on the sky.

What the interface cannot settle is how much of what it shows is known. That question, where measurement ends and plausible fiction begins in a rendered exoplanet, is the subject of the companion paper Plausible Worlds from Sparse Parameters; and what such interfaces can achieve for public understanding, against the wider landscape from artist's impressions to planetarium software, is the subject of the third, From Data Point to Destination.

Acknowledgements

This project exists because the Open Exoplanet Catalogue's maintainers chose openness and decentralisation (Rein 2012), and because the three.js, react-three-fiber and wider WebGL communities made planetary-scale rendering in the browser a practical undertaking. The Milky Way skybox derives from NASA imagery. The classification stands on the exoplanet characterisation literature cited in the companion paper.

References

Exoplanet data infrastructure

• Rein, H. (2012). A proposal for community driven and decentralized astronomical databases and the Open Exoplanet Catalogue. arXiv:1211.7121.
• Akeson, R. L., et al. (2013). The NASA Exoplanet Archive: Data and Tools for Exoplanet Research. PASP 125, 989.
• Schneider, J., Dedieu, C., Le Sidaner, P., Savalle, R., & Zolotukhin, I. (2011). Defining and cataloging exoplanets: the exoplanet.eu database. A&A 532, A79.

Discoveries and characterisation

• Mayor, M., & Queloz, D. (1995). A Jupiter-mass companion to a solar-type star. Nature 378, 355–359.
• Marois, C., et al. (2008). Direct Imaging of Multiple Planets Orbiting the Star HR 8799. Science 322, 1348–1352.
• Gillon, M., et al. (2017). Seven temperate terrestrial planets around the nearby ultracool dwarf star TRAPPIST-1. Nature 542, 456–460.
• Kopparapu, R. K., et al. (2013). Habitable Zones around Main-sequence Stars: New Estimates. ApJ 765, 131.

Orbital mechanics and numerics

• Danby, J. M. A. (1988). Fundamentals of Celestial Mechanics, 2nd ed. Willmann-Bell.
• Colwell, P. (1993). Solving Kepler's Equation Over Three Centuries. Willmann-Bell.
• Cozzi, P., & Ring, K. (2011). 3D Engine Design for Virtual Globes. CRC Press. (Relative-to-eye rendering; high/low floating-point splitting.)

Visualisation systems

• Bock, A., et al. (2020). OpenSpace: A System for Astrographics. IEEE Transactions on Visualization and Computer Graphics 26(1), 633–642.
• Sagristà, A., Jordan, S., Müller, T., & Sadlo, F. (2019). Gaia Sky: Navigating the Gaia Catalog. IEEE TVCG 25(1), 1070–1079.
• NASA/JPL-Caltech. Eyes on Exoplanets. https://eyes.nasa.gov/apps/exo/

Procedural graphics (fuller list in the companion paper)

• Perlin, K. (1985). An Image Synthesizer. SIGGRAPH '85, 287–296.
• Musgrave, F. K., Kolb, C. E., & Mace, R. S. (1989). The synthesis and rendering of eroded fractal terrains. SIGGRAPH '89, 41–50.
• Ebert, D. S., Musgrave, F. K., Peachey, D., Perlin, K., & Worley, S. (2003). Texturing & Modeling: A Procedural Approach, 3rd ed. Morgan Kaufmann.

Appendix: System at a glance