Augmented Reality - QUANTO Solutions (2024)

Augmented Reality (AR) hat sich schnell von einem futuristischen Konzept und einer Nischenanwendung zu einer digitalen Schlüsselstrategie für viele Unternehmen entwickelt. Revolutionäre Benutzerinteraktionen in Verbrauchermärkten, Anwendungen in der Medizintechnik, im Bildungsbereich und generell bei der Transformation und Optimierung von Geschäftsprozessen. Überall haben sich vielversprechende Ansätze etabliert.

Die entwicklungsseitigen Vorteile liegen auf der Hand: Der zunehmende Trend zu webbasierten Softwarelösungen zeigt sich im AR-Bereich durch die Entwicklung browserbasierter Standards. Unternehmen profitieren von der Plattformunabhängigkeit und dem im Vergleich zu nativen Lösungen reduzierten Entwicklungsaufwand. Zudem entfallen Installationsprozesse, was beispielsweise die Usability und Interaktion bei entsprechend kundenorientierten Produkten verbessert oder auch die Integration in Enterprise Security Frameworks in Bezug auf die interne Gerätelandschaft erleichtert.

In diesem Beitrag konzentrieren wir uns auf aktuelle Entwicklungen speziell im Bereich der webbasierten und markerlosen AR. Wir schauen uns dabei praktikable Umsetzungsmethoden an und werfen einen Blick auf mögliche Limitationen und wichtige Trends aus Unternehmenssicht.

Was ist Augmented Reality?

Augmented Reality (AR) beschreibt den visuellen Prozess, in dem die reale Welt um digitale Daten erweitert wird. Im Vergleich zur Virtual Reality (VR), die Benutzer in eine vollständig digitale Umgebung versetzt, überlagert AR beispielsweise eine reale Kamerasicht mit digitalen Elementen wie 3D-Modellen, Animationen oder Textinformationen.

Einsatzbereiche von AR

In der geschäftlichen Anwendung verleiht AR Produkten und Dienstleistungen so eine neue Dimension. Im B2C können Onlinekunden interessante Produkte durch Smartphones oder Tablets mit den realen Dimensionen in den eigenen vier Wänden betrachten. Ähnliche Anwendungen werden im B2B Umfeld implementiert, um Maschinen und Bauteile zu visualisieren oder die visuelle Navigation durch neue Anlagen zu erleichtern. Weitere Anwendungen unterstützen die Ausbildung von Ingenieuren oder technisches Personal bei Reparatur- und Wartungsarbeiten. Spitzentechnologien beschäftigen sich z.B. auch mit AR zur Reduktion von Verletzungen und Erholungszeiten bei chirurgischen Eingriffen. Durch zusätzliche Informationen lässt sich die Präzision chirurgischer Eingriffe erhöhen und Risiken minimieren.

Marker-basierte vs. markerlose Augmented Reality

Ein kritischer Aspekt in den Anforderungen für verschiedene AR-Systeme ist dabei die Entscheidung zwischen marker-basierter und markerloser Projektion digitaler Informationen im Raum bzw. der Verankerung von 3D-Modellen in der realen Welt. Was bedeuten diese Begriffe konkret und wie unterscheiden sie sich in ihrer Anwendung und ihren technischen Anforderungen?

Marker-basierte Augmented Reality

… setzt physische „Marker“ in der Umgebung ein, um digitale Inhalte präzise zu platzieren. Diese Marker, wie QR-Codes, dienen als Orientierungspunkte für die AR-Software, um Objekte genau zu positionieren und zu skalieren. Die Methode bietet hohe Präzision und Zuverlässigkeit bei geringem Ressourcenaufwand. Sie schränkt jedoch die Spontanität und mögliche Einsatzorte durch die Notwendigkeit physischer Marker ein.

Markerlose Augmented Reality

… verzichtet auf physische Marker und verwendet stattdessen fortschrittliche Algorithmen zur Echtzeiterfassung der Umgebung. Diese Technik integriert digitale Inhalte direkt in die reale Welt, was eine flexible Anwendung in verschiedensten Umgebungen ermöglicht. Allerdings ist der Prozess komplexer und kann, abhängig von der Umgebung und der Technologiequalität, in Performanz und Präzision variieren.

Die Entscheidung zwischen marker-basierter und marker-loser AR hängt also stark vom geplanten Anwendungszweck ab.

Plattformunabhängigkeit durch webbasierte AR

Bei der ursprünglichen AR-Entwicklung mit nativen Apps auf mobilen Endgeräten werden plattformspezifische Frameworks wie ARKit für iOS und ARCore für Android genutzt. Sie erleichtern wesentlich das Auslesen von Sensordaten und deren Zusammenführung für AR-Funktionen. Webanwendungen bieten durch ihre Ausführung in standardisierten Browsern den Vorteil der Plattformunabhängigkeit. Jedoch unterscheiden sich die Anforderungen für AR-Applikationen stark von herkömmlichen Webseiten, da Webanwendungen nicht direkt auf native Hardwareschnittstellen, Frameworks oder andere Apps zugreifen können. Die Lösung dieses Problems liegt in den Browser-Schnittstellen.

Browser-Schnittstellen und der WebXR Standard

Der Browser selbst ist eine native App, wie z.B. Safari auf iOS oder Google Chrome auf Android, die vertikal direkt auf Geräte und Ressourcen wie etwa die Grafikkarte zugreift und horizontal mit anderen nativen Anwendungen kommuniziert. Browser-Schnittstellen hingegen sind Module, die nativ in den Browser integriert sind und der JavaScript Laufzeitumgebung für Webanwendungen Funktionen bereitstellen können. Ein klassisches Beispiel hierfür ist die WebGL Schnittstelle, welche die Grafikkarte zum Zeichnen von 3D Modellen und Animationen im Browser nutzt, da normalerweise jeder JavaScript Prozess CPU gebunden ist. Obwohl eine Webanwendung also die Grafikkarte nicht direkt ansprechen kann, ermöglicht die Browser-Schnittstelle deren Verwendung. Zu bestimmten Zwecken und unter strikt kontrollierten Bedingungen. Diese Abkapselung ist zudem sicherheitsrelevant, da Browser täglich Anwendungen ohne Installation aus verschiedenen Quellen ausführen.

Nachdem das Interesse an mobilen AR-Anwendungen mit der Einführung von ARKit und ARCore stieg, wurde 2018 die WebXR-Schnittstelle als W3C Browser-Standard vorgeschlagen. Ziel war es, neben marker-basierter AR auch VR und markerlose AR zu ermöglichen. WebXR bietet nicht nur Funktionen zur Flächenerkennung und Sensordatenvereinigung, sondern auch zur Messung der Lichtverhältnisse oder zur Verankerung und Tracking von digitalen Objekten. Im Falle von Browsern auf Android Plattformen (Abb. 1) wird dies z.B. durch den vorinstallierten Brückendienst “Google Play Services for AR” zum ARCore Framework realisiert.

SLAM Engines: Kernstück für komplexe Echtzeit-Lokalisierung

SLAM steht für „Simultaneous Localization and Mapping“. Ein Verfahren, bei dem ein Gerät gleichzeitig seine eigene Position in einem unbekannten Raum bestimmt und dabei eine Karte dieses Raumes erstellt anhand einer Kamera und weiterer Sensoren. Dies geschieht mithilfe fortschrittlicher Methoden der Computer Vision, die entweder auf traditionellen Algorithmen oder vermehrt auf neuronalen Netzwerken basieren. Während traditionelle Algorithmen explizit programmierte Regeln zur Bildanalyse und Raumerkennung nutzen, lernen neuronale Netzwerke aus einer Vielzahl von Daten, Muster und Strukturen selbständig zu erkennen. Das ermöglicht eine flexiblere und oft genauere Erfassung der Umgebung. Das ARCore Framework, das unter anderem eine SLAM Engine nutzt, dient als prominentes Beispiel, insbesondere bei WebXR auf Android. Die zentrale Rolle von SLAM und dessen Komplexität ist ein wichtiger Faktor zum Verständnis und zur Evaluation der Stärken und Schwächen von existierenden Tools.

Aktuelle Tools für webbasierte, markerlose Augmented Reality

Die folgende Tabelle zeigt eine Auswahl von webbasierten Bibliotheken, Frameworks und anderen Tools, die speziell für markerlose AR in Browsern selektiert wurden.

Bei der Wahl des richtigen Tools geht es nicht nur um grundlegende Features wie markerlose AR. Lizenzmodelle, Entwicklungsmethoden und Deploymentoptionen sind ebenso kritische Faktoren. Open-Source JavaScript Bibliotheken wie THREE.js bieten Flexibilität ohne Lizenzkosten, während kommerzielle Produkte wie 8thWall spezialisierte Funktionen mit Support kombinieren. Der Entwicklungsansatz unterscheidet sich ebenfalls: Webentwicklung setzt auf JavaScript, was einen breiten Pool an Fachkräften eröffnet. Im Gegensatz zu Gruppe derjenigen, die über Skillsim Umgang mit Game Engines wie Unity 3D verfügen. Die Entscheidung zwischen Cloud-basierter oder lokaler Entwicklung beeinflusst den Zugang und die Kontrolle über Daten, während die Deploymentfreiheit von der Wahl des Lizenzmodells abhängt. Unternehmen müssen diese Faktoren sorgfältig abwägen, um ein Tool zu wählen, das ihren Bedürfnissen am besten entspricht.

Ein Aspekt, der in dieser Kurzübersicht besonders ins Auge fällt: Die meisten der weit verbreiteten Tools bauen entweder direkt auf der WebXR-Schnittstelle auf oder stellen eine Simulation davon für andere Tools bereit. Bevor wir einen genaueren Blick auf einige dieser Tools werfen, ist es daher wichtig, ein Verständnis dafür zu entwickeln, wie und in welchem Umfang WebXR derzeit auf verschiedenen Plattformen Unterstützung findet.

Browser- und Plattformkompatibilität für WebXR

Im Gegensatz zu regulierten Standards, wie z.B. Normierungen in der Industrie oder Hardwareproduktion, sind Browserhersteller nicht verpflichtet, Browser Standards wie WebXR zu implementieren. Auch wenn es generell in ihrem eigenen Interesse liegt zur Standardisierung der Entwicklung und Ausführung von Webanwendungen in ihren Browsern beizutragen, um Akzeptanz und Marktanteil zu steigern, ist dies bei spezielleren Funktionen wie Augmented Reality, die noch als relativ neue Konzepte für komplexe Anwendungen im Web gelten, nicht unbedingt der Fall.

Nachfolgend sehen wir eine kurze Übersicht für den aktuellen WebXR Support in prominenten mobilen und Desktop Browser Versionen auf Android und iOS von caniuse.com:

Im Fall von Apple hatte man sich anfänglich bewusst gegen WebXR Support auf iOS-Geräten entschieden, da man AR-Erfahrungen strikt auf native Anwendungen mit ARKit begrenzen wollte. Entsprechend ist diese Schnittstelle aktuell immer noch nicht in Safari auf iPhones oder iPads verfügbar, trotz wiederkehrender Teilnahme in der W3C Immersive Web Working Group. Interessanterweise bietet die Desktop Version von Safari jedoch zumindest experimentellen Support. Browser im Android Ökosystem hingegen, vor allem Google Chrome als Vorreiter, bieten hier die bisher umfangreichsten Implementationen von WebXR. Obwohl Google Chrome auch auf iOS verfügbar ist, fehlt auch dort der WebXR Support, weil Apple auf iOS die Diversität der Browser-Engines beschränkt. Im Endeffekt muss jeder Browser auf iOS dieselbe WebKit Engine wie Safari verwenden, und ist somit auch durch deren Browser Schnittstellen Implementationen limitiert.

WebXR Ausweichstrategien auf iOS

Trotz des stetigen Ausbaus von WebXR stellt sich nun die Frage, welche Workarounds heute schon für die iOS-Plattform existieren. Einige davon wurden in der zweiten Hälfte der Tabellenübersicht für Tools bereits aufgenommen, welche wir nun kurz und prägnant bezüglich ihrer Funktionsweise und daraus resultierenden Vor- und Nachteile beleuchten werden.

QuickLook für native AR-Vorschau auf iOS

Bei QuickLook handelt es sich um ein kostenloses Feature, das auf jedem AR-fähigen iOS-Gerät vorinstalliert ist. Separate Installationsprozesse entfallen damit. Durch eine native Anwendung, welche ARKit für minimale markerlose AR nutzt, lassen sich so Vorschauen von 3D Produktmodellen in der direkten Umgebung schnell und einfach mit hoher Performanz realisieren. Damit Webseiten und Online-Shops dieses Feature nutzen können, gibt es eine Möglichkeit, die native QuickLook App im Safari mit einem Link durch spezielle Attribute für ein bestimmtes Modell anzusteuern:

<a href=“https://example.com/product1.usdz“ rel=“ar“ arc-placement=”wall”>

Produkt in QuickLook AR-Vorschau öffnen

</a>

Vor- und Nachteile

Nachdem der Link geklickt wurde, wird man aus dem Browser heraus zur QuickLook Anwendung für die gegebene Model URL geleitet. Obwohl Aspekte wie Wanddetektion und Verankerung hier besser funktionieren werden, deren Erkennung meist eine komplexere Computer Vision Herausforderung im Vergleich zu Bodenflächen ist, hat man keine Möglichkeit, die Steuerung oder die Oberfläche in der QuickLook Anwendung anzupassen. Dies bedeutet, dass man zwischen der WebXR Anwendung in Android Browsern und QuickLook auf iOS keine uniforme Benutzererfahrung hat. Dies betrifft auch grundlegende Abläufe, wie z.B., dass man mit QuickLook vor Aufruf mit dem “ar-placement” Attribut angeben muss, ob man Wand- oder Bodenflächen ansteuern möchte. Falls man für die Platzierung mehr Dynamik benötigt, muss man hier mehrfach zwischen Browser und QuickLook hin und her wechseln. Zu guter Letzt erlaubt QuickLook nur das von Apple und Disney entwickelte Dateiformat USDZ für 3D Modelle, im Gegensatz zu herkömmlichen Varianten wie GLTF/GLB im Web.

App Clips und WebXR Browser für native WebXR Ausführung auf iOS

Da die WebXR Schnittstelle auf Android für AR vorwiegend eine Brücke zum nativen ARCore Framework für Android darstellt, wäre ein Äquivalent auf iOS für das ARKit Framework nicht sinnvoll? Obwohl wir dies eventuell in der Zukunft von Apple bei der WebXR Implementation im mobilen Safari erwarten können, gibt es heute schon Wege dies zu ermöglichen. Wie zuvor erwähnt, agieren manche der aufgelisteten Tools als Simulatoren der WebXR Schnittstelle im Browser. Dazu gehören z.B. spezialisierte Browser wie “WebXR Viewer”, welche als installierbare App WebXR Anwendungen browsen können, oder die sogenannten “App Clips“. Der ursprüngliche Zweck von App Clips ist es, eine Vorschau der Apps ohne Installation für Benutzer zu bieten, in dem ein kleiner Teil der Anwendung (kleiner 10 MB) direkt heruntergeladen und vom App Store ausgeführt wird. Dies lässt sich aber auch nutzen, um eine Anwendung zu schreiben, die WebXR Schnittstellen Aufrufe auf ARKit Funktionen überträgt mit einer Browser Laufzeit.

Zusätzlich zu nativer Performanz haben wir eine vorwiegend konsistente Benutzererfahrung, da tatsächlich dieselbe WebXR Anwendung, mit der gleichen Steuerung und Oberfläche, auch auf iOS ausgeführt wird. Der einzige Unterschied im Ablauf, ähnlich zu QuickLook, ist die Umleitung auf eine native Anwendung. Wenn man dies selbst implementieren will, muss man den nativen Brückendienst als App Clip öffentlich im App Store hosten und pflegen. Falls dies nicht praktikabel ist oder die Anwendung nur intern und nicht für Dritte zur Verfügung stehen soll, muss man auf Produkte wie VariantLaunch ausweichen, die diese Aufgabe kommerziell übernehmen.

Webbasierte SLAM Engine Frameworks – 8thWall

Es gibt aber auch die Möglichkeit, eine SLAM Engine direkt in Webanwendungen zu integrieren, ohne sich auf spezifische AR-Browser-Schnittstellen zu verlassen. Die 8thWall Plattform von Niantic, die WebXR simuliert, ermöglicht die Nutzung von Browser-Schnittstellen für Sensordaten wie Kamera und Gyroskop auf Android und iOS. Dieses Framework, ausgeführt in der Browserumgebung mittels WebAssembly (WASM) und Computer Vision, bietet eine plattformunabhängige Lösung ohne Installationsbedarf. Aktuell gibt es keine vergleichbaren Alternativen zu 8thWall, was kommerzielle und lizenzkostenfreie Optionen angeht. Die Benutzer müssen jedoch berücksichtigen, dass die Performanz und Genauigkeit dieser Lösung nicht immer mit nativen Anwendungen mithalten kann.

Pre-Mapping und Visuelle Positionierungssysteme (VPS)

Eine Methode, SLAM-Prozesse effizienter zu gestalten, wird unter anderem „Pre-mapping“ genannt, bei dem eine virtuelle Karte durch vorheriges Scannen der Umgebung erstellt und gespeichert wird. Dies beschleunigt den Abruf während der AR-Session und vermeidet anspruchsvolle Generierung der Karte in Echtzeit. Ein Nachteil ist der Verlust der Flexibilität in unbekannten Umgebungen, besonders wenn keine Vorbereitungszeit vorhanden ist. Zusätzlich existieren visuelle Positionierungssysteme (VPS), die GPS mit Bilderkennung kombinieren, um hohe Genauigkeit und Robustheit in markerloser AR zu bieten, was allerdings auch eine Vorbereitung erfordert. Niantic bietet z.B. Lightship VPS als Produkt für webbasierte Anwendungen in diesem Bereich.

Aktuelle Limitationen von webbasierter Augmented Reality

Ein Punkt sind die potenziellen Performance-Unterschiede zwischen webbasierten und nativen AR-Lösungen, speziell bei markerlosen Anwendungen. Dies liegt zum einen in der sicherheitsrelevanten Natur, wie Webanwendungen im Browser ausgeführt werden, begründet und zum anderen an den Abstraktionen, die z.B. im Fall von WebXR zum Einsatz kommen.

Ein simpler Vergleich: FPS-Benchmarking

Um diesen Umstand zu demonstrieren, zeigen wir einen einfachen Vergleich in Form einer Benchmark für die Bildrate (FPS) von Implementationen mit ein paar der aufgelisteten Technologien.

Obwohl diese Resultate nicht zu genau genommen werden sollten, da solche Benchmarks bei vielen Variablen schwer zu standardisieren sind und die Bildrate nur ein Faktor ist, können wir trotzdem generelle Trends beobachten.

Die nativ ausgeführte Variante mit VariantLaunch (VL) erreicht annähernd stabile 60 FPS, während im Browser ausgeführte oder auf WebXR basierende Anwendungen sich je nach Situation zwischen 20 und 30 FPS bewegen. Für manche Modelle und Parameter ließen sich annähernd konstante 30 FPS erreichen. Trotz dieser maßgeblichen Distanz ist es wichtig zu verstehen, dass die Performanz, welche wir aktuell mit webbasierter AR für markerlose Anwendungen erreichen können, für viele Anwendungsfälle ausreichend ist.

Ausblick und aktuelle Trends

Die Entwicklung von WebXR als Standard begann erst ab 2020 wirklich Fahrt aufzunehmen, somit handelt es sich trotz rasanten Fortschritten um eine relativ junge Technologie. Trotz gegenwärtiger Limitationen ist webbasierte und markerlose AR aber im Vergleich zu nativen Anwendungen bereits heute ein solider Lösungsweg. Die jeweiligen Anwendungsfälle müssen jedoch genau analysiert und mit den Kapazitäten aktueller Technologien abgewogen werden.

Obwohl WebXR in der Safari Version für die Apple Vision Pro bereits verfügbar ist und somit eine Freigabe auf iPhones und iPads in naher Zukunft zu erwarten war, wird dieser Prozess nun noch einmal durch neue EU-Verordnungen beschleunigt. In einer kritischen Entwicklung wurde vor ein paar Monaten iOS 17.4 veröffentlicht, welches alternative App Stores und Browser Engines in der EU ermöglicht. Dadurch ließen sich viele Probleme schlagartig lösen, die zuvor Ausweichstrategien für WebXR in Bezug auf Plattformunabhängigkeit benötigten. Auch wenn native WebXR Laufzeitumgebungen oder Browser SLAM Engines immer noch andere Vorteile besitzen.

Mit der rapiden Weiterentwicklung von WebXR und anderen Browser Standards wie z.B. WebGPU, durch welche im Browser ausgeführte neuronale Netzwerke eventuell auch praktikabel werden, sieht die Zukunft für markerlose Webanwendungen vielversprechend aus bezüglich Leistung und Präzision. Der Zeitpunkt ist also besser als jemals zuvor, sich aus Unternehmenssicht damit zu beschäftigen, wie webbasierte AR als nützliche Geschäftsstrategie implementiert werden kann. Da nicht alle Optionen und Aspekte in diesem Beitrag behandelt werden konnten, zögern Sie nicht, sich bei weiteren Fragen an uns zu wenden.