WebXR und Unity – Mixed Reality im Browser Teil 2

Im ersten Teil des Artikels ging es um das Potenzial von WebXR und was die Technologie ausmacht. In diesem zweiten Teil berichte ich von meinen Erfahrungen vom heutigen Stand der WebXR- Entwicklung mit der Unity Game Engine. 

Warum Unity?

Es gibt bereits recht ausgereifte JavaScript-Frameworks mit WebXR-Support. Warum ist eine vollwertige Engine wie Unity noch relevant?  

Dafür gibt es mehrere Gründe: 

• Unity ist eine beliebte Game-Engine mit vielen Features für 3D-Applikationen. 
• Es existiert bereits eine große Community und eine dementsprechende umfangreiche Dokumentation sowie Learning-Ressourcen. 
• Aufgrund der zahlreichen Entwickler*innen gibt es sehr viele Tools und externe Libraries. 
• Ein Großteil der XR-Applikationen sind mit Unity entwickelt. Die meisten XR -Entwickler*innen sind daher üblicherweise eher vertraut mit Unity als mit den Web-Alternativen. 

In den nächsten Abschnitten beschreibe ich zuerst, wie man WebXR in Unity einbindet und warum eine Kombination mit VRTK oder MRTK sinnvoll ist. Dann gehe auf die Experience und Performance einer Unity-WebXR-Applikation auf einem Live-Server ein.

Integration von WebXR in Unity 

Trotz der Vorteile, die Unity bietet, ist der eigentliche Support für WebXR recht überschaubar. Grundsätzlich fehlt eine native Integration in Unity, sodass man eine Drittanbieter-Library benötigt. Diese muss die WebXR JavaScript-API in C# Unity Code bereitstellen, um einen kompatiblen WebGL Build zu ermöglichen. Das Plugin von Mozilla, welches den Export einer WebXR-Applikation aus Unity erlaubt, wird seit knapp einem Jahr nicht mehr weiterentwickelt.

Glücklicherweise gibt es Open-Source-Alternativen, die vergleichbar und (noch) aktiv in Entwicklung sind. Eine davon ist SimpleWebXR; sie unterstützt sogar das Mixed-Reality-Toolkit von Microsoft, welches ein komplexes MR-Input-System bereitstellt. Ein weiteres Projekt ist der WebXR Export basierend auf dem früheren WebVR Exporter, für das ich mich schlussendlich entschieden habe. Einer der Gründe dafür war die für meinen Fall relevante etwas bessere Performance von VRTK im Gegensatz zu MRTK. 

Das Setup ist mit der Einbindung von zwei Packages und einigen Einstellungen im Unity Editor relativ einfach und hat eine Sample Szene an Bord. In dieser ist bereits das Greifen von Objekten möglich. Nach dem ersten Testen fiel mir allerdings auf, dass die Interaktionen auf das Greifen limitiert sind und weitere Komponenten selbst implementiert werden müssten. Ein eigenes Interaktion-Framework zu bauen ist recht aufwendig, falls komplexe Interaktionskonzepte möglich sein sollen. Deshalb gibt es bereits spezielle Frameworks für individuelle Plattformen (etwa Oculus Integration) oder sogar Frameworks wie MRTK oder VRTK, die unterschiedlichste Devices unterstützen.  

Einbindung von VRTK 

VRTK ist ein beliebtes und umfangreiches Toolkit, welches eine Vielzahl an Interaktion-Komponenten für Unity bereitstellt. Bei MaibornWolff haben wir bereits eine ältere Version vom Toolkit bei der VR Toy Factory eingesetzt. Die neue v4 befindet sich derzeit in der Beta und bietet bereits viele einsetzbare Komponenten an, die über Tilia Packages verfügbar sind. So zum Beispiel das TrackedAlias, mit dem man ein beliebiges VR-Rig nachahmen kann. In unserem Fall ist es das WebXR-Rig, mit den Komponenten für den Kopf und den beiden Controller (beziehungsweise Händen). FusedVR hat bereits ein gutes Tutorial veröffentlicht, in dem die Einrichtung genau erklärt wird.  

Nach dem Setup von einigen Komponenten in der Unity-Szene muss nur noch das WebXR-Event für das Greifen zu VRTK weitergeleitet werden. Das Ergebnis ist ein zweites VR-Rig, gesteuert über WebXR. Dieses unterstützt sämtliche VRTK-Funktionalitäten und ermöglicht somit ohne großen Implementierungsaufwand verschiedenste Interaktionen. So konnte ich zum Beispiel ohne nennenswerten Mehraufwand einen VRTK-Button in die Szene integrieren. Da wir außerdem agnostisch in Bezug auf das VR-Headset sind, funktioniert dieser Ansatz mit allen WebXR-kompatiblen Geräten.  

Die Grafik: spartanisch und Low Poly 

Mit diesem Setup hat man eine recht gute Basis für die eigene VR-Anwendung. Doch wie gut läuft diese tatsächlich? Testen kann man das, indem man einen WebGL Build aus Unity macht und diesen auf einem Web-Server hostet. In den meisten Fällen wird von WebXR eine verschlüsselte Verbindung vorausgesetzt (HTTPS). Schlussendlich musste ich dann nur noch die URL in einem kompatiblen Browser abrufen. Das naheliegendste Device war die Oculus Quest 2 mit dem bereits installierten Oculus Browser.

Als Baseline-Test dient die mitgelieferte Wüstenszene mit einigen einfachen interaktiven Objekten ohne VRTK. Diese äußerst simple Szene läuft im Durchschnitt mit sehr guten 90 FPS. Für den ersten eigenen Test mit VRTK nehme ich eine noch einfachere Szene mit einigen interaktiven Objekten. 

Mit 10 Drawcalls, 5.000 Vertices und Baked Lighting kommen wir auf akzeptable 80 bis 90 FPS. Mit weiteren Anpassungen schafft man hier sicherlich auch trotz VRTK stabile 90 FPS.  

Sie sehen gerade einen Platzhalterinhalt von Youtube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren

Für den zweiten Test mit einer etwas komplexeren Umgebung verwende ich ein Low Poly Asset aus dem Unity Asset Store. Nach einigen Anpassungen kommt man auf 70 Drawcalls mit 80.000 Vertices. Das Ergebnis: 60 bis 80 FPS mit zahlreichen Schwankungen. Hier kommen wir schon gefährlich nahe ans Minimum für eine flüssige VR-Experience. Diese Szene wäre ohne große Anpassungen in einer nativen Quest-Applikation ohne solch starke Performance-Einbußen möglich.  

Hier wird deutlich, dass man beim Weg über WebGL grafische Abstriche machen muss. Auch wenn grundsätzlich der Overhead, der beim Übersetzen von WebGL API Calls auf die Betriebssystemebene entsteht, gering sein sollte. Auf der CPU-Seite ist die Performance abhängig vom Browser und aufgrund der Übersetzung zu WebAssembly meist merkbar schlechter als bei nativen Apps. Hinzu kommt, dass wir bisher kein Post-Processing, kein Anti-Aliasing und recht wenig Interaktionen integriert haben. Würde man also eine komplexere Applikation von nativ auf WebXR portieren wollen, wäre das nur mit recht großen Anpassungen möglich. 

Sie sehen gerade einen Platzhalterinhalt von Youtube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.

Mehr Informationen

Inhalt entsperren Erforderlichen Service akzeptieren und Inhalte entsperren

Darüber hinaus sollte man auf die Ladezeiten einer komplexeren Applikation achten, da mehr Content mit einer längeren Wartezeit einhergeht. In meiner Beispielszene war das zwar kein allzu großes Problem (in der Regel weniger als 10 Sekunden), kann aber bei großen Projekten schon mal bis zu einer Minute dauern. Hinzukommt, dass es dabei auch zu Crashes kommen kann, falls der Browser nicht genügend RAM zur Verfügung hat.

Mein Fazit 

Um eines vorwegzunehmen: Ich finde es erstaunlich, dass es trotz fehlendem offiziellen Support möglich ist, mit Unity relativ einfach WebXR-fähige Apps zu entwickeln. Plugins wie WebXR Export funktionieren trotz ihrer sehr kleinen Nutzergruppe gut genug, sodass man mit diesen schon kleinere Projekte umsetzen könnte. Außerdem ist die Community für WebXR Discord recht aktiv, was zumindest ein wenig über einen besseren Support hinwegtröstet.

Mein erster Eindruck als Unity-Entwickler hat sich allerdings bestätigt: Für kommerzielle VR-Projekte ist der Support in Unity noch zu limitiert und kaum erprobt. Empfehlen würde ich den Ansatz also nur denjenigen, die WebXR in internen oder Hobby-Projekten ausprobieren wollen, ohne sich in Web-Frameworks einarbeiten zu müssen. Einen Wechsel von vollwertigen Game-Engines wie Unity werden schließlich die wenigsten machen. 

Anders könnte es aber schon jetzt bei AR-Anwendungen aussehen. Die Web-Alternativen wie A-Frame sind im Vergleich ausgereifter und durchaus für den kommerziellen Bereich denkbar. Außerdem sind die teils fehlenden Features einer Game-Engine bei AR eher verkraftbar. Vor allem für Web- beziehungsweise JavaScript-affine Entwickler*innen ist das schon heute interessant. 

Für die bestehende XR-Community ist WebXR derzeit noch zu sehr Nischen-Technologie. Wirklich relevant wird diese sehr wahrscheinlich nur dann werden, wenn die Qualität vergleichbar mit anderen Drittanbieter-Toolkits wird – oder sogar direkten Support in zum Beispiel Unity über das XR SDK erhält.

---

Über den Autor