Porting von HoloLens-Apps (1. Generation) zu HoloLens 2

Artikel
07/12/2023

Dieses Handbuch soll Entwickler bei der Portierung einer vorhandenen Unity-Anwendung für HoloLens (1. Generation) in eine Anwendung für HoloLens 2-Geräte zu unterstützen. Beim Portieren einer Unity-Anwendung für HoloLens (1. Generation) in eine Anwendung für HoloLens 2 gibt es vier wichtige Schritte.

Die folgenden Abschnitte enthalten Detailinformationen zu den einzelnen Phasen:

1. Schritt	Step 2	Step 3	Step 4

Herunterladen der aktuellen Tools	Aktualisieren des Unity-Projekts	Kompilieren für ARM	Migrieren zu MRTK Version 2

Voraussetzungen

Vor dem Beginn des Portierungsvorgangs wird dringend empfohlen, dass Sie mithilfe der Quellcodeverwaltung eine Momentaufnahme des ursprünglichen Zustands Ihrer Anwendungen speichern. Außerdem empfiehlt es sich, während des Prozesses zu verschiedenen Zeitpunkten den Zustand von Prüfunkten zu speichern. Es kann nützlich sein, eine weitere Instanz der ursprünglichen Anwendung in Unity geöffnet zu haben, damit Sie während des Portierungsprozesses parallel vergleichen können.

Hinweis

Stellen Sie vor dem Portieren sicher, dass die aktuellen Tools für die Windows Mixed Reality-Entwicklung installiert sind. Bei den meisten bestehenden HoloLens-Entwicklern bedeutet dies ein Update auf die neueste Version von Visual Studio 2019 und die Installation des entsprechenden Windows-SDKs. Im weiteren Verlauf werden die verschiedenen Unity-Versionen und das Mixed Reality-Toolkit (MRTK) Version 2 näher erläutert.

Weitere Informationen finden Sie unter Installieren der Tools.

Migrieren des Projekts zur aktuellen Unity-Version

Wenn Sie MRTK v2verwenden, wird empfohlen, vor dem Upgrade Ihres Projekts auf Unity 2020.3 LTS auf MRTK 2.7 zu aktualisieren. MRTK 2.7 unterstützt Unity 2018, 2019 und 2020, sodass Sie sicherstellen können, dass Ihr Projekt bereits vor dem Upgrade von Unity für Unity 2020 bereit ist. Beurteilen Sie alle Plug-In-Abhängigkeiten, die derzeit in Ihrem Projekt vorhanden sind, und bestimmen Sie, ob diese DLLs für ARM64 erstellt werden können. Bei Projekten mit einem von ARM-Hardware abhängigen Plug-In müssen Sie möglicherweise damit fortfahren, Ihre App für ARM zu erstellen.

Aktualisieren von Szenen-/Projekteinstellungen in Unity

Nach dem Update auf Unity 2020.3 LTS ist es für optimale Ergebnisse empfehlenswert, auf dem Gerät bestimmte Einstellungen in Unity zu aktualisieren. Diese Einstellungen werden ausführlich unter Empfohlene Einstellungen für Unity beschrieben.

Zur Erinnerung: Das .NET-Back-End für die Skripterstellung ist seit Unity 2018 veraltet und wurde in Unity 2019 entfernt. Sie sollten unbedingt erwägen, Ihre Projekte auf IL2CPP umzustellen.

Hinweis

Das IL2CPP-Skript-Back-End kann längere Buildzeiten von Unity in Visual Studio verursachen. Entwickler sollten ihren Entwicklercomputer für die Optimierung von IL2CPP-Buildzeiten einrichten. Möglicherweise können Sie besonders bei Unity-Projekten mit sehr vielen Ressourcen (mit Ausnahme von Skriptdateien) oder ständig wechselnden Szenen und Ressourcen von der Einrichtung eines Cacheservers profitieren. Beim Öffnen eines Projekts speichert Unity die qualifizierenden Ressourcen in einem internen Cacheformat auf dem Entwicklercomputer. Bei Änderungen müssen Elemente neu importiert und neu verarbeitet werden. Dieser Prozess kann einmal durchgeführt, in einem Cacheserver gespeichert und anschließend für andere Entwickler freigegeben werden, damit diese Zeit sparen und den erneuten Import der Änderungen nicht mehr einzeln und lokal verarbeiten müssen.

Nachdem alle Breaking Changes behoben wurden, die sich aus der Umstellung auf die aktualisierte Unity-Version ergeben, erstellen Sie Ihre aktuellen Anwendungen auf HoloLens (1. Generation), und testen Sie sie. Dies ist ein guter Zeitpunkt, ein Commit in die Quellcodeverwaltung zu erstellen und zu speichern.

Kompilieren von Abhängigkeiten/Plug-Ins für ARM-Prozessor

HoloLens (1. Generation) führt Anwendungen auf einem x86-Prozessor aus, während HoloLens 2 einen ARM-Prozessor verwendet. Vorhandene HoloLens-Anwendungen müssen für die Unterstützung von ARM portiert werden. Wie bereits erwähnt, unterstützt Unity 2018 LTS die Kompilierung von ARM32-Apps, während Unity 2019 und höher die Kompilierung von ARM32- und ARM64-Apps unterstützt. Die Entwicklung für ARM64-Anwendungen wird bevorzugt, da es einen wesentlichen Unterschied im Hinblick auf die Leistung gibt. Dies setzt jedoch voraus, dass auch alle Plug-In-Abhängigkeiten für ARM64 erstellt werden müssen.

Überprüfen Sie alle in Ihrer Anwendung vorhandenen DLL-Abhängigkeiten. Es empfiehlt sich, Abhängigkeiten zu entfernen, die für Ihr Projekt nicht mehr benötigt werden. Nehmen Sie für die verbleibenden Plug-Ins, die erforderlich sind, die entsprechenden ARM32- oder ARM64-Binärdateien in Ihr Unity-Projekt auf.

Erstellen Sie nach der Aufnahme der relevanten DLLs aus Unity eine Visual Studio-Projektmappe, und kompilieren Sie dann in Visual Studio eine AppX für ARM, um zu überprüfen, ob Ihre Anwendung für ARM-Prozessoren erstellt werden kann. Wir empfehlen, die Anwendung als Commit in der Quellcodeverwaltungslösung zu speichern.

Wichtig

Anwendungen, die MRTK v1 verwenden, können auf HoloLens 2 ausgeführt werden, nachdem das Buildziel in ARM geändert wurde, wobei vorausgesetzt wird, dass alle anderen Anforderungen erfüllt sind. Dies umfasst die Sicherstellung, dass Sie über ARM-Versionen aller Ihrer Plug-Ins verfügen. Ihre App erhält jedoch keinen Zugriff auf HoloLens 2-spezifische Funktionen wie artikuliertes Hand- und Eye-Tracking. MRTK v1 und MRTK v2 verfügen über unterschiedliche Namespaces, die ermöglichen, dass beide Versionen im selben Projekt vorkommen, was für den Übergang von einer Version zur anderen nützlich ist.

Update auf MRTK Version 2

MRTK Version 2 ist das neue Toolkit über Unity, das sowohl HoloLens (1. Generation) als auch HoloLens 2 unterstützt. Hier wurden auch alle neuen Funktionen der HoloLens 2 hinzugefügt, z. B. Handinteraktionen und Eyetracking.

Weitere Informationen zur Verwendung von MRTK Version 2 finden Sie in den folgenden Ressourcen:

Vorbereiten der Migration

Vor der Übernahme der neuen *.unitypackage-Dateien für MRTK v2 ist es empfehlenswert, ein Inventar von (1) jeglichem benutzerdefinierten Code, der in MRTK v1 integriert ist, und (2) jeglichem benutzerdefinierten Code für Eingabeinteraktionen oder Komponenten der Benutzerumgebung zu erstellen. Ein häufiger und weit verbreiteter Konflikt, der bei der Aufnahme des MRTK v2 auftritt, bezieht sich auf Eingabe und Interaktionen. Es wird empfohlen, das Eingabemodell von MRTK v2 zu überprüfen.

Schließlich wurde beim neuen MRTK v2 die Umstellung von einem Modell mit Skripts und Managerobjekten in den Szenen zu einer Architektur mit Konfiguration und Dienstanbietern vollzogen. Daraus ergibt sich ein übersichtlicheres Szenenhierarchie- und Architekturmodell, das jedoch einen gewissen Lernaufwand erfordert, um die neuen Konfigurationsprofile zu verstehen. Lesen Sie das Konfigurationshandbuch zum Mixed Reality-Toolkit, um sich mit den wichtigen Einstellungen und Profilen vertraut zu machen, die Sie an die Anforderungen Ihrer Anwendung anpassen müssen.

Migrieren des Projekts

Nach dem Import von MRTK v2 weist Ihr Unity-Projekt höchstwahrscheinlich viele compilerbezogene Fehler auf. Diese sind aufgrund der neuen Namespacestruktur und neuer Komponentennamen häufig anzutreffen. Fahren Sie mit der Behebung dieser Fehler fort, indem Sie Ihre Skripts ändern und an die neuen Namespaces und Komponenten anpassen.

Informationen zu speziellen API-Unterschieden zwischen HTK/MRTK und MRTK v2, finden Sie im Portierungshandbuch im MRTK Version 2-Wiki.

Bewährte Methoden

Geben Sie dem standardmäßigen MRTK-Shader den Vorzug.
Arbeiten Sie jeweils nur an einem Breaking Change-Typ (Beispiel: IFocusable zu IMixedRealityFocusHandler).
Führen Sie nach jeder Änderung einen Test aus, und nutzen Sie die Quellcodeverwaltung.
Verwenden Sie nach Möglichkeit die MRTK-Standardbenutzerumgebung (Schaltflächen, Tafeln usw.).
Ändern Sie MRTK Dateien nicht direkt, sondern erstellen Sie Wrapper um MRTK-Komponenten.
- Diese Aktion erleichtert die zukünftige Erfassung und Updates des MRTK.
Prüfen und untersuchen Sie die Beispielszenen, die im MRTK bereitgestellt werden, insbesondere HandInteractionExamples.scene.
Erstellen Sie eine canvasbasierte Benutzeroberfläche neu mit Quads, Collidern und TextMeshPro-Text.
Aktivieren Sie gemeinsame Nutzung des Tiefenpuffers und/oder Festlegen des Fokuspunkts. Verwenden Sie einen 16-Bit-Tiefenpuffer, um die Leistung zu verbessern. Stellen Sie sicher, dass Sie beim Rendern von Farben auch die Tiefe rendern. Unity schreibt im Allgemeinen keine Tiefe für transparente und Text-gameobjects.
Wählen Sie Single-Pass-Instanzrendering aus.
Verwenden Sie das HoloLens 2-Konfigurationsprofil für MRTK

Testen Ihrer Anwendung

In MRTK Version 2 können Sie Handinteraktionen direkt in Unity simulieren und Entwicklungen mit den neuen APIs für Handinteraktionen und Eyetracking vornehmen. Das HoloLens 2-Gerät ist erforderlich, um eine zufriedenstellende Benutzererfahrung zu erzeugen. Wir empfehlen, die Dokumentation zu lesen und sich mit den Tools zu befassen, um ein besseres Verständnis zu erhalten. MRTK v2 unterstützt die Entwicklung auf HoloLens (1. Generation), und es können herkömmliche Eingabemodelle wie die „Auswahl durch Tippen in die Luft“ auf HoloLens (1. Generation) getestet werden.

Aktualisieren des Interaktionsmodells für HoloLens 2

Achtung

Wenn Ihr Projekt eine der XR.WSA-APIs verwendet, beachten Sie, dass diese in zukünftigen Unity-Releases zugunsten der neuen XR-Eingabe-APIs von Unity eingestellt werden. Weitere Informationen zu den XR-Eingabe-APIs finden Sie hier.

Nachdem Sie Ihre Anwendung portiert und für HoloLens 2 vorbereitet haben, können Sie die Aktualisierung Ihres Interaktionsmodells und der Hologrammentwurfsplatzierungen in Betracht ziehen. In HoloLens (1. Generation) verfügt Ihre Anwendung wahrscheinlich über das Interaktionsmodell „Anvisieren und Ausführen“, bei dem die Hologramme relativ weit entfernt sind, damit sie in das Sichtfeld passen.

Schritte zum Aktualisieren Ihres Anwendungsentwurfs, damit dieser für HoloLens 2 optimal geeignet ist:

MRTK-Komponenten: Nach der Vorarbeit, wenn Sie MRTK v2 hinzugefügt haben, gibt es verschiedene Komponenten/Skripts, die für HoloLens 2 entworfen und optimiert wurden.
Interaktionsmodell: Erwägen Sie die Aktualisierung Ihres Interaktionsmodells. In den meisten Fällen empfehlen wir, vom Anvisieren und Ausführen zur Handinteraktion zu wechseln. Einige Ihrer Hologramme befinden sich möglicherweise außerhalb der Reichweite Ihrer Arme, und der Wechsel zur Handinteraktion führt zu einer fernen Interaktion mit zielendem Lichtstrahl und Greifgesten.
Platzierung von Hologrammen: Erwägen Sie nach dem Wechsel zum Handinteraktionsmodell, einige Hologramme in den Nahbereich zu verschieben, damit Benutzer mithilfe von Greifgesten der nahen Interaktion direkt mit den Händen mit ihnen interagieren können. Dies sind Typen von Hologrammen, die für direktes Greifen oder direkte Interaktion in die Nähe verschoben werden sollten:

Kleine Zielmenüs
controls
Schaltflächen
Kleinere Hologramme, die beim Greifen und Untersuchen in das HoloLens 2 Sichtfeld passen.

Anwendungen und Szenarien sind verschieden, und wir werden auch in Zukunft anhand von Feedback oder durch fortgesetztes Lernen Entwurfsrichtlinien optimieren und veröffentlichen.

Weitere Tipps zum Verlagern von Anwendungen von x86 zu ARM

Reine Unity-Anwendungen sind einfach, da Sie ein ARM-Anwendungspaket direkt auf dem Gerät erstellen oder bereitstellen können, auf dem das Paket laufen soll. Einige native Unity-Plug-Ins können bestimmte Herausforderungen bezüglich der Entwicklung darstellen. Aus diesem Grund müssen Sie ein Upgrade aller nativen Unity-Plug-Ins auf Visual Studio 2019 vornehmen und dann für ARM neu erstellen.
Für eine Anwendung wurde das Unity AudioKinetic Wwise-Plug-In verwendet. Die verwendete Unity-Version verfügte nicht über ein UWP-ARM-Plug-In, und es mussten erhebliche Anstrengungen investiert werden, um die Soundfunktionen für die Ausführung auf ARM wieder in die fragliche Anwendung einzubinden. Stellen Sie sicher, dass alle erforderlichen Plug-Ins für Ihre Entwicklungspläne in Unity installiert und verfügbar sind.
In manchen Fällen ist ein UWP/ARM-Plug-In für die Plug-Ins vorhanden, die für die Anwendung erforderlich sind, wodurch die Möglichkeit zum Portieren und Ausführen der Anwendung auf HoloLens 2 versperrt ist. Wenden Sie sich an Ihren Plug-In-Anbieter, um das Problem zu beheben und Support für ARM zu erhalten.
Variablen des Typs „minfloat“ (und Varianten wie „min16float“, „minint“ usw.) in Shadern verhalten sich auf HoloLens 2 möglicherweise anders als auf HoloLens (1. Generation). Diese sorgen insbesondere dafür, dass „mindestens die angegebene Bitanzahl verwendet wird“. Auf Intel/Nvidia-GPUs werden minfloats größtenteils als 32-Bit behandelt. Auf ARM wird tatsächlich die angegebene Bitanzahl eingehalten. In der Praxis weisen diese Zahlen auf HoloLens 2 möglicherweise eine geringere Genauigkeit oder einen kleineren Bereich als auf HoloLens (1. Generation).
Die „_asm“-Anweisungen funktionieren anscheinend auf ARM nicht, was bedeutet, dass jeder Code mit „_asm“-Anweisungen neu geschrieben werden muss.
ARM unterstützt den SIMD-Instruktionssatz nicht, weil verschiedene Header wie „xmmintrin.h“, „emmintrin.h“," tmmintrin.h“ und „immintrin.h“ für ARM nicht verfügbar sind.
Der Shader-Compiler auf ARM wird beim ersten Draw-Aufruf nach dem Laden des Shaders oder nach der Änderung einer Komponente, auf die sich der Shader stützt, ausgeführt, und nicht zur Ladezeit des Shaders. Der Einfluss auf die Framerate kann – abhängig von der Anzahl der zu kompilierenden Shader – spürbar sein. Dies hat Auswirkungen darauf, wie Shader auf HoloLens 2 im Vergleich zu HoloLens (1. Gen) behandelt, verpackt und aktualisiert werden sollten.

Freigeben über