Interface utilisateur volumétrique avec Canvas – MRTK3

Notes

Il s’agit d’une vue d’ensemble conceptuelle montrant comment l’interface utilisateur basée sur un canevas hybride est générée. Pour obtenir de la documentation sur les différents éléments préfabriqués d’expérience utilisateur, consultez la documentation sur les composants de l’expérience utilisateur.

MRTK3 introduit une interface utilisateur volumétrique intégrée avec système RectTransform + Canevas de Unity. Bien que ce système ait été utilisé principalement pour les IU plates en 2D, il est capable d’assurer le rendu et la mise en place d’une IU volumétrique en 3D. Cela peut accélérer la conception itérative et améliorer la fidélité des conceptions qui peuvent être créées avec l’IU volumétrique.

Notes

La bibliothèque de composants basés sur un canevas est en cours de développement actif et changera rapidement avec des fonctionnalités, une apparence, une disposition et une architecture nouvelles.

Il était très difficile de concevoir pour les systèmes d’IU de MRTK 2.x qui ne sont pas basés sur un canevas, car il leur manque bon nombre de fonctionnalités de base nécessaires dans un système de conception d’interface.

• ✘ Absence d’unités de conception non physiques
• ✘ Aucun alignement
• ✘ Ni marge, ni remplissage
• ✘ Aucune disposition flexible ou réactive
• ✘ Éléments préfabriqués distincts pour chaque permutation de disposition, de taille et de configuration
• ✘ Prise en charge très limitée de la disposition de collection (dispositions horizontales/verticales composables)
• ✘ Absence de fonctionnalités de conception de base, telles que des rayons d’angles arrondis ou des largeurs de trait dimensionnés de façon absolue
• ✘ Nécessité d’utiliser une mise à l’échelle pour ajuster la taille des éléments d’IU, en altérant de manière destructive les enfants
• ✘ Prise en charge limitée de la souris et du clavier
• ✘ Aucune prise en charge de manette

En raison de ces limitations, l’interface utilisateur volumétrique était plus primitive dans sa conception, et nécessitait une quantité considérable de travail manuel des concepteurs techniques pour créer de belles dispositions.

MRTK3 introduit une approche unifiée. Des contrôles d’IU volumétriques élégants qui prennent en charge toutes les interactions XR (comme l’appui pour le suivi de main articulée et le regard + pincement) peuvent être créés dans un contexte Canvas-RectTransform. Les contrôles peuvent être disposés automatiquement avec une marge adaptée, un remplissage, une flexibilité réactive et toutes les fonctionnalités attendues par les concepteurs. En outre, nous pouvons router des événements UGUI vers le bas dans XRI, afin que les mêmes éléments préfabriqués d’interface utilisateur fonctionnent aussi bien dans des contextes 2D que 3D, y compris des entrées accessibles comme une manette.

Voici les avantages :

• ✔ Unités de conception flexibles qui correspondent à divers contextes physiques (réalité 3D, écrans 2D, TV/Bureau/Mobile/Web)
• ✔ Prise en charge complète de l’alignement rectTransform pour une disposition réactive avec des relations parent/enfant cohérentes
• ✔ Prise en charge complète de la marge et du remplissage RectTransform, via des groupes AutoLayout UnityUI
• ✔ Prise en charge des dispositions flexibles avec priorité et marges, via des groupes AutoLayout UnityUI
• ✔ Un seul élément préfabriqué pour chaque type de contrôle, qui peut être redimensionné et ajusté pour s’adapter à tout contenu ou contexte
• ✔ Dispositions horizontales, verticales et de grille à partir de groupes AutoLayout UnityUI. Des dispositions personnalisées sont disponibles via l’extension des interfaces de Unity.
• ✔ Grande variété de fonctionnalités de conception avancées telles que des rayons d’angles arrondis, des largeurs de trait et des marges dimensionnés de façon absolue, activées par les fonctionnalités avancées de nuanceur d’interface utilisateur dans le package Mixed Reality Graphics Tools.
• ✔ Aucune mise à l’échelle : les dimensionnements et dispositions sont obtenus via des métriques de taille et de décalage RectTransform. Les parents ne modifient pas l’échelle les enfants.
• ✔ Prise en charge complète de la souris et du clavier, en mode natif, par le biais d’événements UGUI, de l’UGUIInputAdapter et du CanvasProxyInteractor (pour plus d’informations, consultez la documentation sur l’architecture interactionnable)
• ✔ Prise en charge de la manette et de la navigation directionnelle/relative

Cette puissance et cette flexibilité peuvent avoir un coût, et l’interface utilisateur basée sur un canevas doit être gérée avec soin pour éviter des écueils courants en matière de performances.

• Chaque « composant mobile » de votre interface utilisateur devrait être un nœud de canevas distinct. Il existe des coûts O(tree_height) associés à la mutation de hiérarchies de canevas. Par conséquent, l’utilisation de plusieurs canevas pour plusieurs éléments mobiles/composants réutilisables est fortement recommandée.
• Évitez d’utiliser un canevas global unique pour toute votre scène.
• Le déplacement et la rotation de canevas et de RectTransforms peuvent avoir des implications sur les performances. Nous vous recommandons vivement d’imbriquer votre canevas sous une transformation « étui » non rectTransform qui sera déplacée au lieu de déplacer directement le canevas.
• Notre processus de masquage et de découpage d’interfaces utilisateurs basées sur collider est toujours en cours de développement. Songez à éviter des affichages défilants avec du contenu pouvant être cliqué.
• Le système de navigation directionnelle Unity par défaut peut, dans certains contextes 3D, se comporter de façon étrange. Nous étudions des systèmes de navigation personnalisée qui se comporteront de manière plus robuste dans des dispositions 3D inhabituelles.

Nous publierons des conseils plus spécifiques pour optimiser vos dispositions basées sur un canevas, car nous effectuons des tests de performances plus détaillés sur une série d’appareils.

Programme d’installation

Nos composants sont créés avec une unité de conception 1 : ratio 1mm, pour les contextes physiques. Par conséquent, lors de la configuration d’un canevas à utiliser avec une interface utilisateur volumétrique, destinée à s’afficher dans des applications 3D immersives :

• Assurez-vous que votre canevas est un espace universel
• Vérifiez que l’échelle du canevas est globalement 0de ,001 sur tous les axes

Pour les applications s’affichant sur un affichage 2D, l’échelle peut être ajustée librement pour correspondre à vos métriques d’utilisabilité spécifiées et aux tailles cibles tactiles minimales.

Lorsque vous utilisez des éléments interactionnables avec l’UGUIInputAdapter (comme notre expérience utilisateur basée sur un canevas), assurez-vous d’avoir un CanvasProxyInteractor sur un GameObject (de préférence vide) dans votre scène. Cela aura pour effet de transférer les événements UGUI via XRI, garantissant ainsi que vos éléments interactionnables fonctionnent correctement.

Si vous souhaitez expérimenter l’entrée UGUI sur des composants autres que d’expérience utilisateur, ajoutez UGUIInputAdapter à votre élément interactionnable XRI. L’entrée UGUI sur des éléments interactionnables non liés à une expérience utilisateur est expérimentale, et plusieurs bogues sont ouverts.

Développement continu

Nous sommes toujours en train de façonner l’histoire du développement pour construire une belle interface utilisateur sur notre variété de plateformes prises en charge. Actuellement, nous fournissons toujours deux versions de la plupart des composants d’expérience utilisateur : une version n’utilisant pas de canevas, avec une disposition statique et non réactive (comme dans MRTK 2.x), et une autre version créée avec notre approche unifiée basée sur un canevas. Au fur et à mesure que nous construisons de nouveaux composants et étoffons l’implémentation de notre bibliothèque de conception, nous prévoyons de déprécier les composants qui ne sont pas basées sur un canevas, dans un souci de cohérence et de maintenance.

Gestion d’état unifiée

En raison de la stricte séparation entre l’état/l’interaction et les éléments visuels, vous remarquerez que les mêmes scripts d’état et d’interaction sont partagés entre les contextes canevas et non basées sur un canevas. C’est voulu. Les mêmes scripts d’interaction peuvent être réutilisés dans n’importe quel contexte visuel ou de disposition, réduisant la surface de l’API et améliorant la cohérence de nos interactions. Par exemple, Slider est le composant d’interaction du curseur pour les curseurs tant canevas que non-canevas, et PressableButton est le même script pour les boutons canevas et non-canevas. À l’avenir, si une nouvelle infrastructure de disposition ou de présentation est adoptée, nous pourrons reprendre la même logique d’interaction et les mêmes systèmes pour garantir la cohérence et la capacité de maintenance.

Le diagramme d’architecture ci-dessous détaille la façon dont les différents événements d’entrée et types d’éléments interactionnables opèrent ensemble pour fournir un état d’interaction unifié. Cliquez sur le diagramme pour afficher une version plus grande.