Portage d’applications HoloLens (1ère génération) vers HoloLens 2

Article
02/18/2025

Ce guide est conçu pour aider les développeurs disposant d’une application Unity existante pour HoloLens (1ère génération) à porter leur application vers l’appareil HoloLens 2. Il existe quatre étapes clés pour porter une application Unity HoloLens (1ère génération) vers HoloLens 2.

Les sections ci-dessous détaillent les informations relatives à chaque étape :

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

Télécharger les outils les plus récents	Mettre à jour le projet Unity	Compiler pour ARM	Migrer vers MRTK v2

Configuration requise

Nous vous recommandons vivement d’utiliser le contrôle de code source pour enregistrer un instantané l’état d’origine de votre application avant de commencer le processus de portage. Nous vous recommandons également d’enregistrer les états de point de contrôle à différents moments pendant le processus. Vous trouverez peut-être utile d’ouvrir un autre instance de l’application d’origine dans Unity afin de pouvoir comparer côte à côte pendant le processus de portage.

Remarque

Avant le portage, vérifiez que les outils les plus récents sont installés pour Windows Mixed Reality développement. Pour la plupart des développeurs HoloLens existants, cela implique la mise à jour vers la dernière version de Visual Studio 2019 et l’installation de la SDK Windows appropriée. Le contenu qui suit explore les différentes versions d’Unity et le Mixed Reality Toolkit (MRTK) version 2.

Pour plus d’informations, consultez Installer les outils.

Migrer votre projet vers la dernière version d’Unity

Si vous utilisez MRTK v2, nous vous recommandons d’effectuer une mise à jour vers MRTK 2.7 avant de mettre à niveau votre projet 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 avant même de mettre à niveau Unity. Évaluez les dépendances de plug-in 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 dur, vous devrez peut-être continuer à générer votre application pour ARM.

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

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

Pour rappel, le back-end de script .NET est déprécié dans Unity 2018 et supprimé à partir d’Unity 2019. Vous devez fortement 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 entre Unity et Visual Studio. Les développeurs doivent configurer leur machine de développement pour optimiser les temps de génération IL2CPP. Vous pouvez également bénéficier de la configuration d’un serveur de cache, en particulier pour les projets Unity avec une grande quantité de ressources (à l’exception des fichiers de script) ou de changer constamment de scènes et de ressources. Lors de l’ouverture d’un projet, Unity stocke les ressources éligibles dans un format de cache interne sur l’ordinateur du développeur. Les éléments doivent être réimporté et traités à nouveau en cas de modification. Ce processus peut être effectué une seule fois, enregistré dans un serveur de cache, puis partagé avec d’autres développeurs pour gagner du temps, par opposition à chaque développeur traitant la réimportation des nouvelles modifications localement.

Après avoir abordé les changements cassants résultant du passage à la version d’Unity mise à jour, générez et testez vos applications actuelles sur HoloLens (1ère génération). Il s’agit d’un bon moment pour créer et enregistrer une validation dans le contrôle de code source.

Compiler les dépendances/plug-ins pour le processeur ARM

HoloLens (1ère génération) exécute des applications sur un processeur x86 ; le HoloLens 2 utilise un processeur ARM. Les applications HoloLens existantes doivent être transférées pour prendre en charge ARM. Comme indiqué précédemment, Unity 2018 LTS prend en charge la compilation des applications ARM32, tandis qu’Unity 2019 et versions ultérieures prend en charge la compilation des applications ARM32 et ARM64. Le développement pour les applications ARM64 est préférable, car il existe une différence importante dans les performances. Toutefois, toutes les dépendances de plug-in doivent également être générées pour ARM64.

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

Après avoir ingéré les DLL appropriées, générez une solution Visual Studio à partir d’Unity et compilez un AppX pour ARM dans Visual Studio pour vérifier que votre application peut être générée pour les processeurs ARM. Nous vous recommandons d’enregistrer l’application en tant que commit dans votre solution de contrôle de code source.

Importante

Les applications utilisant MRTK v1 peuvent être exécutées sur HoloLens 2 après avoir changé la cible de build en ARM, en supposant que toutes les autres exigences sont remplies. Cela inclut la mise en place de versions ARM de tous vos plug-ins. Toutefois, votre application n’a pas accès à des fonctions spécifiques à HoloLens 2, telles que le suivi articulé des mains et des yeux. 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.

Mise à jour vers MRTK version 2

MRTK Version 2 est la nouvelle boîte à outils sur Unity qui prend en charge HoloLens (1ère génération) et HoloLens 2. C’est également là que toutes les nouvelles fonctionnalités de HoloLens 2 ont été ajoutées, telles que les interactions entre les mains et le suivi oculaire.

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

Préparer la migration

Avant d’ingérer les nouveaux fichiers *.unitypackage pour MRTK v2, nous vous recommandons de faire l’inventaire de (1) tout code personnalisé qui s’intègre à MRTK v1 et (2) de tout code personnalisé pour les interactions d’entrée ou les composants d’expérience utilisateur. Le conflit le plus courant et le plus répandu pour un développeur de réalité mixte qui ingère MRTK v2 implique des entrées et des interactions. Nous vous recommandons de consulter le modèle d’entrée MRTK v2.

Enfin, le nouveau MRTK v2 est passé d’un modèle de scripts et d’objets de gestionnaire sur scène à une architecture de fournisseur de services et de configuration. Il en résulte une hiérarchie de scène et un modèle d’architecture plus propres, mais nécessite une courbe d’apprentissage pour comprendre les nouveaux profils de configuration. Lisez le Guide de configuration de Mixed Reality Toolkit pour commencer à vous familiariser avec les paramètres et profils importants que vous devez ajuster aux besoins de votre application.

Migration du projet

Après l’importation de MRTK v2, votre projet Unity présente probablement de nombreuses erreurs liées au compilateur. Celles-ci sont courantes en raison de la nouvelle structure d’espace de noms et des nouveaux noms de composants. Continuez à résoudre ces erreurs en modifiant vos scripts pour les nouveaux espaces de noms et composants.

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

Meilleures pratiques

Donnez la valeur de priorité au nuanceur standard MRTK.
Travaillez sur un type de modification cassant à la fois (exemple : IFocusable vers IMixedRealityFocusHandler).
Testez après chaque modification et utilisez le contrôle de code source.
Utilisez l’expérience utilisateur MRTK par défaut (boutons, ardoises, etc.) dans la mesure du possible.
S’abstenir de modifier directement les fichiers MRTK ; créer des wrappers autour des composants MRTK.
- Cette action facilite l’ingestion et les mises à jour futures de MRTK.
Passez en revue et explorez les exemples de scènes fournis dans mrTK, en particulier HandInteractionExamples.scene.
Régénérez l’interface utilisateur basée sur un canevas avec des quads, des collisionneurs et du texte TextMeshPro.
Activer le partage de mémoire tampon de profondeur ou définir le point de focus ; Pour de meilleures performances, utilisez une mémoire tampon de profondeur de 16 bits. Assurez-vous que lorsque vous affichez la couleur, vous restituez également la profondeur. Unity n’écrit généralement pas de profondeur pour les objets de jeu transparents et textuels.
Sélectionnez Single Pass Instanced Rendering.
Utiliser le profil de configuration HoloLens 2 pour MRTK

Test de votre application

Dans MRTK version 2, vous pouvez simuler des interactions manuelles directement dans Unity et développer avec les nouvelles API pour les interactions manuelles 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 une meilleure compréhension. MRTK v2 prend en charge le développement sur HoloLens (1ère génération) et les modèles d’entrée traditionnels tels que « select via air-tap » 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 l’un des XR. Les API WSA, notez qu’elles sont progressivement supprimées en faveur 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 transférée et préparée pour HoloLens 2, vous êtes prêt à envisager de mettre à jour votre modèle d’interaction et vos placements de conception d’hologrammes. Dans HoloLens (1ère génération), votre application a probablement un modèle d’interaction de regard et de validation avec des hologrammes relativement éloignés pour s’adapter au champ de vision.

Pour mettre à jour la conception de votre application afin qu’elle soit la mieux adaptée à HoloLens 2 :

Composants MRTK : selon le travail préalable, si vous avez ajouté MRTK v2, il existe différents composants/scripts à exploiter qui ont été 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 regard et de la validation aux mains. Certains de vos hologrammes peuvent être hors de portée du bras, et le fait de passer aux mains entraîne des rayons pointant de loin et des mouvements de saisie.
Positionnement des hologrammes : après avoir basculé vers un modèle d’interaction des mains, envisagez de rapprocher certains hologrammes afin que les utilisateurs puissent interagir directement avec eux en utilisant des mouvements de saisie en interaction proche avec leurs mains. Les types d’hologrammes pour se rapprocher directement de la capture ou de l’interaction avec sont les suivants :

petits menus cibles
Contrôles
boutons
hologrammes plus petits qui, lorsqu’ils sont saisis et inspectés, s’insèrent dans le champ de vue HoloLens 2.

Les applications et les scénarios varient ; Nous continuerons d’affiner et de publier des conseils de conception basés sur les commentaires et les apprentissages continus.

Conseils supplémentaires sur le déplacement d’applications de x86 vers ARM

Les applications Unity simples sont simples, car vous pouvez créer une offre groupée d’applications ARM ou la déployer directement sur l’appareil pour que l’offre groupée s’exécute. Certains plug-ins natifs Unity peuvent présenter certains défis de développement. Pour cette raison, vous devez mettre à niveau tous les plug-ins natifs Unity vers Visual Studio 2019, puis reconstruire pour ARM.
Une application utilisait le plug-in Unity AudioKinetic Wwise. La version Unity en cours d’utilisation n’avait pas de plug-in ARM UWP, et il y a eu un effort considérable pour retravailler les fonctionnalités sonores dans l’application en question pour qu’elles s’exécutent sur ARM. Vérifiez que tous les plug-ins requis pour vos plans de développement sont installés et disponibles dans Unity.
Dans certains cas, un plug-in UWP/ARM peut ne pas exister pour les plug-ins requis par l’application, ce qui bloque la possibilité de porter l’application et de l’exécuter sur HoloLens 2. Contactez votre fournisseur de plug-in pour résoudre le problème et fournir une prise en charge pour ARM.
Le minfloat (et les variantes telles que min16float, minint, etc.) dans les nuanceurs peuvent se comporter différemment sur HoloLens 2 que sur HoloLens (1ère génération). Plus précisément, ces informations garantissent qu’au moins le nombre de bits spécifié sera utilisé. Sur les GPU Intel/Nvidia, les minfloats sont en grande partie traités comme 32 bits. Sur ARM, le nombre de bits spécifiés est effectivement respecté. Dans la pratique, ces nombres peuvent avoir moins de précision ou de portée sur HoloLens 2 que sur HoloLens (1ère génération).
Les instructions _asm ne semblent pas fonctionner sur ARM, ce qui signifie que tout code utilisant _asm instructions doit être réécrit.
ARM ne prend pas en charge le jeu d’instructions SIMD, car différents en-têtes, tels que xmmintrin.h, emmintrin.h, tmmintrin.h et immintrin.h, ne sont pas disponibles sur ARM.
Le compilateur de nuanceurs sur ARM s’exécute pendant le premier appel de dessin après que le nuanceur a été chargé ou que quelque chose sur lequel repose le nuanceur a changé, et non au moment du chargement du nuanceur. L’impact sur la fréquence d’images peut être perceptible, en fonction du nombre de nuanceurs à compiler, avec des implications sur la façon dont les nuanceurs doivent être gérés, empaquetés et mis à jour différemment sur HoloLens 2 et HoloLens (1ère génération).

Partager via