Von Ihno Lübbers, und Jonas Mattes

Estimated reading time: 0 Minuten

Techblog

Interaktionsmöglichkeiten in SoftwareCity

Für den IT-Innovation Summit haben wir AR- und VR-Technologie zu einer virtuellen Stadtführung in SoftwareCity kombiniert: Ein Softwareentwickler bewegt sich mit einer HTC Vive in einer virtuellen Software-Stadt. Die anderen Teilnehmer folgen ihm mit der Microsoft HoloLens. Um die verschiedenen User auseinanderzuhalten, nennen wir den virtuellen Stadtführer „Vive-Guy“, die mit einer HoloLens ausgestatteten Touristen heißen „AR-Guys“. Generelle…

Techblog

Für den IT-Innovation Summit haben wir AR- und VR-Technologie zu einer virtuellen Stadtführung in SoftwareCity kombiniert: Ein Softwareentwickler bewegt sich mit einer HTC Vive in einer virtuellen Software-Stadt. Die anderen Teilnehmer folgen ihm mit der Microsoft HoloLens. Um die verschiedenen User auseinanderzuhalten, nennen wir den virtuellen Stadtführer „Vive-Guy“, die mit einer HoloLens ausgestatteten Touristen heißen „AR-Guys“.

Generelle Herausforderungen bei diesem Projekt beschreibt Arnold Schlegel im zweiten Teil der Blogserie.

In diesem Blog geht es um die Funktionen für VR und AR, die für den Use Case programmiert wurden. Die Interaktionsmöglichkeiten mit der Vive hat Ihno umgesetzt, der AR-Teil kommt von Jonas.

VR-Interaktionen

Die Kombination aus AR und VR erlaubt eine ganz neue Form der Kommunikation über Objekte, die in die virtuelle beziehungsweise angereicherte Realität projiziert werden. Christian Langenmaier und Stefan Kassal beschreiben das als das „nächste Level des Screen-Sharing. Damit alle Besucher über das gleiche Gebäude in SoftwareCity sprechen, haben wir eine Markierungsfunktion eingebaut:

VR-Guy kann mit dem rechten Controller einen Laserpointer aktivieren und ein anvisiertes Gebäude mit einem Klick auswählen. Über HoloLens und Vive werden dem VR-Guy selbst und den AR-Guys Metriken zum Gebäude eingeblendet, etwa die Klassengröße.

Ebenfalls mit dem rechten Controller kann VR-Guy die Stadt vergrößern und verkleinern. In der Vive wirkt das wie Zoomen. Außerdem haben wir eine Teleportier-Funktion eingebaut: Wenn VR-Guy den linken Controller betätigt, wird eine Kurve eingeblendet; VR-Guy kann sich zum Schnittpunkt von Kurve und Boden teleportieren.

Mit einer UI haben wir das Konfigurieren des Mappings umgesetzt. Mit einer Liste können viele verschiedene Parameter, beispielsweise Lines-of-Code pro Klasse oder Anzahl bzw. Komplexität der Funktion ausgewählt werden. Um das Mapping zur Laufzeit zu verändern, werden drei Parameter ausgewählt und auf die Breite, Höhe und Farbe der Gebäude in der Softwarestadt gemappt.

Wenn VR-Guy die Grip-Buttons auf einem der Controller drückt, werden virtuelle Tooltips zu den Controllern ein oder ausgeblendet.

Austausch der „Spieler“-Position von Vive zu HoloLens

Im Unterschied zu einer typischen Unity-„Multiplayer“ Anwendung, wird nicht die absolute beziehungsweise globale Position des Spielers mit der HTC-Vive übertragen. Stattdessen benötigt der Spieler mit der HoloLens die relative Position der HTC-Vive im Bezug zur Softwarestadt.

Die relative Positionsübertragung ist nötig, da beide Spieler die Softwarestadt zumindest frei skalieren (Vive) und gegebenenfalls zusätzlich noch rotieren und positionieren (HoloLens) können. Die Änderung, die ein Spieler (A) an der Stadt durchführt, sollen dem anderen Spieler (B) nicht angezeigt werden. Stattdessen soll es aus Sicht von B so aussehen, als würde A seine Position in der Stadt verändern. Wenn also beispielsweise A die Stadt verkleinert (skaliert), sieht es für B so aus, als würde A sich von der Stadt entfernen. Dieses Prinzip gilt ebenfalls für Translation und Rotation der Stadt.

Wie wir die relative Positionsübertragung implementiert haben, zeigt das folgende Codebeispiel:

Mit der von Unity bereitgestellten Funktion InverseTransformPoint(Vector 3), wird vor der Übertragung die (globale) Position in eine zur Softwarestadt relativen Position umgerechnet.

Das nächste Codebeispiel zeigt, wie auf der Empfängerseite, also der HoloLens, die Position des sendenden Spielers wiederum relativ zur eigenen Positionierung der Softwarestadt ein zweites Mal umgerechnet wird:

Im Beispiel ist zu sehen, wie Skalierung, Rotation und Translation des Vive-Guys auf HoloLens-Seite mit den Positionswerten der Softwarestadt initialisiert werden. Dies ist nötig, da ein AR-Guy mit einer HoloLens die Softwarestadt beim Start der Anwendung individuell platziert. Er passt sie beispielsweise genau auf einen realen Tisch an oder platziert sie auf dem Boden im Raum.

Die Herausforderung beim Austausch der Spielerpositionen über das Netzwerk besteht somit darin, dass die Positionen, bevor sie korrekt dargestellt werden, zwei Mal in Relation zur lokalen Softwarestadt der Spieler / Teilnehmer umgerechnet werden müssen: Zunächst auf Senderseite, um die Positionierung der Stadt aus Sicht der HTC-Vive zu berücksichtigen und dann noch einmal auf Empfängerseite, um dasselbe für die HoloLens sicherzustellen.

AR-Interaktion

Da der AR-Nutzer in erster Linie Beobachter ist, sind seine Interaktionsmöglichkeiten eingeschränkt. Es ist ihm nur möglich, die Metriken der einzelnen Gebäude durch anklicken (Gaze-Input) einzusehen und diese wieder auszublenden.

Während des anfänglichen Initialisierungsprozesses sind weitere Interaktionen freigeschaltet, welche sich durch ein sich mitbewegendes Menü per Air Tap oder Clicker auswählen lassen:

  • Das Platzieren der Stadt auf einer beliebigen Oberfläche. Hierzu werden die gescannten Rauminformationen der HoloLens benutzt, um die Stadt einfach auf einem Tisch oder dem Boden zu platzieren. Durch einen Tap/Click wird die Stadt auf der aktuell angesehenen Oberfläche per WorldAnchor dauerhaft fixiert – auch nach einem Neustart der Brille.
So sieht das Platzieren der SoftwareStadt in AR aus – hier aus der Live-Preview.
  • Das Skalieren der Stadt ist durch ein vertikales „Click and Drag“ mit der Hand umsetzbar.
  • Das Rotieren ist durch ein horizontales  „Click and Drag“ erreichbar

Nach dem Initialisieren wird die UI ausgeblendet, damit der Nutzer sich ungestört der Stadt widmen kann.

Soll die Städteansicht nach dem Initialisierungsprozess unerwarteterweise erneut geändert werden müssen, haben wir einen Ball über dem Kopf des Nutzers platziert. An dieser Position fällt er bei normaler Nutzung nicht auf, da der Benutzer tendenziell nach unten schaut und nie senkrecht nach oben. Klickt man auf den Ball, wird die UI wieder sichtbar und die Stadt kann erneut bearbeitet werden.

Pläne fürs Weiterentwickeln

Egal ob AR und VR – jede Technologie fasziniert. Viele unserer Kollegen haben unser Setup mit HoloLens und Vive mit leuchtenden Augen ausprobiert. Nach dem Erfolg beim IT-Innovation Summit wollen wir unseren AR-VR-Use-Case weiter entwickeln. Dafür erweitern wir das Projekt so, dass wir neue Features leichter integrieren können. Anschließend wollen wir die Usability umstellen: Eine unserer Kolleginnen hat in ihrer Masterarbeit die Interaktion in der Virtual Reality untersucht – ihre Erkenntnisse wollen wir umsetzen.

Wie Christian und Stefan in ihrem Blog schreiben, ist das Setup mit VR- und AR-Brille im Moment noch ein teurer Spaß. Trotzdem sind wir gespannt, was die erste kommerzielle AR-VR-Anwendung wird.


Von Ihno Lübbers, und Jonas Mattes

Full-Stack Software Engineer

Ihno arbeitet seit 2017 bei MaibornWolff. Seitdem war er in technologisch sehr verschiedenen Projekten aktiv. Beispiele für die Technologien sind Android, Unity, Unreal, Cloud-Microservices und die Prototypen-Entwicklung. Als Full-Stack Developer liebt es Ihno leidenschaftlich den Blick über den technischen Tellerrand zu werfen und sich in neue Gebiete vorzuwagen. Sein Focus liegt dabei aber immer auf sauberem und gut getestetem Code. Privat ist Ihno oft auf einem rollendem oder rutschendem Board anzutreffen.