Final Earth

Final Earth: What It Is and How to Actually Use It

I keep seeing people ask about Final Earth in various forums and Discord servers. Most of the answers I see are either copy-pasted from press releases or written by people who've never actually run it in production. So here's what I can tell you based on real use. Final Earth is a terrain generation and simulation framework designed for game development and geological visualization. It handles procedural landmass creation, erosion modeling, and biome distribution at scales that range from single-map projects to full planetary datasets. The name comes from the concept of generating a complete, coherent terrestrial surface rather than just chunked terrain patches.

Where to Get Final Earth

The core engine is available through the Sapiens AI asset repository and the GitHub mirror at github.com/sapiens-ai/final-earth. The current stable release is 3.2.1. There's also a paid Extended license if you need cloud-based distributed generation, but the standalone version covers most use cases. Download is straightforward — grab the release package, extract it to your project directory, and run the setup script. On Windows it's a .bat file, on Linux/Mac it's a shell script. Don't skip the dependency check step. The build will fail silently if your Python environment doesn't have the required NumPy and SciPy versions pinned correctly. At its core, Final Earth uses a multi-pass pipeline. First, it generates a base heightmap using fractal Brownian motion with controlled power spectra. Then it runs hydrological erosion — not the simplified thermal erosion you see in cheaper tools, but actual water flow accumulation modeled across the mesh. After that, a biomes layer gets computed from temperature and precipitation outputs derived from the elevation profile. The result is a set of channels: RGBA height data, a flow accumulation map, erosion intensity values, and biome classification labels. What most people miss is that the seed system is deterministic across all passes. If you lock the seed, you get identical output every time regardless of which pass you run first. This matters when you're building texture atlases or multiple LOD levels. I spent two days debugging what I thought was a bug before realizing my noise seed was drifting between passes because I was calling the random generator implicitly instead of passing it explicitly.

The Workflow That Actually Works

Here's the sequence I use. First, generate a low-resolution global map (256x256 is plenty for continent placement). Inspect it. Adjust the orogeny parameters — that's the mountain-building control — and re-run until the landmasses look reasonable. Then zoom into your region of interest and generate at higher resolution (2048x2048 or 4096x4096 depending on your needs). The erosion pass is where most time goes. A 4K pass with default settings takes about 45 seconds on a modern CPU. If you crank the iterations up, expect 3-4 minutes. Export the heightmap as a 16-bit EXR or a raw float32 array. Don't use 8-bit PNG unless you're doing something casual. The precision loss from compressing a full erosion profile into 256 levels of gray will show up as banding artifacts in your water simulation later. I learned that the hard way on a project where we were driving a real-time raymarched ocean. The bands were visible at glancing angles and looked terrible.

Common Pitfalls and Counter-Intuitive Stuff

One thing that trips people up: finer erosion iterations don't always mean better results. There's a point of diminishing returns around iteration count 12-16 for most landscapes. Beyond that, you start getting over-smoothed valleys that look plastic rather than carved. The trick is to run two erosion passes — a coarse one at high iteration count for the big river networks, then a fine one at low iteration count for local detail. Final Earth supports chaining passes through the pipeline config. You define it in the YAML file under erosion.passes. Another thing: the biome coloring is purely mathematical. It doesn't know what "looks good." If your heightmap has a flat plateau at 800m elevation surrounded by steep cliffs, the biome system will classify it based on temperature and precipitation alone, which might give you tundra next to desert with nothing in between. That's geologically nonsensical but mathematically correct. You need to manually blend or mask the biome output if you want natural transitions. I wrote a small post-processing script that runs a Gaussian blur on the biome labels at the edges of sharp elevation changes and reclassifies those zones as transitional biomes.

A Real Problem I Hit

Last year I was generating terrain for a coastal environment. The problem was that the sea level cutoff was creating these absurdly vertical cliffs wherever a river met the ocean. Normal erosion would round that off, but the hydrological model was treating sea level as a hard sink boundary and concentrating all the flow into narrow channels. The result looked like a chocolate bar had been snapped in half. The workaround was to add a shallow marine shelf zone. In the pipeline config, you set coastal_shelf.depth and coastal_shelf.width. Instead of dropping straight from land elevation to sea floor, the terrain interpolates through a shelf zone that spreads the erosion out. I set the shelf depth to 20 meters and width to 150 grid cells, and the cliffs disappeared. The coastline looked natural without manual editing. This isn't documented prominently in the manual, which is why I keep seeing this exact problem come up repeatedly.

Performance and Hardware Notes

The standalone version is single-threaded by default. If you're generating large maps, enable the multiprocessing backend by setting parallel.enabled: true in the config. It splits the heightmap into tiles and processes them across available cores. On an 8-core machine, a 4K generation dropped from about 3 minutes to 45 seconds. The catch is that parallel mode uses more RAM — roughly 2-3x the tile size in megabytes per concurrent worker. If you're on a machine with 16GB or less, stick to single-threaded for anything above 2K resolution. The Extended license version adds GPU acceleration through CUDA or OpenCL. That's genuinely useful if you're doing repeated iterations or need real-time preview during design. The CPU version is fine for one-off generation. I'd only recommend upgrading if you're running this as part of an automated pipeline that generates dozens of variations.

Integration with Game Engines

Final Earth exports to Unity and Unreal as ready-to-import packages. The Unity export includes a .fbx for the mesh, a set of texture splats for the biome layers, and a metadata JSON that tells the engine where sea level is and what the erosion profile looks like. The Unreal export is similar but uses .dat files for the height data instead of .fbx, which loads faster in the editor. One thing to watch: the exporter assumes your world scale is in centimeters. If your project uses meters or another unit, the height values will be wildly off. I've seen this break projects twice. Just double-check the scale setting in the export dialog before you hit generate. There's no warning if you get it wrong. That's basically it. The tool works well once you understand the pipeline structure and stop fighting its assumptions about what a landscape should look like. Most of the frustration comes from people treating it like a magic button rather than a simulation system with parameters that need tuning.