Portage des applications HoloLens (1ère gén.) sur HoloLens 2

Article
07/12/2023

Ce guide sur mesure a été conçu pour aider les développeurs qui disposent d’une application Unity pour HoloLens (1ère génération) à effectuer le portage de leur application vers l’appareil HoloLens 2. Le portage d’une application Unity pour HoloLens (1re génération) vers HoloLens 2 comprend quatre étapes clés.

Les sections ci-dessous expliquent en détail chacune de ces étapes :

Étape 1	Étape 2	Étape 3	Étape 4

Télécharger les derniers outils	Mettre à jour un projet Unity	Compiler pour ARM	Effectuer une migration vers MRTK v2

Prérequis

Avant de démarrer le processus de portage, nous vous recommandons vivement d’utiliser le contrôle de code source pour enregistrer un instantané de l’état d’origine de votre application. Nous vous recommandons également d’enregistrer les états des points de contrôle à différents moments pendant le processus. Il peut s’avérer utile d’avoir une autre instance de l’application d’origine ouverte dans Unity afin de pouvoir comparer côte à côte pendant le processus de portage.

Remarque

Avant d’effectuer le portage, vérifiez que vous avez installé les derniers outils de développement Windows Mixed Reality. Pour la plupart des développeurs HoloLens, il s’agit d’effectuer une mise à jour vers la dernière version de Visual Studio 2019 et d’installer le SDK Windows correspondant. Le contenu ci-dessous offre une présentation détaillée des différentes versions de Unity et de Mixed Reality Toolkit (MRTK), version 2.

Pour plus d’informations, consultez Installer les outils.

Migrer votre projet vers la dernière version de Unity

Si vous utilisez MRTK v2, nous vous recommandons d’effectuer la mise à jour vers MRTK 2.7 avant de mettre votre projet à niveau vers Unity 2020.3 LTS. MRTK 2.7 prend en charge Unity 2018, 2019 et 2020, ce qui vous permet de vous assurer que votre projet est prêt pour Unity 2020 et ce, même avant la mise à niveau d’Unity. Évaluez les dépendances de plug-ins qui existent actuellement dans votre projet et déterminez si ces DLL peuvent être générées pour ARM64. Pour les projets avec un plug-in dépendant d’ARM avec codage en dur, vous devrez peut-être continuer à créer votre application pour ARM.

Mettre à jour les paramètres de scène et de projet dans Unity

Après la mise à jour vers Unity 2020.3 LTS, nous vous recommandons de mettre à jour certains paramètres dans Unity pour des résultats optimaux sur l’appareil. Ces paramètres sont décrits en détail sous Paramètres recommandés pour Unity.

En résumé, le back-end d’écriture de script .NET est déconseillé dans Unity 2018 et supprimé dans Unity 2019. Vous devez envisager de basculer votre projet vers IL2CPP.

Remarque

Le back-end de script IL2CPP peut entraîner des temps de génération plus longs de Unity vers Visual Studio. Les développeurs doivent configurer leur machine de développement pour optimiser les temps de génération pour IL2CPP. Il peut également être avantageux de configurer un serveur de cache, en particulier pour les projets Unity qui ont une grande quantité de ressources (à l’exclusion des fichiers de script), ou des scènes et des ressources qui changent constamment. Lorsque vous ouvrez un projet, Unity stocke les ressources éligibles dans un format de cache interne sur l’ordinateur de développement. Les éléments doivent être réimportés et retraités après modification. Ce processus peut être effectué une fois, enregistré dans un serveur de cache, puis partagé avec d’autres développeurs, au lieu que chaque développeur réimporte localement les éléments modifiés.

Une fois avoir pris en compte les changements importants entraînés par la mise à jour de la version de Unity, générez et testez vos applications actuelles sur HoloLens (1ère génération). C’est le bon moment pour créer et enregistrer une validation dans le contrôle de code source.

Compiler des dépendances ou des plug-ins pour processeurs ARM

HoloLens (1ère génération) exécute les applications sur un processeur x86 alors qu’HoloLens 2 utilise un processeur ARM. Les applications HoloLens existantes doivent être portées pour prendre en charge ARM. Comme indiqué plus haut, Unity 2018 LTS prend en charge la compilation d’applications ARM32, alors qu’Unity 2019 et les versions ultérieures prennent en charge la compilation d’applications ARM32 et ARM64. Il est recommandé de développer des applications pour ARM64, car ce matériel offre de meilleures performances. Toutefois, cela nécessite que toutes les dépendances de plug-ins soient également conçues pour ARM64.

Passez en revue toutes les dépendances DLL qui se trouvent dans votre application. Nous vous recommandons de supprimer les dépendances qui ne sont plus nécessaires pour votre projet. Pour les autres plug-ins nécessaires, ingérez les fichiers binaires ARM32 ou ARM64 dans votre projet Unity.

Après l’ingestion des DLL nécessaires, créez une solution Visual Studio dans Unity, puis compilez un AppX pour ARM dans Visual Studio, afin de vérifier si votre application peut être générée pour des processeurs ARM. Nous vous recommandons d’enregistrer l’application sous forme de commit dans votre solution de contrôle de code source.

Important

Vous pouvez exécuter l’application utilisant MRTK v1 sur HoloLens 2 après avoir remplacé la cible de build par ARM, en supposant que toutes les autres conditions soient remplies. Vous devez donc veiller à disposer des versions ARM de tous vos plug-ins. Cependant, votre application n’aura pas accès aux fonctions spécifiques à HoloLens 2 comme la main articulée et le suivi oculaire. MRTK v1 et MRTK v2 ont des espaces de noms différents qui permettent aux deux versions d’être dans le même projet, ce qui est utile pour passer de l’une à l’autre.

Effectuer une mise à jour vers MRTK version 2

MRTK version 2 est le nouveau kit d’outils en supplément de Unity qui prend en charge à la fois HoloLens (1re génération) et HoloLens 2. Il s’agit également du kit dans lequel toutes les nouvelles fonctionnalités HoloLens 2 ont été ajoutées, notamment les interactions avec les mains et le suivi oculaire.

Pour plus d’informations sur l’utilisation de MRTK version 2, consultez les ressources suivantes :

Se préparer à la migration

Avant d’ingérer les nouveaux fichiers *.unitypackage pour MRTK v2, il est recommandé d’effectuer un inventaire de (1) tout code personnalisé intégré à MRTK v1 et de (2) tout code personnalisé pour les interactions d’entrée ou les composants d’expérience utilisateur. Lors de l’ingestion de MRTK v2, le conflit le plus fréquemment rencontré par les développeurs de réalité mixte concerne les entrées et les interactions. Nous vous recommandons de passer en revue le modèle d’entrée MRTK v2.

Enfin, MRTK v2 est passé d’un modèle de scripts et d’objets gestionnaires en scène à une architecture de configuration et de fournisseur de services. La hiérarchie de scène et le modèle d’architecture sont désormais plus propres. Toutefois, ce changement nécessite que vous compreniez les nouveaux profils de configuration. Lisez le Guide de configuration de Mixed Reality Toolkit pour vous familiariser avec les profils et les paramètres importants que vous devez adapter aux besoins de votre application.

Migration du projet

Après l’importation de MRTK v2, votre projet Unity comprend probablement plusieurs erreurs liées au compilateur. Ces erreurs sont généralement dues à la nouvelle structure des espaces de noms et aux nouveaux noms de composants. Pour corriger ces erreurs, modifiez vos scripts avec les nouveaux espaces de noms et les nouveaux composants.

Pour plus d’informations sur les différences entre HTK/MRTK et MRTK v2 au niveau des API, consultez le guide de portage sur le wiki MRTK Version 2.

Bonnes pratiques

Donner la priorité au nuanceur MRTK standard.
Travailler sur un type de changement cassant à la fois (par exemple : IFocusable qui devient IMixedRealityFocusHandler).
Effectuer des tests après chaque modification et utiliser le contrôle de code source.
Utiliser l’expérience utilisateur MRTK par défaut (boutons, fenêtres, etc.) dans la mesure du possible.
Éviter de modifier directement les fichiers MRTK. Pour cela, ajouter des wrappers autour des composants MRTK.
- Cette action facilite les futures mises à jour et ingestion de MRTK.
Explorer les exemples de scènes fournis dans MRTK (surtout HandInteractionExamples.scene).
Recréer une interface utilisateur basée sur les canevas avec des quadrants, des colliders et du texte TextMeshPro.
Activer Depth Buffer Sharing ou Set focus point ; utiliser une mémoire tampon de profondeur 16 bits pour obtenir de meilleures performances. Vérifier que quand vous rendez des couleurs, vous rendez aussi une profondeur. Unity n’écrit généralement pas de profondeur pour les gameobjects transparents et de texte.
Sélectionner Single Pass Instanced Rendering.
Utilisez le profil de configuration HoloLens 2 pour MRTK.

Test de votre application

Dans MRTK Version 2, vous pouvez simuler des interactions avec les mains directement dans Unity et développer avec les nouvelles API pour les interactions avec les mains et le suivi oculaire. L’appareil HoloLens 2 est nécessaire pour créer une expérience utilisateur satisfaisante. Nous vous recommandons d’étudier la documentation et les outils pour en avoir une meilleure compréhension. MRTK v2 prend en charge le développement sur HoloLens (1ère génération). Les modèles d’entrée traditionnels, comme la sélection via un clic dans l’air, peuvent être testés sur HoloLens (1ère génération).

Mise à jour de votre modèle d’interaction pour HoloLens 2

Attention

Si votre projet utilise des API XR.WSA, notez que celles-ci seront progressivement supprimées au profit des nouvelles API d’entrée XR d’Unity dans les futures versions d’Unity. Vous trouverez plus d’informations sur les API d’entrée XR ici.

Une fois que votre application est portée et préparée pour HoloLens 2, vous êtes prêt pour la mise à jour de votre modèle d’interaction et des positionnements de vos conceptions d’hologrammes. Dans HoloLens (1re génération), votre application comprend probablement un modèle d’interaction de type « Suivi et validation » avec des hologrammes relativement lointains qui rentrent entièrement dans le champ de vision.

Pour mettre à jour votre application afin de l’adapter à HoloLens 2 :

Composants MRTK : En fonction du travail préalable, si vous avez ajouté MRTK v2, vous pourrez tirer parti de plusieurs composants ou scripts conçus et optimisés pour HoloLens 2.
Modèle d’interaction : Envisagez de mettre à jour votre modèle d’interaction. Pour la plupart des scénarios, nous vous recommandons de passer du modèle « Suivi et validation » au modèle d’interaction manuelle. Certains de vos hologrammes peuvent se trouver hors de portée des bras, et le passage à l’interaction manuelle permet des rayons de pointage et des mouvements de saisie de plus loin.
Placement des hologrammes : une fois que vous êtes passé au modèle d’interaction manuelle, vous pouvez rapprocher les hologrammes pour que les utilisateurs puissent interagir directement avec eux en utilisant des mouvements de saisie avec leurs mains. Les types d’hologrammes à rapprocher pour la saisie ou l’interaction directe sont :

petits menus cibles
controls
boutons
hologrammes plus petits qui, quand ils sont saisis et inspectés, tiennent dans le champ de vision d’HoloLens 2.

Les applications et les scénarios varient : nous continuerons donc de fournir des instructions de conception adaptées à chaque situation, en nous basant sur votre feedback et vos expériences.

Conseils supplémentaires sur le passage d’applications de x86 à ARM

Les applications Unity sont simples, car vous pouvez créer un bundle d’applications ARM ou déployer directement sur l’appareil pour exécuter le bundle. Le développement de certains plug-ins natifs Unity peut constituer un défi. Pour cette raison, vous devez mettre à niveau tous les plug-ins Unity natifs vers Visual Studio 2019, puis recréer pour ARM.
Une application utilisait le plug-in Unity AudioKinetic Wwise. La version d’Unity en cours d’utilisation n’avait pas de plug-in UWP ARM et un travail considérable a été nécessaire pour retravailler les fonctionnalités audio dans l’application en question afin qu’elle s’exécute sur ARM. Vérifiez que tous les plug-ins nécessaires pour vos plans de développement sont installés et disponibles dans Unity.
Dans certains cas, il est possible qu’un plug-in UWP/ARM n’existe pas pour les plug-ins requis par l’application, ce qui bloque la capacité à porter l’application et à l’exécuter sur HoloLens 2. Contactez votre fournisseur de plug-ins pour résoudre le problème et obtenir une prise en charge d’ARM.
Dans les nuanceurs, minfloat et ses variantes (telles que min16float, minint, etc.) peuvent ne pas avoir le même comportement dans HoloLens 2 que dans HoloLens (1re génération). Ceux-ci ont pour but de garantir que le nombre de bits spécifié sera utilisé (au minimum). Avec les processeurs graphiques Intel/Nvidia, ils sont le plus souvent traités comme des 32 bits. Sur ARM, le nombre de bits spécifié est respecté. Dans la pratique, ces nombres peuvent avoir une précision ou une portée moindre dans HoloLens 2 que dans HoloLens (1ère génération).
Les instructions _asm ne semblent pas fonctionner sur ARM, ce qui signifie que tout code utilisant les instructions _asm doit être réécrit.
ARM ne prend pas en charge le jeu d’instructions SIMD, car plusieurs en-têtes, comme xmmintrin.h, emmintrin.h, tmmintrin.h et immintrin.h, ne sont pas disponibles sur ARM.
Sur ARM, le compilateur du nuanceur est exécuté lors du premier appel de dessin, après le chargement du nuanceur ou après la modification d’un élément dont dépend le nuanceur, mais pas au moment du chargement du nuanceur. L’impact sur le taux de trames peut être visible, en fonction du nombre de nuanceurs qui doivent être compilés. Cela peut avoir des implications sur la façon dont les nuanceurs doivent être gérés, packagés et mis à jour sur HoloLens 2 par rapport à HoloLens (1ère génération).