Partager via

Guide de configuration du profil MRTK2

  • Article

Mixed Reality Toolkit centralise autant que possible la configuration requise pour gérer le kit de ressources (à l’exception des véritables « choses »).

Ce guide est une procédure pas à pas simple pour chacun des écrans de profil de configuration actuellement disponibles pour le kit de ressources.

Profil de configuration main Mixed Reality Toolkit

Le profil de configuration main, qui est attaché au GameObject MixedRealityToolkit dans votre scène, fournit le point d’entrée main pour le kit de ressources dans votre projet.

Notes

Mixed Reality Toolkit « verrouille » les écrans de configuration par défaut pour s’assurer que vous disposez toujours d’un point de départ commun pour votre projet et il est recommandé de commencer à définir vos propres paramètres à mesure que votre projet évolue. La configuration MRTK n’est pas modifiable en mode lecture.

Profil de configuration MRTK

Tous les profils « par défaut » pour Mixed Reality Toolkit se trouvent dans le projet sdk dans le dossier Assets/MRTK/SDK/Profiles.

Important

DefaultHoloLens2ConfigurationProfile est optimisé pour HoloLens 2. Pour plus d’informations, consultez Profils .

Lorsque vous ouvrez le profil de configuration main Mixed Reality Toolkit, l’écran suivant s’affiche dans l’inspecteur :

Scène de configuration MRTK

Si vous sélectionnez une ressource MixedRealityToolkitConfigurationProfile sans MixedRealityToolkit dans la scène, il vous demandera si vous souhaitez que MRTK configure automatiquement la scène pour vous. Cette option est facultative. Toutefois, il doit y avoir un objet MixedRealityToolkit actif dans la scène pour accéder à tous les écrans de configuration.

Cela héberge la configuration actuelle du runtime actif pour le projet.

À partir de là, vous pouvez accéder à tous les profils de configuration du MRTK, notamment :

Ces profils de configuration sont détaillés ci-dessous dans leurs sections pertinentes :

Paramètres d’expérience

Situé dans la page de configuration main Mixed Reality Toolkit, ce paramètre définit l’opération par défaut de l’Mixed Reality’échelle de l’environnement pour votre projet.

Paramètres d’expérience

Paramètres de caméra

Les paramètres de l’appareil photo définissent la façon dont la caméra sera configurée pour votre projet Mixed Reality, en définissant les paramètres génériques de découpage, de qualité et de transparence.

Profil de l’appareil photo

Paramètres système d’entrée

Le projet Mixed Reality fournit un système d’entrée robuste et bien entraîné pour le routage de tous les événements d’entrée autour du projet, qui est sélectionné par défaut.

Paramètres système d’entrée 1

Derrière le système d’entrée fourni par MRTK se trouvent plusieurs autres systèmes, qui aident à piloter et à gérer les tissages complexes nécessaires pour abstraction des complexités d’un framework multiplateforme/réalité mixte.

Paramètres système d’entrée 2

Chacun des profils individuels est détaillé ci-dessous :

Paramètres de visualisation des limites

Le système de limites traduit la limite perçue signalée par le système de limite/gardien des plateformes sous-jacentes. La configuration du visualiseur de limites vous permet d’afficher automatiquement la limite enregistrée dans votre scène par rapport à la position de l’utilisateur. La limite va également réagir/mettre à jour en fonction de l’endroit où l’utilisateur se téléporte dans la scène.

Paramètres de visualisation englobante

Sélection du système de téléportation

Le projet Mixed Reality fournit un système de téléportation complet pour la gestion des événements de téléportation dans le projet, qui est sélectionné par défaut.

Paramètres système de téléportation

Paramètres de reconnaissance spatiale

Le projet Mixed Reality fournit un système de reconnaissance spatiale régénéré pour travailler avec les systèmes d’analyse spatiale dans le projet, qui est sélectionné par défaut.

Paramètres de reconnaissance spatiale 1

Mixed Reality configuration de la reconnaissance spatiale du Kit de ressources vous permet d’adapter le mode de démarrage du système, que ce soit automatiquement au démarrage de l’application ou plus tard par programmation, ainsi que de définir les étendues pour le champ de vision.

Il vous permet également de configurer les paramètres de maillage et de surface, en personnalisant davantage la façon dont votre projet comprend l’environnement qui vous entoure.

Cela s’applique uniquement aux appareils qui peuvent fournir un environnement analysé.

Paramètres de reconnaissance spatiale 2

Paramètres de diagnostic

Une fonctionnalité facultative mais très utile de MRTK est la fonctionnalité de plug-in diagnostics.

Paramètres de diagnostic

Le profil diagnostics fournit plusieurs systèmes simples à surveiller pendant l’exécution du projet, notamment un commutateur Activé/Désactivé pratique pour activer/désactiver le panneau d’affichage dans la scène.

Paramètres de diagnostic Paramètres système 2

Paramètres système de scène

MRTK fournit ce service facultatif pour vous aider à gérer le chargement/déchargement de scènes additives complexes. Pour déterminer si le système de scène est adapté à votre projet, lisez le Guide de Prise en main système de scène.

Paramètres système de scène 1

Paramètres de services supplémentaires

L’un des domaines les plus avancés de Mixed Reality Toolkit est son implémentation du modèle de localisateur de service qui permet l’inscription de n’importe quel « service » auprès de l’infrastructure. Cela permet à l’infrastructure d’être facilement étendue avec de nouvelles fonctionnalités/systèmes, mais permet également aux projets de tirer parti de ces fonctionnalités pour inscrire leurs propres composants d’exécution.

Tout service inscrit bénéficie toujours de tous les avantages de tous les événements Unity, sans la surcharge et le coût de l’implémentation d’un monobehaviour ou de modèles singleton clunky. Cela permet d’utiliser des composants C# purs sans surcharge de scène pour exécuter des processus de premier plan et d’arrière-plan, par exemple des systèmes de génération, une logique de jeu d’exécution ou pratiquement autre chose.

paramètres système supplémentaires

Paramètres des actions d’entrée

Les actions d’entrée permettent d’extraire toutes les interactions physiques et les entrées d’un projet runtime. Toutes les entrées physiques (à partir des contrôleurs/mains/souris/etc.) sont traduites en une action d’entrée logique à utiliser dans votre projet d’exécution. Cela garantit que, quel que soit l’endroit d’où provient l’entrée, votre projet implémente simplement ces actions en tant que « Choses à faire » ou « Interagir avec » dans vos scènes.

Pour créer une action d’entrée, cliquez simplement sur le bouton « Ajouter une nouvelle action » et entrez un nom de texte convivial pour ce qu’il représente. Il vous suffit ensuite de sélectionner un axe (le type de données) que l’action est destinée à transmettre, ou dans le cas des contrôleurs physiques, le type d’entrée physique auquel elle peut être attachée, par exemple :

Contrainte d’axe Type de données Description Exemple d’utilisation
Aucune Pas de données Utilisé pour une action ou un événement vide Déclencheur d’événements
Brut (réservé) object Paramètres réservés pour un usage ultérieur N/A
Digital bool Données de type booléen activées ou désactivées Bouton d’un contrôleur
Axe unique float Valeur de données de précision unique Une entrée étendue, par exemple un déclencheur
Double axe Vector2 Date de type float double pour plusieurs axes Un pavé ou une manette
Position à trois Dof Vector3 Données de type positionnel à partir de 3 axes flottants Contrôleur de style de position 3D uniquement
Rotation à trois Dof Quaternion Entrée rotationnelle uniquement avec 4 axes flottants Un contrôleur de style trois degrés, par exemple un contrôleur Oculus Go
Six Dof Mixed Reality Pose (Vector3, Quaternion) Une entrée de style de position et de rotation avec les composants Vector3 et Quaternion Un contrôleur de mouvement ou un pointeur

Les événements utilisant des actions d’entrée ne sont pas limités aux contrôleurs physiques et peuvent toujours être utilisés dans le projet pour que les effets d’exécution génèrent de nouvelles actions.

Notes

Les actions d’entrée sont l’un des rares composants qui n’est pas modifiable au moment de l’exécution, il s’agit d’une configuration au moment de la conception uniquement. Ce profil ne doit pas être échangé pendant que le projet est en cours d’exécution en raison de la dépendance de l’infrastructure (et de vos projets) sur l’ID généré pour chaque action.

Profil de configuration

Règles d’actions d’entrée

Les règles d’action d’entrée permettent de traduire automatiquement un événement déclenché pour une action d’entrée dans en différentes actions en fonction de sa valeur de données. Ceux-ci sont gérés de manière transparente dans l’infrastructure et n’entraînent aucun coût de performances.

Par exemple, la conversion de l’événement d’entrée à double axe unique d’un DPad dans en 4 actions correspondantes « Dpad Up » / « DPad Down » / « Dpad Left » / « Dpad Right » (comme illustré dans l’image ci-dessous).

Cette opération peut également être effectuée dans votre propre code. Toutefois, étant donné qu’il s’agissait d’un modèle très courant, le framework fournit un mécanisme pour effectuer cette opération « prête à l’emploi »

Action d’entrée Les règles peuvent être configurées pour n’importe quel axe d’entrée disponible. Toutefois, les actions d’entrée d’un type d’axe peuvent être traduites en une autre action d’entrée du même type d’axe. Vous pouvez mapper une action double axe à une autre action double axe, mais pas à une action numérique ou aucune.

Profil des règles d’action d’entrée

Configuration du pointeur

Les pointeurs sont utilisés pour piloter l’interactivité dans la scène à partir de n’importe quel périphérique d’entrée, en donnant à la fois une direction et un test de positionnement avec n’importe quel objet dans une scène (qui a un collider attaché, ou est un composant d’interface utilisateur). Les pointeurs sont automatiquement configurés par défaut pour les contrôleurs, les casques (regard/focus) et les entrées souris/tactiles.

Les pointeurs peuvent également être visualisés dans la scène active à l’aide de l’un des nombreux composants de ligne fournis par Mixed Reality Toolkit, ou de l’un des vôtres s’ils implémentent l’interface MRTK IMixedRealityPointer.

Profil de pointeur d’entrée
  • Étendue de pointage : détermine l’étendue de pointage globale pour tous les pointeurs, y compris le regard.
  • Pointer des masques de couche Raycast : détermine les pointeurs de couches qui seront raycast.
  • Déboguer des rayons pointants de dessin : aide au débogage permettant de visualiser les rayons utilisés pour la diffusion de rayons.
  • Déboguer les couleurs des rayons pointants de dessin : ensemble de couleurs à utiliser pour la visualisation.
  • Préfabriqué du curseur de regard : permet de spécifier facilement un curseur de regard global pour n’importe quelle scène.

Il existe un bouton d’assistance supplémentaire pour accéder rapidement au fournisseur de regards afin de remplacer certaines valeurs spécifiques pour Le regard si nécessaire.

Configuration des mouvements

Les mouvements sont une implémentation propre au système qui vous permet d’affecter des actions d’entrée aux différentes méthodes d’entrée « Gesture » fournies par différents kits SDK (par exemple, HoloLens).

Notes

L’implémentation actuelle de Gestures est destinée uniquement à HoloLens et sera améliorée pour d’autres systèmes à mesure qu’ils seront ajoutés au Kit de ressources à l’avenir (aucune date pour le moment).

Configuration des mouvements

Commandes vocales

À l’instar des mouvements, certaines plateformes d’exécution fournissent également des fonctionnalités intelligentes de reconnaissance vocale avec la possibilité de générer des commandes qui peuvent être reçues par un projet Unity. Ce profil de configuration vous permet de configurer les éléments suivants :

  1. Paramètres généraux : « Comportement de démarrage » défini sur Démarrage automatique ou Démarrage manuel détermine s’il faut initialiser KeywordRecognizer au démarrage du système d’entrée ou laisser le projet décider quand initialiser le KeywordRecognizer. Le « niveau de confiance de reconnaissance » est utilisé pour initialiser l’API KeywordRecognizer d’Unity
  2. Commandes vocales : enregistre les « mots » et les traduit en actions d’entrée qui peuvent être reçues par votre projet. Elles peuvent également être attachées aux actions du clavier si nécessaire.

Important

Actuellement, le système prend uniquement en charge la reconnaissance vocale lors de l’exécution sur Windows 10 plateformes, par exemple HoloLens et Windows 10 bureau, et sera amélioré pour d’autres systèmes à mesure qu’ils seront ajoutés à MRTK à l’avenir (aucune date pour le moment).

Écrans profil de configuration

Configuration du mappage de contrôleur

L’un des principaux écrans de configuration de Mixed Reality Toolkit est la possibilité de configurer et de mapper les différents types de contrôleurs qui peuvent être utilisés par votre projet.

L’écran de configuration ci-dessous vous permet de configurer l’un des contrôleurs actuellement reconnus par le kit de ressources.

Mappage de contrôleur

MRTK fournit une configuration par défaut pour les contrôleurs/systèmes suivants :

  • Souris (y compris prise en charge de la souris spatiale 3D)
  • Touch Screen
  • Manettes Xbox
  • contrôleurs Windows Mixed Reality
  • Mouvements HoloLens
  • Contrôleurs de wand HTC Vive
  • Contrôleurs Oculus Touch
  • Oculus Remote Controller
  • Appareils OpenVR génériques (utilisateurs avancés uniquement)

Cliquer sur l’image de l’un des systèmes de contrôleur prédéfinis vous permet de configurer une seule action d’entrée pour toutes ses entrées correspondantes. Par exemple, consultez l’écran de configuration du contrôleur Oculus Touch ci-dessous :

Écran de configuration du contrôleur

Il existe également un écran avancé pour configurer d’autres contrôleurs d’entrée OpenVR ou Unity qui ne sont pas identifiés ci-dessus.

Paramètres de visualisation du contrôleur

En plus du mappage du contrôleur, un profil de configuration distinct est fourni pour personnaliser la façon dont vos contrôleurs sont présentés dans vos scènes.

Cela peut être configuré à un niveau « global » (toutes les instances d’un contrôleur pour une main spécifique) ou spécifique à un type/main de contrôleur individuel.

MRTK prend également en charge les modèles de contrôleur sdk natifs pour Windows Mixed Reality et OpenVR. Ceux-ci sont chargés en tant que GameObjects dans votre scène et positionnés à l’aide du suivi du contrôleur de la plateforme.

Si votre représentation de contrôleur dans la scène doit être décalée par rapport à la position du contrôleur physique, définissez simplement ce décalage par rapport au préfabriqué du modèle de contrôleur (par exemple, en définissant la position de transformation du préfabriqué du contrôleur avec une position de décalage).

Profil de visualisation

Utilitaires d’éditeur

Les utilitaires suivants fonctionnent uniquement dans l’éditeur et sont utiles pour améliorer la productivité du développement.

Utilitaires de configuration de l’éditeur MRTK

Inspecteurs de service

Les inspecteurs de service sont une fonctionnalité d’éditeur uniquement qui génère des objets en scène représentant les services actifs. La sélection de ces objets affiche des inspecteurs qui offrent des liens de documentation, contrôlent les visualisations de l’éditeur et donnent des insights sur l’état du service.

Inspecteurs de service

Vous pouvez activer les inspecteurs de service en cochant Utiliser les inspecteurs de service sous Paramètres de l’éditeur dans le profil de configuration.

Convertisseur de mémoire tampon de profondeur

Le partage de la mémoire tampon de profondeur avec certaines plateformes de réalité mixte peut améliorer la stabilisation des hologrammes. Par exemple, la plateforme Windows Mixed Reality peut modifier la scène rendue par pixel pour tenir compte des mouvements de tête subtils pendant le temps nécessaire au rendu d’une image. Toutefois, ces techniques nécessitent des mémoires tampons de profondeur avec des données précises pour savoir où et à quelle distance la géométrie se trouve de l’utilisateur.

Pour s’assurer qu’une scène restitue toutes les données nécessaires à la mémoire tampon de profondeur, les développeurs peuvent activer la fonctionnalité Render Depth Buffer sous Paramètres de l’éditeur dans le profil de configuration. Cela prend la mémoire tampon de profondeur actuelle et la restitue en tant que couleur à la vue de scène en appliquant un effet de post-traitement, DepthBufferRenderer, à la caméra main.

Render Depth Buffer Utility Le cylindre bleu de la scène a un matériau avec ZWrite désactivé de sorte qu’aucune donnée de profondeur n’est écrite

Modification des profils au moment de l’exécution

Il est possible de mettre à jour les profils au moment de l’exécution, et il existe généralement deux scénarios et périodes différents dans lesquels cela est utile :

  1. Changement de profil d’initialisation MRTK : au démarrage, avant l’initialisation de MRTK et le profil devient actif, en remplaçant le profil non encore utilisé pour activer/désactiver différentes fonctionnalités en fonction des fonctionnalités de l’appareil. Par exemple, si l’expérience s’exécute dans la réalité virtuelle qui n’a pas de matériel de mappage spatial, il n’est probablement pas judicieux d’activer le composant de mappage spatial.
  2. Commutateur de profil actif : après le démarrage, après l’initialisation de MRTK et qu’un profil est devenu actif, échangez le profil actuellement utilisé pour modifier le comportement de certaines fonctionnalités. Par exemple, il peut y avoir une sous-expérience spécifique dans l’application qui souhaite supprimer complètement les pointeurs de loin.

Commutateur de profil d’initialisation MRTK

Pour ce faire, joignez un MonoBehaviour (exemple ci-dessous) qui s’exécute avant l’initialisation MRTK (c’est-à-dire Awake()). Notez que le script (c’est-à-dire appeler à SetProfileBeforeInitialization) doit être exécuté avant le MixedRealityToolkit script, ce qui peut être obtenu en définissant les paramètres d’ordre d’exécution du script.

using Microsoft.MixedReality.Toolkit;
using UnityEngine;

/// <summary>
/// Sample MonoBehaviour that will run before the MixedRealityToolkit object, and change
/// the profile, so that when MRTK initializes it uses the profile specified below
/// rather than the one that is saved in its scene.
/// </summary>
/// <remarks>
/// Note that this script must have a higher priority in the script execution order compared
/// to that of MixedRealityToolkit.cs. See https://docs.unity3d.com/Manual/class-MonoManager.html
/// for more information on script execution order.
/// </remarks>
public class PreInitProfileSwapper : MonoBehaviour
{

    [SerializeField]
    private MixedRealityToolkitConfigurationProfile profileToUse = null;

    private void Awake()
    {
        // Here you could choose any arbitrary MixedRealityToolkitConfigurationProfile (for example, you could
        // add some platform checking code here to determine which profile to load).
        MixedRealityToolkit.SetProfileBeforeInitialization(profileToUse);
    }
}

Au lieu de « profileToUse », il est possible d’avoir un ensemble arbitraire de profils qui s’appliquent à des plateformes spécifiques (par exemple, un pour HoloLens 1, un pour la réalité virtuelle, un pour HoloLens 2, etc.). Il est possible d’utiliser différents autres indicateurs (par exemple https://docs.unity3d.com/ScriptReference/SystemInfo.html, , ou si la caméra est opaque/transparente ou non), pour déterminer le profil à charger.

Commutateur de profil actif

Pour ce faire, définissez la MixedRealityToolkit.Instance.ActiveProfile propriété sur un nouveau profil en remplaçant le profil actif.

MixedRealityToolkit.Instance.ActiveProfile = profileToUse;

Notez que lors de la définition ActiveProfile pendant l’exécution, la destruction des services en cours d’exécution se produit après le dernier LateUpdate() de tous les services, et l’instanciation et l’initialisation des services associés au nouveau profil se produisent avant la première mise à jour() de tous les services.

Une hésitation d’application notable peut se produire pendant ce processus. En outre, tout script avec une priorité plus élevée que le MixedRealityToolkit script peut entrer sa mise à jour avant que le nouveau profil soit correctement configuré. Pour plus d’informations sur la priorité du script, consultez Paramètres d’ordre d’exécution du script.

Dans le processus de changement de profil, la caméra d’interface utilisateur existante reste inchangée, garantissant ainsi que les composants de l’interface utilisateur Unity qui nécessitent un canevas fonctionnent toujours après le commutateur.

Voir aussi