Unity 6.6 beendet den experimentellen Status von WebGPU – und lässt es deaktiviert
Unity veröffentlichte Unity 6.6 am 1. September. Es handelt sich um ein „Supported“-Release, das bis zum Erscheinen von 6.7 dasselbe Stabilitätsversprechen wie eine LTS-Version erhält. Zugleich ist es die letzte Station der Unity-6-Reihe vor diesem LTS-Release. Die wichtigste Meldung für alle, die Spiele für den Browser veröffentlichen, ist ein Satz aus dem eine Woche zuvor erschienenen Beitrag des Web-Graphics-Teams: „Ab Unity 6000.6 ist die WebGPU-Grafik-API nicht mehr experimentell, sondern eine vollständig unterstützte Funktion.“
Unity bietet WebGPU bereits seit 6.1 Anfang 2025 als experimentelles Backend an. Wir haben damals darüber berichtet und seitdem die Entwicklung auf Browserseite verfolgt – von der WebGPU-Einführung in Safari bis zur Unterstützung durch alle großen Browser. Nun hat auch die Engine-Seite aufgeholt.
Unitys eigener Rundgang durch die Neuerungen in 6.6
Was WebGPU ermöglicht
Der entscheidende Grund, weshalb WebGPU speziell für Unity wichtig ist, sind Compute-Shader. WebGL 2 hat sie nie unterstützt, weshalb sämtliche Unity-Funktionen, die auf GPU-Berechnungen beruhen, in Web-Builds schlicht fehlten. Mit ausgewähltem WebGPU erhalten Web-Builds den GPU Resident Drawer und GPU-Occlusion-Culling, Spatial-Temporal-Post-Processing-Upscaling, den VFX Graph mit GPU-simulierten Partikeln, Adaptive Probe Volumes und Compute-Skinning. Unitys Demoszenen für den Beitrag waren Fantasy Kingdom, eine dicht bebaute stilisierte Stadt, und das Innere eines Raumschiffs voller VFX-Graph-Partikel – beide liefen in einem Browser.
VFX-Graph-Partikel werden auf der GPU simuliert, weshalb sie unter WebGL 2 nie verfügbar waren. Bild: Unity.
Außerdem gibt es einen schlankeren Kompatibilitätsmodus für Hardware, die zwar WebGPU-Unterstützung meldet, aber nicht den vollständigen Funktionsumfang bewältigt. So erreicht derselbe Build mehr Geräte, ohne dass Entwickler etwas dafür tun müssen.
Was Unity bewusst nicht getan hat
WebGPU ist nicht standardmäßig aktiviert. WebGL 2 bleibt die voreingestellte Grafik-API für Web-Builds. Um WebGPU zu verwenden, öffnet man die Web-Player-Einstellungen, deaktiviert die automatische Auswahl der Grafik-API und fügt WebGPU der Liste hinzu. Unity probiert die APIs zur Laufzeit in ihrer Prioritätsreihenfolge aus und wechselt zur nächsten, wenn die erste nicht verfügbar ist.
WebGPU muss der Liste der Grafik-APIs manuell hinzugefügt werden. Bild: Unity.
Zwei Hinweise aus dem Beitrag können Entwickler einen ganzen Tag kosten, wenn sie sie übersehen. Erstens stellen Browser WebGPU nur in einem sicheren Kontext bereit. Ein Build, der aus einer lokalen Datei oder über einen einfachen HTTP-Host bereitgestellt wird, fällt daher stillschweigend auf WebGL 2 zurück – und man fragt sich, warum die Compute-Funktionen verschwunden sind. Zweitens, in Unitys eigenen Worten: „Nicht alle Geräte, die WebGPU-Unterstützung melden, liefern ein konsistentes Nutzungserlebnis.“ Deshalb führt 6.6 Graphics Device Filtering ein: eine Reihe von Regeln, die für bestimmte Browser, GPUs oder Treiber, die sich als problematisch erwiesen haben, den Rückfall auf eine andere API erzwingen.
Beim restlichen Web-Angebot von 6.6 geht es um Größe und Speicher. WebAssembly64 ermöglicht es einem Browser-Build, bis zu 16 GB Arbeitsspeicher statt der bisherigen Obergrenze von 4 GB zu adressieren – in Chrome und Edge ab Version 128 sowie Firefox ab Version 129. Progressive Asset Loading stellt Assets szenenweise statt als einen einzigen Download vor dem Start bereit. Dadurch kann ein Spieler bereits mit der ersten Szene beginnen, während der Rest nachgeladen wird. Beide Funktionen gehen die zwei Gründe an, aus denen Unity-Webspiele traditionell schwer zu vermitteln waren: Sie waren groß und ihnen ging der Speicher aus.
Der Rest des Releases
Außerhalb des Browsers ist Fast Enter Play Mode nun die Standardeinstellung für neue Projekte und lädt die Szene ohne Domain Reload neu. Unity beschreibt dies als Vorbereitung auf den Wechsel zu CoreCLR in Unity 7. Dictionaries lassen sich endlich nativ im Inspector serialisieren. Ein neues Build-Analysis-Fenster erfasst Build-Verlauf und Kennzahlen, während Content Directories lokale Inhalte mit Addressables-Integration und DirectStorage-Unterstützung unter Windows und Xbox organisieren. Unitys Beispiel für die Shader-Verbesserungen ist ein Build, dessen Dauer nach der Umwandlung von Keyword-Varianten in dynamische Verzweigungen von 1 Stunde und 46 Minuten auf 32 Minuten sank.
Was das für Webspiele bedeutet
Wir arbeiten direkt mit three.js und WebGPU. Dass Unity sein Backend nun aus dem experimentellen Status entlässt, ist daher weniger eine Wettbewerbsbedrohung als eine Bestätigung. GPU-Berechnungen im Browser sind jetzt ein unterstützter Weg in der Engine mit der größten Installationsbasis. Das bedeutet, dass mehr Spiele mit dieser Voraussetzung veröffentlicht werden, mehr Spieler auf Kompatibilitätsprobleme stoßen und Browseranbieter stärker unter Druck geraten, diese zu beheben. Wir haben erläutert, wie WebGPU und WebGL bei Spielen im Vergleich dastehen und welche Engine-Optionen es für das Web gibt. Die Empfehlungen in beiden Beiträgen gelten weiterhin: WebGPU aktivieren und einen WebGL-2-Fallback anbieten, auf echter leistungsschwacher Hardware testen und die Aussage „Der Browser meldet Unterstützung“ als Anfang der Untersuchung betrachten.
Dass Unity WebGPU in einem unterstützten Release standardmäßig deaktiviert lässt, ist die richtige Entscheidung – und zugleich ein Hinweis. Die API ist bereit. Die Gerätelandschaft ist noch nicht einheitlich, und die Engine, die auf all diesen Geräten laufen muss, weiß das besser als jeder andere.