Browser-Rendering hatte gerade seinen besten Monat aller Zeiten
Von Oleg Sidorkin, CTO von Cinevva
Während die Spielebranche den März damit verbrachte, auf der GDC über KI zu diskutieren, machte der Browser-Rendering-Stack in vier Wochen Fortschritte wie sonst in fünf Jahren. Niemand hielt eine Pressekonferenz ab. Niemand veröffentlichte eine provokante Meinung. Fünf verschiedene Dinge geschahen, die gemeinsam veränderten, was „Browsergame“ bedeutet.
Babylon.js treibt das Browser-Rendering seit Jahren voran. Version 9.0 machte den bisher größten Sprung.
Was im März 2026 veröffentlicht wurde
Babylon.js 9.0 erschien mit Clustered Lighting, einer Rendering-Technik, die Hunderte dynamische Lichtquellen in einer Szene verarbeiten kann, ohne die Performance zu ruinieren. Bislang war das ein Feature von AAA-Engines. Das Release umfasst außerdem volumetrische Beleuchtung mit realistischer Lichtstreuung, texturierte Flächenlichter für Effekte wie Buntglas und LED-Anzeigen sowie einen knotenbasierten Partikeleditor. All das läuft sowohl mit WebGPU als auch mit WebGL 2.
PlayCanvas v2.17 führte GPU-beschleunigte Sortierung für Gaussian Splatting unter WebGPU ein. Gaussian Splatting – die Technik, die Fotogrammetrie-Aufnahmen in 3D-Echtzeitszenen verwandelt – war vor zwei Jahren noch Gegenstand einer Forschungsarbeit. Jetzt läuft sie in einer Browser-Engine, wobei der Sortierdurchlauf von der GPU beschleunigt wird.
Three.js r183 benannte sein PostProcessing-Modul in RenderPipeline um. Das klingt nach einer kleinen API-Änderung, doch die Bezeichnung ist wichtig. „Post-Processing“ ist etwas, das man nachträglich an ein Hobbyprojekt anfügt. Eine „Render-Pipeline“ ist produktionsreife Infrastruktur. Das Three.js-Team signalisiert damit, dass die Bibliothek für anspruchsvolle, strukturierte Rendering-Architekturen bereit ist.
Chrome 146 führte den WebGPU Compatibility Mode ein. Dadurch können ältere GPUs, die nicht den vollständigen WebGPU-Funktionsumfang unterstützen, WebGPU nun über einen Pfad mit reduziertem Funktionsumfang nutzen. Die Installationsbasis von WebGPU hat sich damit drastisch vergrößert.
Das W3C veröffentlichte WebGPU als Candidate Recommendation Draft. Dies ist der formale Schritt auf dem Weg zu einem offiziellen Webstandard. WebGPU ist nicht mehr experimentell. Es befindet sich im Standardisierungsprozess.
Warum dieser Monat anders ist
Jedes einzelne dieser Releases wäre bereits bemerkenswert. Dass alle fünf im selben Monat erschienen sind, erzeugt einen sich gegenseitig verstärkenden Effekt.
Vor fünf Jahren bedeutete „Browsergame“ ein einfaches 2D-Spiel, vielleicht mit ein paar Canvas-Effekten, wenn man ambitioniert war. Vor drei Jahren ließ sich mit sorgfältiger Optimierung grundlegendes 3D umsetzen. Vor einem Jahr hielt WebGPU Einzug in produktiv eingesetzte Browser, und die technischen Grenzen begannen sich zu verschieben.
Doch im März 2026 wandelte sich der Abstand zwischen nativem und browserbasiertem Rendering von „erheblich“ zu „schrumpft rasant“. Für Clustered Lighting brauchte man Unreal oder Unity. Für Gaussian Splatting brauchte man ein Forschungslabor. Für Post-Processing-Pipelines in Produktionsqualität brauchte man eine eigene Engine. Alle drei werden nun in quelloffenen Browser-Engines ausgeliefert, die jeder per npm installieren kann.
Three.js Water Pro läuft mit WebGPU. Das ist ein Browser.
Was meiner Meinung nach als Nächstes passiert
Bei Cinevva setzen wir von Anfang an auf die Bereitstellung von Spielen nach dem Browser-first-Prinzip. Unsere These war stets, dass sich die Rendering-Lücke schließen würde, weil sich die Webplattform schneller weiterentwickelt als native Engines. WebGPU brauchte länger, als ich erwartet hatte, doch die Annäherung findet nun wie vorgesehen statt.
Der praktische Effekt betrifft die Distribution. Ein Spiel, das im Browser läuft, benötigt weder einen Download noch eine Installation oder die Freigabe durch eine Plattform. Es wird über eine URL geladen. Das war schon immer der Vorteil des Browsers, doch er spielt erst dann eine Rolle, wenn die Rendering-Qualität gut genug ist, dass Entwickler sich tatsächlich dafür entscheiden.
Diese Schwelle haben wir inzwischen überschritten. Nicht für jedes Spiel. Nicht für Open-World-AAA-Titel mit Raytracing. Doch für eine immer größere Klasse von Spielen mit Echtzeit-3D, dynamischer Beleuchtung, Partikelsystemen und fotogrammetrischen Assets ist der Browser eine praktikable Zielplattform. Und anders als bei nativen Plattformen fallen am anderen Ende keine 30 % Plattformgebühr an.
Die Frage lautete nie: „Werden Browser aufholen?“ Sie lautete: „Wann?“ Der März 2026 hat sie beantwortet.
Verwandte Artikel:
- Babylon.js 9.0: Clustered Lighting und Gaussian Splatting — die vollständige technische Analyse
- Chrome 146 führt den WebGPU Compatibility Mode ein — Erweiterung der WebGPU-Installationsbasis
- Webspieleentwicklung tritt in die WebGPU-Ära ein — wie wir hierhergekommen sind
- Vergleich von Webgame-Engines — Babylon.js, Three.js, PlayCanvas und der Rest
- Erste Schritte mit WebGPU für Spieleentwickler — praktische Einführung in die neue API
- Technologien für offene 3D-Welten im Browser — die Rendering-Architektur hinter Browserwelten