TerraKit terrain generator

The problem

Building a believable terrain for a real-time engine usually means either hand-sculpting it or wrestling a raw elevation model into shape, then hand-authoring the erosion, the texturing and the planting on top. It is slow, and the result rarely holds up as real terrain: the hydrology is painted on rather than computed.

What we built

TerraKit turns a sentence — optionally a survey DEM and a few site photos — into a finished terrain. A planner reads the prompt, a fact sheet computed from the terrain, and evidence from the photos, then authors every parameter: erosion, stream threshold, snowline, paint rules, a species table, settlement style. With no DEM it writes a landform spec and synthesises the heightfield itself, then runs the same real hydrology, erosion and vegetation as the survey path.

How it was engineered

A deterministic Python core does the work — ingest to any coordinate system, analytics, priority-flood hydrology with Strahler ordering and HAND, hydrology-consistent super-resolution, a rule-based paint language and variable-radius vegetation scatter — and writes a self-contained terrain package. The Unity add-on imports that package and keeps the look editable at runtime: paint mix, snowline, wetness, vegetation density and water level are compute shaders over shipped analytics maps, so a sentence like "thin out the trees and raise the water" changes the hillside without a rebuild. The model never touches a raster.

Verified

The core has 79 offline tests covering coordinate conventions, hydrology invariants, super-resolution, the rule language and byte-identical rebuilds. The Unity side runs EditMode tests against a synthetic sample: heightmap orientation and georeference check out, and GPU paint matches the CPU bake to a mean weight difference of about 0.01 across seven layers. Honest about resolution — the manifest records source resolution and synthesis strength, so nobody plans around a gully the upsampler invented.