Eine offene Welt im Browser entwickeln, Teil 4: Streaming vor aufwendigem Terrain

Von Oleg Sidorkin, CTO und Mitgründer von Cinevva

Neu hier? Nutze den Serienleitfaden. Er erklärt, was ein Spike ist, und verlinkt alle Teile.

Beim Streaming scheitern Projekte, die nur „gut aussehen“, in der Regel.

In einem Standbild lässt sich vieles verbergen. Einen 40-ms-Ruckler beim Überschreiten einer Chunk-Grenze kann man nicht verbergen.

Wir testeten das Streaming bewusst, bevor wir eine fortgeschrittene Terrain-Repräsentation entwickelten. So erhielten wir klare Erkenntnisse über das Lade- und Entladeverhalten.

Spike 6 validierte den laufenden Austausch benachbarter Chunks mit einfachen Chunk-Inhalten.

Spike 6 in einem neuen Tab öffnen ↗ · Quellcode ansehen

Anschließend wechselten wir in Spike 11 zum eigentlichen Terrain-Ansatz: Heightmap-Chunk-Streaming mit Dekodierung im Worker und schrittweiser Verfeinerung von 17×17- über 33×33- bis hin zu 65×65-Sampling-Rastern.

Spike 11 in einem neuen Tab öffnen ↗ · Quellcode ansehen

Die Reihenfolge war wichtiger, als wir erwartet hatten. Hätten wir direkt mit komprimierten Heightmap-Chunks begonnen, wäre die Ursache jedes Rucklers unklar gewesen: ein Problem beim Dekodieren, beim Hochladen der Textur oder beim Aktualisieren der Geometrie. Spike 6 beseitigte eine Ebene der Unsicherheit, bevor Spike 11 zusätzliche Komplexität einführte.

Eine praktische Erkenntnis aus diesem Kapitel floss in spätere Spikes ein: Verzögerungen beim Hochladen müssen direkt gemessen werden, statt sie aus der durchschnittlichen FPS-Zahl abzuleiten. Die durchschnittliche FPS-Zahl verschleiert einzelne Frame-Spitzen – und genau diese spüren die Nutzer tatsächlich.

In Teil 5 wenden wir uns den visuellen Kosten zu, wenn Vegetation, Terrain-Shader und kaskadierte Schatten um dasselbe Frame-Budget konkurrieren.

In diesem Kapitel erwähnte Technologien

Chunk-basiertes Streaming. Die Welt wird in ein Raster unabhängiger Chunks unterteilt, die typischerweise 64×64 Meter groß sind. Während sich der Spieler bewegt, werden Chunks am hinteren Rand entladen, während Chunks am vorderen Rand gestreamt werden. So funktioniert Skyrims Zellensystem: Ein 5×5-Raster aus Zellen wird um den Spieler herum geladen und bei seiner Bewegung ausgetauscht. In der Browser-Version kommt die Netzwerklatenz hinzu, wodurch vorausschauendes Vorladen anhand der Spielergeschwindigkeit entscheidend wird. Weitere Informationen bietet unser Leitfaden zur Streaming-Architektur.

Schrittweise Heightmap-Verfeinerung. Das Terrain wird zuerst in niedriger Auflösung übertragen und anschließend verfeinert. Die Rastergrößen sind nicht willkürlich: Jede Stufe ist ein $(2^k+1)\times (2^k+1)$-Raster, sodass $17=2^4+1$, $33=2^5+1$ und $65=2^6+1$ gilt. Das $+1$ sorgt dafür, dass an jeder Grenze ein gemeinsamer Sample-Wert vorhanden ist und benachbarte Chunks nahtlos aneinanderpassen. Mit jeder Stufe vervierfacht sich die Anzahl der Samples ungefähr ($n^2$ wächst, wenn sich die Seitenlänge verdoppelt). Ein 17×17-Raster – das Minimum für einen 64-m-Chunk bei 4 m Abstand – ist komprimiert etwa 200 Byte groß und rendert sofort eine sichtbare Oberfläche. Danach wird die 33×33-Verfeinerung und schließlich die volle 65×65-Auflösung gestreamt. Jede Stufe fügt Samples hinzu, ohne die vorherigen Daten zu ersetzen. Das lässt sich direkt auf LOD-Ringe von Geometry Clipmaps übertragen, bei denen weit entferntes Terrain Daten mit niedriger Auflösung und Terrain im Nahbereich die volle Auflösung verwendet. Siehe schrittweises Laden von Chunks.

Delta-Kodierung und Komprimierung. Heightmap-Daten lassen sich gut komprimieren, weil benachbarte Zellen ähnliche Werte aufweisen. Bei der Delta-Kodierung wird die Differenz zwischen jeder Zelle und ihrem vorhergesagten Wert – dem Durchschnitt ihrer Nachbarn – gespeichert, wodurch sich die Werte um null gruppieren. In Kombination mit zlib oder brotli schrumpft ein 65×65-Chunk von unkomprimierten 8,4 KB auf komprimierte 1–2 KB. Bei reduzierter Präzision für weit entfernte Chunks – 8 Bit statt 16 Bit – sind es 0,5–1 KB. Siehe Komprimierung von Terrain-Daten.

Vorausschauendes Vorladen. Chunks werden geladen, bevor der Spieler sie erreicht. Der Vorlauf muss die Strecke abdecken, die der Spieler während des Ladens eines Chunks zurücklegt, $d_{\text{prefetch}}=v\cdot t_{\text{load}}$, und skaliert daher mit der Geschwindigkeit: Bei Schrittgeschwindigkeit (5 km/h) werden 2 Chunks (128 m) im Voraus geladen, bei Laufgeschwindigkeit (15 km/h) 4 Chunks. Der Ladering verschiebt sich entsprechend der Bewegungsrichtung. Eine Prioritätswarteschlange sortiert ausstehende Anfragen nach Dringlichkeit und bricht Anfragen für Chunks ab, von denen sich der Spieler inzwischen entfernt hat. Siehe vorausschauendes Vorladen.

---

Teil 4 von 12.
Zurück: Teil 3 – Die unspektakulären Spikes, die uns gerettet haben
Weiter: Teil 5 – Das Budget für die schönen Dinge
Serienleitfaden: /de/blog/2026-02-25-open-world-browser-series-guide