WebVR und Chrome: ein kurzer Überblick.

In diesem Beitrag werden wir thematisieren, was ein Virtual-Reality (VR)-fähiger Browser eigentlich mit sich bringt. Viele Nutzer erwarten, dass dies bedeutet, dass Sie ihren Browser starten, ihr Head-Mounted-Display aufsetzen und sofort in ein komplettes VR-Browsing-Erlebnis eintauchen. Das ist aber natürlich nicht der Fall und es wird noch sehr lange dauern bis diese Erlebnisse möglich sein werden.

Das Hinzufügen con WebVR macht den Browser somit nicht zu einem kompletten Virtual Reality Erlebnis. Stattdessen stellt es eine API zur Verfügung, die es Entwicklern ermöglicht, VR-Inhalte im Kontext einer Webseite zu erstellen. Stellen Sie sich vor. Sie durchstöbern Amazon und finden eine Jacke, einen TV oder ein Fahrrad oder was auch immer Sie interessiert. Wenn Amazon`s Entwickler die WebVR API nutzten, konnten Sie eine Schaltfläche mit der Aufschrift „View in VR“ hinzufügen, mit der Sie das Objekt über ein VR-Headset in 3D im Maßstab 1:1 betrachten können. Im Falle eines Kleidungsstücks könnte man z.B. um das Produkt herumgehen, sich hineinlehnen und die Nähte durchsuchen, als säße es tatsächlich vor einem. Sie können sich auch ähnliche Erfahrungen mit Lehrwerkzeugen, Datenvisualisierung, Mapping usw. vorstellen. WebVR gibt Entwicklern die Werkzeuge an die Hand, die Sie benötigen, um dies zu realisieren.

Und natürlich wird es auch Spiele geben. Das ist so selbstverständlich, dass es noch nicht einmal erwähnenswert ist.

Wie ist der Stand der Dinge?

Schon seit einigen Jahren erlaubt Chrome das Anzeigen von VR. Das bedeutet, dass WebVR-Features erst dann zu Chrome selbst hinzugefügt werden, wenn die API ausgereift ist und es ausreichend Entwickler- und Benutzerinteressierte gibt. Eine eindeutige Prognose, ob VR diesmal der Durchbruch gelingt oder wieder ein Flop bevorsteht, lässt sich nicht eindeutig machen. Es macht natürlich keinen Sinn neue Funktionen zu Chrome hinzuzufügen, wenn nur ein winziger Bruchteil der Enthusiasten in der Lage sein wird, diese zu nutzen. Darüber hinaus gibt es nur sehr wenige VR-Geräte, die für Entwickler an dieser Stelle offen zugänglich sind, so dass bis dato noch ganz klar ist, welche Funktionalitäten am Ende des Tages möglich sein werden. Wenn wir uns zu früh auf eine API festlegen, riskieren wir, Geräte auszuschließen, die nicht den Annahmen eines sehr kleinen Sample-Sets entsprechen.

Wenn wir warten bis VR allgegenwärtig wird, bevor wir es zu einem echten Teil der Plattform machen, werden wir jedoch stark zurückhängen. Die Aufrechterhaltung eines experimentiellen offenen Codebereich des Browsers für die VR-Entwicklung gibt uns die Möglichkeit, die Knicke in der API-Implementierung herauszuarbeiten ohne die Kerncodebasis vorzeitig zu stören.

Momentan unterstützen viele Beispiele den Oculus Rift und wir werden uns auch die Unterstützung für Cardboards SDK anschauen. Es kommen alle VR-Lösungen in Betracht, die über ein Open Source SDK verfügen. Wir sollten auch erwähnen, dass dies ein Nebenprodukt für uns ist. Von daher werden wir nicht jedes neu erscheinende VR-Gadget sofort integrieren.

Unseren Content für WebVR werden wir regelmäßig aktualisieren, um sicherzustellen, dass Sie mit der zukünftigen Chrome-Entwicklung auf dem neuesten Stand bleiben.

Das L-Wort.

Wir müssen an dieser Stelle auch auf etwas näher auf die Latenzzeit eingehen. Die erste und letzte Sache, die irgendjemand erwähnt, wenn er über die VR-Entwicklung spricht. Um die angestrebte mystische „Präsenz“ zu erreichen, sollte eine Latenzzeit über 20 ms nicht überschritten werden. Das Problem ist, dass Browser nicht gerade für ihre niedrige Latenzzeit bekannt sind. Wie sieht es aber nun konkret beim Chrome-Browser aus?

Es dauert insgesamt 64ms von einer Headset-Bewegung bis zum LCD-Wechsel. Als Referenz auf der gleichen Maschine gibt uns ein anderes Beispiel eine Probe von 48ms. Das ist eigentlich gar nicht so schlimm, wie es auf dem ersten Blick erscheint. Das bedeutet, dass das Beispiel 3 Bilder auf einem 60Hz-Display aufnimmt, damit ihre Kopfbewegung das Bild auf dem Bildschirm beeinflusst. Chrome nimmt also 4 Bilder auf. Eine Differenz von einem Frame im Vergleich zu einer nativen App ist definitiv nicht überwindbar. Natürlich sind beide noch weit entfernt von 20ms, aber diese Zeitvorgabe gilt als zukünftiges Ziel.

Wie können wir also die Latenzzeit im Browser reduzieren? Das ist eine weitaus kompliziertere Frage, als es den Anschein hat und es gibt eine Menge Leute im Chrome-Team, die auf verschiedene Weise an diesem Problem arbeiten. Es kann einige Abkürzungen geben, die VR-Inhalte für den Fortschritt benötigen. Chrome verfügt über eine ziemlich umfangreiche Rendering–Pipeline, die darauf ausgerichtet ist, traditionelle Web-Inhalte so reibungslos wie möglich wiederzugeben. Dies beinhaltet eine Menge Layout, Rastering und Compositing mit wenig Nutzen, wenn ihr Inhalt ein einzelner, bildschirmfüllender WebGL-Kontext ist. Daher kann es in diesem speziellen Fall zu einigen Vorteilen kommen, wenn der Compositing-Prozess kurzgeschlossen wird. Wir hatten noch nicht die Möglichkeit, es wirklich auszuprobieren, aber es ist ein Beispiel für die Arten von Optimierungen, die durchgeführt werden können, um diese schwer fassbare „Präsenz“ zu erreichen.

Unterschiede bei der Implementierung.

Chrome`s experimentielle Implementierung von WebVR ist sehr ähnlich zu Mozilla`s Prototyp, aber es gibt derzeit einige kleine Unterschiede aufgrund der parallelen Natur der laufenden Entwicklung. Es ist durchaus möglich, Web-Applikationen zu entwickeln, die mit beiden funktionieren und ich erwarte, dass die Unterschiede beseitigt werden, da die Entwickler uns eine bessere Vorstellung davon geben, was wichtig ist und was nicht.

(Denken Sie daran, dass sich diese Schnittstellen ändern werden. Dies ist nur eine Beschreibung der Ausgangsversionen.)

Erstens, da es Blinks Richtlinie ist keine vorangestellte APIs mehr hinzuzufügen beginnt keine der Funktionen mit WebKit, blink oder so ähnlich. Um auf sie zuzugreifen, müssen Sie stattdessen Chrome mit dem Flag enable-vr starten.

GetVRDevices in Chrome gibt ein Return zurück, anstatt einen Callback anzunehmen. Das ist aus folgenden Gründen der Fall:

• Viele neue Web-APIs tendieren in Richtung Promise-Nutzung für asynchrones Verhalten.
• Promises haben explizite „Erfolgs-“ und „Misserfolgspfade“, die gut zum Anwendungsfall passen.
• Promises werden genau einmalig auf Erfolg oder Misserfolg hin überprüft, was Unklarheiten darüber auslöst, ob ein Callback nicht auch dauerhaft ausgelöst werden kann (z.B. wenn neue Geräte angeschlossen werden).

Einen Code zu schreiben, welcher mit beiden Browsern funktioniert, ist trivial.

Chrome`s PositionSensorVRDevice ist fast identisch mit Mozilla`s, verfügt aber über eine ResetSensor-Funktion. Der Aufruf dieser Funktion setzt die HDM-Sensoren zurück, um die aktuelle Richtung des Benutzers „vorwärts“ zu berücksichtigen.

Chrome`s M`HMDVRDevice hat ein paar Attribute, die bei Mozilla fehlen und es fehlen ein Paar, die in Mozilla`s Code vorhanden sind. Chrome verfügt über die Vektoren displaySize und renderTargetSize, um die Auflösung des HMD-Displays und die empfohlene Renderzielgröße anzuzeigen. Die Renderzielgröße wird voraussichtlich größer als die Anzeigegröße sein und wird so berechnet, dass die gerenderte Ausgabe ein Verhältnis von 1:1 Pixel hat, wobei die Anzeige an ihrem verzerrtesten Punkt angezeigt wird, nachdem das resultierende Bild durch den Prozess der Verzerrungsnachbearbeitung gelaufen ist. Es ist erwähnenswert, dass das devicePixelRatio nicht berücksichtigt werden sollte, wenn man die Größe eines Canvases für VR-Rendering festlegt.

(Update: Chrome unterstützt displaySize nicht mehr, da es keinen Einfluss auf das Rendering hat. RenderTargetSize wurde in getRecommendedRenderTargetSize() geändert, um der Tatsache Rechnung zu tragen, dass sich sein Wert ändert, wenn das Sichtfeld geändert wird.)

Chrome fehlt derzeit die feinere Kontrolle über das Sichtfeld von Mozilla. Sie können getRecommendedFieldofView aufrufen, aber es gibt keine getCurrentEyeFieldOfView. GetMaximumEyeFieldOfView oder setFieldOfView. Alle Renderings in Chrome gehen derzeit davon aus, dass Sie das empfohlene FOV verwenden.

(Update: Chrome unterstützt nun setFieldOfView, getMaximumEyeFieldOfView und getCurrentEyeFieldOfView)

Schließlich können Sie mit Chrome vrDistortion:false in webkitRequestFullscreen zusammen mit vrDisplay:hdm übergeben, um zu verhindern, dass das Postprocessing zur Verzerrung läuft. Dies ist nützlich für die Überprüfung der Renderergebnisse, kann aber auch verwendet werden, wenn Sie einen eigenen Verzerrungsdurchlauf implementieren möchten. Die API liefert zur Zeit keine Informationen über die gewünschte Verzerrungsformel, allerdings ist dies eine „best guess“-Affäre, möglicherweise basierend auf dem HDM-Namen. Es wird dringend empfohlen, den Browser die Verzerrung für Sie übernehmen zu lassen.

(Update: Lassen Sie uns die Fullscreen-API besser erklären. Es gibt zwei Funktionen in Chrome, die Sie für den Vollbildmodus verwenden können: webkitRequestFullScene und webkitRequestFullScreen. Erstere ist veraltet, während letztere der W3C-Spezifikation entspricht. Ich habe nur die konforme Version eingerichtet, um mit der VR-API zu arbeiten. Wenn Sie den anderen benutzen, gehen Sie in den Vollbildmodus, erhalten aber nicht den Verzerrungseffekt. Also kurz gesagt, verwenden Sie den folgenden Code für den Cross-Browser VR Fullscreen:)

Wir möchten auch darauf hinweisen, dass Chrome den Oculus DK1 Latenztester unterstützt, ohne dass der Entwickler dafür etwas tun musste.

Lassen Sie uns noch einmal betonen, dass all diese Änderungen verworfen sind, die auf den Bedürfnissen der Entwickler beruhen.

Bekannte Probleme.

In erster Linie ist es so, dass beim Aufruf von webkitRequestFullscreen das Canvas zwar im Vollbildmodus arbeitet, aber nicht automatisch den Inhalt auf der HDM anzeigt. Entweder müssen Sie das Fenster auf das HDM-Display verschieben, bevor Sie den Vollbildmodus einschalten oder Sie verwenden das Screen Mirroring. Keine der beiden Optionen ist großartig, aber hoffentlich ist diese Situation nur von kurzer Dauer. Ziel ist es, wenn Sie mit einem VR-Gerät im Vollbildmodus arbeiten, der Inhalt automatisch auf das HDM-Display übergeht und dann auf das Hauptdisplay zurückkehrt, wenn Sie Escape drücken.

Und die Übergabe einer HMD an die Vollbild-API funktioniert nur mit Canvas-Elementen, die im Moment einen WebGL-Kontext haben. Diese Einschränkung wird wahrscheinlich noch eine Weile bestehen bleiben, während wir uns Mozillas Arbeit mit 3D-CSS-Inhalten in VR anschauen. Um es ganz offen zu sagen: Ich habe keine Ahnung, wie das aus einer UX-Perspektive funktionieren wird und da Mozilla mehr Manpower auf WebVR hin ausgerichtet hat, bin ich froh, dass sie es zuerst fühlen dürfen.

Auch das endgültige Ausgabebild nach der Verzerrung ist die gleiche Größe wie ihr Renderziel und nicht die Größe des HDM-Displays. Ich denke, dass dieses Ziel mit chromatischer Aberration Correction erreicht werden könnte, aber wir können natürlich keine Garantie darauf geben. Es ist aus Sicht der Speichernutzung sicherlich nicht optimal und sollte in naher Zukunft korrigiert werden.

Wie können Sie helfen?

Wenn Sie sich für diese Technologie begeistern und mithelfen wollen, Sie voranzutreiben, dann finden wir das großartig. Wahrscheinlich werden Sie dieser Technologie am besten zum Vorankommen verhelfen, wenn Sie etwas Großartiges entwickeln, was WebVR verwendet. Ob es nun darum geht, Support in eine bestehende Anwendung zu hacken oder etwas völlig Neues zu erstellen – je mehr Anwendungsfälle es gibt, desto überzeugender wird die API.