WebXR und Unity – Mixed Reality im Browser Teil 1

In den letzten Jahren ist das Angebot an verschiedener Mixed-Reality-Hardware immer größer geworden – und damit auch die Bandbreite der Nutzer*innen. Trotz einiger etablierter Standards bleibt es allerdings schwierig, XR-Anwendungen über mehrere Plattformen möglichst einfach zugänglich zu machen. Nicht Jede*r hat das spezielle VR-Headset oder das aktuelle iPhone, für das die Applikation entwickelte wurde. In diesem Artikel stelle ich die Technologie WebXR vor, die dabei helfen soll, plattformunabhängige Use Cases zu realisieren.  

In diesem ersten Teil gebe ich einen groben Überblick dieser Web-Technologie und warum diese für Mixed-Reality-Entwickler*innen relevant ist. Im zweiten Teil schildere ich anschließend meine ersten Eindrücke der tatsächlichen Entwicklung im Kontext der Unity Game Engine. 

Was ist WebXR?

WebXR ist eine API mit dem Ziel, Virtual Reality wie auch Augmented Reality Web-fähig zu machen. Es ist die logische Fortführung von WebVR. Konkret bedeutet das, innerhalb von Web-Anwendungen entsprechende Interfaces zu XR-Geräten zur Verfügung zu stellen. Somit wird eine Mixed-Reality-Applikation über WebXR auf unterschiedlichen Endgeräten, etwa VR-Headsets, über den Web-Browser erlebbar. Vorstellen kann man sich das wie bei einer Progressive-Web-App, die plattformunabhängig ist und somit auf iOS als auch auf Android funktioniert. Bei WebXR können es aber deutlich mehr unterschiedliche Plattformen und Devices sein – von der preiswerten Oculus Quest 2 bis hin zur High-End-VR-Brille Valve Index. 

Was kann WebXR nicht?

In der Theorie ist WebXR ideal für die wachsende Bandbreite an Mixed-Reality-Hardware, die jedes Jahr neu auf den Markt kommt. In der Praxis erfüllt sich das Versprechen noch nicht. So fehlt zum Beispiel aktuell der Support in einigen wichtigen Browsern (Safari auf iOS oder Firefox). Darüber hinaus kann es vorkommen, dass XR-Hardware grundsätzlich unterstützt wird, aber bestimmte Features wie Hand Tracking fehlen.  

WebXR ist kein Engine-Komplettpaket. Um eine WebXR-fähige App zu entwickeln, benötigt man einige andere Technologien, unter anderem eine Rendering-Engine, mit der 3D-Inhalte dargestellt werden können (meist WebGL). Der Aufwand, eine solche Engine für die Entwicklung zu bauen, ist sehr groß, sodass die meisten Entwickler*innen auf bestehende Frameworks zurückgreifen. Welche WebXR-Features aber tatsächlich out-of-the-box verwendet werden können, hängt stark von dem jeweiligen Framework ab. Daher ist nicht nur die Weiterentwicklung des WebXR-Standards wichtig, sondern auch, wie gut der Framework-Support ist. 

Warum WebXR trotzdem relevant ist (und wahrscheinlich bleiben wird)

Wäre besagte Plattformunabhängigkeit der einzige Vorteil der Technologie, gäbe es diesen Blog-Artikel wahrscheinlich nicht. Denn diesen Standard gibt es mit OpenXR bereits. Er wird von zahlreichen XR-Runtimes und Plattformen unterstützt – darunter auch WebXR. Obwohl OpenXR grundsätzlich ein Schritt nach vorne ist, ist das Einrichten in einigen Fällen aufwendig oder wird von Engines wie Unity teils für bestimmte Plattform vernachlässigt oder erst gar nicht unterstützt. 

WebXR ist im Vergleich zur Entwicklung für spezifische Plattformen oder der Verwendung von OpenXR attraktiv für Use Cases, bei denen der einfache Zugang zur Applikation auf mehreren Plattformen wichtig ist. Zusätzlich eignet sich der Web-Ansatz natürlich bei XR-Inhalten, die nicht zu einem App-Store-Modell passen. 

Nehmen wir zum Beispiel eine potenzielle VR-Applikation, die zum Training von Fachpersonal in einem Produktionsumfeld dient und mit zwei Controllern bedient werden kann. Realisiert man das mit einer App für die beliebte Oculus Quest 2, bleibt die Kompatibilität mit anderen Plattformen auf der Strecke. Zusätzlich muss man Fragen zur Verteilung der App über den Oculus Store beziehungsweise „Oculus for Business“ lösen, oder bei Pilotprojekten händisches Deployment in Kauf nehmen. Solche Detailfragen gilt es bei potenziell allen unterstützten Plattformen zu klären. Eine WebXR-Anwendung ist dagegen über eine URL im Browser des Endgeräts erreichbar. Die einzige Voraussetzung ist ein WebXR-kompatibler Browser. 

Was WebXR noch zurückhält 

In der Praxis fehlt WebXR noch einiges bis zur Business-Reife. Beispiele sind der noch löchrige Support in Web-Browsern, die nicht ganz ausgereiften Toolkits oder Performance-Einbußen und die schlechtere visuelle Qualität. Es ist ein bekanntes Problem: Die Technologie bleibt unausgereift, weil nicht genügend Andrang von Entwickler*innen da ist. Dieser bleibt entsprechend niedrig. Die Technologie ist oft noch zu riskant und aufwendig, um in größeren kommerziellen Projekten verwendet zu werden. Besonders bemerkbar macht das sich für XR-Entwickler*innen, die etablierte Engines wie Unity verwenden. Es gibt derzeit keinerlei Engine-Toolkits, die von größeren Teams aktiv entwickelt werden. Die einzige Option sind Open-Source-Projekte, die von nur einer Person entwickelt werden und entsprechend von heute auf morgen eingestellt werden könnten. Im Gegensatz dazu haben etwa bei A-Frame mehr als 40 Entwickler*innen an dem Release der aktuellen Version 1.1.0 mitgewirkt.

Bei Web-Frameworks spiegelt sich somit die wachsende Community auch in der fortgeschritteneren Qualität wider. Für weniger anspruchsvolle Use Cases fallen außerdem fehlende Game-Engine-Features nicht allzu sehr ins Gewicht. Im Gegenzug kann man aber von einer stabilen Integrierung und einer hohen Wahrscheinlichkeit für Long-Term-Support profitieren.  

Die Diskrepanz zwischen der existierenden XR-Community und Zielgruppe der besten WebXR-Frameworks, ist aus meiner Sicht einer der Hauptgründe, wieso zurzeit fast keine kommerzielle Anwendung auf WebXR setzt. 

XR im Web – der Durchbruch steht noch aus

Das Konzept von WebXR hat auf dem Papier sehr eindeutige Vorteile, wie etwa bei Rahmenbedingungen der Distribution von B2B-Anwendungen. Trotzdem sind die theoretischen Vorteile nur so gut wie ihre Implementierung in der Praxis. Eines der größten Probleme von WebXR ist, dass sich die besten Frameworks nicht für den bestehenden Pool an XR-Entwickler*innen eignen. Die Ansätze für Unity sind schlicht zu unausgereift und der Weg über Web-Frameworks erfordert Ressourcen sowie Zeit für einen Technologiewechsel. Riskant ist es in beiden Fällen. Wahrscheinlich wird sich WebXR in Zukunft nur dann etablieren, wenn direkter Support in Game-Engines existiert oder Unternehmen den Schritt wagen, größere kommerzielle Apps mit Web-Alternativen zu entwickeln. 

Im zweiten Teil berichte ich von meinen Erfahrungen mit dem derzeitigen Stand der WebXR-Entwicklung in Unity und ob sich dieser Ansatz für bestimmte Use Cases eignet. 

---

Über den Autor