Partager via


Guide du programmeur de script visuel Mesh

Accédez à l’article de vue d’ensemble de Visual Scripting

Limites

  • Seul un sous-ensemble de fonctionnalités Unity est exposé aux scripts visuels.
  • Les variables et les propriétés avec des types non simples (y compris les références d’objet) ne sont pas automatiquement partagées. Pour en savoir plus sur ce sujet, consultez Partage et mise en réseau ci-dessous.

Hello World

Le script visuel le plus simple que vous pouvez créer est un script qui ouvre simplement une boîte de message :

Capture d’écran du graphique de script visuel de l’exemple Hello World

Voici comment il ressemble dans Mesh :

Fenêtre de navigateur mesh avec une boîte de dialogue contextuelle affichant Hello World et un bouton OK

Capture d’écran de l’éditeur Unity avec la scène Mesh Visual Scripting Hello World ouverte.

Test de vos scripts

Avant de charger votre scène sur Mesh, vous pouvez développer et tester des scripts visuels, même avec plusieurs clients en mode écran fractionné, à l’aide du mode Lecture avec émulation mesh.

Diagnostics de script visuel dans l’éditeur

Lorsqu’un GameObject avec une machine de script est sélectionné dans la hiérarchie de transformation, Mesh affiche le panneau Diagnostics de script visuel mesh en bas du panneau Inspecteur :

Capture d’écran du panneau diagnostics mesh Visual Scripting

Le panneau de diagnostics fournit des commentaires immédiats sur les avertissements ou erreurs susceptibles d’empêcher vos scripts de fonctionner correctement dans Mesh.

Limitation actuelle : les futures versions du panneau de diagnostics peuvent également donner un aperçu de l’utilisation de variables et de propriétés partagées par le script visuel et afficher des diagnostics et des avertissements supplémentaires.

Chargement vers Mesh

Utilisez le chargeur mesh pour charger des scènes qui contiennent des scripts visuels. Pour ouvrir le chargeur, dans le menu Mesh Toolkit , sélectionnez Environnements.

Remarque : Mesh Uploader valide les scripts visuels avant le chargement et refuse de charger lorsqu’il existe des erreurs de validation dans des scripts visuels. Les diagnostics détaillés sont générés dans la console.

Partage et mise en réseau

État du script partagé et local

Mesh utilise le script visuel Unity, qui est conçu pour fonctionner sans mise en réseau. Les scripts visuels s’exécutent indépendamment sur chaque client. Toutefois, l’expérience Mesh des utilisateurs est partagée ; tous les utilisateurs connaissent une seule scène partagée qui ressemble à celle de tous les clients.

L’effet de l’exécution d’un script visuel est la façon dont il modifie l’état de la scène.

Par défaut, Mesh réplique automatiquement les modifications de scène effectuées par des scripts visuels sur un client vers tous les autres clients. Outre tout ce qui est partagé dans une scène, un état reste indépendant sur chaque client (en d’autres termes, local).

Les modifications locales sont temporairement prioritaires sur les modifications provenant des clients. Exemple : Si vous continuez à animer un objet localement, votre animation locale n’est pas compromise par les modifications provenant d’autres clients.

Il existe une limitation du taux de mise à jour automatique. Un client n’envoie pas de mises à jour supplémentaires pendant qu’un client est toujours en cours d’exécution ; il existe une mise à jour envoyée par aller-retour via le serveur. Cela représente environ cinq à six mises à jour par seconde dans des situations pratiques. Cela signifie qu’une animation fluide pilotée par un client ne semble pas lisse sur d’autres clients. La meilleure pratique consiste à effectuer des animations lisses localement, idéalement pas par le biais de scripts visuels, mais par le biais du système d’animation Unity normal.

La cohérence éventuelle de l’état partagé est garantie (même si les états des clients peuvent temporairement être différents).

État local :

  • État local naturel : sons, interface utilisateur, rendu.
  • État local contrôlé par l’utilisateur : sous-scènes marquées avec le composant Étendue de script local.
  • État local technique : objets qui ne font pas partie de la hiérarchie de scènes (par exemple, matériaux de renderer, ressources).

État partagé :

  • Limité aux variables de script visuel et aux propriétés des composants GameObjects et scène qui font partie de la hiérarchie de scène.
  • Seules les variables et les propriétés de types simples peuvent être répliquées : entiers, nombres à virgule flottante, booléens, chaînes, Color, ,//Vector24Quaternion3 , Matrix4x4et .Rect

Toute modification de l’état partagé est envoyée sur le réseau. Cela augmente le trafic réseau et, s’il est utilisé sans précaution, peut consommer une bande passante significative.

Déclencheurs de script partagé et local

Tous les flux de script visuel commencent en réponse à un événement.

  • Si l’événement provient d’un seul client (par exemple, l’utilisateur clique sur un bouton), le script visuel s’exécute uniquement sur ce client.
  • Si l’événement se produit sur tous les clients, le script visuel s’exécute sur tous les clients (par exemple, événement du minuteur, modification de propriété partagée, mise à jour de variable partagée, avatar entre le déclencheur, le corps physique touches collider).

Lors de l’ajout d’un nœud pour détecter si un objet est sélectionné, il est important de choisir celui qui convient. Vous avez deux choix : Corps interagissant maillage : sélectionné localement et corps interagissant maillage : est sélectionné. Supposons, par exemple, que vous souhaitiez avoir un bouton qui peut être cliqué pour déclencher la téléportation. Pour que le participant clique sur le bouton et se transporte uniquement, utilisez le corps interagissant mesh : est sélectionné localement .

Capture d’écran du corps interagissant maillage sélectionné localement.

Pour que le participant clique sur le bouton et la téléporte tout le monde dans l’expérience, utilisez le corps interagissant mesh : est sélectionné nœud. Dans chaque cas, le texte au-dessus du nœud vous indique le comportement à attendre :

Capture d’écran du nœud Mesh Interactable Body Is Selected, qui affectera tous les clients.

Si un script local définit une variable partagée et qu’un deuxième script écoute les modifications apportées à cette variable (à l’aide du déclencheur On State Changed ; voir ci-dessous), le deuxième script est exécuté sur tous les clients.

Mesh propose des nœuds de script spéciaux :

  • Sur les déclencheurs Interval à intervalles réguliers, de façon synchrone sur tous les clients.
  • Sur les déclencheurs Changement d’état lorsque ses entrées changent (par exemple, propriétés partagées, variables partagées, local).
  • Afficher la boîte de dialogue affiche une boîte de dialogue de message avec du texte personnalisé qui peut éventuellement fournir des boutons en tant qu’options de réponse.

Mesh fait certains compromis en faveur de la simplicité :

  • Si plusieurs clients essaient de modifier les mêmes données, le dernier client gagne (au lieu d’utiliser un modèle de mise à jour de données basée sur les transactions).
  • Pour garantir la cohérence des données, les scripts visuels qui s’exécutent sur tous les clients ne doivent pas lire, puis écrire des propriétés ou des variables partagées. Si cela se produit, il déclenche une erreur d’exécution et abandonne l’exécution du flux de script.

Bonnes pratiques

Les scripts visuels sont beaucoup plus lents que le code C# natif. En outre, Mesh augmente les scripts visuels avec des fonctionnalités réseau et d’autres fonctionnalités d’intégration, et les actions de script visuel apparemment peu chargés peuvent entraîner le trafic réseau.

Les problèmes de performances dans les scripts visuels sont presque toujours causés par les scripts effectuant des mises à jour à haute fréquence des variables ou des propriétés de composant partagées par défaut.

  • Utilisez les composants d’étendue de script local de manière libérale pour vous assurer que seules les variables et les propriétés des composants qui doivent être synchronisées entre les clients entraînent une surcharge réseau. Tout ce qui est animé localement avec un script visuel ne doit pas être partagé.

  • Utilisez le déclencheur de script On State Changed pour démarrer des flux de script en réponse à la modification des variables ou des propriétés de composant. Cela fonctionne à la fois pour l’état local et partagé. Il est également recommandé de synchroniser les animations locales.

  • Utilisez le déclencheur de script On Interval au lieu d’un déclencheur à fréquence élevée comme On Update pour démarrer des flux de script contrôlables et réguliers.

Éléments à prendre en compte :

  • Dans la mesure du possible, évitez de déclencher des scripts visuels chaque image. Au lieu d’utiliser On Update, utilisez On State Changed ou On Interval.

  • Si vous devez déclencher un script visuel chaque image, effectuez-le sur autant d’objets que possible.

  • Ne mettez pas à jour les propriétés partagées à haute fréquence. Au lieu de cela, envisagez de rendre les propriétés mises à jour à haute fréquence locales à l’aide du composant Étendue de script local. N’oubliez pas que les variables de script visuel sont également partagées par défaut !

  • N’utilisez pas de variables d’objet si les variables de flux fonctionnent.

  • Évitez de mettre à jour des propriétés ou des variables partagées dans des scripts visuels qui sont déclenchés simultanément sur tous les clients.

  • Évitez de définir des propriétés physiques (transformation et vélocité) sur le même corps physique sur plusieurs clients en même temps. Cela peut facilement se produire par accident dans des scripts visuels qui répondent aux déclencheurs de changement de scène partagé.

  • N’essayez pas de résoudre les problèmes de performances en regroupant plusieurs flux de script qui fonctionnent sur des objets individuels dans un flux de script unique qui fonctionne sur de nombreux objets. La surcharge de démarrage d’un flux de script est négligeable, et la complexité ajoutée que vous devez ajouter pour consolider votre script peut très bien négation de tout léger avantage de performances que vous pouvez obtenir de réduire le nombre de ScriptMachines.

Conseils

  • Les propriétés de composant et les variables de script visuel qui ont des types simples sont automatiquement partagées entre les clients d’une session. Pour réduire la surcharge en limitant la quantité de partage, ajoutez un composant d’étendue de script local au GameObject approprié, puis effectuez l’une des opérations suivantes :

    Pour partager des variables de script visuel, mais pas des propriétés de composant, ni les variables de script ou les propriétés de composant des objets enfants :
    Dans le composant Étendue de script local, sélectionnez Partager des variables de script visuel sur cet objet de jeu.

    Capture d’écran du composant d’étendue de script local avec sa propriété nommée « Partager des variables de script visuel sur cet objet de jeu » sélectionnée.

    Pour conserver toutes les variables de script visuel et propriétés de composant pour l’objet actuel et ses objets enfants locaux :
    Pour ce faire, il suffit d’ajouter le composant Étendue de script local et de conserver les variables de script visuel Share sur cet objet game non sélectionné.

    Capture d’écran du composant d’étendue de script local avec sa propriété nommée « Partager des variables de script visuel sur cet objet de jeu » n’a pas été sélectionnée.

    Vous pouvez voir plusieurs exemples de l’utilisation du composant Étendue de script local dans le chapitre 3 de notre didacticiel Mesh 101 qui se concentre sur les scripts visuels.

  • Pour effectuer quelque chose dans des intervalles de temps réguliers dans la synchronisation entre les clients, utilisez le nœud déclencheur On Interval .

  • Pour faire quelque chose en réponse à certaines propriétés de composant ou variables de script visuel changeant (par exemple, car cela ou un autre client les définissait dans un script visuel), utilisez le déclencheur On State Changed

  • Il existe d’autres fonctions visual Scripting fournies par Mesh. Consultez les sections Microsoft Mesh et Microsoft>>Events>Mesh dans le Finder flou.

Sécurité

Mesh protège les utilisateurs contre les scénarios de menace tels que ceux-ci :

  • Contenu de scène compromis , par exemple, des tentatives malveillantes d’accès aux données locales sensibles.
  • Client compromis ou canal de transport ( par exemple, des tentatives malveillantes de lecture ou d’écriture de données distantes inaccessibles sur d’autres clients).

Pour ce faire, Mesh exécute des scripts visuels dans un bac à sable (comme JavaScript dans un navigateur web).

Au démarrage de la scène, Mesh utilise une liste verte organisée pour valider les scripts visuels afin de limiter l’accès à certains types de composants Unity et à un sous-ensemble sécurisé de leurs propriétés.

Au moment de l’exécution de la scène, Mesh limite l’accès à certaines parties de la scène :

  • Localement : en empêchant l’accès aux éléments internes de Mesh et à d’autres données sensibles.
  • À distance : en vérifiant que l’auteur de la scène a l’intention de modifier cette partie de la scène. Pour ce faire, analyse statiquement les scripts visuels côté récepteur pour leurs écritures de scène potentielles.

Exemples :

  • Un script visuel local malveillant veut donner à tous les avatars des têtes bobble. À cette fin, il tente d’analyser l’intégralité de la scène pour GameObjects qui représentent les têtes d’avatar. Mesh filtre automatiquement les résultats de l’analyse pour exclure le système d’avatar.
  • Un client distant malveillant veut faire face à la scène en retournant tous les GameObjects à l’envers. Pour ce faire, il envoie une mise à jour de propriété qui définit l’échelle verticale de chaque GameObject dans la scène. Toutefois, étant donné qu’aucun script visuel sur le client de réception n’est conçu pour faire quoi que ce soit, le client local ignore l’entrée distante.

Intégration de maillage

Limitation actuelle : cette section décrit une préversion des fonctionnalités qui fonctionnent toujours en cours.

En règle générale, l’intégration à d’autres composants est souvent effectuée en changeant et en écoutant les modifications des propriétés des composants. Par exemple :

  • Interactions : observez les propriétés « Is Hovered » et « Is Selected ».

  • Interactions physiques : observez les corps dans le volume du déclencheur ou en contact avec un collisionneur.

  • Avatars : lire la position de l’avatar, la rotation de la vue et la plaque de nom. (Non disponible pour le moment.)

  • État de session : répertorier les participants et lire les informations des participants. (Non disponible pour le moment.)

  • Script cloud : fonctionne en tandem avec les scripts cloud qui peuvent lire et écrire des variables et des propriétés de composant. (Non disponible pour le moment.)

Certains composants fournissent des actions locales :

  • Gestionnaire audio
  • Durée
  • Animateurs
  • Rendu : propriétés de matériau et de nuanceur de lecture et d’écriture

La physique est gérée spécialement parce que la simulation d’un objet physique donné fait toujours autorité par un seul client : son propriétaire. Pour effectuer ce travail, la définition des propriétés physiques déclenche un transfert automatique de propriété vers le client qui applique la modification.

Étapes suivantes