Konzeption und Gestaltung von Mixed Reality Anwendungen

Virtual Reality, Mixed Reality und Augmented Reality gehören in der Informatik zu den Bereichen des Visual Computings. Visual Computing umfasst die graphische Datenverarbeitung. Je nach Technik bieten sich unterschiedliche Möglichkeiten und somit auch unterschiedliche Anwendungsgebiete an.

Virtual Reality

In Virtual Reality (VR) ist es dem Anwender möglich, eine künstlich erstellte Welt zu erleben. Der Anwender taucht dabei komplett in eine, am Computer erstellte Welt ein. Mittels Datenbrille, sogenannte Head Mounted Displays (HMD), welche ähnlich wie ein Helm oder eine Brille aufgesetzt werden, können visuelle Daten betrachtet werden. Diese HMDs sind ausgestattet mit einer Linse für jedes Auge, wodurch der Anwender die gezeigten Bilder dreidimensional wahrnehmen kann.

Eine besonders wichtige Rolle spielt das Tracking, welches zum Beispiel durch entsprechende Sensorik und Infrarot-Kameras realisiert werden kann. Hierbei werden die Be-wegungen und die Position des Anwenders erfasst, um diese in der Software zu verarbeiten. So kann beispielsweise mit der Bewegung des Kopfes, die Blickrichtung in der Anwendung gesteuert werden. Somit kann sich der Anwender, auf ganz natürliche und intuitive Art, in der virtuellen Welt umschauen und nimmt dabei ein 360° Erlebnis in 3D wahr.

Auch weitere Interaktionen können, je nach Technik, erfasst werden. Mittels Kontrollern, Handtracking oder speziellen Handschuhen ist es möglich die Bewegungen oder Gesten der Hände wahrzunehmen und Eingaben zu verarbeiten. Für ein möglichst hochwertig immersives Erlebnis spielen noch weitere Faktoren, wie zum Beispiel das Sounddesign, in der Gestaltung einer VR-Anwendung eine große Rolle.

Augmented Reality

Während in Virtual Reality eine komplett künstliche Welt erschaffen wird, werden in Augmented Reality (AR) nur zusätzliche, virtuelle Inhalte in die reale Welt eingeblendet. Für AR ist ein HMD nicht zwingend erforderlich, hierfür kann auch schon ein Tablett PC oder Smartphone mit einer Kamera ausreichen. Die reale Welt wird mittels Kamera gefilmt und am Bildschirm ausgegeben. Auf dem Bildschirm können zusätzliche Inhalte, passend zur Umgebung, angezeigt werden. Die Herausforderung für AR-Anwendungen besteht darin, die reale Welt zu erkennen und die virtuellen Inhalte passend dazu einzublenden.

Mixed Reality

Die hier zu behandelnde Thematik befasst sich vor allem mit Mixed Reality (MR). In Mixed Reality wird, wie in Virtual Reality, ein HMD eingesetzt. Jedoch wird Bezug auf die reale Umgebung, wie bei Augmented Reality Anwendungen, genommen. Mixed Reality wird häufig auch unter AR zusammengefasst. Mixed Reality war ursprünglich ein Marketing Begriff, eingeführt von Microsoft.

Bei der Hololens von Microsoft handelt es sich um ein „optical seethrough“ HMD. Durch dieses HMD kann der Anwender hindurchschauen, ähnlich einer normalen Brille. Virtuelle Objekte können auf die Gläser projiziert werden und in der realen Welt verankert werden. Für den Anwender entsteht der Eindruck eines Hologramms in seiner Umgebung. Da dieses Hologramm in der realen Welt verankert wird, ist es möglich, diese Objekte von verschiedenen Perspektiven zu betrachten. In Mixed Reality ist es zudem möglich, virtuelle Objekte mit der realen Umgebung interagieren zu lassen. Es kann beispielsweise ein Hologramm auf einem physikalischen Tisch abgestellt werden, oder ein virtueller Ball kann an einer realen Wand abprallen.

Im Vergleich zu Arbeiten am normalen Bildschirm wird bei XR-Lösungen der Anwender körperlich beansprucht. Dies ermöglicht neben sportlichen Betätigungen und Therapiemöglichkeiten auch Simulationen und Erprobungen von potentiell kritischen Arbeitsschritten, welche beispielsweise über Kopf ausgeführt werden müssen.

UseCaseManager Anwendung

Im Rahmen dieser Arbeit wurde eine Mixed Reality Anwendung konzeptioniert, gestaltet und implementiert. Mit dieser Anwendung werden zukünftig neue Use Cases mit der Hololens evaluiert. Die Anwendung verarbeitet die spezifischen Use Case-Daten mit Hilfe von ScriptableObjects. Die Architektur ist soweit abstrakt gehalten, um keine konkreten Daten eines Use Cases zu enthalten. Die Daten werden erst zur Laufzeit geladen und instanziiert. Für die MR-Anwendung wurden mehrere Gestaltungsmöglichkeiten erprobt. Eine große Herausforderung besteht darin, die virtuellen Hologramme korrekt in der physikalischen Welt zu platzieren.

Ziele

Ziel dieser Arbeit ist es, das Portfolio des Kundens des digitalen Arbeitens durch die neue Technologie Mixed Reality zu erweitern, um digital erarbeitete Konzepte ohne Medienbruch an Hardware-Prototypen zu validieren. Dazu soll ermittelt werden, welche Kriterien für eine MR-Anwendung entscheidend sind und wo die Grenzen der aktuellen Technik liegen. Mit der Erstellung einer Use Case Anwendung sollen zukünftig neue mögliche Anwendungsgebiete und die Einsatzmöglichkeiten der Microsoft Hololens evaluiert werden können. Es sollen, mit möglichst geringem Aufwand, neue Anwendungsgebiete erstellt und erprobt werden können. Die Erstellung eines neuen Use Cases sollte möglichst innerhalb eines Arbeitstages möglich sein und keine tieferen Programmierkenntnisse voraussetzen.

In einer vorangegangenen internen Analyse wurde ermittelt, welche Arten von Use Cases relevant sein werden. Es müssen verschiedene Bauteile am realen Objekt verortet werden können, diese Bauteile sollen dabei ein- und ausblendbar sein. Als zweiten Use Case Art sollen Information schrittweise dargestellt werden können, beispielsweise um Anleitungen erstellen zu können.

Stand der Technik

Hardware Hololens

Die Hololens von Microsoft ist ein standalone Gerät, welches die Recheneinheit direkt im HMD verbaut hat. Der Betrieb funktioniert dadurch völlig eigenständig, ohne den Anschluss an einen High-End-Rechner, der beispielsweise für eine HTC Vive (VR) erforderlich ist. Da die HoloLens über ein Inside-Out Tracking verfügt, sind keine externen Tracking-Kameras erforderlich. Daraus resultierend ergibt sich eine hohe Fle-xibilität der Einsatzorte, jedoch ist die Leistungsfähigkeit stark limitiert.

Hardwarespezifikation

• Intel Atom x5-Z8100 1 GHz (32-Bit Architektur)
• 2 GB RAM
• HoloLens Graphics (HPU)
• 64 GB Flashspeicher
• 2 HD 16:9 light Engines
• Tiefenkamera
• 4 Umgebungskameras
• IMU
• 2 MP Foto/Video Kamera
• MR-Capture Sensor
• 4 Mikrofone
• 2 Lautsprecher
• Helligkeits-Sensor
• Zwei Akkus mit 2-3 Stunden aktiver Laufzeit
• Gewicht 579 g

Die Microsoft Hololens gilt nach ANSI Z87.1, CSA Z94.3 und EN 166 als Sicherheitsbrille.

Die Hololens kann komplett ohne Kontroller gesteuert werden, dies ist für einen potentiellen Einsatz in Umgebungen wie Werkstätten eine gute Grundlage, da der Anwender seine Hände frei behält. Die Anwendungen können mittels „Gaze“, „Gesture“, „Voice“ und optional auch mit einem „Clicker“ gesteuert werden.

• Gaze beschreibt die Steuerung durch Fokussierung mittels Kopfbewegungen.
• Mittels Gesture können verschiedene Aktionen durch definierte Fingerbewe-gungen ausgeführt werden. Diese werden mit Hilfe der eingebauten Kameras er-fasst.
• Voice-Befehle können ebenfalls dazu genutzt werden, um bestimmte Aktionen auszuführen. Die natürliche Sprache ist ein sehr intuitives Mittel, dies kann je-doch, in besonders geräuschvollen Umgebungen, problematisch werden.
• Der Clicker ist ein kleiner, optionaler Controller, welcher mit der Hand bedient werden kann.

Entwicklung Mixed Reality

Vuforia

Vuforia ist eine AR-Plattform. Hiermit können verschiedene Methoden zur Objekterkennung umgesetzt werden. Diese AR Techniken können ebenfalls für MR angewandt werden. Mittels Marker-Tracking können 2D Bilder am realen Objekt eingescannt werden, um die Position zu bestimmen. Neben diversen anderen Möglichkeiten ist ebenfalls ein 3D-Model Scan möglich. Hier wird das reale Objekt anhand seiner Formen und Farben erkannt.

Spatial Mapping

Die Hololens scannt ihre Umgebung und erstellt daraus entsprechende 3D Daten. An diesen Umgebungsdaten werden die Hologramme verankert. Somit können die virtuellen Inhalte an eine feste Position in der realen Welt platziert werden. Neben der Verankerung können diese Umgebungsdaten dazu genutzt werden, um die virtuellen Inhalte mit der realen Welt interagieren zu lassen. Ein Hologramm kann von einer physikalischen Oberfläche verdeckt werden oder damit kollidieren. Für die markanten Flächen der Umgebungsdaten, werden einfache 2D-Planes in der Anwendung erstellt. Mit diesen kann anschließend interagiert werden.

Die Umgebungsdaten sind fest mit einer Netzwerk SSID verknüpft. Wechselt die Hololens in ein anderes WLAN-Netzwerk, so muss die Umgebung neu erfasst werden. Verbindet sich die Hololens erneut mit einem bekannten Netzwerk, so werden die dazugehörigen Umgebungsdaten geladen.

Abstand der Hologramme

Die Hologramme sollten zur optimalen Darstellung in einem Abstand von mindestens 85 cm angezeigt werden. Im Optimalfall sollte das darzustellende Objekt zwischen 1,25m und 5m Abstand vom Betrachter haben.

Aus diesen empfohlenen Abständen ergibt sich, dass Anwendungsgebiete mit besonders kleinen Objekten, welche normalerweise mit geringem Abstand betrachtet werden, gegenwärtig nicht gut für Mixed Reality geeignet sind. Ebenso sind Objekte mit besonders großer Entfernung nur schwer realisierbar. Objekte welche sich in einem geringeren Abstand als 85 cm befinden, werden standardmäßig nicht dargestellt. Jedoch kann dieses Verhalten überschrieben werden. Durch den relativ kleinen und eingeschränkten Sichtbereich der HoloLens sind besonders große Objekte meistens nur schwer vollständig sichtbar.

Shared Experience mit der Hololens

Mit der Hololens sind Zusammenarbeiten möglich, dafür wird eine aktive Internetverbindung nicht zwingend benötigt. Die HMDs müssen sich lediglich im selben Netzwerk befinden. Hierfür werden die Geräte via WiFi verbunden. Um allen Anwendern das gleiche Erlebnis zu bieten, werden die Spatial Anchors geteilt. Somit können auf jedem HMD, die Hologramme an den identischen Positionen dargestellt werden. Es können zahlreiche verschiedene Szenarios mittels Shared Experience erstellt werden. Diese können jedoch in drei verschiedene Kategorien unterteilt werden:

Präsentation Alle Anwender sehen die gleichen Inhalte. Eine Person, welche die Präsentation leitet, kann zusätzliche Steuerelemente oder Informationen, wie Notizen haben.

Kollaboration Bei kollaborativen Arbeiten wird gemeinsam, mit den gleichen Inhalten interagiert. Jeder Anwender kann die Änderungen der anderen Teilnehmer sehen und selbst entsprechend bearbeiten.

Beratung Ein Anwender kann die Arbeiten eines weiteren Anwenders beobachten und entsprechende Anweisungen erteilen. Hierfür können zum Beispiel, wie in Skype für die Hololens, dem Berater verschiedene Werkzeuge zur Verfügung gestellt werden, um Interaktionen, wie das Markieren eines Objekts, zu ermöglichen.

Bei einer Shared Experience müssen nicht alle Anwender mit einer Hololens arbeiten. Es können, je nach Anwendung und Anwendungsgebiet, auch Arbeiten am normalen Arbeitsrechner oder an anderen Geräten durchgeführt werden und auf eine Hololens übertragen werden. Shared Experiences können sowohl Co-Located, als auch Remote oder eine Mischung aus Co-Located und Remote sein. Co-Located bezeichnet Shared Experiences in der gleichen physikalischen Umgebung, während bei Remote Sessions die Anwender sich von unterschiedlichen Orten aus vernetzen.

Je nach Anwendungsgebiet bestehen andere Herausforderungen, die bei der Konzeption neuer MR-Anwendungen bedacht werden müssen, so kann je nach Anzahl der Anwender, die Darstellung und die Interaktion der Objekte entscheidend sein. Stehen bei einer Remote Anwendung keine identischen, physikalischen Umgebungen zur Verfügung, muss besonders auf die Positionierung geachtet werden.

Farbtrennung

Das Display der Hololens besteht aus drei übereinanderliegenden Wellenleitern. Für jede Grundfarbe existiert jeweils ein Wellenleiter. Die Bildinformationen werden mit Mikrodisplays in den Brillenbügeln erzeugt und auf die Wellenleiter geführt. Durch diese Bauart des Displays, kann es zur Aufteilung der Farben kommen. Der Anwender sieht dabei die einzelnen Farbtöne, Rot, Grün und Blau separiert voneinander. Die Hologramme können dabei verzerrt wirken. Dieser Effekt kann besonders bei weißen oder hellen Objekten auftreten. Bei schnellen Kopfbewegungen des Anwenders oder sich schnell bewegenden Hologrammen, kann dieser Effekt ebenfalls verstärkt auftreten. Ist die empfohlene Framerate von 60 FPS nicht gegeben, kann dies auch eine Farbtrennung bei den Hologrammen verursachen.

Diesem Effekt kann entgegengewirkt werden, wenn das entsprechende Objekt, dem Blick des Anwenders mit einer Verzögerung folgt. Jedoch kann sich das negativ auf die eigentliche Funktion auswirken. In diesem konkreten Fall hätte der Anwender Schwierigkeiten, das Objekt präzise zu positionieren. Auch bei einer verzögerten Bewegung kann die Farbtrennung weiterhin auftreten.

Stabilisierung der Hologramme

In der Hololens ist eine hardwaregestützte Stabilisierungs-Ebene vorhanden. 3D-Modelle, welche sich auf dieser Ebene befinden, erhalten eine besonders effiziente Stabilisierung. Diese Stabilisierungs-Ebene wird automatisch mit dem Fokus des Anwenders gesetzt und aktualisiert. Diese Automatisierung führ jedoch nicht immer zum gewünschten Resultat. Um besonders relevante Objekte in diese Ebene einzubinden, kann dies in der Anwendung explizit bestimmt werden. Für die UseCaseManager Anwendung wird die Stabilisierungs-Ebene stets auf die virtuellen Objekte gelegt. Die Ebene wird nicht mit dem Fokus des Anwenders ausgerichtet. Damit wird vermieden, dass beispielsweise das weniger kritische Menü in dieser Ebene liegt, anstelle der wichtigen Modelle am realen Objekt.

Für eine möglichst optimale Stabilität der Hologramme ist eine konstante Framerate von 60 FPS erforderlich. Ist diese nicht gegeben, können sich Hologramme in ihren Positionen verschieben. Besonders bei großen Modellen ist eine leichte Bewegung oft wahr-nehmbar.

Einschränkungen

Mit einem Gesamtgewicht von 579 Gramm und einer maximalen Akkulaufzeit von zwei bis drei Stunden ist die Hololens, für einen längeren Betrieb, nicht einsetzbar. Durch das relativ hohe Gewicht ist der Tragekomfort negativ einzustufen.

Die Genauigkeit der Hologramme ist ebenfalls gegenwärtig noch eingeschränkt. Je nach Blickwinkel ergibt sich eine leichte Verschiebung der virtuellen Objekte. Die Ausprägung dieses Verhaltens unterscheidet sich auch von Gerät zu Gerät. Mittels Sensortuning und Augenabstands-Messung (IPD) kann diesem Verhalten entgegengewirkt werden, jedoch kann dies nicht vollständig neutralisiert werden.

Eingeschlagener Realisierungsweg

Auf Basis der Game-Engine Unity3d wurde ein Anwendungs-Prototyp erstellt. Hierbei wurde erprobt, welche Voraussetzungen für eine Mixed-Reality Anwendung erforderlich sind und welche Möglichkeiten bestehen. Dieser Prototyp wurde anschließend entsprechend zu einer einsetzbaren UseCaseManager-App weiterentwickelt.

Unity und Mixed Reality Toolkit

Die Anwendung wurde unter Zuhilfenahme des Mixed Reality Toolkits in Unity 5.6.4f1 entwickelt. Ab Unity 2017.1 stehen in der Engine diverse Tools und APIs für die Entwicklung von XR Anwendungen standardmäßig zur Verfügung. Beispielsweise sind Vuforia Schnittstellen in der Engine inkludiert. Diese Version stand dem Kubnden, zum Zeitpunkt dieser Arbeit, jedoch noch nicht zur Verfügung. Der Build-Prozess für „Universal Windows Platfrom“-Anwendungen (UWP) muss über Microsoft Visual Studio abgewickelt werden. Es muss eine Solution in Unity erstellt werden, welche anschließend in Visual Studio, für die Hololens bereitgestellt werden kann. Mit dem Mixed Reality Toolkit kann diese Prozesskette automatisiert, in einem Schritt ausgeführt werden. Für die hier erstellte Anwendung wurde Microsoft Visual Studio 2017 verwendet.

Unity ist eine Game-Engine für Echtzeitanwendungen. In einer Game-Engine sind zahlreiche Mechaniken und Design Patterns bereits umgesetzt, welche als Grundlage für eine interaktive Echtzeitanwendung gelten. Diese können, wie die Game-Loop mit der Update-Methode oder das Rendering, vom Entwickler genutzt werden und müssen nicht manuell implementiert werden. Neben Unity gibt es noch weitere Game-Engines welche, unter bestimmten Konditionen, verwendet werden dürfen. In der Unreal-Engine, der Cry-Engine oder auch der Lumberyard-Engine von Amazon wird jedoch die Entwicklung einer Hololens Anwendung nur begrenzt unterstützt.

Realisierung der Anwendung

Tracking und Positionierung

Eine große Herausforderung für Mixed Reality Anwendungen besteht darin, die virtuellen Objekte in der realen Umgebung zu platzieren. Um entsprechende Use Cases an einem realen Objekt durchführen zu können, müssen die virtuellen Inhalte möglichst präzise auf das entsprechende Objekt gelegt werden können.

Für das jeweilige reale Objekt wird ein virtuelles Pendant in die Anwendung integriert. Die Oberfläche des Objekts wird als transparentes Hologramm dargestellt. Damit kann der Anwender erkennen, wo die virtuellen Objekte positioniert sind. Werden die virtuellen Objekte auf ein physikalisches Objekt gelegt, kann die Position des virtuellen Modells mit dem physikalischen Objekt einfach verglichen werden. Zusätzlich besteht die Möglichkeit, einen Use Case ohne ein physikalisches Objekt auszuführen, da das virtuelle Modell als Ersatz für das reale Objekt dienen kann. Um das virtuelle Modell auf das physikalische Gegenstück zu legen gibt es zahlreiche Möglichkeiten. Das Erkennen eines Realobjekts und die daraus resultierende Positionierung der virtuellen Objekte weißt jedoch einige kritische Problemstellungen auf.

Marker-Tracking

Mit dem Marker-Tracking kann die Position anhand von 2D-Markern erkannt werden. Da die Anwendung möglichst flexibel gehalten werden soll, ist ein Marker-Tracking nur schwer realisierbar. Die Marker müssen für jedes Objekt vermessen werden und exakt am realen Objekt angebracht werden. Es müssen immer die gleichen Marker verwendet werden oder neue Marker müssen in die Anwendung eingepflegt werden. Diese Marker können oft nur schwer am realen Objekt angebracht werden, da nur sehr wenige Flächen dafür geeignet sind. Die Marker benötigen eine ebene Fläche, welche sich immer konstant an derselben Position befindet.

Model-Tracking

Mit dem Model-Tracking kann ein reales Objekt anhand seiner Form und Farben erkannt werden. Wird ein Modell in der realen Umgebung erkannt, kann das virtuelle Gegenstück automatisch auf die entsprechende Position Platziert werden. Die Problemstellungen des Marker-Trackings gelten ebenfalls für das Model-Tracking. Hinzu kommt, dass nicht für alle Use Cases immer ein passendes 3D Modell vorliegt. Dieses wird benötigt um die Anwendung auf den Modell-Scan zu trainieren. Sind am physikalischen Objekt diverse Teile ausgebaut oder noch nicht eingebaut, ergibt sich eine abweichende Oberfläche. Hier müsste für jede denkbare Kombination ein 3D-Modell als Vorlage für die Anwendung vorliegen. Das ist nicht realisierbar.

Das Vuforia Model-Tracking, genannt “Object Recognition”, erfordert zudem einen Upload des Modells in die Vuforia-Cloud. Hier wird anhand des 3D-Modells eine Datenbank online erstellt, mit welcher das eigentliche Tracking lokal durchgeführt werden kann. Der Upload von sensiblen Daten in eine Anbieter-Cloud ist nicht realisierbar.

Badge Tracking

Um eine möglichst hohe Flexibilität in der Anwendung zu gewährleisten, wurden drei verschiedene Möglichkeiten der Hologramm-Positionierung in die Anwendung integriert. Diese Positionierungsmethoden funktionieren alle auf Basis des Spatial-Mappings. Es wird jedoch kein Umgebungsmodell fest in die Anwendung integriert. Dadurch würde sich der Einsatzort der Hololens mit der UseCaseManager Anwendung auf einen definierten Ort beschränken. Die Umgebung wird dynamisch zur Laufzeit gescannt und kontinuierlich aktualisiert. Dieses Vorgehen erfordert entsprechende Rechenleistung, welche auf der Hololens nur begrenzt zur Verfügung steht.

In unserer Lösung muss der Anwender jeweils einen virtuellen Badge auf das reale Pendant am Objekt platzieren. Mit den daraus erhaltenen Positionswerten kann die Position der Hologramme interpoliert werden. In Abhängigkeit der Präzision mit welcher der Anwender die virtuellen Badges platziert, ist die Genauigkeit der Positionierung.

In der ersten Prototyp-Implementierung wurde diese Tracking-Variante mit nur einem Badge umgesetzt. Dies führte zu einem trivialen Positionierungsalgorithmus, jedoch war dieser sehr Fehleranfällig. Schon kleine Abweichungen, bei der Positionierung des Badges, wirkten sich direkt auf die gesamte Positionierung aus. Daraus resultierend wurde der Algorithmus um mindestens einen weiteren Badge erweitert. Durch die Platzierung von zwei Badges entstehen insgesamt vier dreidimensionale Vektoren. Zwei Vektoren für die Position in der Welt und zwei Vektoren für die dazugehörige Rotation. Aus diesen Werten kann die Position des Objekts robuster ermittelt werden. Kleine Abweichung bei der Positionierung der Badges, wirken sich nicht mehr so groß aus, als bei der Positionierung mit nur einem Badge.

In einer kleinen Versuchsreihe ergab sich eine hinreichend genaue Positionierung in über 83% der Fälle. Die größten negativen Auswirkungen haben dabei Abweichungen in der Y-Rotation. Kleine Abweichungen der Position auf der X-, Y- oder Z-Achse sind hingegen kaum wahrnehmbar, da die Hololens selbst nicht 100% präzise ist. Rotationen um die X- oder Z-Achse sind beim Badge-Tracking nicht möglich, da diese Abweichungen einen zu großen, negativen Einfluss auf die Genauigkeit der Positionierung haben. Die X- und Z-Rotationen werden normalerweise nicht benötigt und sind entsprechend im Algorithmus konstant auf 0,0 gesetzt.

Die Versuchsreihe wurde virtuell im Unity Editor durchgeführt, hier können die Positionswerte und die Verschiebungen genau ermittelt werden. Im realen Anwendungsfall kann die Genauigkeit nur nach Augenmaß bestimmt werden. Durch die Steuerung mit Maus und Tastatur im Editor, ist die Versuchsreihe nicht optimal repräsentativ. Die Platzierung der Badges ist am realen Objekt, mit der Nutzung der Hololens, einfacher durchführbar.

In dieser Versuchsreihe galt ein Versuch als nicht bestanden, wenn die Abweichung, auf mindestens einer Achse, größer als 1,0 war. Je nach Use Case können diese Abweichungen, am realen Objekt noch ausreichend genau sein. Es zeigte sich, dass für viele der möglichen Anwendungsfälle eine deutlich ungenauere Positionierung ausreichend ist. Wie präzise diese Positionierung funktioniert, liegt letztendlich jedoch an der Genauigkeit des Anwenders.

Gaze-Positionierung

Der Anwender hat die Möglichkeit das Hologramm frei in der Umgebung zu positionieren. Hierbei wird das zu platzierende Hologramm an die Blickrichtung angeheftet und mit einer Bestätigung des Anwenders, in der Welt verankert. Mit der Gaze-Positionierung ist eine einfache Platzierung möglich, auch ohne ein reales Objekt. Die Genauigkeit der Position steht in Abhängigkeit zum Anwender. Diese Variante eignet sich gut für eine schnelle, einfache und grobe Positionierung. Nach dieser Positionierung kann das Hologramm noch manuell feinjustiert werden.

Manuelle Positionierung

Zur Feinjustierung hat der Anwender die Möglichkeit das Hologramm via „Drag and Drop“ zu verschieben. Hierbei hat es sich als sinnvoll erwiesen, die Bewegungsachsen separat auszuwählen, um ein Objekt nur in eine gewünschte Richtung zu manipulieren. Eine Positions- und Rotationsmanipulation auf allen Achsen gleichzeitig, führt zu ungewünschten Änderungen an bereits passenden Positionswerten. Die Möglichkeiten der Interaktion mit der Hololens bieten hier keine ausreichenden Möglichkeiten mit entsprechendem Feedback, um eine komplexere Operation präzise durchzuführen.

Integration neuer Use Cases

Zur Erstellung neuer Use Cases und deren Integration in die UseCaseManager Anwendung wurden mehrere mögliche Lösungswege untersucht. Da es sich bei Hololens Anwendungen um „Universal Windows Platform“ (UWP) Anwendungen handelt, ist im Vergleich zu regulären Unity-Windows Anwendungen, eine abweichende Verzeichnisstruktur der gebauten Anwendung vorhanden. So ist auf der Hololens beispielsweise kein Verzeichnis „StreamingAssets“ verfügbar. Auf Dateien in diesem Verzeichnis kann normalerweise über den Explorer zugegriffen werden.

Wird in Unity eine Anwendung für „PC, Mac & Linux Standalone“ gebaut, so wird eine ausführbare Datei erstellt, mit einem dazugehörigen „Data“-Verzeichnis. In diesem Verzeichnis befinden sich sämtliche Dateien und Verzeichnisse der Anwendung. Bei einer UWP Anwendung werden verschiedene unzugängliche APPX-Dateien erstellt, welche neben der Anwendung verschiedene Abhängigkeiten enthalten. Diese APPX-Dateien können auf Windows Geräten, wie der HoloLens, ausgeführt werden.

Dynamisches Laden mit AssetBundles

AssetBundles bieten die Möglichkeit Assets nach Bedarf, dynamisch in eine fertig gebaute Anwendung zu laden. Dies kann dazu genutzt werden, um zusätzliche Inhalte bereitzustellen (DLCs), optimierte Inhalte passend zum System des Anwenders zu laden, oder um die initiale Speicherplatzbelegung zu verringern.

Ein AssetBundle kann sämtliche Assets, wie Skripte, 3D-Daten, Szenen, Texturen, Prefabs etc. beinhalten. Neue AssetBundles können in der Unity Engine erstellt werden. Um diese Inhalte in eine bestehende Anwendung auf der Hololens zu integrieren, müssen diese auf einem Server bereitgestellt werden.

Für die hier zu erstellende Anwendung, stellen AssetBundles aktuell keine optimale Lösung dar. Sowohl die benötigte Infrastruktur, als auch die Erstellung neuer AssetBundles sind zu aufwändig. Da die AssetBundles in Unity erstellt werden müssten und die Hololens gegenwärtig ohnehin am Arbeits-Rechner angeschlossen werden muss, um neue Inhalte zu laden, kann stattdessen die gesamte Anwendung neu deployed werden. Dies ist einfach durchzuführen und verkürzt den Aufwand.

Für zukünftige Anwendungen könnte diese Thematik jedoch einen validen Lösungsweg darstellen.

Abstrahierung mittels ScriptableObjects

Der UseCaseManager wurde abstrakt gestaltet, so dass keine Informationen eines konkreten Use Cases enthalten sind. Diese Informationen werden in ScriptableObjects gehalten, welche zur Laufzeit in die Anwendung geladen werden. Diese ScriptableObjects enthalten neben den textuellen Beschreibungen und der Art des Use Cases, nur Referenzen auf Prefabs. Die Prefabs, welche unter anderem die 3D-Daten enthalten, müssen in der Anwendung enthalten sein und können nicht erst zur Laufzeit geladen werden. Auch die ScriptableObject-Dateien existieren nur in der Unity Umgebung als solche. Ein manuelles Hinzufügen oder Entfernen im File-Explorer ist nicht möglich. Daraus resultierend muss die Anwendung neu gebaut werden, wenn neue Use Cases erstellt werden.

Der Vorteil des Ladens zur Laufzeit besteht nur darin, dass der Entwickler entscheiden kann, wann welche Daten in den Speicher geladen werden und nicht alle Daten während der gesamten Laufzeit im Speicher vorliegen müssen. Dieser Vorteil ist jedoch in diesem Fall eher gering einzustufen, da diese Objekte nur Strings, Integer und Referenzen enthalten, die auch nur in einer kleinen Anzahl vorkommen und benötig werden. Der Speicherbedarf ist minimal.

Das eigentliche Anwendungsgebiet von ScriptableObjects besteht darin, Datenduplikate zu vermeiden und die Speicherverwendung zu reduzieren. So können große Datensätze, welche in mehreren Instanzen Verwendung finden, zentral gehalten werden, ohne dabei eine komplette Kopie aller Daten pro Instanz anzufertigen.

In diesem Fall bestehen die Vorteile jedoch in der leichten Erstellung eines neuen ScriptableObjects und die damit verbundene Abstrahierung der Anwendung. So können je nach Use Case unterschiedliche Inhalte in eine Szene geladen werden. Dadurch müssen nicht alle verfügbaren Objekte im Arbeitsspeicher gehalten werden, sondern nur diese, welche für den aktuell geladenen Use Case erforderlich sind. Der Anwendung ist es somit möglich, zahlreiche verschiedene Use Cases zu verwalten. Die Limitierung der Anzahl der Use Cases, stellt der persistente, 64 Gigabytes große Flashspeicher der Hololens dar.

Durch die implementierte Editor Erweiterung können neue ScriptableObjects mittels User Interface in Unity erstellt werden. Im Unity-Inspector können anschließend textuelle Informationen in das ScriptableObject geschrieben werden und auf zuvor angelegte Prefabs, mit den entsprechenden importierten 3D-Modellen, referenziert werden. Optional können für die Prefabs zusätzliche Features erstellt werden, wie beispielsweise Animationen oder ein skriptgesteuertes Verhalten.

Anhand des im ScriptableObjects festgelegten Use Case Typs, kann der Use-CaseManager die Use Cases unterschiedlich darstellen. Hierzu gibt es für jeden Use Case Typ eine eigene Szene in Unity. Jede Szene verarbeitet die Informationen aus dem geladenen ScriptableObject unterschiedlich. So kann ein Use Case als Schrittanleitung oder auch als Multiselect-Anwendung, in welcher verschiedene Elemente ein- und ausgeblendet werden können, dargestellt werden.

Use Cases vom Typ LinearProcess

Der Use Case Typ LinearProcess stellt schrittweise Informationen dar. Dies kann für Reparaturanleitungen oder Trainingsanweisungen genutzt werden. Dies bietet die Einsatzmöglichkeit zahlreicher interessanter Anwendungsfälle. Mit dem UseCaseManager können beispielsweise beliebig viele Reparaturanleitungen erstellt und evaluiert werden.

Der Anwender bekommt in übersichtlichen Schritten, die benötigten Informationen bereitgestellt. Sowohl eine textuelle Anweisung, mit optionalen Zusatzinformationen, als auch eine grafische Darstellung stehen dem Anwender zur Verfügung. Bei einer Reparaturanleitung kann der Monteur direkt erkennen an welchen Stellen sich welche Komponenten befinden und beispielsweise welche Schrauben zu lösen sind.

Hierbei sind vor allem Arbeiten an dunklen Orten problematisch. Ist die Umgebung dunkel und relativ eng, können die Kameras der Hololens Schwierigkeiten bekommen die Umgebung zu erkennen. Daraus resultierend würde das gerenderte Bild nicht mehr stabil im Raum positioniert sein, oder sogar kurzzeitig komplett verschwinden. Sobald die Hololens ihre Umgebung wieder ausreichend erkennt, wird das Bild wieder korrekt dargestellt. Um Hologramme mit sehr geringem Abstand zum Betrachter darzustellen, muss die Clipping-Plane entsprechend überschrieben werden. Diese sorgt dafür, dass alle Objekte mit einem geringeren Abstand als 85 cm, normalerweise ausge-blendet werden.

Im hier entwickelten UseCaseManager können Objekte mit einem Abstand von 1 cm betrachtet werden. Die Darstellung der Objekte, bei diesem geringen Abstand, funktioniert problemlos, allerdings kann die Präzision der Positionierung beziehungsweise die Hologramm-Stabilität geringfügig nachlassen.

Use Cases vom Typ Multiselect

Als zweiten Use Case Typ wurde ein Multiselect-Tool erstellt. Hiermit können verschiedene Objekte am realen Objekt ein- und ausgeblendet werden. So kann der Anwender gezielt untersuchen, an welchen Stellen welche Objekte verbaut sind. Die Verortung von verschiedenen Bauteilen ergibt ein breites Spektrum an möglichen Use Cases.

Der User hat die Möglichkeit mittels Air-Tap einzelne Objekte zu selektieren. Auch Objekt-Gruppen können, bei der Erstellung des Use Cases, definiert werden. In diesen Gruppen können mehrere Objekte zusammengefasst werden, um diese einfach gemeinsam anzeigen zu können.

Die Anwendung ist so gestaltet, dass beliebig viele Objekte und Gruppen erstellt werden können. Dies ermöglicht eine hohe Flexibilität, bei der Erstellung und Evaluierung neuer Use Cases. Das User Interface skaliert automatisch mit der Anzahl der Objekte. Mit der gewonnenen Flexibilität kann jedoch nicht sichergestellt werden, dass die Anwendung mit jedem Use Case performant auf der Hololens ausführbar ist. Bei einem Use Case mit zahlreichen Objekten, kann die empfohlene Framerate von 60 FPS möglicherweise nicht konstant gehalten werden, besonders wenn alle Objekte zeitgleich angezeigt werden. Eine zuverlässige Limitierung, in der Anzahl der Objekte, ist wenig sinnvoll. Die Performance ist nicht nur von der Anzahl der zu rendernden Objekte abhängig, sondern auch von der Größe der Objekte, die Anzahl der Polygone, die Anzahl der Drawcalls beziehungsweise der Render-Batches. Es ist ein großer Unterschied, ob zahlreiche einfache und kleine Schrauben, oder aber ein großes komplexes Modell dargestellt werden sollen.

Zusätzliche Features, wie Animationen, Collider mit einem bestimmten Skript-Verhalten, wirken sich ebenfalls negativ auf die Performance aus. Hier muss der Ersteller des Use Cases testen, ob die Darstellung der Objekte noch performant möglich ist. Selbiges gilt auch für Use Cases vom Typ LinearProcess, allerdings ist die Auswirkung nicht so kritisch, da die Objekte nicht alle zeitgleich, sondern schrittweise, angezeigt werden.

Kriterien für performante 3D Daten

Ein 3D Modell, genannt Mesh besteht aus mehreren Polygonen. Besitzt ein Mesh sehr viele Polygone, so bezeichnet man dieses als High-Poly-Mesh. Diese Modelle können sehr realistisch und sehr detailliert aussehen. Ein Low-Poly-Mesh hingegen besitzt nur eine geringe Anzahl an Polygonen. Diese Modelle sehen meistens sehr grob und wenig detailliert aus. Je weniger Polygone ein Mesh besitzt, desto weniger Rechenleistung wird für die Darstellung in Echtzeit benötigt.

Neben der Anzahl der Polygone spielen die Drawcalls beziehungsweise Render-Batches in Unity, eine entscheidende Rolle. Drawcalls können reduziert werden, wenn die 3D-Modelle aus möglichst wenigen einzelnen Objekten bestehen und dabei möglichst wenige Materials verwenden. Objekte mit demselben Material können in einem Render-Batch zusammengefasst werden.

Performance Optimierung im Renderprozess

Neben der Optimierung der eigentlichen 3D-Modellen, können in Unity weitere Optimierungen für das Rendering vorgenommen werden. Diese funktionieren allerdings nur sehr begrenzt für Mixed Reality Anwendungen. So können mit dem Static-Render-Batching Objekte performanter berechnet und gerendert werden, welche ihre Transform-Werte nicht verändern. Dies Bedeutet jedoch, dass diese Objekte nicht bewegbar sind. Die Objekte müssen in MR Anwendungen beweglich bleiben, um diese positionieren zu können. Eine weitere Möglichkeit bietet das Occlusion Culling. Hierbei wird das Rendering für alle Objekte, welche aktuell nicht von der Kamera erfasst werden, deaktiviert. Die Komplette Game-Szene wird in mehrere Segmente unterteilt. Schließlich werden in jedem Frame nur die Segmente gerendert, welche für den Anwender sichtbar sind. Da in MR Anwendungen nur wenige virtuelle Inhalte vorhanden sind und es auf genau diese ankommt, gibt es nur wenige sinnvolle Möglichkeiten, nicht sichtbare Inhalte vom Renderprozess auszunehmen.

Darstellung der Hologramme

Um Hologramme deutlich sichtbar darzustellen, ist es vorteilhaft kontrastreiche Farben für die Objekte zu verwenden. Besonders wenn Differenzierungen erkannt werden müssen, wie zum Beispiel die Schrauben an einem Bauteil. Hologramme überlagern das physikalische Gegenstück jedoch so deutlich, dass es dem Anwender schwerfallen kann, das physikalische Objekt zu bearbeiten. An der Hololens kann die Helligkeit der virtuellen Elemente eingestellt werden. Eine passende Einstellung der Helligkeit kann hierbei nützlich sein. Um ein optimales Arbeiten zu ermöglichen, wurde die Möglichkeit geschaffen, die virtuellen Objekte aus- und einzublenden. Mittels GUI-Steuerung oder Sprachbefehl kann der Anwender sich die Objekte nach Bedarf anzeigen lassen.

User Interface

Das Interface ist [...] das zentrale Element, welches den Benutzer, die zu lösende Aufgabe und das dafür benötigte Werkzeug miteinander verbindet und muss daher auf die Anforderungen der Aufgabe, die Fähigkeiten, Erfahrungen und Präferenzen des Benutzers sowie die Funktionalität des Werkzeugs abgestimmt sein. (Thesmann 2016, S2)

Als zentrale Bedienelemente wurden einfache grafische Benutzerschnittstellen (GUI) gestaltet. Dieses GUI verfügt über mehrere Buttons, welche durch Fokussierung und Air-Tap bedient werden können. Als Orientierungshilfe wird dem Anwender ein weißer Punkt angezeigt, um zu erkennen auf welchem Objekt der Fokus liegt. Dies wird weiter verstärkt durch entsprechendes hervorheben der aktiven Buttons. Die meisten Buttons wurden, zur besseren Darstellung, ausschließlich mit grafischen Symbolen beschriftet. Zum besseren Verständnis wurden Tooltipps realisiert, welche nach 1,5 Sekunden, beim Fokussieren eines Buttons erscheinen. Neben dem optischen Feedback wurden auch akustische Signale integriert, um das fehlende haptische Feedback zu kompensieren.

Das GUI kann während eines aktiven Use Cases in zwei unterschiedliche Modi geschalten werden. Im Objekt-Modus bewegt sich das GUI in einem definierten Radius um das zu bearbeitende physikalische Objekt herum. Dabei wird es immer gegenüber der Anwenderposition platziert und zeigt immer in die Richtung des Betrachters. Damit ist sichergestellt, dass die Informationen immer lesbar sind. Im Pinn-Modus kann der Anwender das GUI an eine beliebige Stelle in der realen Welt platzieren. Dieses bleibt anschließend fest an dieser Position verankert und bewegt sich nicht. Je nach Präferenzen des Anwenders und nach Art des Einsatzortes, kann ein anderer Modus vorteilhafter sein.

Für die wichtigen Funktionen eines aktiven Use Cases wurden zusätzliche Sprachbefehle umgesetzt, um dem Anwender die Bedienung zu erleichtern. Exemplarisch dafür, können im LinearProcess mit den Befehlen „Next“ und „Previous“ die einzelnen Schritte navigiert werden. Der Anwender muss keinen Button am GUI fokussieren und keinen Air-Tap mit der Hand ausführen. So ist sichergestellt, dass eventuelle Arbeiten nicht unterbrochen werden müssen, um beispielsweise zum nächsten Schritt einer Anleitung zu gelangen. Die Spracherkennung basiert auf der, in Windows 10 integrierten, Speech-Engine.

Justierung der Hololens am Anwender

Da die Hololens nur über ein kleines Sichtfeld verfügt, ist es ausschlaggeben wie passend der Anwender das HMD aufgesetzt hat. Sitzt die Hololens nicht korrekt auf dem Kopf, so wird das wahrnehmbare Sichtfeld deutlich verkleinert. Um sicherzustellen, dass der Anwender das vollständige Sichtfeld wahrnehmen kann, wird zu Beginn der Anwendung ein virtueller Rahmen eingeblendet. Der Anwender kann somit überprüfen, ob alle Seiten dieses Rahmens sichtbar sind und dies entsprechend bestätigen. Ist der Rahmen nicht vollständig sichtbar, kann die Hololens nachjustiert werden.

Ergebnisse

Im Rahmen dieser Arbeit entstand eine Mixed Reality Anwendung zur Evaluierung neuer Use Cases. Entwickelt mit der Game Engine Unity, wurde eine für die Microsoft Hololens konzeptionierte Lösung, erstellt. Die zu Beginn gestellten Anforderungen konnten größtenteils sehr gut bei der Konzeptionierung berücksichtig werden. Mit der Durchführung einer ersten Use Case Evaluation, konnte die Anwendung ausführlich erprobt werden.

Erstellte UseCaseManager Anwendung

Mit dem UseCaseManager können beliebige Use Cases ausgeführt werden, dabei ist kein Use Case fest in der Anwendung implementiert. Es können gegenwärtig zwei verschiedene Typen von Use Cases dargestellt werden. Mit den Typen LinearProcess und Multiselect kann eine große Anzahl an denkbaren Szenarien erstellt werden. Mit dem entwickelten Badge-Tracking können die virtuellen Objekte einfach und intuitiv auf das physikalische Objekt gelegt werden. Um eine hohe Flexibilität zu erreichen, wurde die Möglichkeit geschaffen, individuelle Referenz-Modelle für einen Use Case zu integrieren. Damit ist gewährleistet, dass auch Use Cases für andere Objekte evaluiert werden können. Eine automatische Positionierung mit individuellen Referenz-Modellen ist jedoch nicht möglich, diese müssen manuell in der realen Welt platziert werden. Das Referenz-Modell dient hierzu als Orientierung. Mit Hilfe der drei unterschiedlichen Tracking-Tools, kann der Anwender die Hologramme je nach Situation im Raum platzieren.

Für eine verbesserte Usability kann das, zur Steuerung benötigte User Interface, in zwei unterschiedliche Modi geschalten werden. Der Anwender kann entscheiden, ob das UI sich relativ zu seiner Position um das Objekt herumbewegt, oder ob es fest an einer Stelle, vom Anwender platziert wird. Des Weiteren kann der Anwender wichtige Steuerelemente auch mittels Sprachsteuerung bedienen, damit kann die Anwendung auch bedient werden, wenn der Anwender keine freie Hand zur Verfügung hat. Um die Usability weiter zu verbessern wurden Funktionen wie die Gruppenselektion von mehreren Objekten, für den Use Case Typ Multiselect, eingeführt.

Erstellung neuer Use Cases

Mit einem Aufwand von weniger als einem Arbeitstag und ohne Programmierkenntnisse kann ein neuer Use Case für die UseCaseManager Anwendung erstellt werden. Hierfür müssen nur die aufbereiteten 3D-Modelle in die Unity-Engine importiert werden und eine neue ScriptableObject-Datei erstellt und textuell befüllt werden. Die 3D-Modelle müssen als Prefab abgespeichert werden, dabei muss das Transform im Ursprung liegen. Das gespeicherte Prefab kann anschließend im erstellten ScriptableObject referenziert werden. Nach dem Anlegen eines neuen Use Cases muss die Anwendung manuell auf die Hololens deployed werden. Dies ist unter der Verwendung des MixedReality-Toolkits mit nur einem entsprechenden Klick möglich. Gegeben durch die hohe Abstrahierung der Anwendung ist es dem Ersteller eines Use Cases möglich, weitere Funktionalitäten zu einem Use Case hinzuzufügen. Es ist prinzipiell möglich diverse Skriptverhalten zu erstellen und diese entsprechend an ein Objekt anzuwenden. Derartige Möglichkeiten setzen jedoch entsprechende Fähigkeiten des Erstellers eines Use Cases voraus. Da diese Möglichkeit keine Anforderung war, ist es eine zusätzliche Erweiterung der Möglichkeiten.

Ausblick

Weiterentwicklung der Hololens

Die Hololens wird kontinuierlich von Microsoft weiterentwickelt. Hier werden sich in Zukunft zahlreiche neue Möglichkeiten ergeben, sowohl seitens der Software, als auch der Hardware und der damit verbundenen Leistungsfähigkeit. Es ist bereits eine neue Version der Hololens geplant, diese soll mit einer verbesserten Hardware ausgeliefert werden. Neben den allgemeinen Verbesserungen ist auch ein spezieller KI-Prozessor geplant. Dieser soll neben einer verbesserten Version der Holographic Processing Unit, als Co-Prozessor arbeiten und Neuronale Berechnungen lokal verarbeiten können.

Individuelle Modell Erkennung

Der UseCaseManager könnte mit einem eigenen Algorithmus erweitert werden, welcher das physikalische Pendant zu dem erstellten 3D-Referenz-Modell erkennt. So könnte ein eigenes Modell-Tracking umgesetzt werden, welches komplett lokal berechnet wird. Mit einer weiterentwickelten Hololens könnte die nötige Rechenleistung möglicherweise verfügbar sein. Um die Problematik zu lösen, dass das CAD-Modell nicht immer exakt dem realen Objekt entspricht, könnte der Erkennungs-Algorithmus dahingehend gestaltet werden, dass Kanten des Meshes interpoliert werden oder ignoriert werden, um mögliche Übereinstimmungspunkte zu finden.

Streaming und externe Berechnungen

Eine potentielle Möglichkeit besteht darin, sämtliche Berechnungen nicht auf der limitierten Hardware der Hololens durchzuführen, sondern auf einem separaten Rechner oder einer firmeninternen Cloud-Lösung. Die Sensordaten der Hololens müssten in Echtzeit auf den Server übertragen werden und das gerenderte Bild müsste auf die Hololens gestreamt werden. Gegenwärtig werden an verschiedenen Institutionen, wie dem Fraunhofer IGD, verschiedene Lösungen entwickelt, um komplexe CAD Daten und ein damit verbundenes Tracking performant berechnen zu können. Jedoch schränkt eine solche Lösung, die Einsatzorte der Hololens ein. Diese könnte beispielsweise nicht mit zu einem Lieferanten genommen werden, sondern währe an das Firmen-Netzwerk und somit an fest definierte Einsatzorte gebunden.

Weiterentwicklung des UseCaseManagers

Auf Grundlage der zukünftigen Ergebnisse der Use Case Evaluationen, kann die Use-CaseManager Anwendung erweitert werden. Sowohl die Usability kann möglicherweise weiter verbessert werden, als auch neue Use Case Typen können implementiert werden. Anforderungen der einzelnen Fachbereiche können in die Anforderungen der Anwendung mit aufgenommen werden.

Das Badge Tracking könnte dahingehend erweitert werden, dass dies auch für die individuellen Referenzmodelle anwendbar ist. Für Arbeiten mit mehreren Anwendern können Shared Experiences in die Anwendung integriert werden. Für Use Cases vom Typ LinearProcess könnten sich Präsentationen eignen. Ein Anwender könnte somit mehrere Teilnehmer, zum Beispiel für eine Reparatur, schulen. Für Multiselect Use Cases könnte zusätzlich noch die Kollaboration interessant sein, um gemeinsam die gleichen Objekte zu bearbeiten.

Tool zur Erstellung neuer Use Cases

Um die Erstellung neuer Use Cases weiter zu vereinfachen, könnte ein weiteres Tool entwickelt werden. Dieses Tool würde auf Unity-Editor-Erweiterungen basieren.

Akustische Anweisungen

Als Verbesserung der Usability könnten die textuellen Anweisungen der LinearProcess Use Cases vertont werden. Dem Anwender könnten somit die Arbeitsschritte vorgelesen werden. Allerdings ist es wenig praktikabel für jeden zu erstellenden Use Case neue Sprecheraufnahmen anzufertigen. Dies wäre mit entsprechenden Aufwand und zusätzlichen Kosten verbunden. Alternativ zu eingesprochenen Anweisungen, könnten elektronische Voice-Befehle ausgegeben werden. Hierfür gibt es verschiedene Cloud-Lösungen, wie Text-to-Speech-Services mit Watson IBM oder mit Amazon Web Services (AWS). Dies würde jedoch wieder die aktive Nutzung einer Anbieter-Cloud bedeuten. Die Cloud Nutzung würde entsprechende Kosten verursachen und kann kritisch in Bezug auf empfindliche Informationen sein. Im Rahmen von UWP Anwendungen könnte auch die Windows Speech API genutzt werden. Elektronische Stimmen sind oftmals jedoch schwerer verständlich, als professionell eingesprochene Phrasen, besonders bei Fremdwörtern oder Fachbegriffen.