Bonnes pratiques de création de scripts visuels mesh pour les performances
Vue d’ensemble
Les scripts visuels ne sont pas intrinsèquement lents, mais ils sont beaucoup plus lents que, par exemple, le code C#.
Lorsque vous créez des scripts visuels dans votre environnement, il est préférable de les utiliser pour connecter des fonctionnalités existantes, et non pour un travail lourd : rendre la colle, et non les girders. La façon la plus simple de s’assurer que vos scripts visuels n’ont pas d’impact sur les performances globales de votre environnement est de s’assurer qu’ils ne font pas beaucoup du tout au premier endroit.
Événements de script haute et basse fréquence
Visual Scripting offre une large sélection d’événements que vous pouvez utiliser pour déclencher des flux de script visuel.
Essayez d’éviter :
Lors de la mise à jour, de la mise à jour fixe, de la mise à jour tardive et similaire. Ces événements se déclenchent très fréquemment (souvent à la même vitesse que les images de rendu), et même si votre script ne fait pas grand-chose, même le démarrage a une surcharge qui peut avoir un impact notable sur les performances de votre environnement s’il se produit dans de nombreux endroits à la fois.
Sur le séjour du déclencheur et sur le séjour en collision. Même si ces événements ne sont actifs que dans certaines conditions (par exemple, lorsqu’un objet physique se trouve à l’intérieur d’un volume de déclencheur physique ou touche un collider), alors que ces conditions sont données, elles se déclenchent très fréquemment.
Il n’existe aucun remplacement direct par défaut pour ces événements à haute fréquence. Ils ne sont pas désactivés. Vous pouvez donc les utiliser s’il est absolument nécessaire, mais nous vous recommandons d’essayer de tirer parti des fonctionnalités intégrées telles que le composant Animator, qui peut être contrôlé par des scripts visuels ou restructurer votre logique de script pour être réactive plutôt que active-par exemple, à l’aide d’événements On State Changed .
Si vous ne pouvez pas éviter ces événements à haute fréquence, vous pourrez peut-être réduire leur impact en gardant l’ensemble du composant Script Machine inactif lorsqu’il n’est pas nécessaire. Un autre script visuel peut utiliser le jeu d’ordinateurs | de script activé pour désactiver et activer un graphique de script entier. En cas de désactivation, aucun de ses nœuds d’événements ne se déclenche et n’a aucun coût d’exécution.
Ils sont légèrement dangereux pour les performances, mais parfois nécessaires :
- En cas d’entrée de collision et de sortie de collision. Normalement, ces événements ne sont déclenchés qu’une seule fois lorsqu’un corps physique touche le collider, et une fois de plus lorsqu’il cesse de toucher. Toutefois, parfois, un corps physique se bloque entre deux collisionneurs ; dans ce cas, il peut commencer à se giguer rapidement et à l’arrière, déclenchant de nombreux événements sur collision dans une succession très rapide. Nous vous recommandons d’utiliser les événements On Trigger à la place.
Il s’agit OK à utiliser dans certaines situations :
Sur Interval , vous pouvez déclencher des flux de script dans des intervalles personnalisables (par exemple, une fois par seconde) définis par le biais de son paramètre Interval . Vous pouvez utiliser le paramètre Delay pour décaler l’exécution de différents événements On Interval qui ont le même intervalle.
Le nœud minuteur n’est pas un événement, mais déclenche son port Tick une fois par frame pour la durée du minuteur une fois qu’il a été démarré en entrant son port de démarrage . Lorsque le minuteur n’est pas en cours d’exécution, il n’a aucun coût d’exécution.
Essayez de ne pas utiliser ces événements pour continuer à vérifier si certaines variables, propriétés ou conditions ont changé. Il est préférable d’utiliser un événement On State Changed pour écouter les modifications à un coût inactif zéro.
Il s’agit toujours OK à utiliser :
Sur les déclencheurs Changement d’état, uniquement si et quand l’un de ses ports d’entrée change leur valeur. Pour les variables de script et les propriétés de composant, cette opération est implémentée de manière très efficace, ce qui entraîne un coût d’exécution nul tant que rien ne change.
Sur l’état modifié peut également être utilisé pour observer des entrées plus complexes (par exemple, les résultats d’un calcul) qui nécessitent qu’elle réévalue l’entrée une fois par image pour déterminer si elle a changé. Vous devrez activer l’option Autoriser l’interrogation pour activer cette fonctionnalité. L’interface utilisateur de modification de script vous informe de cela et vous avertit de l’impact potentiel sur les performances. Même si, il sera encore un peu plus efficace que de scripter votre propre logique d’interrogation à l’aide d’un événement On Update .
Sur l’élément de dictionnaire ajouté et sur l’élément de dictionnaire supprimé, fonctionne de la même façon et n’a aucun coût d’exécution tant que rien ne change.
Sur l’entrée du déclencheur et sur la sortie du déclencheur, aucun des dangers potentiels de performances des événements de collision correspondants (voir ci-dessus).