Dieter Petereit 28. Juni 2018

WebXR und 3D-Webdesign: Licht und Schatten

Webdesign für Virtual-Reality-Headsets und andere Geräte ist prinzipiell möglich. Die WebXR-Device-API wurde dieser Tage als Editor’s Draft veröffentlicht. Nur, wozu soll die Technologie gut sein?

WebXR-Device-API im Status eines Editor’s Draft

Ich weiß nicht, ob du es schon mitbekommen hast. Die WebVR Community Group, maßgeblich betrieben von Mitarbeitern der Firmen Mozilla und Google, hat sich umbenannt und heißt jetzt Immersive Web Community Group. Bislang hatte sie sich mit dem Thema WebVR, also der virtuellen Realität im Web, befasst, nun ist der Aufgabenbereich breiter.

Dem gesunden Menschenverstand folgend, wurde WebAR, also die erweiterte Realtität (Augmented Reality) für das Web in die Spoezifizierung durch die Community-Group integriert. Deshalb heißt der angestrebte Standard nun weder WebVR, noch WebAR, sondern WebXR (vermutlich Extended Realtity, auch wenn das offiziell nirgends so steht). WebXR soll alle Technologien umfassen, die sich mit Formen digitaler Realität auf unterschiedlichsten Geräten befassen. Da ist das VR-Headset dabei, aber auch das Smartphone als Hauptbetrachtungssystem für erweiterte Realitäten, sowie alle Geräte, von denen wir heute nur träumen können.

Die eben veröffentlichte WebXR-Device-API soll entsprechend die Standard-Spezifikation werden. Sie basiert auf der bisher geleisteten Arbeit der WebVR-API, die immerhin schon in Version 1.1 vorgelegen hatte. Die neue Spezifikation befindet sich im Status eines „Editor’s Draft”, also keinem offiziell bedeutsamem Status.

Ziel der WebXR-Device-API ist es einerseits, VR- und AR-Hardware in die Lage zu versetzen, Web-Inhalte darzustellen. Andererseits sollen Entwickler mit Werkzeugen ausgestattet werden, die dabei helfen, virtuelle Realitäten im Browser zu erschaffen und dann auf Headsets, Smartphones und anderen Geräten nutzbar zu machen. Dabei ist nicht zuletzt der Zugriff auf die entsprechenden Gerätefeatures per JavaScript wichtig.

Der aktuelle Chrome in Version 67 unterstützt bereits WebXR. Die Unterstützung muss allerdings manuell aktiviert werden. Unter chrome://flags suchst du nach #webxr. Von den dann gefundenen vier als Experimenten gekeinnzeichneten Elementen aktivierst (enable) du mindestens das oberste, nämlich die eigentliche WebXR-Device-API. Auf caniuse.com suchst du WebXR derzeit noch vergeblich. Hier lässt sich nur die ältere WebVR-Spezifikation auf Browser-Unterstützung prüfen.

WebXR soll responsiv funktionieren

In der Berichterstattung rund um die WebXR-API ist viel die Rede davon, dass sich WebXR-Anwendungen responsiv verhalten sollen. Damit ist weniger die Anpassung an verschiedene Bildschirmgrößen und -auflösungen gemeint, als vielmehr das automatische Wechseln zwischen VR und AR, denn beide Perspektiven haben ihren spezifischen Nutzen.

VR-Spiele sind nicht unbeliebt, konnten sich aber auch noch nicht durchsetzen. (Foto: Depositphotos)

VR ist geeignet, ein Element in Relation zum eigenen Körper zu betrachten und einzuschätzen. AR ist geeignet, Elemente in Relation zur Umgebung zu betrachten und einzuschätzen. Optimal wäre deshalb ein VR-Headset mit transparentem Durchblick. Bis es so etwas gibt, müssen wir wohl zwischen den Technologien wechseln. Gut, wenn das „responsiv” möglich ist, also etwa durch Aufruf der gleichen Website einmal mit dem Headset, einmal mit dem Smartphone, aber ohne weitere Eingriffserfordernisse des Nutzers.

WebXR: Web-Inhalte in die virtuelle oder erweiterte Realität bringen

Beim bisherigen WebVR geht es „nur” darum, bisherige 3D-Designs auf VR-Headsets zu bringen. Das könnte man sehr einfach über Screen-Mirroring machen, indem man also seine VR-Brille einfach als zweiten Bildschirm anschließt. Insofern ist es nicht verwunderlich, dass etwa Three.js gerne für die Entwicklung genommen wird.

Unterstützt werden die gängigen VR-Einheiten, allen voran Google’s Cardboard, Oculus Rift, Samsung Gear VR, sowie die HTC Vive.

Konsequenterweise wird auch bei WebVR-Part des WebXR mit WebGL gearbeitet. Die eigentliche virtuell-reale Darstellung erfolgt innerhalb eines HTML5-Canvas-Elements, was, wenn man ehrlich ist, schlussendlich nicht wirklich viel mit Webdesign zu tun hat. DOM-Elemente, die man mittels der 3D-Erweiterungen zu CSS auch verwenden könnte, werden aus Gründen der technischen Komplexität derzeit nicht unterstützt. WebGL-Inhalte sind derzeit die einzigen darstellbaren VR-Elemente.

Ein VR-Headset ist kein zweiter Monitor

Zurück zu den Monitoren: VR-Brillen haben selbstverständlich ganz andere Spezifikationen, aber auch Fähigkeiten als Monitore. Eine VR-Brille als zweiten Bildschirm einzubinden, kann daher nur ein fieser Kompromiss sein, der nichts mit enem grandios beeindruckenden Nutzererlebnis zu tun haben kann. Sicherlich lassen sich Inhalte so konsumieren, aber dass man dafür jetzt gezielt ein VR-Headset aufsetzen wollen würde, nee.

VR-Headsets bieten, wenn man auf der kleinsten Funktionsebene schaut, mindestens noch eine lageabhängige Anpassung des Viewports in alle Himmelsrichtungen. Zudem befinden sich am Headset zumeist Steuerelemente für die Interaktion mit dem Gezeigten. Hardware, wie HTCs Vive, geht sogar noch mehrere Schritte weiter und verfügt über weitere Körpersensoren, mit denen man dann beispielsweise auch greifen oder andere Hand-Interaktionen vornehmen kann.

Für ein realistisches VR-Erlebnis bedarf es zudem extrem niedriger Latenz-Zeiten. Schon auf dem Monitor nervt es gewaltig, wenn du eine Eingabe machst und erst gefühlte Sekunden später den Effekt dessen auf dem Bildschirm siehst. Das Problem potenziert sich in der virtuellen Realität deutlich.

Stell dir vor, du drehst den Kopf, aber das Sichtfeld zieht erst mit einiger Verspätung nach. Du würdest schon auf kurze Dauer mit ziemlicher Sicherheit eine Form von Seekrankheit erleiden, da die sensorischen Impulse nicht mit den optischen übereinstimmen.

Für VR auf Smartphones gilt daher: Je leistungsfähiger das Phone, desto besser. Positiv formuliert…

Und wozu soll das gut sein?

Ich bin generell skeptisch, was die Sinnhaftigkeit von WebVR angeht und sehe die virtuelle Realität eher im Gaming- und Augmented-Reality-Bereich gut und nützlich angesiedelt. Was ich von VR-Webdesign halte, habe ich in diesem Cartoon zum Ausdruck gebracht:cartoon

Wenn ich mir den Mixed-Reality-Showcase bei MozVR ansehe, sehe ich wenig, was mich vom Gegenteil überzeugen könnte. Natürlich, der Panorama Viewer ist ganz nett, aber dafür würde ich mir jetzt kein VR-Headset zulegen.

Mixed-Reality-Showcase bei Mozilla. (Screenshot: D. Petereit)

Die Werbeindustrie wird sich wohl darauf stürzen, wie schon seinerzeit auf Flash. Immerhin kann man dann so tolle „immersive” Erlebnisse kreiieren, die voll supi sind. Eine weitere Industrie fällt mir noch ein. Es ist jene, die schon seit langem für den meisten Traffic im Web verantwortlich ist und sogar dafür sorgen könnte, dass namhafte Stückzahlen an VR-Headsets in diskreten Verpackungen nach Hause geliefert werden.

Wenn ich begeisterungsfähiger wäre, könnten mir vielleicht die 360-Grad-Videos der Sportschau gefallen. Tun sie aber nicht und warum? Es ist eigentlich ganz einfach.

VR-Angebot der Sportschau: Eher flau. (Screenshot: D. Petereit)

Bei einem Musikstück folgen die Musiker vorgegebenen Vereinbarungen, in dem Falle Noten genannt. Ich möchte kein 360-Grad-Musikstück hören, bei dem einfach alle spielen und alles irgendwie so schön sphärisch klingt. Ich habe auch noch nie auf Sky andere Perspektiven bei Sportübertragungen eingeschaltet, weil ich davon ausgehe, dass eine Bildregie nicht überflüssig ist. Selbst bei der eben angesprochenen Branche mit dem hohen Traffic könnte ich mir den Nutzen eines 360-Grad-Videos nicht vorstellen. Soll ich mir den ansehen, der den Film macht?

Ich sags dir, VR ist was für Spiele, aber nichts fürs Webdesign.

Bei WebAR sieht die Sache anders aus

Erweiterte Realität ist indes etwas, von dem ich überzeugt bin, dass es sich durchsetzen wird. Eben erst habe ich dazu hier auf Dr. Web einen längeren Beitrag geschrieben.

AR: Hier werden weitere Informationen über das Live-Bild geblendet. (Illustration: Depositphotos)

Jetzt nimm die Inhalte dieses Beitrags und kombiniere sie mit meinem Beitrag „Designer, bau keine Apps, wenn Websites reichen”. Jetzt schaust du noch in „Was sind Progressive Web Apps und wieso sollte dich das interessieren?” und schon wird ein Schuh draus.

Okay, okay. Du brauchst das jetzt nicht wirklich alles zu lsesen, obwohl es nicht schaden würde. Ich bringe die Gesamtausgabe mal auf den Punkt.

  1. Erweiterte Realität kann in vielen Bereichen, etwa in Service und Support, aber auch im Vertrieb großen Nutzen entfalten.
  2. Wenn du eine breite Nutzerschaft erreichen willst, ist es heutzutage nicht mehr ratsam, Apps zu programmieren, denn die meisten versauern ungenutzt in den App-Stores.
  3. Statt Apps setzt du auf das relativ neue Konzept der Progressive Web App, einer Website, die auf diverse Geräte-APIs zugreifen kann und so leistungsmäßig nativen Apps in kaum noch etwas nachsteht.

Mit anderen Worten: Was heutzutage mit AR in Apps geht, geht morgen auch mit AR auf Websites, ohne die spezifischen Nachteile nativer Apps zu haben. Das begeistert mich.

Also, lasst uns die WebXR-Device-API durchaus gebührend feiern, wenn auch nicht so sehr mit Blick auf das verschwundene V, sondern vielmehr mit Blick auf das nicht vorhandene A im geänderten Namen.

(Quellennachweis Artikelbild: Depositphotos)

Dieter Petereit

Dieter Petereit

ist seit 1994 im Netz unterwegs, aber bereits seit über 30 Jahren in der IT daheim. Seit Anfang des neuen Jahrtausends schreibt er für diverse Medien, hauptsächlich zu den Themenfeldern Technik und Design. Man findet ihn auch auf Twitter und Google+.
Dr. Webs exklusiver Newsletter
Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Kennst du schon unseren Newsletter?

Hinweise zum Datenschutz, also dem Einsatz von Double-Opt-In, der Protokollierung der Anmeldung, der Erfolgsmessung, dem Einsatz von MailChimp als Versanddienstleister und deinen Widerrufsrechten findest du in unseren Datenschutzhinweisen.

Cookies

Weitere Informationen zu den Auswahlmöglichkeiten findest du hier. Dazu musst du zunächst keine Auswahl treffen!

Um Dr. Web zu besuchen, musst du eine Auswahl treffen.

Deine Auswahl wurde gespeichert!

Informationen zu den Auswahlmöglichkeiten

Was du erlaubst!

Um fortfahren zu können, musst du eine Auswahl treffen. Nachfolgend erhältst du eine Erläuterung der verschiedenen Optionen und ihrer Bedeutung.

  • Ich stimme zu:
    Du erlaubst uns das Setzen aller Cookies, die wir in unseren Datenschutzhinweisen genannt haben. Dazu gehören Tracking- und Statistik-Cookies. Aus dem Tracking per Google Analytics bieten wir auf der Seite Datenschutz ein Opt-Out, also die Möglichkeit der Abmeldung, an.
  • Ich stimme nicht zu:
    Wir verzichten bei dieser Option auf den Einsatz von Google Analytics. Die für den Betrieb von Dr. Web notwendigen Cookies werden aber dennoch gesetzt. Einzelheiten entnimmst du bitte den Datenschutzhinweisen

Du kannst deine Cookie-Einstellungen jederzeit hier ändern: Datenschutz. Impressum

Zurück