Landschaftsgenerierung mit dynamischem LOD und Streaming für offene Welten im Browser

Heightmaps mit Perlin Noise sind der Standard-Ausgangspunkt für prozedurales Terrain. Ein paar fBm-Oktaven schichten, einen Farbverlauf drüber, und schon hast du etwas, das terrainartig aussieht. Genau hier endet jedes Tutorial. Aber echte Landschaften sehen nicht wie gestapeltes Rauschen aus. Sie haben Flusstäler, die vom Wasser geschnitten wurden, Felswände, die von Spannungsbrüchen geformt sind, Höhlen und Bögen, die über Millionen Jahre durch Erosion entstanden. Sie haben korrelierte Texturen (Gras auf flachem Boden, Fels an steilen Hängen, Schnee über der Baumgrenze), die aus denselben physikalischen Prozessen hervorgehen, die die Geometrie geformt haben.

Dieser Leitfaden behandelt, was nach dem Rauschen kommt. Physikalisch fundierte Generierungsverfahren, volumetrische Repräsentationen, die Höhlen und Überhänge abbilden, diffusionsbasierte neuronale Terrainsynthese und die GPU-getriebenen LOD- und Streaming-Pipelines, die nötig sind, um das alles in einem Browser-Tab mit 60 fps zu rendern.

Alles hier zielt auf unsere konkrete Randbedingung: eine offene Multiplayer-Welt in WebGL 2 und WebGPU, über das Netz gestreamt, von Creators bearbeitbar.

Warum Heightmaps nicht ausreichen

Eine Heightmap speichert einen Höhenwert pro Gitterpunkt. Sie ist eine 2D-Funktion: gegeben (x, z), liefere y. Diese Repräsentation ist kompakt, GPU-freundlich und schnell zu rendern. Sie hat aber grundlegende Grenzen, die für eine Creator-Welt zählen.

Keine Höhlen oder Überhänge. Eine Heightmap kann kein Terrain abbilden, in dem ein Punkt zwei verschiedene Höhen hat. Höhlen, Bögen, Felsüberhänge, Tunnel und fliegende Inseln sind alle unmöglich. Minecraft, No Man's Sky und Deep Rock Galactic brauchen genau deshalb volumetrisches Terrain.

Keine vertikalen Merkmale. Eine senkrechte Felswand ist in einer Heightmap eine nahezu unendliche Steigung, was extreme Texturdehnung und Kollisionsartefakte erzeugt. Echte Klippen haben horizontale Merkmale wie Vorsprünge und Spalten, die eine Heightmap nicht abbilden kann.

Rauschen sieht wie Rauschen aus. Selbst mit 8 fBm-Oktaven und Domain Warping bleibt dem Terrain etwas Synthetisches. Es fehlt die gerichtete Struktur echter Geologie: Gratlinien, Entwässerungsnetze, Sedimentablagerungen, tektonische Falten. Diese Muster entstehen aus physikalischen Prozessen, nicht aus Noise-Funktionen.

Creator-Bearbeitung ist begrenzt. Können Creator nur Höhen verändern, können sie keine Tunnel graben, keine Höhlen anlegen und keine unterirdischen Räume bauen. Für eine Welt, die Creator wirklich formen können, muss die Terrain-Repräsentation Subtraktion genauso unterstützen wie Addition.

Die Lösung ist nicht, Heightmaps ganz aufzugeben. Sie bleiben die beste Repräsentation für die 90 % Terrain, die eine einfache Oberfläche sind. Die Lösung ist ein hybrider Ansatz: Heightmap-Basisterrain mit volumetrischen Auflagen dort, wo komplexe Geometrie nötig ist, physikalisch korrekte Generierung für realistische Landformen und neuronale Synthese für die Vielfalt, die Rauschen nicht erreicht.

Die kurze Antwort: was wir tatsächlich bauen würden

Vor dem Tiefgang hier der Entscheidungsrahmen. Der Rest des Artikels erklärt jedes Teil.

Terrain-Repräsentation

Nutz ein hybrides System aus Heightmap plus SDF. Die Heightmap deckt die ganze Welt ab (günstig, kompakt, erprobt). SDF-Volumen existieren nur dort, wo Höhlen, Überhänge oder von Creators geschnitzte Merkmale sie verlangen (vielleicht 5 bis 10 % der Chunks). So bleiben 90 % der Welt auf Heightmap-Kosten, während beliebige Geometrie dort möglich ist, wo sie gebraucht wird.

Generierungs-Pipeline

Läuft serverseitig als verkettetes Verfahren:

1. Terrain Diffusion (oder MESA für Text-Prompts) erzeugt aus einem Seed die Basis-Heightmap. Das ersetzt Rauschen durch geologisch realistische Landformen, trainiert auf echten Höhendaten.
2. Analytische Erosion (Stream Power Law) verfeinert die Heightmap in Millisekunden mit Flussnetzen und Gratlinien.
3. TerraFusion oder Geodiffussr erzeugt aus der Heightmap korrelierte Texturen (oder du nimmst prozedurale Regeln nach Neigung und Höhe für den WebGL-2-Rückfall).
4. Ökosystem-Simulation liefert Dichtekarten für Vegetation.
5. Erosion im Arenite-Stil erzeugt SDF-Volumen für Felswände, Bögen und Höhlen, wo das Terrain sie verlangt.
6. Chunken, komprimieren, ins CDN hochladen. Durchschnittlicher Chunk: 2 bis 8 KB. Komplexer Chunk mit volumetrischen Daten: 20 bis 100 KB.

Creator greifen in diese Pipeline ein, indem sie Parameter anpassen ("feuchter", "gebirgiger", "Höhlen ergänzen"), ihre Absicht skizzieren oder direkt mit Pinseln und SDF-Werkzeugen modellieren.

LOD-Strategie

Browser-Fähigkeit	Heightmap-LOD	Volumetrisches LOD	Vegetations-LOD
WebGPU	GPU-getriebener Quadtree (CDLOD) mit Compute-Culling und Indirect Draw	Multiresolution-SDF mit Marching Cubes im Compute plus Transvoxel	ComputeInstanceCulling mit Indirect Draw
WebGL 2	Geometry Clipmaps mit Ring-Aktualisierung auf der CPU	Vorab erzeugte Meshes in 2 bis 3 LOD-Stufen, gecacht	Frustum-Culling auf der CPU, InstancedMesh

Beide Wege nutzen Geomorphing im Vertex-Shader für Übergänge ohne Ploppen. Beide nutzen Billboard-Impostoren für ferne Vegetation. Der WebGPU-Weg ist schneller (3,5 ms Terrain-Budget), der WebGL-2-Weg ist aber tragfähig (6,5 ms).

Streaming

Progressives Laden: zuerst die Terrain-Geometrie (unter 100 ms), dann Texturen (unter 300 ms), dann Vegetation (unter 1 s), dann volumetrische Daten (unter 3 s). Vorabladen nach der Spielergeschwindigkeit. Speicherbudget: 256 MB für Terrain insgesamt.

Bearbeiten

Heightmap-Pinsel für das Modellieren der Oberfläche (anheben, absenken, glätten, erodieren). SDF-Primitive für volumetrisches Bearbeiten (Höhlen schnitzen, Bögen ergänzen). Beides ist lokal sofort da, synchronisiert in 100 bis 300 ms zum Server und wird über Delta-Updates an andere Spieler verteilt.

Was in welcher Reihenfolge zu bauen ist

Monat 1-2: Heightmap-Terrain mit Geometry Clipmaps. Nur WebGL 2. Streaming vom CDN. Prozedurale Materialien nach Neigung und Höhe. Damit ist Terrain in jedem Browser auf dem Schirm. Für die Generierung Rauschen plus analytische Erosion nutzen, Terrain Diffusion kann warten.

Monat 3-4: Vegetation und Atmosphäre. GPU-instanziiertes Gras und Bäume aus Dichtekarten. Prozeduraler Himmel mit Tag-Nacht-Wechsel. Atmosphärischer Nebel. Cascaded Shadow Maps. Die Welt beginnt, sich wie ein Ort anzufühlen.

Monat 5-6: Bearbeiten für Creator. Heightmap-Pinselwerkzeuge. Delta-basierte Synchronisation für Terrain-Änderungen im Multiplayer. Räumliches Sperren für gleichzeitiges Bearbeiten. Ab hier fangen Creator an, die Welt zu formen.

Monat 7-9: Volumetrisches Terrain und der WebGPU-Weg. SDF-Auflagen für Höhlen und Überhänge. Marching Cubes im WebGPU-Compute. Transvoxel für LOD-Grenzen. SDF-Modellierwerkzeuge. Das schaltet den vollen Werkzeugkasten frei.

Monat 10-12: Neuronale Generierung und Feinschliff. Terrain Diffusion oder MESA für die Basis-Heightmap. TerraFusion und Geodiffussr für Texturen. Phasor Noise für Mikrodetails. Hex-Tiling gegen Wiederholung. Virtual Texturing. Laplace-Blending. Das Terrain erreicht Produktionsqualität.

Diese Reihenfolge heißt: nach 2 Monaten existiert etwas Spielbares, nach 4 etwas Schönes, nach 6 etwas Bearbeitbares und nach 12 etwas auf dem Stand der Technik.

Der Rest dieses Artikels ist die Recherche hinter jeder Entscheidung.

Terrain-Repräsentationen jenseits von Heightmaps

Signed Distance Fields (SDFs)

Ein Signed Distance Field speichert an jedem Punkt im 3D-Raum die Entfernung zur nächsten Oberfläche. Positive Werte liegen außen, negative innen, und der Nulldurchgang ist die Oberfläche selbst. SDFs bilden beliebige 3D-Formen ab, inklusive Höhlen, Bögen und schwebender Geometrie.

Um ein SDF als Mesh zu rendern, führst du Marching Cubes (oder eine Variante) aus, um den Nulldurchgang als Dreiecke zu extrahieren. Die Mesh-Auflösung hängt von der Gitterauflösung ab: Ein SDF-Gitter mit 256x256x256 erzeugt Terrain, das bei 1-Meter-Auflösung etwa einen Chunk abdeckt.

Umsetzung im Browser: WebGPU-Marching-Cubes läuft über Compute Shader vollständig auf der GPU. Will Ushers Implementierung webgpu-marching-cubes verarbeitet ein 256³-Gitter in Echtzeit im Browser und erreicht native Geschwindigkeit. Der Algorithmus ist trivial parallelisierbar, jede Zelle wird unabhängig verarbeitet, und damit ideal für GPU-Compute.

@compute @workgroup_size(4, 4, 4)
fn marchingCubes(@builtin(global_invocation_id) id: vec3<u32>) {
    let sdfValues = sampleSDF(id);
    let caseIndex = classifyCell(sdfValues);
    if (caseIndex == 0u || caseIndex == 255u) { return; }
    let triangles = lookupTriangulation(caseIndex);
    let vertices = interpolateEdges(sdfValues, triangles);
    appendToMeshBuffer(vertices);
}

Speicherkosten: Ein 256³-SDF mit 8-Bit-Quantisierung belegt unkomprimiert 16 MB. Der Großteil des Volumens ist aber leer, also weit von der Oberfläche entfernt. Lauflängenkodierung oder ein spärlicher Octree drücken das typischerweise auf 100 bis 500 KB pro Chunk, vergleichbar mit Heightmap-Terrain.

Bearbeiten: SDF-Terrain ist von Natur aus bearbeitbar. Material hinzufügen ist eine min()-Operation auf dem Distanzfeld. Material entfernen, also graben, ist ein max() mit einer negierten Form. Weiches Überblenden zwischen Formen nutzt smoothMin(). Diese Operationen laufen in einem Compute Shader mit interaktiven Raten.

Dual Contouring

Marching Cubes setzt Vertices auf Gitterkanten, was weiche Oberflächen ergibt, aber scharfe Merkmale verliert (Klippenkanten, Felsecken). Dual Contouring setzt einen Vertex pro Zelle an die Position, die die Oberfläche in dieser Zelle am besten repräsentiert, und erhält so scharfe Kanten und Ecken.

Der Algorithmus braucht sowohl die Werte des Distanzfeldes als auch die Oberflächennormalen (den Gradienten des SDF) an jedem Gitterpunkt. Er löst pro Zelle ein kleines Kleinste-Quadrate-Problem, um die optimale Vertexposition zu finden. Das Ergebnis ist ein Mesh, das weiches Terrain und scharfe felsige Merkmale gleichermaßen erfasst.

Neural Dual Contouring (Chen et al., 2022, arXiv:2202.01999) ersetzt den Kleinste-Quadrate-Löser durch ein neuronales Netz, das optimale Vertexpositionen und Kantendurchgänge vorhersagt. Es erreicht bessere Rekonstruktionsgenauigkeit und Merkmalserhaltung, besonders bei komplexen natürlichen Felsformationen.

Der Transvoxel-Algorithmus

Das schwerste Problem bei volumetrischem Terrain ist nicht das Erzeugen des Meshes. Es sind die LOD-Übergänge. Sitzt ein hochauflösender Chunk neben einem niedrig auflösenden, passen die Meshes an der Grenze nicht zusammen und es entstehen sichtbare Risse.

Der Transvoxel-Algorithmus, entworfen von Eric Lengyel (transvoxel.org), löst das, indem er an Grenzen zwischen Auflösungen besondere Übergangszellen einfügt. Diese Zellen überbrücken den Auflösungsunterschied mit zusätzlichen Dreiecken, die zu beiden Seiten exakt passen. Der Algorithmus reduziert das komplexe Grenzproblem auf 73 Äquivalenzklassen, verglichen mit rund 1,2 Millionen Fällen bei einem Brute-Force-Ansatz.

Transvoxel ist ausdrücklich für Echtzeitanwendungen gedacht, in denen sich Voxeldaten dynamisch ändern (Creator-Änderungen, Erosion, Abbau). Er ist patentfrei und steckt in ausgelieferten Spielen (Space Engineers, Astroneer). Für eine Browser-Welt mit bearbeitbarem volumetrischem Terrain ist Transvoxel die LOD-Lösung.

Hybrid: Heightmap-Basis plus volumetrische Auflagen

Der praktische Ansatz für eine offene Welt im Browser ist ein geschichtetes System:

Schicht 1: Heightmap-Terrain deckt die gesamte Welt ab. Das ist die günstige, kompakte Repräsentation für sanfte Hügel, Täler und Berge. Sie streamt als kleine Heightmap-Patches pro Chunk, je 2 bis 4 KB. Gerendert wird mit Geometry Clipmaps bei konstanten GPU-Kosten.

Schicht 2: Volumetrische Auflagen existieren nur in Chunks, in denen komplexe Geometrie gebraucht wird. Höhlen, Felswände, Bögen, von Creators geschnitzte Tunnel und unterirdische Räume werden als spärliche SDF-Volumen gespeichert. Nur Chunks mit volumetrischen Daten kosten SDF-Speicher und Marching-Cubes-Rechenzeit.

Schicht 3: Creator-Änderungen werden als SDF-Bearbeitungen über den Basisschichten gespeichert. Wer einen Tunnel gräbt, speichert die SDF-Form des Tunnels. Das Rendering-System kombiniert die Heightmap-Oberfläche mit volumetrischen Subtraktionen und Additionen zum endgültigen Mesh.

Dieser Hybrid kostet bei flachem Terrain fast nichts, nur die Heightmap, und skaliert allein dort, wo Komplexität existiert. In einer typischen Welt brauchen vielleicht 5 bis 10 % der Chunks volumetrische Daten.

Physikalisch korrekte Terraingenerierung

Rauschen erzeugt zufälliges Terrain. Physik erzeugt realistisches Terrain. Der Unterschied ist sichtbar: Noise-Terrain hat keine Struktur, es ist überall zufällig holprig, während physikalisches Terrain Flussnetze, Gratlinien, Schwemmfächer und Felsbänder hat, die aus Erosion und Tektonik hervorgehen.

Hydraulische Erosion: die Grundlage

Sebastian Lagues Umsetzung hydraulischer Erosion in Aktion. Simulierte Regentropfen fließen bergab, erodieren Material nach Geschwindigkeit und Neigung und lagern Sediment ab, wenn das Tempo fällt — so wird aus flachem Rauschen ein Gefüge aus Flusstälern, Gratlinien und Schwemmfächern.

Wasser fließt bergab, nimmt Sediment auf und lagert es ab, wenn es langsamer wird. Dieser eine Prozess, über Millionen virtueller Jahre simuliert, verwandelt merkmalsloses Rauschen in Terrain mit erkennbaren geologischen Merkmalen.

Der partikelbasierte Ansatz lässt simulierte Regentropfen auf die Heightmap fallen. Jeder Tropfen fließt bergab, folgt dem Gradienten, erodiert Material nach Geschwindigkeit und Neigung, trägt Sediment als gelöste Last und lagert es ab, wenn die Geschwindigkeit sinkt oder die Kapazität überschritten wird. Nach 200.000 bis 500.000 Partikeln entwickelt das Terrain:

• Flusstäler, die dem Weg des maximalen Wasserflusses folgen
• Gratlinien, die Einzugsgebiete trennen
• Schwemmfächer, wo steile Täler in flache Ebenen münden
• V-förmige Täler in Gebirgsterrain, U-förmige in vergletschertem Terrain

GPU-Umsetzung: Die Partikelsimulation ist parallelisierbar. Jedes Partikel ist unabhängig, die Näherung ignoriert Partikel-Partikel-Wechselwirkung, was für Erosion in Ordnung ist. Ein WebGPU-Compute-Shader verarbeitet 10.000 Partikel pro Frame bei 60 fps und schafft 200.000 Partikel in etwa 3 Sekunden Echtzeit.

Sebastian Lagues quelloffene Umsetzung (GitHub) ist der übliche Ausgangspunkt. Sie läuft einfädig in C# und verarbeitet eine 1024x1024-Heightmap in wenigen Sekunden. Die GPU-Version ist 50- bis 100-mal schneller.

Thermische Erosion

Wasser ist nicht die einzige Erosionskraft. Temperaturwechsel lassen Fels reißen und zerfallen, das ist thermische Verwitterung. Übersteigt die Neigung zwischen zwei Terrainpunkten den Schüttwinkel eines Materials, fällt Material vom höheren zum tieferen Punkt. Daraus entstehen:

• Schutthalden am Fuß von Klippen, also Haufen abgefallenen Gesteins
• Weicher werdende Gratlinien über die Zeit
• Materialabhängige Profile, harter Fels hält steile Neigungen, weicher Boden fällt zu sanften Winkeln zusammen

Thermische Erosion ist einfacher als hydraulische. Sie ist eine lokale Operation: Vergleiche für jede Zelle den Höhenunterschied zu den Nachbarn. Übersteigt die Neigung den Schwellwert, verschiebe Material bergab. Sie läuft als ein Compute-Shader-Durchgang pro Iteration und konvergiert in 50 bis 100 Iterationen.

Hydraulische und thermische Erosion zusammen ergeben Terrain, das dramatisch natürlicher aussieht als jede der beiden allein. Wasser schneidet Täler, thermische Erosion mildert die Grate dazwischen und füllt die Talböden mit Schutt.

Das Stream Power Law: analytische Erosion

Neuere Forschung bietet eine Alternative zur partikelbasierten Simulation. Das Stream Power Law, eine geomorphologische Gleichung, die die Erosionsrate mit Einzugsgebiet und Neigung verknüpft, lässt sich analytisch lösen statt iterativ simulieren.

Cordonnier et al. (2024, HAL) kombinieren das analytische Stream Power Law mit Hangrutschungen und Hangdiffusionsprozessen. Das Ergebnis ist Terraingenerierung, die physikalisch fundiert ist, aber als mathematische Funktion läuft und nicht als zeitliche Simulation. Du gibst eine rauschbasierte Heightmap und Parameter hinein (Niederschlagsrate, Gesteinshärte, tektonische Hebungsrate) und bekommst in Millisekunden erodiertes Terrain.

Dieser analytische Ansatz ist ideal für eine Browser-Welt, weil er bei der Terraingenerierung einmal serverseitig läuft und nicht iterativ. Die Parameter sind von Creators einstellbar, "mach diese Region gebirgiger" justiert die Hebungsrate, "mach es feuchter" erhöht den Niederschlag und tieft die Täler.

Arenite: Multi-Physik-Erosion (SIGGRAPH 2025)

Arenite simuliert Spannung, Winderosion, fluviale Erosion und Partikelablagerung, um aus geschichtetem Fels Bögen, Hoodoos und Tafelberge zu erzeugen. Die serverseitige Generierung liefert SDF-Volumen, die direkt in eine Marching-Cubes-Pipeline fließen.

Arenite (Projektseite) ist ein physikbasierter Sandstein-Simulator, der aus einfachen Anfangsbedingungen Bögen, Nischen, Hoodoos und Tafelberge erzeugt. Nutzer malen Erodierbarkeitskarten (Schichten aus weichem und hartem Fels) und Vegetation, dann simuliert das System:

• Spannungsverteilung durch die Felssäule
• Winderosion, die freiliegendes weiches Material bevorzugt abträgt
• Fluviale Erosion durch Wasserfluss
• Partikelablagerung, die neue Formationen bildet

Die GPU-Umsetzung braucht für komplexe Formationen auf einer Desktop-GPU unter 5 Minuten. Das ist für Echtzeit im Browser zu langsam, für serverseitige Generierung aber schnell genug. Ein Creator könnte eine Felswand mit weichen und harten Schichten definieren und binnen Minuten eine realistische Bogenformation bekommen.

Die Ausgabe ist ein 3D-Voxelfeld, das direkt in unsere SDF- und Marching-Cubes-Pipeline passt.

Flexible Erosion über Repräsentationen hinweg

Ein Paper von IRIT-STORM aus 2024 ("Flexible Terrain Erosion", Springer) löst ein praktisches Problem: Die meisten Erosionsverfahren funktionieren nur auf Heightfields. Nutzt dein Terrain Voxel, SDFs oder geschichtete Materialien, brauchst du für jedes eigenen Erosionscode.

Das flexible Erosionsverfahren zerlegt Erosion in zwei unabhängige Prozesse: Terrainveränderung, also Material von der Oberfläche abtragen, und Materialtransport, also Sediment mit Partikeln bewegen, die einfacher Physik folgen. Jedes Partikel hat konfigurierbare Größe, Dichte, Rückprall und Sedimentkapazität. Ein optionales Vektorfeld steuert die Partikelbewegung für realistische Fluiddynamik.

Weil die Partikel über eine einheitliche Schnittstelle zur Materialveränderung mit dem Terrain interagieren, funktioniert dieselbe Simulation auf Heightfields, Voxelgittern, impliziten Oberflächen und geschichteten Materialstapeln. Für unser hybrides Terrain aus Heightmap-Basis und SDF-Auflagen heißt das: Ein Erosionssystem deckt beide Repräsentationen ab. Die Partikelsimulation läuft parallel auf der GPU.

Flussnetze und Einzugsgebiete

Erosion schneidet Flüsse, aber überzeugende Flussnetze zu erzeugen verlangt mehr, als Wasser bergab laufen zu lassen. Zwei Ansätze liefern bessere Ergebnisse:

Entwässerung zuerst (Amit Patel, Red Blob Games, Projekt) baut das Flussnetz auf, bevor Höhen zugewiesen werden. Beginne mit einem Graphen (Voronoi oder Dreiecksnetz). Klassifiziere Kanten als Grate (kein Fluss), Zuläufe (Wasser fließt hinein) oder Abflüsse (Wasser fließt hinaus). Das erzeugt realistische Entwässerungshierarchien, in denen Flüsse aus kleinen Nebenflüssen zu großen Wasserläufen zusammenlaufen, entlang der Rosgen-Klassifikation für verschiedene Flusstypen (verzweigte Gerinne in flachem Terrain, enge Schluchten im Gebirge).

Flussakkumulation verfolgt, wie viel Wasser durch jede Terrainzelle läuft. Lass simulierten Regen gleichmäßig fallen, ihn bergab fließen und zähle Besuche pro Zelle. Zellen mit hoher Akkumulation sind Flussbetten. Zellen mit mittlerer Akkumulation sind saisonale Bäche. Die Akkumulationskarte steuert außerdem die Erosionsstärke (mehr Wasser gleich mehr Erosion) und die Vegetationsverteilung (Flussufer sind feuchter und tragen andere Pflanzenarten).

Für eine Creator-Welt wird das Flussnetz bei der Terrainerstellung serverseitig erzeugt und pro Chunk als 2D-Karte der Flussrichtungen plus Wasserakkumulationskarte gespeichert. Der Browser-Client nutzt diese Karten, um Wasseroberflächen zu rendern (flache Ebenen auf der richtigen Höhe in Flussbetten) und die Vegetationsverteilung zu steuern, also üppiger in Wassernähe.

Küsten- und Uferlinien-Generierung

Küsten sind, wo Terrain auf Wasser trifft, und sie haben charakteristische Merkmale, die normale Erosion nicht erzeugt: Steilküsten, Strandablagerungen, Watten, Brandungspfeiler und Brandungsplattformen.

NEWTS1.0 (2024, MIT) modelliert die Entwicklung felsiger Küsten mit zwei Erosionsmechanismen: gleichmäßiger Rückgang, also konstante Erosionsrate, und wellengetriebene Erosion, bei der die Rate von der Streichlänge und dem Einfallswinkel der Wellen abhängt. Das Modell läuft über tausende simulierte Jahre und erzeugt Landzungen, Buchten, Brandungspfeiler und Bögen, die zur realen Küstengeomorphologie passen.

Für eine Browser-Welt würden Küstenmerkmale bei der Welterstellung vorab erzeugt. Die Parameter (dominante Wellenrichtung, Schwankung der Gesteinshärte entlang der Küste) lassen Creator den Charakter ihrer Küste bestimmen. Eine Einstellung "norwegischer Fjord" ergibt steilwandige Meeresarme. Eine Einstellung "tropisches Atoll" ergibt flache Sandküsten mit Lagunen.

Höhlen- und Untergrundgenerierung

Höhlen verlangen vollständig volumetrisches Terrain (SDFs oder Voxel), denn Heightmaps können geschlossene Räume nicht abbilden. Die Generierungsansätze:

3D-Noise-Schwellwerte sind die einfachste Methode. Taste an jedem Voxel 3D-Perlin- oder Simplex-Noise ab. Werte unter einem Schwellwert sind fest, darüber leer. Über Schwellwert und Noise-Parameter steuerst du Tunneldurchmesser, Vernetzung und Kammergröße. Das ergibt organische, wurmartige Höhlensysteme, die an Minecraft erinnern.

PLUME (Procedural Layer Underground Modeling Engine) (2024, arXiv:2508.20926) erzeugt realistische Höhlen- und Lavaröhrenumgebungen mit geschichteten prozeduralen Regeln. Ursprünglich für Weltraumforschung gebaut, zur Simulation marsianischer Lavaröhren, liefert es geologisch plausible unterirdische Strukturen mit Stalaktiten, Säulen und Kammersystemen.

L-System-Tunnel mit Metaball-Aushöhlung nutzen eine L-System-Grammatik, um verzweigte Tunnelpfade durch das Terrain wachsen zu lassen, und schneiden die eigentliche Tunnelgeometrie dann mit impliziten Metaball-Oberflächen. Die Metabälle ergeben weiche, gerundete Höhlenwände. Mehrere Durchgänge mit verschiedenen Parametern erzeugen Hauptgänge, Seitenkammern und enge Verbindungstunnel.

Für eine Creator-Welt hängt die Höhlengenerierung am SDF-Auflagen-System. Das Basisterrain ist eine Heightmap, ohne Höhlen. Braucht ein Chunk Höhlen, entweder aus prozeduraler Generierung oder aus Creator-Design, wird ein SDF-Volumen erzeugt, das Höhlengeometrie vom Basisterrain abzieht. Die Marching-Cubes-Pipeline rendert die kombinierte Oberfläche.

Vegetation als physikalischer Prozess

Vegetation wird in Spielen üblicherweise prozedural nach Regeln platziert, etwa "Gras unter 2000 m, Bäume unter 1500 m, Schnee über 3000 m". Das ist schnell, ergibt aber gleichförmige, unrealistische Verteilung.

Physikalisch fundierte Vegetationssimulation modelliert jede Pflanze als Konkurrent um Ressourcen: Licht, Wasser, Bodennährstoffe. Die Simulation:

1. Samen werden über das Terrain verstreut
2. Jede Pflanze wächst entsprechend der verfügbaren Ressourcen (Wasser kommt aus der hydraulischen Erosionssimulation, Sonnenlicht hängt von Neigung und Exposition ab, Bodentiefe von der Erosionsgeschichte)
3. Pflanzen konkurrieren: Bäume beschatten Gras weg, ein dichtes Kronendach verhindert neue Sämlinge
4. Über simulierte Zeit entstehen Biome von selbst: Wälder in wasserführenden Tälern, spärliche Vegetation auf windigen Graten, Feuchtgebiete dort, wo Wasser stehen bleibt

Die Ökosystem-Simulation von Deussen et al. (Paper) erzeugt Waldverteilungen, die zu realen ökologischen Mustern passen. Die Simulation läuft auf einem 2D-Gitter, eine Zelle pro Terrain-Chunk, und liefert Dichtekarten und Artzuweisungen, die das Rendering-System für GPU-instanziierte Vegetationsplatzierung nutzt.

Für eine Browser-Welt läuft die Vegetationssimulation einmal während der Weltgenerierung, serverseitig. Die Ausgabe ist ein Satz Dichtekarten pro Chunk: Baumdichte, Grasdichte, Blumendichte, Dichte von Felsschutt. Der Browser-Client nutzt diese Karten mit GPU-Instancing, um Vegetation zur Laufzeit zu verteilen.

Diffusionsbasierte Terrainsynthese

Hier bewegt sich das Feld am schnellsten. Diffusionsmodelle, dieselbe Technik, die hinter Stable Diffusion für Bilder steht, werden auf Terraingenerierung angewandt, und die Ergebnisse sind deutlich realistischer als rauschbasierte Verfahren.

Terrain Diffusion: ein Nachfolger für Perlin Noise

Terrain Diffusion läuft in Minecraft und streamt in Echtzeit unendliches, seed-konsistentes Terrain. Trainiert auf echten Höhendaten, erzeugt es Landschaften mit geologischer Struktur, an die Noise-Funktionen nicht herankommen.

Terrain Diffusion (Goslin, 2025, arXiv:2512.08309, Projektseite) ist der bedeutendste Fortschritt bei prozeduraler Terraingenerierung seit Perlin Noise 1985. Die Arbeit wurde inzwischen für SIGGRAPH 2026 angenommen, und der kanonische arXiv-Titel lautet jetzt "InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation". Der InfiniteDiffusion-Algorithmus und das Terrain-Diffusion-Framework sind die zwei Hälften desselben Papers.

Die zentrale Neuerung ist InfiniteDiffusion, ein Algorithmus, der Diffusions-Sampling für unbegrenzte Domänen neu formuliert. Klassische Diffusionsmodelle erzeugen Ausgaben fester Größe, etwa eine 512x512-Heightmap. InfiniteDiffusion erzeugt Terrain unbegrenzter Ausdehnung mit:

• Seed-Konsistenz: Derselbe Seed ergibt immer dasselbe Terrain, wie bei Perlin Noise
• Zufallszugriff in konstanter Zeit: Du kannst die Höhe an jedem Punkt abfragen, ohne zuerst Nachbarregionen zu erzeugen
• Keine Randartefakte: Unbegrenzte Generierung ohne sichtbare Nähte oder Wiederholung

Das System nutzt einen hierarchischen Stapel von Diffusionsmodellen. Die oberste Ebene erfasst Merkmale planetarischen Maßstabs, also Kontinente und Gebirgszüge. Jede weitere Ebene ergänzt feinere Details: einzelne Gipfel, Täler, kleinskalige Rauheit. Eine kompakte Laplace-Kodierung stabilisiert die Ausgaben über den enormen Dynamikbereich von Meereshöhe bis Himalaya-Gipfel.

Leistung: Die Generierung hält mit Echtzeit-Erkundung mit. Das Paper berichtet, dass die Terrainsynthese selbst am theoretischen Extrem der Orbitalgeschwindigkeit (etwa 7.700 m/s) auf einer Consumer-GPU 9-mal schneller läuft als das Durchqueren. Zum Projekt gehört eine Minecraft-Integration, die Terrainsynthese in Echtzeit zeigt.

Warum das für uns zählt: Terrain Diffusion erzeugt Landschaften, die auf echten Höhendaten trainiert sind, also auf der tatsächlichen Topografie der Erde. Die Ausgabe hat Flussnetze, Gebirgszüge, Küstenmerkmale und Plateaustrukturen, die aus den Trainingsdaten hervorgehen und nicht aus handjustierten Noise-Parametern. Ein Creator könnte sagen "erzeuge Terrain wie die schottischen Highlands", und das Diffusionsmodell würde etwas mit dem richtigen geologischen Charakter liefern.

Das Modell läuft während der Weltgenerierung serverseitig. Die Ausgabe ist eine normale Heightmap, die wie alle anderen Terraindaten in den Browser streamt. Das Generierungsverfahren ist für den Client unsichtbar.

TerraFusion: Geometrie und Textur gemeinsam

TerraFusion erzeugt Heightmap und Textur gemeinsam aus einer handgezeichneten Skizze. Die Korrelation zwischen Geometrie und Material ist eingebaut, Flussbetten kommen sandig heraus, Felswände felsig, flacher Boden grasig, ohne jedes manuelle Splat-Malen.

TerraFusion (2025, arXiv:2505.04050) geht weiter und erzeugt Heightmaps und Terraintexturen gemeinsam. Die zentrale Einsicht: Terraingeometrie und Oberflächenerscheinung sind korreliert, Flussbetten sind sandig, Felswände felsig, flache Bereiche grasig. Erzeugt man sie getrennt, entstehen Widersprüche.

TerraFusion nutzt ein Latent-Diffusion-Modell mit getrennten VAEs für Heightmaps und Texturen, trainiert darauf, ihre gemeinsame Verteilung zu modellieren. Das System unterstützt:

• Unbedingte Generierung: zufälliges plausibles Terrain mit passenden Texturen
• Skizzengeführte Generierung: Ein Creator zeichnet eine grobe Karte (hier Täler, dort Grate, Klippen an dieser Kante) und das Modell erzeugt detaillierte Geometrie und Texturen, die zur Skizze passen

Für eine Creator-Welt ist das mächtig. Ein Creator skizziert die groben Züge seines Grundstücks, und das System füllt geologisch plausibles Terrain mit passenden Oberflächenmaterialien auf. Kein Heightmap-Malen, kein Textur-Splatting, keine manuelle Materialzuweisung.

MESA: Text zu Terrain

MESA gibt aus Text-Prompts gepaarte Satellitenbilder und DEMs aus. Trainiert auf dem globalen Copernicus-Datensatz, versteht es echtes Terrain in jedem Maßstab und jeder Klimazone: Fjorde, Steppen, Ackerland, alpine Grate.

MESA (2025, arXiv:2504.07210, CVPR-2025-Workshop) erzeugt Terrain aus Textbeschreibungen. Es ist auf globalen Fernerkundungsdaten des Copernicus-Programms trainiert und hat damit jede Art terrestrischer Landschaft gesehen.

Ein Prompt wie "ein Fjord mit steilen Granitwänden, der sich zu einer felsigen Küste öffnet" ergibt eine Heightmap mit der passenden geologischen Struktur. "Sanft hügeliges Ackerland mit einem weiten Flusstal" ergibt etwas völlig anderes.

MESA führt den Datensatz Major TOM Core-DEM als Erweiterung ein, der Satellitenbilder weltweit mit digitalen Höhenmodellen paart. Diese Trainingsdaten geben dem Modell ein Verständnis dafür, wie echtes Terrain in jedem Maßstab und jeder Klimazone aussieht.

Geodiffussr: textgeführte Terrain-Texturierung

Geodiffussr nimmt eine Heightmap und einen Text-Prompt und erzeugt Oberflächentexturen, die die Höhe respektieren. Schnee erscheint nur über plausiblen Höhenlagen, Vegetation dünnt mit der Höhe aus, Wasser liegt in Senken. Die Geometrie bleibt unverändert.

Geodiffussr (2025, arXiv:2511.23029) nimmt eine bestehende Heightmap und erzeugt Texturen nach Textbeschreibungen, wobei es die Höhendaten respektiert. "Herbstwald" ergibt orange und goldenes Laub an mittleren Hängen mit nacktem Fels an steilen Wänden. "Tropische Küste" ergibt Palmenvegetation im Flachen mit Korallensand auf Meereshöhe.

Das System nutzt mehrskalige Inhaltsaggregation, damit Texturzuweisungen die Höhe respektieren: Schnee erscheint nur über einer physikalisch plausiblen Höhe, Gewässer liegen in Senken, Vegetation dünnt mit der Höhe aus.

Für eine Creator-Welt heißt das, dass Terraintexturen aus einem Text-Prompt neu erzeugt werden können, ohne die Geometrie zu ändern. Ein Creator modelliert das gewünschte Terrain, beschreibt dann die Stimmung ("dunkle vulkanische Einöde" oder "üppiger Laubwald") und das System erzeugt passende Oberflächenmaterialien.

Dynamisches LOD für Terrain im Browser

Großes Terrain überall in voller Auflösung zu rendern ist im Browser unmöglich. Eine Welt von 4 km x 4 km bei 1-Meter-Auflösung sind allein 16 Millionen Terrain-Vertices. Dynamisches LOD reduziert das unabhängig von der Weltgröße auf eine konstante, handhabbare Vertexzahl.

Geometry Clipmaps

Die ursprüngliche SIGGRAPH-2004-Präsentation der Geometry Clipmaps. Konzentrische Terrainringe mit halbierender Auflösung halten die Vertexzahl unabhängig von der Weltgröße konstant, und sie sind bis heute die Grundlage der meisten Browser-Terrain-LODs.

Geometry Clipmaps (Losasso und Hoppe, SIGGRAPH 2004, Paper) sind weiterhin der Goldstandard für Heightmap-Terrain-LOD. Die Idee: Rendere Terrain als Satz konzentrischer quadratischer Ringe um die Kamera. Jeder Ring hat die doppelte Fläche des vorherigen, aber die halbe Auflösung.

Nah an der Kamera, im innersten Ring: volle Auflösung, 1 Meter Gitterabstand. Ein Ring weiter: 2 Meter Abstand, vierfache Fläche. Nächster Ring: 4 Meter Abstand, sechzehnfache Fläche. Und so weiter über 6 bis 8 Stufen, bis der äußerste Ring die gesamte sichtbare Weite abdeckt.

Die Gesamt-Vertexzahl ist konstant: etwa N² mal Stufen, wobei N die Ringbreite in Vertices ist. Bei N=256 und 8 Stufen sind das rund 500.000 Vertices. Das rendert gleich, ob die Welt 1 km oder 100 km breit ist.

Umsetzung im Browser: Geometry Clipmaps funktionieren in WebGL 2, weil sie nur normale Vertexbuffer-Aktualisierungen brauchen, keine Compute Shader. Bewegt sich die Kamera, aktualisiert die CPU die Heightmap-Daten jedes Rings, indem sie das Terrain in der passenden Auflösung abtastet. Der Vertex-Shader liest Höhenwerte aus einer Textur und verschiebt das flache Gitter.

Morphing: Der Übergang zwischen LOD-Stufen erzeugt naiv umgesetzt sichtbares Ploppen. Geomorphing, weiter unten in einem eigenen Abschnitt, blendet Vertexpositionen im Vertex-Shader über eine Übergangszone zwischen Stufen und erzeugt weiche, ploppfreie Übergänge ohne zusätzliche Draw Calls.

CDLOD: quadtree-adaptive Clipmaps

CDLOD (Strugar, 2014, Paper) verbessert Geometry Clipmaps, indem es statt fester konzentrischer Ringe einen Quadtree nutzt. Der Quadtree passt sich dem Terrain an: Flache Bereiche nutzen grobe Knoten, Bereiche mit hohem Detail wie Klippen und Grate werden feiner unterteilt.

Das zählt für eine Creator-Welt, weil verschiedene Chunks verschieden komplex sind. Eine flache Wiese braucht minimale Auflösung. Eine Gebirgsregion mit Klippen und Höhlen braucht maximales Detail. CDLOD verteilt Auflösung dorthin, wo sie wirkt.

Die Quadtree-Traversierung auf der CPU ist leichtgewichtig, wenige Hundert Knoten, und bestimmt, welche Terrain-Patches in welcher Auflösung gezeichnet werden. Die GPU rendert jedes Patch als instanziiertes Gitter mit LOD-Uniforms pro Patch.

Concurrent Binary Trees: Tessellierung im Planetenmaßstab

Adaptive CBT-Tessellierung für Terrain im Planetenmaßstab: Dreiecke unterteilen sich nahe der Kamera und verschmelzen in der Ferne, vollständig auf der GPU. Unter 0,2 ms auf Konsolen-Hardware.

Concurrent Binary Trees (CBT) sind eine GPU-freundliche Datenstruktur für adaptive Terrain-Tessellierung, vorgestellt von Benyoub und Dupuy (Intel, HPG 2024, Paper, GitHub).

Die Kernidee: Stelle das Terrain als Binärbaum dar, in dem jeder Knoten ein Dreieck ist. Adaptive Unterteilung spaltet Dreiecke nahe der Kamera und verschmilzt weit entfernte. Der Binärbaum liegt vollständig im GPU-Speicher als 1D-Array, ein Binärheap, und Unterteilen und Verschmelzen laufen als Compute Shader.

Das Paper von 2024 erweitert CBT von quadratischen Heightmap-Domänen auf beliebige Polygon-Meshes. Damit kannst du eine Kugel tessellieren, für planetarisches Rendering, oder ein beliebiges Basis-Mesh, für eine Spielwelt mit nicht rechteckigen Grenzen. Die entscheidende Verbesserung: CBT als Speicherpool-Verwalter statt als implizite Kodierung zu nutzen erlaubt viel höhere Unterteilungsstufen.

Leistung: Terrain-Tessellierung im Planetenmaßstab in unter 0,2 ms auf Hardware auf Konsolenniveau. Der Algorithmus skaliert linear mit der Prozessorzahl. Für WebGPU eröffnet das einen Weg zu Terrain-Rendering im Planetenmaßstab im Browser, allerdings bei hoher Umsetzungskomplexität.

GPU-getriebenes LOD mit WebGPU

WebGPU ermöglicht eine vollständig GPU-getriebene Terrain-Pipeline, die die CPU aus LOD-Entscheidungen heraushält:

1. Compute-Durchgang 1: Frustum- und Occlusion-Culling. Ein Compute Shader testet die Bounding Box jedes Terrain-Patches gegen das Sichtfrustum und einen Occlusion-Buffer (den heruntergerechneten Tiefenpuffer des vorherigen Frames). Unsichtbare Patches werden komplett verworfen.

2. Compute-Durchgang 2: LOD-Auswahl. Für sichtbare Patches wird die Größe im Bildschirmraum berechnet und die passende LOD-Stufe gewählt. LOD-Stufe und Patch-ID werden in einen Indirect-Draw-Buffer geschrieben.

3. Compute-Durchgang 3: Mesh-Erzeugung (für volumetrisches Terrain). Für Chunks mit SDF-Daten laufen Marching Cubes, um das Mesh in der gewählten LOD-Auflösung zu erzeugen.

4. Indirect Draw. Ein einzelner Aufruf drawIndexedIndirect() rendert alle Terrain-Patches. Die GPU entscheidet alles: was gezeichnet wird, in welcher Auflösung, in welcher Reihenfolge.

Diese Pipeline hat unabhängig von Weltgröße und Komplexität konstante CPU-Kosten, nämlich das Anstoßen der Compute Shader und den Indirect Draw Call. Die GPU übernimmt alle Entscheidungen pro Patch.

@compute @workgroup_size(64)
fn lodSelection(@builtin(global_invocation_id) id: vec3<u32>) {
    let patchIdx = id.x;
    let bounds = patchBounds[patchIdx];

    if (!frustumTest(bounds, viewProjection)) { return; }
    if (occlusionTest(bounds, depthPyramid) == OCCLUDED) { return; }

    let screenSize = projectedSize(bounds, viewProjection, screenDimensions);
    let lod = clamp(u32(log2(maxScreenSize / screenSize)), 0u, MAX_LOD);

    let drawIdx = atomicAdd(&drawCount, 1u);
    drawArgs[drawIdx] = DrawArgs(patchIdx, lod, indexCount[lod], indexOffset[lod]);
}

Geomorphing: LOD-Übergänge ohne Ploppen

Das größte visuelle Artefakt bei Terrain-LOD ist Ploppen: Vertices springen plötzlich auf neue Positionen, wenn ein Patch die LOD-Stufe wechselt. Geomorphing beseitigt das, indem es Vertexpositionen über eine Übergangszone weich zwischen LOD-Stufen interpoliert.

Die Umsetzung steckt vollständig im Vertex-Shader. Jeder Vertex speichert sowohl seine Position in der aktuellen LOD-Stufe als auch die in der nächstgröberen. Überschreitet die Kameraentfernung die Übergangsschwelle, blendet ein Morph-Faktor zwischen beiden:

float morphFactor = smoothstep(lodNear, lodFar, distanceToCamera);
float morphedHeight = mix(fineLodHeight, coarseLodHeight, morphFactor);
gl_Position = viewProjection * vec4(worldPos.x, morphedHeight, worldPos.z, 1.0);

Hoppes Paper zu Geometry Clipmaps (GPU Gems 2, Kapitel 2) beschreibt die vollständige Umsetzung für Clipmap-Ringe. Die Morph-Zone sind die äußeren 20 % jedes Rings. Innerhalb dieser Zone laufen Vertices weich auf die Auflösung des nächsten Rings zu. Der visuelle Effekt: Die Terraingeometrie "schmilzt" zwischen Detailstufen, statt zu springen. Bei typischen Kamerageschwindigkeiten ist der Übergang unsichtbar.

Blending im Bildraum (Scherzer et al., Paper) ist eine Alternative, die gerenderte Bilder zweier LOD-Stufen im Bildschirmraum überblendet. Das verkraftet extremere LOD-Unterschiede, etwa Übergänge von Mesh zu Billboard, kostet für die Übergangszone aber einen zusätzlichen Render-Durchgang.

GPU-getriebenes Vegetations-Culling

Vegetation, also Bäume, Gras und Steine, ist in einer offenen Welt oft die größte Quelle von Draw Calls. Ein naiver Ansatz zeichnet jede Vegetationsinstanz in jedem Frame. GPU-getriebenes Culling, in Three.js inzwischen über WebGPU verfügbar, entfernt unsichtbare Instanzen, bevor sie den Rasterizer erreichen.

Three.js' ComputeInstanceCulling (Doku) bietet Frustum- und LOD-Culling für instanziierte Meshes mit 10- bis 100-fachem Leistungsgewinn bei großen Instanzzahlen. Die Pipeline:

1. Ein Compute Shader liest alle Bounding Spheres der Instanzen
2. Testet jede gegen das Kamerafrustum, ein Test gegen 6 Ebenen
3. Wendet entfernungsbasiertes LOD an: Instanzen jenseits einer Schwelle wechseln auf geringeres Detail oder werden ganz verworfen
4. Überlebende Instanzen werden in einen Buffer verdichtet und per drawIndirect gezeichnet

Die CPU leistet null Arbeit pro Instanz. Nach dem Aufsetzen kostet es einen Compute-Dispatch plus einen Indirect Draw Call pro Vegetationstyp, unabhängig von der Instanzzahl.

Für dichtere Vegetation packt Three.js' IndirectBatchedMesh (Doku) mehrere Geometrietypen (Bäume, Büsche, Steine) in einen Buffer und zeichnet sie per Multi-Draw-Indirect. Ein Draw Call für die gesamte Vegetation eines Chunks.

Zusammen mit dem Verteilen aus Dichtekarten in unserem Vegetationssystem heißt das: Die Dichtekarte erzeugt in einem Compute Shader 50.000 Positionen für Grashalme, der Culling-Durchgang entfernt die 70 %, die außerhalb des Bildes oder zu weit weg sind, und ein Indirect Draw Call rendert die verbleibenden 15.000 Halme. CPU-Kosten insgesamt: vernachlässigbar.

LOD für volumetrisches Terrain

Volumetrisches Terrain (SDF plus Marching Cubes) braucht ein eigenes LOD-System, weil das Mesh erzeugt und nicht vorab erstellt wird. Der Ansatz:

Multiresolution-SDF-Speicherung. Speichere das SDF in mehreren Auflösungen in einer mipmap-artigen Hierarchie. Stufe 0 ist volle Auflösung, 1-Meter-Voxel. Stufe 1 sind 2-Meter-Voxel, achtmal weniger Daten. Stufe 2 sind 4-Meter-Voxel. Auf jeder Stufe wird das SDF heruntergerechnet, indem der minimale Absolutabstand genommen wird.

LOD-gewählte Marching Cubes. Führe Marching Cubes auf der SDF-Stufe aus, die zum gewünschten LOD passt. Nahe Chunks nutzen Stufe 0. Ferne Chunks nutzen Stufe 2 oder 3. Der Transvoxel-Algorithmus behandelt die Grenze zwischen verschiedenen Stufen.

Caching. Erzeugte Meshes werden gecacht, bis sich das SDF ändert (Creator-Bearbeitung) oder die LOD-Stufe wechselt (Kamera hat sich deutlich bewegt). Bei statischem Terrain wird das Mesh einmal erzeugt und wiederverwendet.

Streaming-Architektur für Terrain

Format der Chunk-Daten

Jeder Terrain-Chunk (64x64 Meter) streamt als kompaktes Binärpaket:

ChunkPacket {
  header: {
    chunkX: i16, chunkZ: i16,
    version: u32,
    flags: u8  // hasHeightmap | hasVolumetric | hasVegetation
  }
  heightmap: {
    resolution: u8,      // 65x65 for full, 33x33 for half, 17x17 for quarter
    quantizedHeights: u16[resolution * resolution],  // delta-encoded, zlib compressed
    splatMap: u8[4 * resolution * resolution]         // RGBA blend weights, LZ4 compressed
  }
  volumetric?: {         // only present if flags.hasVolumetric
    sdfResolution: u8,   // typically 32 or 64
    sparseOctree: bytes  // run-length encoded sparse SDF
  }
  vegetation?: {         // only present if flags.hasVegetation
    treeDensityMap: u8[16 * 16],    // 4m resolution density grid
    grassDensityMap: u8[32 * 32],   // 2m resolution density grid
    rockDensityMap: u8[16 * 16]
  }
  creatorObjects: {
    count: u16,
    objects: PlacedObject[]   // assetId + transform + properties, ~40 bytes each
  }
}

Typische Größen:

• Chunk nur mit Heightmap (flaches Terrain): 2 bis 4 KB komprimiert
• Heightmap plus Vegetation: 4 bis 8 KB
• Heightmap plus volumetrisch plus Vegetation (komplexer Chunk): 20 bis 100 KB
• Nachbarschaft von 5x5 in vollem Detail: 50 bis 500 KB insgesamt

Progressives Laden von Chunks

Chunks laden in einer Prioritätsreihenfolge nach Entfernung, Bewegungsrichtung und Datentyp:

Priorität 1 (sofort, unter 100 ms): Heightmap-Geometrie für Chunks, die der Spieler gleich betritt. Die Terrainoberfläche erscheint zuerst. Selbst in der niedrigsten Auflösung (17x17 pro Chunk) ist der Boden da.

Priorität 2 (schnell, unter 300 ms): Splat Maps und Terraintexturen. Der Boden bekommt Farbe.

Priorität 3 (Streaming, unter 1 s): Aufwertung auf die volle Heightmap-Auflösung. Dichtekarten für Vegetation. GPU-Instancing erzeugt Bäume und Gras.

Priorität 4 (Hintergrund, unter 3 s): Volumetrische SDF-Daten für Chunks mit Höhlen und Überhängen. Marching Cubes erzeugt das Mesh in einem Web Worker und überträgt den Buffer an den Haupt-Thread.

Priorität 5 (nachrangig, unter 10 s): Von Creators platzierte Objekte. Hochauflösende Texturen für Bauwerke. Detailobjekte wie Blumen, kleine Steine, Geröll.

Vorausschauendes Vorabladen

Warte nicht, bis der Spieler einen Chunk betritt, um ihn zu laden. Sag anhand der Geschwindigkeit voraus, wohin er geht, und lade voraus:

• Gehgeschwindigkeit (5 km/h): 2 Chunks voraus laden (128 m). Bei typischer Breitbandlatenz sind das 200 bis 400 ms Vorlauf.
• Laufen und Reiten (15 km/h): 4 Chunks voraus laden. Der Lade-Ring verschiebt sich mit der Bewegungsrichtung.
• Fliegen und Schnellreise: Rendering während des Übergangs anhalten. Die Ziel-Chunks mit höchster Priorität streamen. Rendering fortsetzen, sobald genug Daten für ein erstes Bild da sind.

Das Vorablade-System verfolgt, welche Chunks im Cache liegen, welche unterwegs sind (angefragt, aber noch nicht angekommen) und welche gebraucht werden. Eine Prioritätswarteschlange sortiert offene Anfragen nach Dringlichkeit. Anfragen für Chunks, von denen sich der Spieler wegbewegt hat, werden abgebrochen.

Speicherbudget und Verdrängung

Ein Browser-Tab bekommt auf dem Desktop 2 bis 4 GB. Das Terrain-System muss mit einem Bruchteil davon leben, der Rest ist für Rendering, Physik, Netzwerk und den JavaScript-Heap.

Zielbudget: 256 MB für alle Terraindaten.

Bei unseren typischen Chunk-Größen:

• Gecachte Chunks in vollem Detail: ~100 (Nachbarschaft 10x10) mit je 5 bis 100 KB, also 5 bis 10 MB Rohdaten
• Terrain-Geometrie auf der GPU: ~50 MB (Vertex- und Indexbuffer für sichtbares Terrain)
• Terraintexturen: ~100 MB (KTX2-komprimiert, im Atlas gepackt)
• Instanzbuffer für Vegetation: ~50 MB (Positionen, Rotationen, Skalierungen fürs GPU-Instancing)
• SDF-Volumen und gecachte Marching-Cubes-Meshes: ~50 MB

Chunks jenseits der Sichtweite werden zuerst aus dem GPU-Speicher verdrängt (Texturen, Vertexbuffer), dann aus dem CPU-Cache. Die rohen Heightmap-Daten gehen zuletzt, weil sie am günstigsten zu halten und am wichtigsten sind, wenn der Spieler sich umdreht.

Biom-Übergänge und Vermeiden von Kachelmustern

Weiche Biomgrenzen

Echte Landschaften haben keine harten Kanten zwischen Biomen. Ein Wald hört nicht an einer Linie auf und wird Wüste. Es gibt einen Gradienten: Dichter Wald dünnt zu vereinzelten Bäumen aus, dann Buschland, dann spärliche Wüstenvegetation. Das richtig zu machen lässt die Welt durchgehend wirken statt gekachelt.

AutoBiomes (Kötter et al., Paper) verbindet prozedurale Terraingenerierung mit vereinfachter Klimasimulation. Temperatur, Feuchte und Höhe bestimmen an jedem Punkt den Biomtyp. Zwischen Biomen interpolieren Materialgewichte und Vegetationsdichte über eine Übergangszone, typischerweise 50 bis 100 Meter breit. Die Breite variiert nach Biompaar: Wald zu Grasland ist breit und allmählich, Klippe zu Wasser ist schmal und abrupt.

Für eine Creator-Welt läuft die Biomzuweisung auf einem grobem Gitter, eine Biomprobe pro 16x16-Meter-Fläche. Der Terrain-Shader liest die Biomwerte für das aktuelle Fragment und seine Nachbarn, interpoliert Materialgewichte in der Übergangszone und blendet Texturen entsprechend. Das Verteilen der Vegetation nutzt dieselben interpolierten Dichtewerte, die Baumdichte verläuft am Waldrand also allmählich.

Creator-Kontrolle: Lass Creator Biom-Überschreibungen auf ihren Grundstücken malen. Das System erzeugt Standardbiome aus Terraineigenschaften, Creator können sie aber überschreiben. Mal "Sumpf" auf eine Senke und das Material wechselt zu trübem Wasser, Moos und toten Bäumen. Die Biom-Malkarte ist pro Chunk ein 16x16-Gitter aus Biom-IDs (256 Byte), das die prozedurale Zuweisung überschreibt.

Hex-Tiling: Texturwiederholung beseitigen

Das häufigste visuelle Artefakt beim Terrain-Rendering ist Texturwiederholung. Eine 1-Meter-Grastextur über eine 100-Meter-Wiese gekachelt erzeugt sichtbare Gittermuster. Zwei Techniken beheben das:

Hex-Tiling (Mikkelsen, Demo) ersetzt das quadratische Kachelgitter durch ein hexagonales. Jede Sechseckkachel tastet die Textur mit zufälligem Versatz und zufälliger Drehung ab. Die Sechseckgrenzen werden überblendet, um Nähte zu verbergen. Das Ergebnis ist eine Fläche, die gleichmäßig zufällig aussieht statt gekachelt. Kosten: etwa 3 zusätzliche Texturabtastungen pro Fragment. Die Technik wird in Produktionsspielen breit eingesetzt und läuft in jedem Fragment-Shader.

Stochastisches Texturfiltern (Pharr et al., NVIDIA, 2024, Paper) filtert nach dem Shading statt davor, mit stochastischem Sampling. Der Fehler aus dem stochastischen Sampling ist minimal und wird von raumzeitlichem Denoising gut abgefangen. Das ergibt genauere gefilterte Resultate und funktioniert mit komprimierten und spärlichen Texturen. Beim Terrain beseitigt es sowohl Kachelartefakte als auch die Filterartefakte, die Hex-Tiling an Übergängen manchmal einführt.

Für eine Browser-Welt ist Hex-Tiling die praktische Wahl, es läuft in jedem Shader. Stochastisches Filtern braucht mehr Infrastruktur, liefert aber bessere Ergebnisse, wenn temporales Denoising verfügbar ist, was in einem WebGPU-Weg mit TAA der Fall wäre.

Terrain-Materialsystem

Triplanare Projektion

Klassisch UV-gemappte Texturen dehnen sich an steilen Hängen furchtbar, weil die UV-Koordinaten sich stauchen. Triplanare Projektion projiziert Texturen entlang aller drei Achsen (X, Y, Z) und blendet nach der Oberflächennormale:

vec3 blending = abs(normal);
blending = normalize(max(blending, 0.00001));
blending /= (blending.x + blending.y + blending.z);

vec4 xaxis = texture(material, worldPos.yz * scale);
vec4 yaxis = texture(material, worldPos.xz * scale);
vec4 zaxis = texture(material, worldPos.xy * scale);

vec4 color = xaxis * blending.x + yaxis * blending.y + zaxis * blending.z;

Felswände bekommen die X- oder Z-Projektion, ohne Dehnung. Flacher Boden bekommt die Y-Projektion. Das Blending ist weich und automatisch. Kein UV-Auffalten nötig.

Babylon.js hat ein eingebautes TriPlanar Material. Three.js braucht einen eigenen Shader, die Umsetzung sind aber etwa 30 Zeilen GLSL.

Für PBR-Terrain wendest du die triplanare Projektion auf alle Kanäle an: Albedo, Normale, Roughness und Ambient Occlusion. Dieselben Blend-Gewichte gelten für jeden Kanal.

Materialzuweisung nach Neigung und Höhe

Statt Splat Maps von Hand zu malen, weist du Materialien prozedural nach Terraineigenschaften zu:

float slope = acos(dot(normal, vec3(0, 1, 0)));
float altitude = worldPos.y;

float grassWeight = smoothstep(0.3, 0.0, slope) * smoothstep(2000.0, 1500.0, altitude);
float rockWeight = smoothstep(0.2, 0.5, slope);
float snowWeight = smoothstep(2500.0, 3000.0, altitude) * smoothstep(0.4, 0.1, slope);
float sandWeight = smoothstep(5.0, 0.0, altitude) * smoothstep(0.15, 0.0, slope);

Flacher Boden in geringer Höhe bekommt Gras. Steile Hänge bekommen Fels. Große Höhe bekommt Schnee, aber nur auf Flächen, die flach genug sind, dass Schnee liegen bleibt. Nahe Meereshöhe kommt Sand. Die Übergänge sind weich und physikalisch motiviert.

Für eine Creator-Welt legst du Höhenschwellen und Blend-Zonen pro Chunk als bemalbare Parameter offen. Creator können die Baumgrenze anheben oder senken, die Schneedecke ausweiten oder einen grasigen Hügel in eine Sandwüste verwandeln, indem sie die Materialregeln ihres Grundstücks anpassen.

GPU-freundliches Laplace-Textur-Blending

Klassisches Textur-Blending, also lineare Interpolation zwischen Schichten, erzeugt entweder sichtbare Nähte oder ausgewaschene, kontrastarme Ergebnisse. Laplace-Pyramiden-Blending löst das, verlangt traditionell aber teure Vorberechnung.

Wronski (NVIDIA, 2025, JCGT) stellt eine GPU-freundliche Variante vor, die in Echtzeit-Shadern ohne Vorberechnung und ohne Zusatzspeicher läuft. Die Technik nutzt die normale Mipmap-Kette als Näherung der Laplace-Pyramide: Taste die Textur auf der aktuellen und auf einer gröberen Mip-Stufe ab, berechne die Differenz (den Laplace-Anteil) und blende die Laplace-Beiträge jeder Schicht.

Das Ergebnis erhält scharfe lokale Merkmale, einzelne Grashalme, Felsrisse, und blendet in größeren Maßstäben weich. Die Kosten sind ein paar zusätzliche Texturabtastungen pro Fragment. Bei Terrain, in dem du pro Pixel 4 oder mehr Materialschichten blendest, ergibt das merklich bessere Ergebnisse als lineares Blending, besonders an den Übergängen zwischen Gras, Fels und Sand.

Phasor Noise für Erosionsdetails

Normales Terrain sieht aus der Nähe oft flach aus, weil die Erosionssimulation auf der Heightmap-Auflösung arbeitet, einem 1-Meter-Gitter. Echtes Terrain hat feinskalige Erosionsmuster wie Rinnen, Runsen und Verwitterungsrisse im Zentimeterbereich.

Grenier et al. (2024, CGF) nutzen Phasor Noise, um Terrain-Mikrodetails in Echtzeit zu ergänzen. Phasor Noise synthetisiert strukturierte Muster, indem es ein stochastisches Phasenfeld definiert, das in periodische Funktionen fließt. Auf Terrain angewandt erzeugt es räumlich variierende Erosionsmuster, die:

• Schmale Rinnen über Maßstäbe hinweg zu größeren Runsen bündeln
• Sich automatisch an der Terrainneigung ausrichten, Erosionsmuster folgen der Falllinie
• Bis zu 32-fache Verstärkung erreichen, also Detail bei 32-facher Heightmap-Auflösung ergänzen
• Vollständig in einem Fragment-Shader mit interaktiven Bildraten laufen

Für eine Browser-Welt läuft Phasor Noise im Terrain-Shader als Detailschicht. Die Heightmap liefert die großskalige Form. Phasor Noise ergänzt im Fragment-Shader überzeugende Mikroerosion, ohne die Geometriekomplexität zu erhöhen. Die Parameter (Musterfrequenz, Amplitude, Ausrichtung) können pro Biom variieren: tiefe Rinnen auf nacktem Fels, sanfte Wellen auf Sanddünen, raue rindenartige Struktur auf getrocknetem Schlamm.

Virtual Texturing für Terrain

In großen Maßstäben wird der Terrain-Texturatlas unhandlich. Eine Welt von 4 km x 4 km mit einem Texel pro Zentimeter bräuchte eine Textur von 400.000 x 400.000 Pixeln. Offensichtlich unmöglich.

Virtual Texturing, auch Megatexture genannt, aus id Softwares Rage, löst das, indem es die Terraintextur als gepagete Struktur behandelt. Die vollständige Textur existiert konzeptuell, aber nur die auf dem Bildschirm sichtbaren Kacheln liegen im GPU-Speicher.

Die Pipeline:

1. Feedback-Durchgang: Rendere das Terrain mit einem Shader, der ausgibt, welche Texturkachel jedes Pixel braucht (Kachel-ID und Mip-Stufe). Lies das zur CPU zurück oder verarbeite es mit einem Compute Shader.
2. Kacheln laden: Lade angeforderte Kacheln vom CDN oder erzeuge sie prozedural aus den Splat-Map-Daten.
3. Indirektionstextur: Eine kleine Textur bildet virtuelle Kachelkoordinaten auf physische Kachelkoordinaten in einem Texturatlas ab.
4. Render-Durchgang: Der Terrain-Shader schlägt in der Indirektionstextur die richtige physische Kachel nach und tastet die Materialtextur aus dem Atlas ab.

WebGPUs Compute Shader können Feedback-Analyse und Verwaltung der Seitentabelle vollständig auf der GPU erledigen. Die CPU verwaltet nur die Kachel-Ein- und Ausgabe.

Das Ergebnis: Terrain mit einmaliger Texturierung in jeder Auflösung, ohne Explosion des Texturspeichers. Kacheln weit von der Kamera laden in geringer Auflösung. Nahe Kacheln laden hochauflösend. Der Gesamtspeicherverbrauch bleibt in einem festen Budget, typischerweise 128 bis 256 MB Texturatlas.

Dynamische Terraineffekte

Pfützen und Nässe

Regen fällt nicht nur. Er sammelt sich. In Senken bildet er Pfützen. Auf Flächen erzeugt er nassen Glanz. An steilen Hängen läuft er ab. Das zu simulieren lässt Wetter mit dem Terrain verbunden wirken statt als rein visuelle Auflage.

Der shaderbasierte Ansatz simuliert keine Fluiddynamik. Er nutzt die Terrain-Heightmap, um zu bestimmen, wo sich Wasser sammelt:

float concavity = heightCenter * 4.0 - heightLeft - heightRight - heightUp - heightDown;
float puddleDepth = max(0.0, concavity * rainIntensity - evaporationRate * timeSinceRain);
float wetness = smoothstep(0.0, 0.02, puddleDepth);

vec3 wetColor = baseColor * 0.7;
float wetRoughness = baseRoughness * 0.3;
vec3 finalColor = mix(baseColor, wetColor, wetness);
float finalRoughness = mix(baseRoughness, wetRoughness, wetness);

Konkave Bereiche, also der negative Laplace-Operator der Heightmap, sammeln Wasser. Je tiefer die Wölbung, desto größer die Pfütze. Nasse Flächen dunkeln nach und werden reflektierender, also weniger rau. Der Effekt verblasst mit der Zeit, nachdem der Regen aufhört.

Für volle Pfützenspiegelungen ergänzt du einen planaren Reflexionsdurchgang an der Pfützenoberfläche. Oder du nimmst Screen-Space Reflections (SSR), die günstiger sind und in den Post-Processing-Stapeln von Three.js und Babylon.js schon vorliegen.

Regentropfen auf Pfützenoberflächen nutzen eine einfache 2D-Wellengleichung in einer Feedback-Textur (Saurel, 2026, Blog). Jeder Tropfen erzeugt eine Welle, die nach außen läuft und abklingt. Die Wellentextur moduliert die Normal Map der Pfütze und erzeugt bei 60 fps überzeugende Kräuselmuster.

Fußspuren und Terrainverformung

Läuft ein Spieler auf weichem Terrain wie Sand, Schnee oder Schlamm, verstärken Fußspuren das Gefühl körperlicher Anwesenheit. Die Technik: Halte pro Chunk eine kleine Verformungstextur (64x64 Pixel gleich 4 KB), die Höhenverschiebungen speichert. Tritt eine Figur auf weiches Terrain, stempele eine Fußspurform in die Verformungstextur.

Der Terrain-Vertex-Shader liest die Verformungstextur und zieht die Verschiebung von der Höhe ab. Der Terrain-Fragment-Shader dunkelt den Fußspurbereich ab, verdichteter Boden ist dunkler, und erhöht die Rauheit, weil die Oberfläche gestört ist.

Fußspuren verblassen mit der Zeit, Schnee füllt sie auf, Regen wäscht Schlammspuren weg, indem die Verformungstextur allmählich auf null gesetzt wird. Die Verblassrate hängt vom Wetter ab: schnell bei Regen, langsam bei Trockenheit.

Für eine Multiplayer-Welt sind Fußspurdaten flüchtig und lokal. Jeder Client erzeugt Fußspuren für sichtbare Spieler. Die Verformungstextur muss nicht zwischen Clients synchronisiert werden, jeder sieht seine eigene Version vergänglicher Spuren. Das erspart die Netzwerkkosten, jeden Schritt zu senden.

Prozeduraler Himmel und Tag-Nacht-Wechsel

Der Himmel ist die größte sichtbare Fläche jeder offenen Welt. Er setzt die Stimmung für das gesamte Terrain.

Three.js hat ein vollständiges Himmelssystem mit prozeduraler Sonne und Mond, Tag-Nacht-Wechsel, Wolken, Sternen und Lensflares. Das eingebaute Three.js-Beispiel Sky (auch als WebGPU-Variante verfügbar) setzt Preethams analytisches Himmelsmodell um.

Für physikalisch genauere Ergebnisse setzt webgpu-sky-atmosphere Hillaires Atmosphärenmodell als WebGPU-Post-Process um. Es unterstützt mehrere Streuphasenfunktionen und erzeugt korrekte Luftperspektive (fernes Terrain wirkt hazig), Sonnen- und Sonnenuntergangsfarben sowie Himmelsverläufe aus ersten Prinzipien.

TerrainView7 zeigt Planetenrendering in Originalgröße in WebGPU mit vorberechneter atmosphärischer Streuung und beweist, dass physikalisch genaues Atmosphärenrendering im Browser läuft.

Für eine Creator-Welt werden die Himmelsparameter (Sonnenstand, Wolkendeckung, Trübungsdichte) über die Weltuhr des Servers auf allen Clients synchronisiert. Der Himmels-Shader läuft lokal auf jedem Client und erzeugt für alle Spieler dieselbe Beleuchtung.

Terrainbeleuchtung: indirekte Ausleuchtung

Direktes Sonnenlicht erledigen Shadow Maps. Aber Farbe und Helligkeit von Terrain im Schatten, also Umgebungs- und indirektes Licht, sind für die Bildqualität ebenso wichtig. Reinschwarze Schatten sehen falsch aus. Schatten sollten von der Himmelsfarbe getönt sein, blau an einem klaren Tag, grau bei Bewölkung.

Für eine Browser-Welt ist der praktische Ansatz:

Indirekte Beleuchtung im Bildschirmraum mit Sichtbarkeits-Bitmaske (Jimenez et al., 2023, Paper) verbessert normales SSAO, indem sie pro Pixel 32 gerichtete Sichtbarkeitssektoren verfolgt. Das erfasst nicht nur, wie verdeckt ein Punkt ist, sondern die Richtung der Verdeckung. Dünne Flächen lassen Licht von der anderen Seite korrekt durch. Das Ergebnis ist indirekte Ausleuchtung, die auf nahe Geometrie reagiert, ohne Infrastruktur für Global Illumination.

Die Kosten entsprechen SSAO, also 1 bis 2 ms. Die visuelle Verbesserung ist deutlich: Terrain in Schluchten nimmt Bounce-Licht von den Schluchtwänden auf. Die Unterseiten von Überhängen werden von Bodenreflexion beleuchtet. Der Effekt verbindet sich mit der atmosphärischen Streuung des Himmels-Shaders zu physikalisch motivierter Umgebungsbeleuchtung.

Physik-Integration für Terrain

Rapiers Heightfield-Collider

Rapiers WASM-Physik-Engine bietet native Heightfield-Collider, optimiert für Terrain. Einen Terrain-Collider zu erzeugen ist unkompliziert:

const heights = new Float32Array(65 * 65);
// Fill with heightmap data...
const groundCollider = RAPIER.ColliderDesc.heightfield(
  64, 64, heights, new RAPIER.Vector3(64.0, 100.0, 64.0)
);
world.createCollider(groundCollider);

Der Heightfield-Collider nutzt das strukturierte Gitter für effiziente Broadphase-Abfragen. Ein Raycast gegen ein Heightfield ist O(log n) statt O(n) wie bei einem Dreiecksnetz. Bei einem 65x65-Chunk lösen Kollisionsabfragen in Mikrosekunden auf.

Für Chunks mit volumetrischem Terrain, also SDF-Auflagen, erzeugst du aus der Marching-Cubes-Ausgabe ein Dreiecksnetz und nutzt einen Trimesh-Collider. Der ist teurer als ein Heightfield-Collider, verkraftet aber beliebige Geometrie. Erzeuge Trimesh-Collider nur für die 3 bis 5 Chunks, die dem Spieler am nächsten sind. Ferne Chunks brauchen keine Physik.

Leistung: Rapiers Heightfield-Collider für einen 65x65-Chunk kostet etwa 0,1 ms pro Physikschritt für Abfragen des Charaktercontrollers. 5 aktive Chunks mit Heightfield-Collidern: 0,5 ms. Ein Trimesh-Collider für einen volumetrischen Chunk: 0,2 bis 0,5 ms. Gesamtbudget für Terrainphysik: unter 1 ms, deutlich innerhalb der 2 bis 3 ms Physikbudget für die ganze Welt.

Terrainbewusster Charaktercontroller

Der Charaktercontroller muss auf Terraineigenschaften reagieren:

• Neigungsgrenze: Die Figur kann Hänge bis 45 Grad gehen. Steilere Hänge lassen sie rutschen. Das nutzt die Terrainnormale an der Figurenposition, günstig aus dem Heightmap-Gradienten berechnet.
• Reaktion auf Oberflächenmaterial: Auf Fels zu gehen erzeugt andere Schrittgeräusche und Bewegungsgeschwindigkeit als auf Sand oder Schlamm. Die Splat Map des Terrains liefert an jedem Punkt das Oberflächenmaterial.
• Stufen erklimmen: Die Figur kann Vorsprünge bis 0,5 Meter hochsteigen. Rapiers KinematicCharacterController erledigt das automatisch mit konfigurierbarer Stufenhöhe.

Interaktives Terrain-Bearbeiten im Browser

In einer Creator-Welt wird Terrain nicht nur erzeugt. Es wird von Spielern modelliert, verändert und umgeformt. Die Werkzeuge müssen reaktionsschnell sein, also sofortiges visuelles Feedback geben, und vernetzt, sodass andere Spieler Änderungen binnen Sekunden sehen.

WebGPU-SDF-Editor

Reinder Nijhoffs WebGPU SDF Editor zeigt, dass vollwertiges SDF-Modellieren heute im Browser funktioniert. Der Editor unterstützt:

• Sechs Grundformen (Kugel, Box, Kegel, Zylinder, Kapsel, Torus) mit Position, Rotation und Skalierung
• Boolesche Operationen (Vereinigung, Subtraktion, Schnitt) mit weichem Blending und konfigurierbaren Blend-Radien
• Hierarchische Szenengraphen mit Gruppen und verschachtelten Operationen
• Echtzeit-Rendering über mehrere GPU-Compute-Shader-Stufen, octree-basierte Raumaufteilung über 16.384 Gitterzellen und Oberflächenextraktion per Marching Cubes oder Surface Nets
• Temporales Antialiasing und Ambient Occlusion über Shadow Maps

Jede Grundform wird als 28 Floats (112 Byte) in einem einzigen GPU-Buffer gespeichert. Diese kompakte Darstellung heißt, dass eine komplexe Terrainbearbeitung, also dutzende SDF-Grundformen für einen Höhleneingang, einen Bogen oder eine geschnitzte Felswand, unter 5 KB wiegt und sofort zu anderen Spielern synchronisiert.

Für eine Creator-Welt sieht der SDF-Bearbeitungs-Workflow so aus:

1. Der Creator wählt ein Modellierwerkzeug (Kugel hinzufügen, Box abziehen, weich blenden)
2. Klicken und Ziehen in der Welt platziert und dimensioniert die SDF-Grundform
3. Der Client führt sofort Marching Cubes auf dem geänderten SDF aus, um das lokale Mesh zu aktualisieren (Feedback in unter 16 ms)
4. Die SDF-Bearbeitung (Formtyp plus Transformation plus Blend-Modus, rund 100 Byte) geht an den Server
5. Der Server prüft die Bearbeitung (innerhalb des Grundstücks des Creators, ohne Überschneidung mit geschützten Flächen) und verteilt sie an nahe Spieler
6. Die Clients der anderen Spieler wenden die SDF-Bearbeitung an und erzeugen ihr lokales Mesh neu

Die Gesamtlaufzeit, bis eine Bearbeitung für andere sichtbar ist: 100 bis 300 ms, je nach Netzwerklatenz. Der Creator sieht seine Bearbeitung sofort, weil sie lokal vor der Serverbestätigung angewandt wird.

Pinselbasiertes Heightmap-Bearbeiten

Für die Heightmap-Schicht, also die 90 % Terrain ohne volumetrische Merkmale, genügt ein einfacheres Bearbeitungsmodell. Der Creator malt Höhenänderungen mit einem Pinsel:

• Anheben und absenken: Höhe in einem Radius mit Abfall addieren oder subtrahieren
• Glätten: Höhen in einem Radius mitteln und scharfe Merkmale entfernen
• Planieren: Alle Höhen in einem Radius auf einen Zielwert setzen
• Erosionspinsel: Ein paar Schritte hydraulischer Erosion lokal im Pinselradius anwenden

Die Heightmap-Bearbeitung ist ein Delta: ein kleines Patch aus Höhenänderungen, das über dem Basisterrain liegt. Das Delta-Patch ist winzig (ein 32x32-Gitter aus 16-Bit-Höhenoffsets gleich 2 KB) und geht als eine einzige Nachricht an andere Spieler. Mehrere Delta-Patches sammeln sich pro Chunk und werden serverseitig periodisch in die dauerhafte Heightmap des Chunks zusammengeführt.

Randbedingungen für gemeinsames Bearbeiten

Bearbeiten mehrere Creator denselben Chunk gleichzeitig, braucht das System Regeln:

• Räumliches Sperren: Nur ein Creator darf eine bestimmte Teilfläche von 8x8 Metern gleichzeitig bearbeiten. Die Sperre wird beim Beginn eines Pinselstrichs erworben und beim Abheben des Pinsels freigegeben. Sperren laufen nach 10 Sekunden Inaktivität aus.
• Nicht überlappende Bearbeitungen: Bearbeiten zwei Creator verschiedene Teile desselben Chunks, greifen beide Bearbeitungen ohne Konflikt, sie verändern verschiedene Heightmap-Zellen oder SDF-Regionen.
• Überlappende Bearbeitungen: Bearbeiten zwei Creator dieselbe Stelle, serialisiert der Server die Bearbeitungen in Eingangsreihenfolge. Beide Clients sehen nach dem Abgleich dasselbe Endergebnis.

Das ist einfacher als der vollständige CRDT-Ansatz für platzierte Objekte, weil Terrainbearbeitungen additive Operationen auf einem kontinuierlichen Feld sind (Höhen, SDF-Abstände) und nicht diskreter Objektzustand.

Virtuelle Geometrie im Nanite-Stil in WebGPU

Nanite in der Unreal Engine 5 rendert Milliarden Dreiecke, indem es zur Build-Zeit einen Cluster-DAG (gerichteten azyklischen Graphen) baut und zur Laufzeit pro Cluster anhand des Fehlers im Bildschirmraum das richtige LOD wählt. Die gesamte Pipeline läuft auf der GPU. Dieser Ansatz wurde nach WebGPU portiert.

Nanite WebGPU

Nanite WebGPU rendert eine vollständige Szene in Chrome, mit Meshlet-LOD, Software-Rasterisierung in WGSL-Compute-Shadern und Frustum- sowie Occlusion-Culling pro Meshlet. Kein natives Plugin, reines WebGPU.

Nanite WebGPU von Scthe (über 1.100 GitHub-Sterne) ist eine vollständige Browser-Umsetzung der Kernarchitektur von Nanite:

• Meshlet-LOD-Hierarchie, offline mit der Cluster-Erzeugung von meshoptimizer gebaut
• Software-Rasterizer, umgesetzt in WGSL-Compute-Shadern, innerhalb der Grenzen von WebGPU, wo Hardware-Rasterisierung Draws pro Cluster nicht effizient leisten kann
• Culling pro Instanz und pro Meshlet über Frustum- und Occlusion-Tests
• Billboard-Impostoren für extrem ferne Objekte
• Unterstützung für Texturen und Normalen pro Vertex

Die Pipeline: Meshes werden in Cluster von rund 128 Dreiecken zerlegt. Benachbarte Cluster werden gruppiert, und jede Gruppe wird vereinfacht (mit meshoptimizer), wobei geteilte Grenzen erhalten bleiben. Das wiederholt sich rekursiv, bis das gesamte Mesh auf einen einzigen Cluster zusammenfällt. Zur Laufzeit läuft ein Compute Shader den DAG ab und wählt pro Gruppe den gröbsten Cluster, der bei der aktuellen Bildschirmauflösung weniger als 1 Pixel Fehler erzeugt.

THREE-Nanite ist eine entstehende Three.js-Umsetzung, die auf integrierter Grafik 20 bis 40 fps erreicht und dabei Hunderttausende Dreiecke bewältigt. Sie zeigt, dass Rendering im Nanite-Stil selbst auf schwacher Browser-Hardware tragfähig ist.

meshoptimizer: die Grundlage der LOD-Pipeline

meshoptimizer von Arseny Kapoulkine ist die Bibliothek hinter den meisten browserkompatiblen LOD-Pipelines. Version 1.0 (2025) bietet:

• Mesh-Vereinfachung mit Fehlermetriken, also wie stark sich die Form geändert hat, genutzt für die LOD-Auswahl
• Cluster-Erzeugung für Meshlet-Hierarchien im Nanite-Stil
• Vertex-Cache-Optimierung für GPU-freundliche Dreiecksreihenfolge
• Overdraw-Optimierung, um Pixel-Shader-Kosten zu senken
• Vertex-Quantisierung und -Kompression für kleinere Downloads

meshoptimizer 1.0, erschienen im Dezember 2025, liefert ein neues Single-Header clusterlod.h, das kontinuierliches LOD im Nanite-Stil direkt umsetzt. Es baut eine Hierarchie von Clustern, die fortschreitend gruppiert und vereinfacht werden, nutzbar so wie sie ist oder als Referenz für eine eigene Pipeline. Genau dieses Cluster-DAG-Primitiv braucht die Terrain-Pipeline für das Mesh-LOD von SDF und Marching Cubes.

Für unsere Terrain-Pipeline verarbeitet meshoptimizer die Marching-Cubes-Ausgabe des SDF-Terrains zu optimierten, geclusterten Meshes mit LOD-Hierarchien. Die Offline-Verarbeitung läuft serverseitig. Der Browser erhält vorab geclusterte Meshes und trifft die LOD-Auswahl zur Laufzeit GPU-getrieben.

Die Kombination aus meshoptimizer für die LOD-Erzeugung und WebGPU-Compute für die Laufzeitauswahl gibt Browser-Terrain dasselbe Architekturmuster wie Nanite, angepasst an die Randbedingungen des Webs.

Terrainbewusstes Leveldesign

Terrain ist nicht nur eine Fläche, auf der man geht. Seine Form lenkt die Spielerbewegung, richtet Aufmerksamkeit aus und erzeugt den emotionalen Rhythmus des Erkundens. Die besten offenen Welten nutzen Terrain als Designwerkzeug.

Sichtlinien und Landmarken

Das Kapitel Wayfinding im Level Design Book dokumentiert, wie Terrainhöhe steuert, was Spieler sehen und wohin sie gehen. Ein Grat verbirgt, was dahinter liegt, und erzeugt Neugier. Ein Tal bündelt Bewegung zu seinem tiefsten Punkt. Eine hohe Landmarke wie ein Turm, ein Berggipfel oder ein auffälliger Baum, aus der Ferne sichtbar, gibt Spielern ein Ziel, auf das sie zugehen.

Für eine Creator-Welt heißt das, dass die Terraingenerierung natürliche Wegfindungsmerkmale erzeugen sollte. Gratlinien sollten Sichtlinien brechen und "Enthüllungsmomente" schaffen, wenn ein Spieler einen Hügel erklimmt und ein neues Gebiet sieht. Täler sollten auf interessante Orte zulaufen. Erhöhte Punkte sollten existieren, an denen Creator weithin sichtbare Landmarken setzen können.

Erkunden aus Neugier

Forschung der Purdue University (Paper) benennt vier Auslöser für räumliches Erkunden:

1. Extrempunkte erreichen (höchster Gipfel, äußerster Rand, tiefste Höhle). Terrain sollte klare Extreme haben, die das Erreichen belohnen.
2. Sichtverdeckungen auflösen (was ist hinter dieser Klippe? in dieser Höhle?). Terrain, das die Sicht blockiert, motiviert Bewegung, um das Verborgene zu finden.
3. Objekte, die nicht dorthin gehören (ein Bauwerk in der Wildnis, ein Licht in der Dunkelheit). Von Creators platzierte Objekte im Kontrast zu natürlichem Terrain ziehen Aufmerksamkeit.
4. Räumliche Zusammenhänge verstehen (wie verbindet sich dieses Tal mit jener Küste?). Terrain mit lesbarer Geografie fördert Kartenlesen und Routenplanung.

PlotMap: KI-gestützte Platzierung von Points of Interest

PlotMap (arXiv:2309.15242) automatisiert das Layout von Points of Interest, indem es narrative Anforderungen nimmt (diese Quest braucht ein Dorf am Fluss, jene eine Ruine auf einem Hügel) und Terrainorte findet, die die räumlichen Randbedingungen erfüllen. Für eine Creator-Welt könnte ein ähnliches System vorschlagen, wo Bauwerke nach Terraineigenschaften hingehören: "dieser Hügel hat gute Sichtlinien für einen Wachturm", "dieses geschützte Tal würde zu einem Dorf passen".

Fließendes Wasser und Wasserfälle

Flüsse und Wasserfälle sind Terrainmerkmale, die optischen Reiz mit Umgebungsklang und spielerischer Funktion verbinden, Wasser als Hindernis, Ressource oder Weg.

Flüsse rendern

Flüsse in offenen Welten werden üblicherweise als texturierte Bänder gerendert, die der Terrainoberfläche folgen. Das Bandmesh wird aus dem Fluss-Spline erzeugt, gespeichert als Kontrollpunkte, und auf die Terrain-Heightmap projiziert. Der Fluss-Shader wendet an:

• Flussrichtungs-UVs, die in Fließrichtung scrollen und den Eindruck fließenden Wassers erzeugen
• Schaum an den Rändern, wo der Fluss das Ufer trifft, tiefenbasiert, ähnlich wie Uferschaum
• Geschwindigkeitsvariation nach Gerinnebreite, enge Abschnitte fließen schneller, weite langsamer
• Transparenz mit tiefenabhängiger Farbe, flach ist klar, tief ist dunkel

Für eine Browser-Welt sind Flussdaten kompakt: ein Spline (20 bis 50 Kontrollpunkte pro Flussabschnitt, rund 400 Byte) plus Parameter für Breite und Fließgeschwindigkeit. Der Client erzeugt das Flussmesh lokal, indem er den Spline auf seine Terrainoberfläche projiziert.

Wasserfälle rendern

Wo ein Fluss über eine Felswand stürzt, ersetzt ein Partikelsystem die flache Flussoberfläche. Der hybride Ansatz aus der Forschung zu Echtzeit-Wassersimulation (EG): Regionen, die kein Höhenfeld abbilden kann, also Wasserfälle und Spritzer, werden zu Sprüh-, Spritz- und Schaumpartikeln, die Masse und Impuls mit der Fluidsimulation austauschen.

Für eine Browser-Welt sind Wasserfälle einfacher: Erkenne, wo der Fluss-Spline eine Höhenunstetigkeit im Terrain kreuzt, erzeuge dort ein Partikelsystem mit Abwärtsgeschwindigkeit und ergänze am Fuß einen Schaumspritzer. Die Partikel sind GPU-instanziierte Quads mit scrollenden Alpha-Texturen. 500 Partikel pro Wasserfall, ein Draw Call. Der Klang fallenden Wassers nutzt die Web-Audio-API mit Entfernungsdämpfung.

Impostoren für ferne Terrainmerkmale

Bäume, Steine, Gebäude und andere Terrainmerkmale werden in der Ferne winzig. Sie als vollständige 3D-Meshes zu rendern verschwendet GPU-Zyklen. Impostoren ersetzen ferne Objekte durch vorgerenderte flache Bilder, die zur Kamera zeigen.

Oktaedrische Impostor-Atlanten

Ein oktaedrischer Impostor erfasst das Aussehen eines 3D-Objekts aus mehreren Blickwinkeln und legt sie in einem Texturatlas ab. Zur Laufzeit tastet der Shader den Atlas nach der aktuellen Blickrichtung ab und interpoliert zwischen den beiden nächsten erfassten Winkeln.

Ein hemi-oktaedrischer Atlas, also Ansichten nur aus der oberen Halbkugel, weil man Bäume selten von unten betrachtet, liefert bei gleicher Texturgröße die doppelte Winkelauflösung eines vollen oktaedrischen Atlas. Unitys Impostor-System berichtet, dass die Framezeit von 111 ms auf 5,78 ms fällt, wenn 1.600 Bauminstanzen von echten Meshes (je 140.000 Dreiecke) auf Impostoren umgestellt werden.

Für eine Browser-Welt sieht die Impostor-Pipeline so aus:

1. Serverseitig: Jedes Asset aus 16 bis 32 Blickwinkeln rendern und Farbe, Normale und Tiefe erfassen
2. In eine Atlastextur packen, ein Atlas pro Asset, rund 256x256 Pixel, unter 100 KB als KTX2
3. Zur Laufzeit: Instanzen jenseits der Impostor-Entfernung, typischerweise 100 bis 200 m, werden als Billboards gerendert, die den Atlas abtasten
4. Über eine Übergangszone von 20 m zwischen Mesh und Impostor überblenden, um den Wechsel zu verbergen

Billboard Splatting (BBSplat)

Billboard Splatting (2024, arXiv:2411.08508) geht weiter und nutzt lernbare texturierte planare Grundformen. Statt vorgerenderter Ansichten optimiert BBSplat Billboard-Positionen und -Texturen so, dass sie das 3D-Objekt aus jedem Winkel bestmöglich repräsentieren. Das erreicht bis zu 17-fache Kompression gegenüber 3D-Gaussian-Splatting und erhält dabei das blickwinkelabhängige Aussehen. Für ferne Terrainmerkmale in einer Browser-Welt könnte BBSplat den Impostor-Speicher pro Asset senken und gleichzeitig die Winkelabdeckung verbessern.

Professionelle Terrain-Werkzeuge und was sie lehren

Bevor du eine Terrain-Pipeline von Grund auf baust, lohnt es sich zu verstehen, was professionelle Offline-Werkzeuge tun. Diese Werkzeuge sind Jahrzehnte Terrainforschung, destilliert in Produktions-Workflows.

Gaea (QuadSpinner) ist GPU-beschleunigt und gibt bei Änderungen nahezu sofort Rückmeldung. Es unterstützt gekachelte Builds bis 2 Millionen Pixel Kantenlänge, automatischen LOD-Mesh-Export und einen knotenbasierten Graphen, in dem jeder Knoten ein physikalischer Prozess ist (Erosion, Sedimentation, Hebung, thermische Verwitterung). Gaeas Erosionsknoten erzeugen Terrain, das handmodelliert aussieht, weil sie konkrete physikalische Prozesse modellieren statt allgemeines Rauschen. Die zentrale Einsicht: Gaea nutzt keinen einzigen Erosionsalgorithmus. Es bietet getrennte Knoten für fluviale Erosion (Flussschnitt), thermische Erosion (Felszerfall), Küstenerosion (Wellenwirkung) und Winderosion (Dünenbildung). Sie in einem Graphen zu kombinieren ergibt Terrain mit dem geologischen Charakter eines bestimmten Klimas.

World Machine nimmt einen ähnlichen Graphenansatz mit Fokus auf die Makrostruktur des Terrains. Sein "Layout Generator" lässt Artists die grobe Form von Terrainmerkmalen skizzieren (hier ein Berg, dort ein Tal, entlang dieser Kante eine Küste), und das System füllt physikalisch plausibles Detail auf. Das ist genau der Creator-Workflow, den wir wollen: Absicht skizzieren, Geologie bekommen.

World Creator hebt sich durch Echtzeitvorschau während des Bearbeitens und eingebaute Flussgenerierung ab, die das Terrain analysiert und Fließwege anhand der Entwässerungsanalyse automatisch berechnet.

Was wir aus diesen Werkzeugen mitnehmen: Der Knotengraph-Ansatz zum Kombinieren physikalischer Prozesse ist mächtiger als jeder einzelne Algorithmus. Unsere serverseitige Generierungs-Pipeline sollte Verkettung unterstützen: Rausch-Basis > tektonische Hebung > hydraulische Erosion > thermische Verwitterung > Küstenerosion > Vegetation. Creator steuern die Parameter jeder Stufe. Die Pipeline läuft serverseitig in Sekunden und liefert Heightmaps, Splat Maps und Dichtekarten für Vegetation.

SoilMachine: quelloffene Geomorphologie

SoilMachine koppelt hydraulische, thermische und Winderosion in einem geschichteten Terrainmodell. Die mehrschichtige Datenstruktur trägt Merkmale, die Heightmaps nicht abbilden können: Höhlen, Überhänge, Tafelberge und Grundwasserverteilungen.

SoilMachine ist ein quelloffener modularer Geomorphologie-Simulator, der mehrere Erosionssysteme (hydraulisch, thermisch, Wind) mit Sedimenttransport und -ablagerung koppelt. Gebaut in C++ mit GPU-Compute, liefert er eine Referenzumsetzung des Mehrprozess-Erosionsansatzes, den professionelle Werkzeuge nutzen.

Die zugehörige Bibliothek soillib (C++20, MIT-Lizenz) stellt die zugrunde liegenden Geomorphologie-Primitive als wiederverwendbare Bibliothek bereit. Und hydro-gen setzt sowohl gitterbasierte (Shallow Water) als auch partikelbasierte (Regentropfen) hydraulische Erosion in OpenGL-Compute-Shadern um, mit Parameteranpassung in Echtzeit.

Diese quelloffenen Werkzeuge könnten für unsere serverseitige Generierungs-Pipeline angepasst werden. Die Compute-Shader-Umsetzungen übertragen sich direkt auf WebGPU, falls wir Erosion je im Browser laufen lassen wollen, für Creator-Feedback in Echtzeit.

Mehrschichtige Terrainmaterialien

Echtes Terrain ist keine einzelne Oberfläche. Es sind Schichten: Grundgestein unten, Boden darauf, Schnee oder Sand, der sich auf Flächen sammelt. Dynamische Schichtung verändert den visuellen Charakter des Terrains mit Jahreszeiten, Wetter und Creator-Handlungen.

Geschichtete Höhenfeld-Repräsentation

Statt einer einzelnen Heightmap nutzt du pro Gitterzelle mehrere Höhenschichten:

Cell {
  bedrock_height: f16,    // permanent rock surface
  soil_height: f16,       // accumulated soil/sediment above bedrock
  snow_height: f16,       // dynamic snow accumulation
  water_height: f16       // standing water depth
}

Insgesamt: 8 Byte pro Zelle, gegenüber 2 Byte für eine einzelne Heightmap. Bei einem 65x65-Chunk sind das 34 KB vor Kompression. Weiterhin kompakt.

Die sichtbare Oberfläche ist bedrock + soil + snow. Der Terrain-Shader liest alle Schichten und blendet Materialien entsprechend: Wo der Boden dünn ist, scheint Fels durch. Wo Schnee liegt, ist die Fläche weiß. Wo Wasser steht, bekommst du Pfützen oder Seen.

Dynamische Akkumulation

Schnee sammelt sich bei Schneefall auf flachen, nach oben zeigenden Flächen. Die Akkumulationsrate hängt von der Oberflächennormale ab (steile Hänge halten keinen Schnee), von der Temperatur (höhenabhängig) und von Schutz (Bereiche unter Überhängen bleiben frei). Ein Compute-Shader-Durchgang aktualisiert die Schneeschicht einmal pro Wetter-Tick, also alle paar Sekunden.

Sandakkumulation funktioniert ähnlich mit windgetriebener Ablagerung. Wind trägt Partikel von freiliegenden Flächen und lagert sie hinter Hindernissen und in geschützten Bereichen ab.

Für eine Creator-Welt heißt dynamische Akkumulation, dass das Terrain bei verschiedenem Wetter anders aussieht. Schnee bedeckt die Welt im Schneesturm und schmilzt in einer klaren Phase. Regen füllt Senken mit Wasser. Das lässt die Welt reagieren, ohne dass Creator etwas tun müssen.

Mehrschichtige Erosion

Das Paper "3D Real-Time Hydraulic Erosion Simulation using Multi-Layered Heightmaps" von 2024 (EG) erweitert Erosion auf mehrere Schichten. Wasser erodiert Boden schneller als Grundgestein. Sediment lagert sich als neue Bodenschicht ab. Die Simulation erhält die Schichtintegrität, Grundgestein bleibt unter Boden, und ermöglicht dabei komplexe Merkmale wie Überhänge, wo Grundgestein über erodiertem Boden auskragt.

Leistung: etwa 6 ms pro Simulationsschritt auf einer RTX 3070 bei 2048x2048 Auflösung. Das ist für serverseitige Generierung schnell genug, für eine Simulation pro Frame im Browser aber zu langsam. Die geschichtete Repräsentation funktioniert für statische Terraingenerierung, und die dynamische Schnee- und Wasserakkumulation läuft als günstigerer Shader pro Frame.

Gras, Fels und Detail-Rendering

Die Landschaft braucht mehr als Terraingeometrie und Texturen. Sie braucht Grashalme, die im Wind wiegen, Steine auf Hängen und kleine Details wie Blumen, Kiesel und abgefallene Zweige, die Nahansichten natürlich aussehen lassen.

GPU-instanziiertes Gras

Eine Million Grashalme mit GPU-Instancing in einem einzigen Draw Call gerendert. Dieselbe Technik funktioniert in Three.js und WebGPU: Transformationen pro Instanz, Windanimation im Vertex-Shader und eine Dichtekarte, um Halme aus Terraindaten zu verteilen.

Browserbasiertes Gras-Rendering ist in Three.js gut erprobt und funktioniert über GPU-Instancing. Der Ansatz aus al-ros Gras-Demo rendert 100.000 Grashalme mit einem einzigen Draw Call über InstancedBufferGeometry.

Jeder Grashalm ist ein einfaches Quad, 4 bis 8 Dreiecke. Attribute pro Instanz legen Position, Höhe, Biegerichtung, Farbvariation und Windphase fest. Der Vertex-Shader:

1. Liest die Transformation der Instanz
2. Wendet Windanimation über Sinuswellen an, gekoppelt an Weltposition und Zeit
3. Biegt den Halm nach Windstärke, mehr Biegung an der Spitze, keine an der Basis
4. Legt einen Farbverlauf an, dunkler an der Basis, heller an der Spitze für Subsurface Scattering

Codrops' Tutorial zu fluffigem Gras (2025, Tutorial) zeigt einen Shell-Texturing-Ansatz: Rendere die Bodenebene mehrfach mit zunehmendem Versatz, wobei jede Schicht eine Noise-Textur abtastet, um den Eindruck eines dichten Grasvolumens zu erzeugen. Das ist bei sehr dichter Bedeckung günstiger als das Instanzieren einzelner Halme, aus der Nähe aber weniger realistisch.

Für eine Creator-Welt kommt die Grasdichte aus der Vegetations-Dichtekarte pro Chunk. Die GPU verteilt Halmpositionen zur Renderzeit aus der Dichtekarte. Es werden keine Daten pro Halm gespeichert oder gestreamt. Die Dichtekarte ist pro Chunk ein 32x32-Gitter (1 KB), und die GPU erzeugt daraus Tausende Halminstanzen.

Prozedurales Fels- und Klippendetail

Felswände und felsiges Terrain brauchen geometrisches Detail, das die Basis-Heightmap oder das SDF in vernünftiger Auflösung nicht liefern kann. Zwei Ansätze ergänzen sich:

Resurfacing per GPU-Mesh-Shader (Raad et al., Eurographics 2025, Paper) erzeugt prozedurale Geometrie zur Renderzeit aus einem groben Kontrollnetz. Der Mesh-Shader liest eine Basis-Terrainfläche und ergänzt Verschiebung, Risse und Vorsprünge, ohne die Detailgeometrie im Speicher zu halten. Das senkt den VRAM-Bedarf und ermöglicht dynamisches LOD.

Instanziiertes Felsverteilen setzt vorgefertigte Fels-Meshes über GPU-Instancing auf steile Hänge und Klippenkanten. Ein Compute Shader liest Terrainnormale und Neigung und verteilt Felsinstanzen dort, wo die Neigung eine Schwelle übersteigt. Jede Instanz ist ein kleines Mesh von 200 bis 500 Dreiecken mit zufälliger Drehung und Skalierung. 10.000 verteilte Steine kosten mit Instancing vernachlässigbar viel Rechenzeit.

Straßen und Wege

Von Creators platzierte Straßen, Trampelpfade und Wege müssen sich dem Terrain anpassen und das Oberflächenmaterial verändern, also Gras durch Erde oder Stein ersetzen.

Der Ansatz jeder großen Game-Engine: Definiere den Weg als Spline, eine Reihe von Kontrollpunkten. Projiziere den Spline auf die Terrainoberfläche. Erzeuge ein Bandmesh, das dem Spline folgt und leicht über dem Terrain liegt. Leg eine Straßentextur auf das Band. Blende im Terrain-Shader das Terrainmaterial innerhalb der Spline-Breite über eine projizierte Textur oder ein Decal zum Straßenmaterial.

Für eine Browser-Welt zeichnet ein Creator einen Weg auf das Terrain. Der Client erzeugt Kontrollpunkte und schickt sie an den Server, einige Dutzend vec3-Werte. Der Server speichert den Spline. Alle Clients rendern das Straßenband lokal, indem sie den Spline auf ihr Terrainmesh projizieren. Die Straßendaten sind winzig, Spline-Punkte, vielleicht 200 Byte, die visuelle Wirkung ist aber groß: Wege, die Creator-Bauten verbinden, lassen die Welt bewohnt wirken.

Schatten für Terrain

Terrainschatten sind entscheidend für Lesbarkeit, also das Verstehen der Terrainform, und für Atmosphäre, also die Stimmung der Tageszeit. In einer offenen Welt wirft die Sonne Schatten über das gesamte sichtbare Terrain.

Cascaded Shadow Maps (CSM)

CSM teilt das Sichtfrustum in 3 bis 4 Entfernungsbereiche, die Kaskaden. Jede Kaskade rendert eine Shadow Map aus Sonnenperspektive in einer Auflösung, die zu ihrer Entfernung passt. Nahe Kaskade: hohe Auflösung, detaillierte Schatten unter Bäumen und Gebäuden. Ferne Kaskade: niedrige Auflösung, breite Bergschatten.

Three.js und Babylon.js unterstützen beide CSM. Die entscheidende Optimierung fürs Terrain: Rendere in der Shadow Map nur das Terrain, keine einzelnen Grashalme oder Kleindetails. Gras beschattet sich über die Shadow Map des Terrains, nicht über eine eigene.

Leistungsbudget: 3 bis 4 Schattenkaskaden mit je 1024x1024. Terrain in Shadow Maps zu rendern kostet 0,5 bis 1 ms, die Terraingeometrie liegt ohnehin im GPU-Speicher. Das Abtasten von 4 Kaskaden im Terrain-Shader kostet 0,2 bis 0,3 ms.

Terrain-Eigenschattierung aus der Heightmap

Bei sehr großem Terrain, wo CSM teuer wird, berechne eine Horizontkarte vorab: Speichere für jede Terrainzelle den maximalen Höhenwinkel in 8 Himmelsrichtungen. Zur Renderzeit vergleichst du den Sonnenwinkel mit der Horizontkarte, um zu bestimmen, ob ein Punkt im Schatten liegt. So löst Skyrim Eigenschatten für fernes Terrain jenseits der CSM-Reichweite.

Die Horizontkarte wird serverseitig aus der Heightmap berechnet, wenige Sekunden Rechenzeit, und streamt pro Chunk als 128x128-Textur (16 KB komprimiert). Die visuelle Wirkung ist erheblich: Bergtäler dunkeln selbst auf extreme Sichtweiten realistisch nach.

Kompression von Terraindaten fürs Streaming

Das Netz ist der Engpass einer Browser-Welt. Jedes in den Terraindaten gesparte Byte ist eine schnellere Ladezeit.

Heightmap-Kompression

Rohe 16-Bit-Heightmaps komprimieren gut, weil benachbarte Zellen ähnliche Werte haben. Die Pipeline:

1. Delta-Kodierung: Speichere die Differenz zwischen jeder Zelle und ihrem vorhergesagten Wert, dem Mittel der Nachbarn. Delta-Werte sind klein und häufen sich um null.
2. Quantisierung: Reduziere für ferne Chunks die Präzision von 16 Bit auf 12 oder 8 Bit. Auf 500 Meter Entfernung ist 8-Bit-Höhenpräzision (0,4 m Auflösung über 100 m Höhenbereich) von 16 Bit nicht zu unterscheiden.
3. Entropiekodierung: Wende zlib oder brotli auf den delta-kodierten Strom an. Typische Kompressionsrate: 4- bis 8-fach.

Ergebnis: Ein 65x65-Chunk mit 16 Bit geht von 8,4 KB roh auf 1 bis 2 KB komprimiert. Bei reduzierter 8-Bit-Präzision: 0,5 bis 1 KB.

Progressives Heightmap-Streaming

Schick Terrain zuerst in niedriger Auflösung und verfeinere dann. Eine 17x17-Heightmap, das Minimum für einen 64-m-Chunk mit 4 m Zellabstand, sind 578 Byte roh und unter 200 Byte komprimiert. Das Terrain ist sofort sichtbar. Dann streamt die 33x33-Verfeinerung, die die ungeraden Zeilen und Spalten ergänzt. Dann die vollen 65x65. Jede Stufe ergänzt Detail, ohne vorherige Daten zu ersetzen.

Das deckt sich mit den LOD-Ringen der Geometry Clipmaps: Fernes Terrain nutzt die niedrig auflösende Version (17x17), der Mittelbereich die mittlere (33x33), die Nähe die volle (65x65). Die Streaming-Priorität entspricht dem Rendering-LOD.

Kompression von SDF-Volumen

Spärliche SDF-Volumen komprimieren dramatisch, weil die meisten Voxel weit von der Oberfläche liegen, also leerer Raum sind. Optionen:

Lauflängenkodierung: Kodiere Läufe identischer Werte, also leere Voxel. Typische SDF-Volumen sind über 95 % leer, RLE erreicht also 10- bis 50-fache Kompression.

Spärlicher Octree: Speichere nur Octree-Knoten, die oberflächenschneidende Voxel enthalten. Leerer Raum hat keine Knoten. Ein 64³-SDF-Volumen mit einem einzelnen Höhlentunnel hat vielleicht nur 2.000 bis 5.000 belegte Knoten, gegenüber 262.144 Voxeln insgesamt, jeder mit 1 bis 2 Byte gespeichert.

Entropiegetriebene progressive Kompression (2024, HAL) greift bei 3D-Raumdaten, indem sie den Raum rekursiv mit entropieoptimierten Ebenen und adaptiver Quantisierung partitioniert. Das ergibt einen Strom von Verfeinerungen, optimiert auf den Kompromiss zwischen Rate und Verzerrung, was besonders bei den niedrigen Bitraten des Netzwerk-Streamings nützt.

Alles zusammen: die Terrain-Pipeline im Browser

Der strategische Überblick oben in diesem Artikel liefert den schnellen Entscheidungsrahmen und den Bauplan in Phasen. Dieser Abschnitt liefert das vollständige technische Detail für die serverseitige Generierungs-Pipeline und die Rendering-Pipeline im Browser.

Generierungs-Pipeline (serverseitig)

Die Generierungs-Pipeline läuft als gerichteter Graph physikalischer Prozesse, inspiriert vom Knotengraph-Ansatz von Gaea und World Machine. Jede Stufe nimmt die Ausgabe der vorherigen und verfeinert sie. Creator steuern die Parameter jeder Stufe.

Stufe	Eingabe	Prozess	Ausgabe	Zeit
1. Basisterrain	Seed oder Text-Prompt	Terrain Diffusion / MESA / Rauschen plus fBm	16-Bit-Heightmap	1-5 s
2. Erosion	Heightmap	analytisches Stream Power plus thermische Erosion	erodierte Heightmap, Flussakkumulationskarte, Sedimentkarte	0,5-2 s
3. Flüsse	erodierte Heightmap, Flusskarte	Extraktion des Entwässerungsnetzes, Gerinneschnitt	Fluss-Splines, Wasserspiegelkarte	0,5 s
4. Küste	Heightmap nahe Meereshöhe	Wellenerosion im NEWTS-Stil	Küstenmerkmale (Klippen, Strände, Brandungspfeiler)	1-3 s
5. Volumetrisch	Heightmap plus Creator-Absicht	Arenite-Erosion / Höhlengenerierung / SDF-Modellierung	spärliche SDF-Volumen für betroffene Chunks	1-60 s
6. Materialien	Heightmap plus Erosionskarten	TerraFusion / Geodiffussr / prozedurale Regeln	Splat Maps, Terraintexturen	1-5 s
7. Vegetation	Heightmap plus Flusskarte plus Materialien	Simulation der Ökosystem-Konkurrenz	Dichtekarten pro Biom pro Chunk	1-3 s
8. Horizontkarten	endgültige Heightmap	maximaler Höhenwinkel in 8 Richtungen	Eigenschattierungstextur pro Chunk	2-5 s
9. Chunking	alle Ausgaben	schneiden, delta-kodieren, komprimieren, hashen	Chunk-Pakete auf dem CDN	5-10 s
Gesamt				15-90 s

Eine neue Welt von 4x4 km entsteht in 15 bis 90 Sekunden. Creator-Bearbeitungen, also Modellieren und Parameteränderungen, führen nur die betroffenen Stufen für die betroffenen Chunks erneut aus, typischerweise in unter 5 Sekunden.

Rendering-Pipeline (Browser)

Schritt	WebGPU-Weg	WebGL-2-Rückfall	Frame-Budget
1. Streaming	Prioritätswarteschlange, vorausschauendes Vorabladen	dasselbe	entfällt (asynchron)
2. Heightmap-Terrain	GPU-getriebener CDLOD-Quadtree, Compute-Culling, Indirect Draw	Geometry Clipmaps, Ring-Aktualisierung auf der CPU	0,5-1 ms
3. Volumetrisches Mesh	Marching Cubes im Compute plus Transvoxel	vorab erzeugte Meshes aus dem Web Worker, 2-3 gecachte LODs	0,5-2 ms
4. LOD-Übergänge	Geomorphing im Vertex-Shader	dasselbe	oben enthalten
5. Materialien	triplanares PBR plus Laplace-Blending plus Phasor-Noise-Detail plus Virtual Texturing	triplanares PBR plus lineares Blending plus vorgebackene Splat Maps	1-1,5 ms
6. Vegetation	ComputeInstanceCulling plus IndirectBatchedMesh, hex-gekachelte Bodendecke	Frustum-Culling auf der CPU plus InstancedMesh	1-1,5 ms
7. Wasser	flussrichtungsorientierte Flussbänder, tiefenbasierter Uferschaum	dasselbe, einfachere Spiegelungen	0,5 ms
8. Schatten	CSM mit 3-4 Kaskaden plus Eigenschatten über Horizontkarte	CSM mit 2 Kaskaden	0,5-1 ms
9. Atmosphäre	Hillaire-Himmelsmodell plus volumetrischer Nebel plus Wetterpartikel	Preetham-Himmel plus Entfernungsnebel	0,5 ms
10. Dynamische Effekte	Pfützenbildung, Fußspurverformung, Schnee und Regen	Pfützenbildung, Regenpartikel	0,3 ms
Terrain gesamt			3,5-6,5 ms

Bei 60 fps, also 16,6 ms pro Frame, verbraucht das Terrain-System auf WebGPU 21 % des Frame-Budgets und auf WebGL 2 39 %. Der Rest bleibt für Spieler-Avatare, Creator-Objekte, UI, Netzwerk und Post-Processing.

Warum das im Browser funktioniert

Die gesamte Pipeline ist um drei Browser-Randbedingungen herum entworfen:

Speicher (maximal 2 bis 4 GB): Das Terrainbudget von 256 MB passt, weil Heightmap-Chunks je 2 bis 8 KB groß sind (delta-kodiert), SDF-Volumen spärlich sind (100 bis 500 KB pro volumetrischem Chunk), Vegetation zur Laufzeit aus 1 KB großen Dichtekarten erzeugt wird und Texturen KTX2-Kompression nutzen (150 KB pro 1024x1024). Zu jedem Zeitpunkt wiegt die im Browser sichtbare Welt insgesamt 50 bis 200 MB.

Kein Festplattenzugriff: Alles streamt über das Netz. Progressives Laden heißt, dass der Spieler Terrain in unter 100 ms sieht (niedrig auflösende Heightmap), texturiertes Terrain in unter 300 ms und volles Detail in unter 3 s. Vorabladen nach Geschwindigkeit verbirgt Ladezeiten beim normalen Erkunden.

Die GPU schwankt enorm: Der WebGPU-Weg bedient High-End-Desktops. Der WebGL-2-Rückfall bedient alles andere, auch Mobilgeräte. Dieselben Chunk-Daten treiben beide Wege. Der Unterschied liegt in der Rendering-Technik, nicht im Datenformat. Ein Chromebook mit WebGL 2 sieht dieselbe Welt wie eine RTX 4090 mit WebGPU, nur mit weniger Detail und kürzerer Sichtweite.

Forschungspapiere

Terrain-Repräsentation und Mesh-Erzeugung

"Marching Cubes: A High Resolution 3D Surface Construction Algorithm" -- Lorensen und Cline (SIGGRAPH 1987). DOI. Der grundlegende Algorithmus, um Dreiecksnetze aus volumetrischen Daten zu extrahieren. 38 Jahre später noch das verbreitetste Verfahren zur Isoflächenextraktion. GPU-parallele Umsetzungen laufen in WebGPU-Compute-Shadern in Echtzeit.

"Dual Contouring of Hermite Data" -- Ju, Losasso, Schaefer, Warren (SIGGRAPH 2002). DOI. Erzeugt Meshes, die scharfe Merkmale erhalten (Klippenkanten, Felsecken), die Marching Cubes abrundet. Braucht zusätzlich zu den Distanzwerten die Oberflächennormalen.

"Neural Dual Contouring" -- Chen et al. (2022). arXiv:2202.01999. Ersetzt die Kleinste-Quadrate-Vertexplatzierung im Dual Contouring durch einen gelernten Prädiktor. Bessere Oberflächenqualität bei komplexen natürlichen Merkmalen.

"The Transvoxel Algorithm" -- Lengyel (2009, aktualisiert 2024). transvoxel.org. Nahtlose LOD-Übergänge für Voxel-Terrain. Beseitigt Risse an Auflösungsgrenzen mit 73 Typen von Übergangszellen. Patentfrei, für Echtzeitanwendungen entworfen.

Terrain-LOD und Rendering

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" -- Losasso und Hoppe (SIGGRAPH 2004). Paper. Terrain-Rendering mit konstanten Kosten über konzentrische LOD-Ringe. Bewältigt 40-GB-Terrains bei interaktiven Raten. Die Grundlage der meisten Browser-Terrain-Renderer.

"CDLOD: Hybrid LOD for Terrain Rendering" -- Strugar (2014). Paper. Quadtree-adaptive Verbesserung der Geometry Clipmaps. Verteilt Auflösung nach Terrainkomplexität statt allein nach Entfernung.

"GPU-Driven Rendering Pipelines" -- Ubisoft (SIGGRAPH 2015), Wihlidal und Hoppe. Hat den GPU-getriebenen Ansatz formalisiert, in dem Compute Shader Culling, LOD-Auswahl und die Erzeugung von Draw Calls übernehmen. Das Architekturmuster unserer WebGPU-Terrain-Pipeline.

Physikalische Terraingenerierung

"Physically-Based Analytical Erosion for Fast Terrain Generation" -- Cordonnier et al. (2024). HAL. Analytische Stream-Power-Erosion, die iterative Simulation vermeidet. Erzeugt physikalisch plausibles Terrain in Millisekunden.

"Fast Hydraulic Erosion Simulation and Visualization on GPU" -- Mei, Decaudin, Hu (2007). HAL. GPU-parallele hydraulische Erosion über Shallow-Water-Simulation. Die Basis der meisten Erosionsumsetzungen in Game-Engines.

"Arenite: A Physics-Based Sandstone Simulator" -- SIGGRAPH 2025. Projekt. Multi-Physik-Erosion, die aus Spannungs- und Erosionssimulation Bögen, Hoodoos und Nischen erzeugt. Läuft auf Desktop-GPUs in unter 5 Minuten.

"Efficient Debris-flow Simulation for Steep Terrain Erosion" -- Purdue CGVLAB (2024). Paper. GPU-beschleunigte Schuttströme und Steilhangerosion, die realistische Gebirgsmerkmale erzeugen.

"Flexible Terrain Erosion" -- IRIT-STORM (2024). Springer. Partikelbasierte Erosion, die über eine einheitliche Schnittstelle auf Heightfields, Voxelgittern, impliziten Oberflächen und geschichteten Materialien arbeitet. Ermöglicht ein Erosionssystem für hybride Terrain-Repräsentationen.

Terraindetail und Texturierung

"GPU-Friendly Laplacian Texture Blending" -- Wronski (NVIDIA, 2025). JCGT. Laplace-Pyramiden-Blending für Terrainmaterialien in Echtzeit, ohne Vorberechnung. Erhält scharfe Merkmale und beseitigt Nahtartefakte. Ein paar zusätzliche Texturabtastungen pro Fragment.

"Real-time Terrain Enhancement with Controlled Procedural Patterns" -- Grenier et al. (2024). CGF. Mikroerosionsdetail auf Basis von Phasor Noise bei bis zu 32-facher Heightmap-Auflösung. Neigungsorientierte Muster laufen vollständig in einem Fragment-Shader.

Adaptive Tessellierung

"Concurrent Binary Trees for Large-Scale Game Components" -- Benyoub und Dupuy (Intel, HPG 2024). Paper. GPU-freundliche Binärbaum-Datenstruktur für adaptive Terrain-Tessellierung. Rendert Geometrie im Planetenmaßstab in unter 0,2 ms. Von quadratischen Domänen auf beliebige Polygonnetze erweitert.

Höhlen- und Untergrundgenerierung

"PLUME: Procedural Layer Underground Modeling Engine" -- 2024. arXiv:2508.20926. Quelloffenes Framework, das realistische Höhlen- und Lavaröhrenumgebungen mit geschichteten prozeduralen Regeln erzeugt. Ursprünglich für Weltraum-Robotik gebaut.

Neuronale Terrainsynthese

"InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation" -- Goslin (2025, SIGGRAPH 2026). arXiv:2512.08309. Unendliche, seed-konsistente Terraingenerierung über hierarchische Diffusionsmodelle mit Laplace-Kodierung. Auf Consumer-GPUs 9-mal schneller als die Referenz.

"TerraFusion: Joint Generation of Terrain Geometry and Texture" -- 2025. arXiv:2505.04050. Latent Diffusion für gleichzeitige Heightmap- und Textursynthese mit Skizzenkonditionierung.

"MESA: Text-Driven Terrain Generation" -- CVPR-2025-Workshop. arXiv:2504.07210. Text zu Terrain mit Copernicus-Fernerkundungsdaten als Training.

"Geodiffussr: Generative Terrain Texturing with Elevation Fidelity" -- 2025. arXiv:2511.23029. Textgeführte Erzeugung von Terraintexturen, die per Flow Matching die Höhendaten respektiert.

"Sketch2Terrain: AI-Driven Real-Time Terrain Sketch Mapping" -- 2025. Projekt. Skizze zu Terrain in Augmented Reality. 38 % Effizienzgewinn gegenüber manuellem Kartieren.

Vegetation und Ökosystem-Simulation

"GPU-Based Real-Time Procedural Distribution of Vegetation on Large-Scale Virtual Terrains" -- SBGames 2018. Paper. Quadtree-basiertes Verteilen von Vegetation über biotische und abiotische Faktoren auf der GPU.

"Procedural Generation and Rendering of Forests" -- 2022. Paper. L-System-Baumgenerierung, kombiniert mit Simulation der Ökosystem-Konkurrenz für realistische Waldverteilung.

"Real-Time Procedural Generation with GPU Work Graphs" -- AMD GPUOpen 2024. Paper. GPU-Work-Graphs, die über 79.000 Vegetationsinstanzen in unter 4 ms erzeugen.

GPU-Technik im Browser

"GSWT Renderer" -- SIGGRAPH Asia 2025. GitHub. Renderer mit WebGPU plus Rust und Wasm, der Gaussian Splatting Wang Tiles für unendliches 3D-Terrain mit dynamischem LOD und Streaming nutzt.

"GPU Compute in the Browser at the Speed of Native: WebGPU Marching Cubes" -- Usher (2024). Blog. Zeigt, dass WebGPU-Compute bei parallelen Mesh-Erzeugungsalgorithmen native Geschwindigkeit erreicht.

Voxel-Rendering und großmaßstäbliche Szenen

"Aokana: A GPU-Driven Voxel Rendering Framework for Open World Games" -- 2025. arXiv:2505.02017. Sparse Voxel DAG mit LOD und Streaming für Szenen mit zehn Milliarden Voxeln. 9-fache Speicherreduktion und 4,8-mal schnelleres Rendering als der bisherige Stand der Technik. Für die Integration in Game-Engines entworfen.

Prozedurale Geometrie und Resurfacing

"Real-time Procedural Resurfacing using GPU Mesh Shaders" -- Raad et al. (Eurographics 2025). Paper. Erzeugt zur Renderzeit detaillierte geometrische Oberflächen aus groben Kontrollnetzen über Mesh-Shader. Ermöglicht dynamisches LOD, ohne hochauflösende Geometrie im Speicher zu halten.

Terrainschatten

"Optimizing Terrain Shadows" -- AMD GPUOpen. Blog. Praktische CSM-Optimierung für großmaßstäbliches Terrain. Behandelt Kaskadenaufteilung, GPU-effizientes Rendern von Shadow Maps und terrainspezifische Optimierungen.

Virtuelle Geometrie und Mesh-Optimierung

"Nanite WebGPU" -- Scthe (2024). GitHub, Demo. Vollständige Browser-Umsetzung der Nanite-Architektur aus UE5: Meshlet-LOD-Hierarchie, Software-Rasterizer in WGSL, Culling pro Meshlet, Billboard-Impostoren.

"Billions of Triangles in Minutes" -- Kapoulkine (2025). Blog. Meshoptimizer v1.0 für hierarchische geclusterte LOD-Erzeugung. Verarbeitet riesige Meshes effizient zu Cluster-DAGs im Nanite-Stil.

"Billboard Splatting (BBSplat)" -- 2024. arXiv:2411.08508. Lernbare texturierte planare Grundformen für Novel-View-Synthese mit 17-facher Kompression gegenüber 3D-Gaussian-Splatting.

Terrainbeleuchtung und Global Illumination

"Global Illumination in Once Human" -- GDC 2025. Session. Hybride GI für eine offene Welt von 16 km: mit neuronalem Netz komprimierte Probes (Verhältnis 69:1), ML-basierte Auflösung von Innen-Außen-Lecks, dynamische Probe-Reaktionen.

"GI with AMD FidelityFX Brixelizer" -- GDC 2024. Paper. Compute-basierte spärliche Distanzfeld-Kaskaden mit Probes im Bildschirmraum. Kein Hardware-Raytracing nötig.

"Radiance Cascades" -- 2024. Blog. Rauschfreie Global Illumination in Echtzeit über kaskadierte Radiance-Strukturen, ohne zeitliche Akkumulation.

Leveldesign und Erkunden

"PlotMap: Automated Layout Design for Building Game Worlds" -- 2023. arXiv:2309.15242. KI-gestützte Platzierung von Points of Interest, die narrative räumliche Randbedingungen auf dem Terrain erfüllt.

"Spatial Exploration Triggers" -- Purdue University (FDG 2022). Paper. Vier Entwurfsmuster, die Spieler zum Erkunden treiben: Extrempunkte, Sichtverdeckungen, unpassende Objekte, räumliche Zusammenhänge.

Datenkompression und Streaming

"Entropy-driven Progressive Compression of 3D Point Clouds" -- SGP 2024. Paper. Auf Rate und Verzerrung optimierte progressive Kompression über rekursive Raumpartitionierung mit adaptiver Quantisierung. Erzeugt Verfeinerungsströme, die zu Netzwerk-Streaming mit variabler Bandbreite passen.

Interaktives Bearbeiten

"WebGPU SDF Editor" -- Nijhoff (2026). Projekt. Vollwertiges SDF-Modellieren im Browser, mit Marching Cubes in Echtzeit, booleschen Operationen, weichem Blending und Octree-Raumpartitionierung. 112 Byte pro Grundform.

Fluss- und Küstengenerierung

"Procedural River Drainage Basins" -- Patel (Red Blob Games). Projekt. Entwässerung-zuerst-Flussgenerierung über Kantenklassifikation in Voronoi- und Dreiecksnetzen. Baut Flusshierarchien, bevor Terrainhöhen zugewiesen werden.

"NEWTS1.0: Numerical Model of Coastal Erosion by Waves and Transgressive Scarps" -- MIT (2024). Paper. Vereinfachtes Küstenerosionsmodell mit gleichmäßigem Rückgang und wellengetriebener Erosion. Erzeugt Landzungen, Buchten, Brandungspfeiler und Bögen, die zur realen Geomorphologie passen.

Weiterlesen

• Browser-3D-Technik für offene Welten behandelt die vollständige Architektur einer Multiplayer-Creator-Welt im Browser
• Tech-Stack für Web-Spiele 2026 behandelt die Grundlagen von WebGL, WebGPU und WebAssembly
• Technischer Bericht zu Three.js und USDC über das Laden von 3D-Assets im Browser
• Führende quelloffene Gen-AI-Modelle für die KI-Generierungs-Pipeline
• WebGPU-Einstieg — Compute Shader für GPU-getriebenes Terrain
• Web Workers für Spiellogik — Terraingenerierung in Worker auslagern
• Physik-Bibliotheken für Spiele — Physik für Terraininteraktion und Heightfield-Collider
• Wo du kostenlose Game-Assets findest — Quellen für Texturen und Materialien beim Terrain-Rendering

Probier es gleich ausSetz eine erzeugte Landschaft in ein Spiel

Terrain ist besser, wenn du darauf laufen kannst.

Kostenlos erstellen →Kostenlos, läuft im Browser, keine Installation nötig.