Recommandations en matière de performances pour Unity

Cet article s’appuie sur les recommandations en matière de performances pour la réalité mixte, mais se concentre sur les améliorations spécifiques à Unity.

Nous avons récemment publié une application appelée Principes de base de la qualité qui couvre les problèmes courants de performances, de conception et d’environnement et les solutions pour les applications HoloLens 2. Cette application est une excellente démonstration visuelle pour le contenu qui suit.

Utiliser les paramètres recommandés pour le projet Unity

La première étape la plus importante lors de l’optimisation des performances des applications de réalité mixte dans Unity consiste à s’assurer que vous utilisez les paramètres d’environnement recommandés pour Unity. Cet article contient du contenu avec certaines des configurations de scène les plus importantes pour la création d’applications Mixed Reality performantes. La section suivante met en évidence certains de ces paramètres recommandés.

Comment profiler avec Unity

Unity fournit Unity Profiler intégré, qui est une excellente ressource pour recueillir des informations précieuses sur les performances de votre application particulière. Bien que vous puissiez exécuter le profileur dans l’éditeur, ces métriques ne représentent pas l’environnement d’exécution réel. Les résultats doivent donc être utilisés avec prudence. Profilez à distance votre application tout en l’exécutant sur l’appareil pour obtenir les informations les plus précises et les plus exploitables.

Unity fournit une excellente documentation pour :

1. Comment connecter le profileur Unity aux applications UWP à distance
2. Comment diagnostiquer efficacement les problèmes de performances avec Unity Profiler

Profilage GPU

Profileur Unity

Avec le profileur Unity connecté et après avoir ajouté le profileur GPU (voir Ajouter un profileur dans le coin supérieur droit), on peut voir combien de temps est passé sur le CPU & le GPU respectivement au milieu du profileur. Cela permet au développeur d’obtenir une approximation rapide si son application est limitée à l’UC ou au GPU.

Débogueur de cadre Unity

Le débogueur de cadres de Unity est également un outil puissant et perspicace à utiliser. Il vous donne un bon aperçu de ce que fait le GPU à chaque image. Il faut faire attention à d’autres cibles de rendu et aux commandes blit à copier entre elles, car elles sont coûteuses sur HoloLens. Dans l’idéal, aucune cible de rendu hors écran ne doit être utilisée sur HoloLens. Elles sont ajoutées lors de l’activation de fonctionnalités de rendu coûteuses (par exemple, MSAA, HDR ou effets plein écran comme le flou lumineux) qui doivent être évitées.

Superposition de la fréquence d’images HoloLens

La page Performances système du Portail d’appareil fournit un bon résumé des performances de l’UC et du GPU de l’appareil. Vous pouvez activer Afficher le compteur de fréquence d’images dans le casque et Afficher le graphique de fréquence d’images dans le casque. Ces options activent respectivement un compteur FPS et un graphique qui vous donnent un retour d’information immédiat dans n’importe quelle application en cours d’exécution sur votre appareil.

PIX

PIX peut également être utilisé pour profiler les applications Unity. Il existe également des instructions détaillées sur l’utilisation et l’installation de PIX pour HoloLens 2. Dans une version de développement, les mêmes scopes que vous voyez dans le débogueur de trame de Unity seront également affichés dans PIX et pourront être inspectés et profilés plus en détail.

UnityEngine.XR.XRSettings.renderViewportScale = 0.7f;

Recommandations relatives aux performances du processeur

Le contenu ci-dessous couvre des pratiques de performances plus approfondies, particulièrement destinées au développement Unity & C#.

Références de cache

Nous vous recommandons de mettre en cache les références à tous les composants et GameObjects pertinents lors de l’initialisation, car les appels de fonction répétitifs tels que GetComponent<T>() et Camera.main sont plus coûteux par rapport au coût de mémoire pour stocker un pointeur. Camera.main utilise simplement FindGameObjectsWithTag() en dessous, qui recherche à grands frais votre graphe de scène pour un objet caméra avec la balise « MainCamera ».

using UnityEngine;
using System.Collections;

public class ExampleClass : MonoBehaviour
{
    private Camera cam;
    private CustomComponent comp;

    void Start() 
    {
        cam = Camera.main;
        comp = GetComponent<CustomComponent>();
    }

    void Update()
    {
        // Good
        this.transform.position = cam.transform.position + cam.transform.forward * 10.0f;

        // Bad
        this.transform.position = Camera.main.transform.position + Camera.main.transform.forward * 10.0f;

        // Good
        comp.DoSomethingAwesome();

        // Bad
        GetComponent<CustomComponent>().DoSomethingAwesome();
    }
}

Éviter les opérations coûteuses

1. Éviter d’utiliser LINQ

   Bien que LINQ puisse être propre et facile à lire et à écrire, il nécessite généralement plus de calcul et de mémoire que si vous écriviez l’algorithme manuellement.

   // Example Code
   using System.Linq;
   
   List<int> data = new List<int>();
   data.Any(x => x > 10);
   
   var result = from x in data
                where x > 10
                select x;
   

2. API Unity courantes

   Certaines API Unity, bien qu’utiles, peuvent être coûteuses à exécuter. La plupart d’entre eux impliquent de rechercher dans l’ensemble de votre graphique de scène une liste correspondante d’objets de jeu. Ces opérations peuvent généralement être évitées en mettant en cache les références ou en implémentant un composant de gestionnaire pour les GameObjects afin de suivre les références au moment de l’exécution.

       GameObject.SendMessage()
       GameObject.BroadcastMessage()
       UnityEngine.Object.Find()
       UnityEngine.Object.FindWithTag()
       UnityEngine.Object.FindObjectOfType()
       UnityEngine.Object.FindObjectsOfType()
       UnityEngine.Object.FindGameObjectsWithTag()
       UnityEngine.Object.FindGameObjectsWithTag()
   

3. Méfiez-vous de la boxe

   Le boxing est un concept de base du langage C# et du runtime. Il s’agit du processus d’encapsulation de variables de type valeur telles que char, int, bool, , etc. dans des variables de type référence. Lorsqu’une variable de type valeur est « mise en boîte », elle est encapsulée dans un System.Object, qui est stocké sur le tas managé. La mémoire est allouée et, éventuellement, lorsqu’elle est éliminée, doit être traitée par le ramasse-miettes. Ces allocations et désallocations entraînent un coût de performances et, dans de nombreux scénarios, sont inutiles ou peuvent être facilement remplacées par une alternative moins coûteuse.

   Pour éviter le boxing, assurez-vous que les variables, les champs et les propriétés dans lesquels vous stockez les types numériques et les structures (y compris Nullable<T>) sont typés comme des types spécifiques tels que int, float? ou MyStruct, au lieu d’utiliser object. Si vous placez ces objets dans une liste, veillez à utiliser une liste fortement typée, telle List<int> que plutôt que List<object> ou ArrayList.

   Exemple de boxe en C#

   // boolean value type is boxed into object boxedMyVar on the heap
   bool myVar = true;
   object boxedMyVar = myVar;
   

Chemins de code répétitifs

Toute fonction de rappel Unity répétitive (c’est-à-dire Update) qui est exécutée plusieurs fois par seconde et/ou par trame doit être écrite avec soin. Toute opération coûteuse ici a un impact énorme et constant sur les performances.

1. Fonctions de rappel vides

   Bien que le code ci-dessous puisse sembler innocent à laisser dans votre application, d’autant plus que chaque script Unity s’initialise automatiquement avec une méthode Update, ces rappels vides peuvent devenir coûteux. Unity fonctionne en va-et-vient entre une frontière de code non géré et managé, entre le code UnityEngine et votre code d’application. Le changement de contexte sur ce pont est assez coûteux, même s’il n’y a rien à exécuter. Cela devient particulièrement problématique si votre application comporte des centaines d’objets de jeu avec des composants qui ont des rappels Unity répétitifs vides.

   void Update()
   {
   }
   

2. Opérations à privilégier pour l’exécution une fois par image

   Les API Unity suivantes sont des opérations courantes pour de nombreuses applications holographiques. Bien que cela ne soit pas toujours possible, les résultats de ces fonctions peuvent généralement être calculés une seule fois et les résultats réutilisés dans l’ensemble de l’application pour une image donnée.

   1. Il est recommandé de disposer d’une classe ou d’un service Singleton dédié pour gérer votre regard Raycast dans la scène, puis de réutiliser ce résultat dans tous les autres composants de la scène, au lieu d’effectuer des opérations Raycast répétées et identiques par chaque composant. Certaines applications peuvent nécessiter des lancers de rayons d’origines différentes ou sur différents LayerMasks.

       UnityEngine.Physics.Raycast()
       UnityEngine.Physics.RaycastAll()
   

   1. Évitez les opérations GetComponent() dans les rappels Unity répétés comme Update() en mettant en cache les références dans Start() ou Awake()

       UnityEngine.Object.GetComponent()
   

   1. Il est recommandé d’instancier tous les objets, si possible, lors de l’initialisation et d’utiliser le regroupement d’objets pour recycler et réutiliser les GameObjects tout au long de l’exécution de votre application

       UnityEngine.Object.Instantiate()
   

3. Évitez les interfaces et les constructions virtuelles

   L’appel d’appels de fonction via des interfaces par rapport à des objets directs ou l’appel de fonctions virtuelles peut souvent être beaucoup plus coûteux que l’utilisation de constructions directes ou d’appels de fonctions directes. Si la fonction ou l’interface virtuelle n’est pas nécessaire, elle doit être supprimée. Cependant, l’impact sur les performances de ces approches en vaut la peine si leur utilisation simplifie la collaboration de développement, la lisibilité et la maintenance du code.

   En règle générale, il est recommandé de ne pas marquer les champs et les fonctions comme virtuels, sauf s’il est clairement prévu que ce membre doit être remplacé. Il faut être particulièrement prudent autour des chemins de code haute fréquence qui sont appelés plusieurs fois par image ou même une fois par image, comme une UpdateUI() méthode.

4. Évitez de transmettre des structures par valeur

   Contrairement aux classes, les structures sont de type valeur et lorsqu’elles sont transmises directement à une fonction, leur contenu est copié dans une nouvelle instance. Cette copie ajoute le coût du processeur, ainsi que plus de mémoire sur la pile. Pour les petites structures, l’effet est minime et donc acceptable. Cependant, pour les fonctions invoquées à plusieurs reprises chaque image et les fonctions prenant de grandes structures, modifiez si possible la définition de la fonction pour qu’elle passe par référence. En savoir plus ici

Divers

1. Physique

   1. En général, le moyen le plus simple d’améliorer la physique consiste à limiter le temps consacré à la physique ou le nombre d’itérations par seconde. Cela réduit la précision de la simulation. Voir TimeManager dans Unity.

   2. Les types de collisionneurs dans Unity ont des caractéristiques de performance très différentes. L’ordre ci-dessous répertorie les collisionneurs les plus performants et les collisionneurs les moins performants de gauche à droite. Il est important d’éviter les collisionneurs de maillage, qui sont nettement plus chers que les collisionneurs primitifs.

   Maillage de boîte <<< de capsule < sphérique < (Convexe) < Maillage (non convexe)

2. Animations

   Désactivez les animations inactives en désactivant le composant Animateur (la désactivation de l’objet de jeu n’aura pas le même effet). Évitez les modèles de conception dans lesquels un animateur se trouve dans une boucle et définit une valeur pour la même chose. Cette technique représente une surcharge considérable, sans effet sur l’application. En savoir plus ici.

3. Algorithmes complexes

   Si votre application utilise des algorithmes complexes tels que la cinématique inverse, la recherche de chemins, etc., cherchez une approche plus simple ou ajustez les paramètres pertinents pour leurs performances.

Recommandations en matière de performances entre UC et GPU

En général, les performances CPU-GPU se résument aux appels de tirage soumis à la carte graphique. Pour améliorer les performances, les appels de tirage doivent être stratégiquement a) réduits ou b) restructurés pour des résultats optimaux. Étant donné que les appels de dessin eux-mêmes sont gourmands en ressources, les réduire réduira le travail global requis. De plus, les changements d’état entre les appels de dessin nécessitent des étapes de validation et de traduction coûteuses dans le pilote graphique et, par conséquent, la restructuration des appels de dessin de votre application pour limiter les changements d’état (c’est-à-dire des matériaux différents, etc.) peut améliorer les performances.

Unity a un excellent article qui donne un aperçu et plonge dans les appels de tirage par lots pour leur plate-forme.

• Unity draw Traitement par lots des appels

Rendu d’instance en un seul passage

Le rendu d’instance en un seul passage dans Unity permet de réduire les appels de dessin pour chaque œil à un appel de dessin instancier. En raison de la cohérence du cache entre deux appels de dessin, il y a également une amélioration des performances sur le GPU.

Pour activer cette fonctionnalité dans votre projet Unity

Lisez les articles suivants de Unity pour plus d’informations sur cette approche de rendu.

• Maximiser les performances de réalité augmentée et de réalité virtuelle avec un rendu stéréo avancé
• Instanciation en un seul passage

Traitement par lot statique

Unity est capable de regrouper de nombreux objets statiques pour réduire les appels de dessin au GPU. Le traitement par lots statique fonctionne pour la plupart des objets Renderer dans Unity qui 1) partagent la même matière et 2) sont tous marqués comme statiques (sélectionnez un objet dans Unity et cochez la case en haut à droite de l’inspecteur). Les GameObjects marqués comme statiques ne peuvent pas être déplacés pendant l’exécution de votre application. Par conséquent, le traitement par lots statique peut être difficile à appliquer sur HoloLens, où pratiquement tous les objets doivent être placés, déplacés, mis à l’échelle, etc. Pour les casques immersifs, le traitement par lots statique peut réduire considérablement les appels de dessin et ainsi améliorer les performances.

Pour plus d’informations , lisez Traitement par lots statiquesous Tirage par lots des appels dans Unity .

Traitement par lot dynamique

Dans la mesure où il est problématique de marquer des objets comme statiques pour le développement HoloLens, le traitement par lots dynamique peut être un excellent outil pour compenser ce manque de fonctionnalité. Il peut également être utile sur les casques immersifs. Cependant, le traitement par lots dynamique dans Unity peut être difficile à activer car les GameObjects doivent a) partager le même matériau et b) répondre à une longue liste d’autres critères.

Lisez Traitement par lots dynamique sous Tirage par lots des appels dans Unity pour la liste complète. Le plus souvent, les GameObjects ne peuvent pas être traités par lots dynamiquement, car les données de maillage associées ne peuvent pas comporter plus de 300 sommets.

Autres techniques

Le traitement par lot ne peut se produire que si plusieurs GameObjects sont capables de partager le même matériau. En règle générale, cela sera bloqué par la nécessité pour les GameObjects d’avoir une texture unique pour leur matériau respectif. Il est courant de combiner des textures en une seule grande texture, une méthode connue sous le nom d’atlassement de texture.

De plus, il est préférable de combiner les maillages en un seul GameObject lorsque cela est possible et raisonnable. Chaque moteur de rendu dans Unity a son appel de dessin associé au lieu de l’envoi d’un maillage combiné sous un seul moteur de rendu.

Recommandations relatives aux performances du GPU

Bande passante et taux de remplissage

Lors du rendu d’une image sur le GPU, une application est liée soit par la bande passante de la mémoire, soit par le taux de remplissage.

• La bande passante mémoire est le taux de lectures et d’écritures que le GPU peut effectuer à partir de la mémoire
  • Dans Unity, modifiez la qualité de la texture dans Modifier>les paramètres>du projet Paramètres de qualité.
• La vitesse de remplissage fait référence aux pixels qui peuvent être dessinés par seconde par le GPU.
  • Dans Unity, utilisez la propriété XRSettings.renderViewportScale .

Optimiser le partage du tampon de profondeur

Nous vous recommandons d’activer le partage de la mémoire tampon de profondeur pour optimiser la stabilité de l’hologramme. Lors de l’activation de la reprojection tardive basée sur la profondeur avec ce paramètre, nous vous recommandons de sélectionner un format de profondeur de 16 bits au lieu du format de profondeur de 24 bits . Les mémoires tampons de profondeur de 16 bits réduisent considérablement la bande passante (et donc la puissance) associée au trafic de mémoire tampon de profondeur. Cela peut représenter une amélioration importante à la fois de la réduction de la puissance et des performances. Toutefois, l’utilisation du format de profondeur 16 bits peut avoir deux conséquences négatives.

Z-Fighting

La fidélité réduite de la plage de profondeur rend le z-fighting plus susceptible de se produire avec 16 bits qu’avec 24 bits. Pour éviter ces artefacts, modifiez les plans de découpe proches/lointains de la caméra Unity pour tenir compte de la précision inférieure. Pour les applications basées sur HoloLens, un plan de clip éloigné de 50 m au lieu des 1 000 m par défaut de Unity peut généralement éliminer tout combat z.

Tampon de gabarit désactivé

Lorsque Unity crée une texture de rendu avec une profondeur de 16 bits, aucun tampon de gabarit n’est créé. La sélection du format de profondeur 24 bits, comme décrit dans la documentation Unity, crée une mémoire tampon z de 24 bits et une mémoire tampon de gabarit de 8 bits (si 32 bits est applicable sur un appareil (par exemple, HoloLens), ce qui est généralement le cas).

Éviter les effets de plein écran

Les techniques qui fonctionnent en plein écran peuvent être coûteuses car leur ordre de grandeur est de millions d’opérations par image. Il est recommandé d’éviter les effets de post-traitement tels que l’anticrénelage, la fleurs, etc.

Paramètres d’éclairage optimaux

L’éclairage global en temps réel dans Unity peut fournir des résultats visuels exceptionnels, mais implique des calculs d’éclairage coûteux. Nous vous recommandons de désactiver l’éclairage global en temps réel pour chaque fichier de scène Unity via lesparamètres> d’éclairage derendu> de fenêtre > Décochez l’option Éclairage global en temps réel.

De plus, il est recommandé de désactiver toute projection d’ombres, car celles-ci ajoutent également des passes GPU coûteuses sur une scène Unity. Les ombres peuvent être désactivées par lumière, mais peuvent également être contrôlées de manière holistique via les paramètres de qualité.

Modifier>Paramètres du projet, puis sélectionnez la catégorie >Qualité et sélectionnez Faible qualité pour la plateforme UWP. Il est également possible de définir la propriété Ombres sur Désactiver les ombres.

Nous vous recommandons d’utiliser un éclairage intégré avec vos modèles dans Unity.

Réduire le nombre de poly

Le nombre de polygones est réduit de

1. Suppression d’objets d’une scène
2. Décimation des actifs, qui réduit le nombre de polygones pour un maillage donné
3. Implémentation d’un système de niveau de détail (LOD) dans votre application, qui restitue les objets éloignés avec une version de polygone inférieur de la même géométrie

Présentation des nuanceurs dans Unity

Une approximation facile pour comparer les nuanceurs en termes de performances consiste à identifier le nombre moyen d’opérations que chacun exécute au moment de l’exécution. Cela peut être fait facilement dans Unity.

1. Sélectionnez votre ressource de nuanceur ou sélectionnez un matériau, puis dans le coin supérieur droit de la fenêtre de l’inspecteur. Sélectionnez l’icône d’engrenage suivie de « Sélectionner le nuanceur ».

   

2. Une fois la ressource de shader sélectionnée, sélectionnez le bouton « Compiler et afficher le code » sous la fenêtre de l’inspecteur.

   

3. Après la compilation, recherchez la section statistiques dans les résultats avec le nombre d’opérations différentes pour le vertex et le pixel shader (Remarque : les pixel shaders sont souvent aussi appelés fragment shaders).

   

Optimiser les nuanceurs de pixels

En regardant les résultats statistiques compilés à l’aide de la méthode ci-dessus, le nuanceur de fragments exécutera généralement plus d’opérations que le nuanceur de vertex, en moyenne. Le shader de fragment, également appelé shader de pixel, est exécuté par pixel sur la sortie de l’écran, tandis que le shader de vertex n’est exécuté que par sommet de tous les maillages dessinés à l’écran.

Ainsi, non seulement les fragment shaders ont plus d’instructions que les vertex shaders en raison de tous les calculs d’éclairage, mais les fragment shaders sont presque toujours exécutés sur un jeu de données plus volumineux. Par exemple, si la sortie d’écran est une image de 2 Ko sur 2 Ko, le nuanceur de fragments peut être exécuté 2 000*2 000 = 4 000 000 de fois. Si vous affichez deux yeux, ce nombre double puisqu’il y a deux écrans. Si une application de réalité mixte a plusieurs passes, des effets de post-traitement en plein écran ou le rendu de plusieurs maillages au même pixel, ce nombre augmente considérablement.

Par conséquent, la réduction du nombre d’opérations dans le nuanceur de fragments peut généralement donner des gains de performances beaucoup plus importants par rapport aux optimisations du nuanceur de vertex.

Alternatives aux nuanceurs Unity Standard

Au lieu d’utiliser un rendu physique réaliste (PBR) ou un autre shader de haute qualité, envisagez d’utiliser un shader plus performant et moins cher. Mixed Reality Toolkit fournit le nuanceur standard MRTK qui a été optimisé pour les projets de réalité mixte.

Unity propose également des options de shader non éclairé, vertex, diffus et d’autres options de shader simplifiées qui sont plus rapides que le shader Unity Standard. Pour plus d’informations, consultez Utilisation et performances des nuanceurs intégrés.

Préchargement du nuanceur

Utilisez le préchargement du nuanceur et d’autres astuces pour optimiser le temps de chargement du nuanceur. En particulier, le préchargement du shader signifie que vous ne verrez aucun problème dû à la compilation du shader d’exécution.

Limiter le découvert

Dans Unity, on peut afficher l’overdraw pour sa scène, en basculant le menu du mode draw dans le coin supérieur gauche de la vue Scene et en sélectionnant Overdraw.

En général, le surtirage peut être atténué en éliminant les objets à l’avance avant qu’ils ne soient envoyés au GPU. Unity fournit des détails sur l’implémentation de l’élimination de l’occlusion pour son moteur.

Recommandations relatives à la mémoire

Une allocation excessive de mémoire & des opérations de désallocation peuvent avoir des effets néfastes sur votre application holographique, entraînant des performances incohérentes, des images figées et d’autres comportements préjudiciables. Il est particulièrement important de comprendre les considérations de mémoire lors du développement dans Unity, car la gestion de la mémoire est contrôlée par le ramasse-miettes.

Nettoyage de la mémoire

Les applications holographiques perdent du temps de calcul de traitement au profit du ramasse-miettes (GC) lorsque celui-ci est activé pour analyser les objets qui ne sont plus dans le champ d’application pendant l’exécution et que leur mémoire doit être libérée, afin qu’elle puisse être mise à disposition pour être réutilisée. Les allocations et désallocations constantes nécessitent généralement que le nettoyage de la mémoire s’exécute plus fréquemment, ce qui nuit aux performances et à l’expérience utilisateur.

L’une des pratiques les plus courantes qui conduisent à un nettoyage excessif de la mémoire n’est pas de mettre en cache les références aux composants et aux classes dans le développement Unity. Toutes les références doivent être capturées pendant Start() ou Awake() et réutilisées dans des fonctions ultérieures telles que Update() ou LateUpdate().

Autres conseils rapides :

• Utilisez la classe C# StringBuilder pour créer dynamiquement des chaînes complexes au moment de l’exécution.
• Supprimez les appels à Debug.Log() lorsqu’ils ne sont plus nécessaires, car ils s’exécutent toujours dans toutes les versions de construction d’une application
• Si votre application holographique nécessite généralement beaucoup de mémoire, envisagez d’appeler System.GC.Collect() lors des phases de chargement, comme lors de la présentation d’un écran de chargement ou de transition.

Regroupement d’objets

Le regroupement d’objets est une technique populaire pour réduire le coût de l’allocation et de la désallocation continues d’objets. Pour ce faire, allouez un grand nombre d’objets identiques et réutilisez les instances inactives et disponibles à partir de ce pool au lieu de faire apparaître et de détruire constamment des objets au fil du temps. Les pools d’objets sont parfaits pour les composants réutilisables dont la durée de vie est variable au cours d’une application.

• Didacticiel sur le regroupement d’objets dans Unity

Performance au démarrage

Envisagez de démarrer votre application avec une scène plus petite, puis d’utiliser SceneManager.LoadSceneAsync pour charger le reste de la scène. Cela permet à votre application d’atteindre un état interactif aussi rapidement que possible. Il peut y avoir un pic de processeur important pendant l’activation de la nouvelle scène et tout contenu rendu peut bégayer ou saccader. Une façon de contourner ce problème consiste à définir la propriété AsyncOperation.allowSceneActivation sur « false » sur la scène en cours de chargement, à attendre le chargement de la scène, à effacer l’écran en noir, puis à le remettre sur « true » pour terminer l’activation de la scène.

N’oubliez pas que pendant le chargement de la scène de démarrage, l’écran de démarrage holographique s’affiche à l’utilisateur.