Physique haute performance dans Unity 5
Nous utilisons PhysX 2.8.3 depuis un certain temps. Nous ne nous sommes pas contentés d'utiliser la version standard de PhysX, mais nous l'avons étendue grâce à de nombreux correctifs apportés par les ingénieurs d'Unity au fil des ans. Cela fait si longtemps, et nous remercions PhysX 2 pour tous les poissons. Comme annoncé lors de la GDC'14, Unity 5.0 propose une mise à jour vers PhysX 3.3. Voyons cela de plus près.
PhysX SDK 3 est une refonte radicale du bon vieux PhysX SDK 2.x. En fait, l'équipe PhysX a pris les meilleures idées et les meilleures approches de la version 2.x et a réécrit l'ensemble du SDK à partir de zéro. Cela signifie que l'ensemble du code est différent, que toutes les interfaces sont différentes et que la plupart des fonctionnalités sont différentes.
Nous allons maintenant vous donner un avant-goût de ce que l'on ressent en utilisant la physique d'Unity 5.0.
Pour commencer par quelque chose de simple, nous avons fait en sorte que la force d'adaptation puisse être commutée et désactivée par défaut. La force adaptative est une technique spéciale de PhysX qui permet de compenser les erreurs numériques lors de la simulation des piles. Cependant, les retours des développeurs d'Unity nous indiquent que la force adaptative contribue beaucoup à l'instabilité globale du contenu des jeux. Attendez-vous à ce que vos objets de type pile se comportent mieux à l'avenir.
Le déplacement des collisionneurs statiques sera beaucoup moins coûteux. Un collisionneur statique est un objet de jeu doté d'un composant collisionneur, mais sans composant Rigidbody. Auparavant, comme le SDK supposait que les collisionneurs statiques n'étaient pas déplacés, le déplacement d'un collisionneur statique déclenchait une reconstruction coûteuse de l'arbre AABB, ce qui affectait fortement les performances globales.
Dans Unity 5, nous utiliserons la même structure de données pour gérer le mouvement des collisionneurs dynamiques et statiques. Malheureusement, nous perdrons l'avantage des collisionneurs statiques qui consomment moins de mémoire que les collisionneurs dynamiques. Cependant, à l'heure actuelle, le coût associé au déplacement des Static Colliders est l'une des 3 principales causes de problèmes de performance dans les jeux Unity. Nous voulions changer cela.
La détection continue des collisions a été améliorée d'un ordre de grandeur. La détection continue des collisions est utilisée pour éviter que des corps se déplaçant rapidement ne traversent d'autres corps sans qu'aucune collision ne soit détectée. Imaginez une balle tirée sur une feuille de papier, ou une partie de billard où certaines boules se déplacent plus vite que d'autres.
Dans Unity 5.0, le SDK génère toutes les données nécessaires pour gérer les mouvements rapides. Il suffit d'activer la détection continue des collisions pour que cela fonctionne. PhysX3 dispose d'un algorithme utilisé pour détecter si la simulation CCD coûteuse est réellement nécessaire compte tenu de la vitesse actuelle du corps ou si une simulation discrète par défaut convient parfaitement. Il est activé une fois que vous avez activé le CCD.
PhysX3 supporte plus de Rigidbodies sur la broadphase. En fait, vous pourrez avoir plusieurs centaines de milliers de corps sur un seul cadre sur les plates-formes de bureau et les plates-formes de type bureau. Auparavant, les corps étaient soumis à une limite fixe de 64k. Il ne s'agissait pas d'une constante que nous pouvions facilement augmenter, mais d'une conséquence des économies réalisées sur les bits dans l'ensemble du SDK. Certaines consoles cibles, comme la PlayStation 3, auront encore cette limitation. Les matériaux physiques sont également limités : à l'heure où nous écrivons ces lignes, vous ne pouvez pas disposer de plus de 64 000 matériaux, quelle que soit la plate-forme.
Dans Unity 5.0, nous avons réduit le coût de la mise à l'échelle des Mesh Colliders. Auparavant, pour mettre à l'échelle un Mesh Collider, il fallait créer un nouveau mesh avec l'échelle intégrée dans les vertices, ce qui demandait beaucoup de temps et de mémoire. Avec PhysX3, nous sommes en mesure de prendre en charge la mise à l'échelle non négative sans aucune cuisson. C'est pratiquement gratuit.
Ensuite, examinons deux sous-systèmes qui diffèrent tellement de la version Unity 4.x que l'on peut les considérer comme nouveaux : les modules de tissus et de véhicules.
Commençons par le tissu. Dans Unity 4, la simulation de tissu est prise en charge par les composants InteractiveCloth et SkinnedCloth. InteractiveCloth a un comportement de maillage semblable à celui d'un tissu, c'est-à-dire un "tissu physique" qui interagit avec d'autres corps physiques, peut appliquer des forces, etc. InteractiveCloth étant coûteux en calcul, Unity 4 en propose un autre, SkinnedCloth, pour l'habillement des personnages.
Comme SkinnedCloth est découplé du pipeline de simulation principal, il est plus performant qu'InteractiveCloth. Le principal problème avec le tissu est que les deux composants étaient assez instables et coûtaient cher. Avec l'intégration de PhysX3, nous avons décidé d'abandonner le support d'InteractiveCloth et de n'avoir qu'un seul composant de tissu, appelé simplement Cloth, conçu pour l'habillement des personnages.
Dans Unity 5.0, Cloth ne réagit plus à tous les collisionneurs d'une scène et n'applique plus de forces au monde. Au lieu de cela, nous disposons d'une solution plus rapide, multithread et plus stable pour l'habillement des personnages. Lorsque vous l'ajoutez, le nouveau composant Cloth ne réagit plus du tout aux corps.
Ainsi, Cloth et le monde ne se reconnaissent pas et ne se voient pas l'un l'autre jusqu'à ce que vous ajoutiez manuellement des colliders du monde au composant Cloth. Même après cela, la simulation reste à sens unique : le tissu réagit à ces corps mais n'applique pas de forces en retour. En outre, vous ne pouvez utiliser que trois types de collision avec le tissu : une sphère, une capsule et une capsule conique, construite à l'aide de deux sphères. Tous ces changements ont été introduits pour améliorer les performances.
L'interface de création dans Unity 5.0 est similaire à celle de SkinnedCloth, et nous travaillons dur pour l'améliorer dans la version 5.x. Il faut s'attendre à ce que des éléments tels que l'intégration des avatars Mecanim soient ajoutés au cours du cycle 5.x.
Le nouveau composant Cloth prend en charge le GPU via CUDA en interne, mais nous avons décidé de le publier plus tard dans le cycle 5.x pour plusieurs raisons. Tout d'abord, CUDA ne fonctionne que sous Windows avec du matériel NVIDIA, et nous sommes très présents sur Mac et Linux. Deuxièmement, nous voulons vraiment concentrer nos efforts de correction des bogues sur les éléments de base en premier lieu et passer ensuite à l'intégration des éléments fantaisistes.
Maintenant, quelques mots sur les véhicules. PhysX3 dispose d'un nouveau SDK pour les véhicules que nous avons utilisé pour implémenter notre composant WheelCollider. Le nouveau composant offre une suspension et un frottement des pneus beaucoup plus réalistes. En outre, elle corrige un certain nombre d'autres problèmes de longue date.
Dans Unity 5.0, le nouveau composant peut être utilisé d'emblée pour générer un comportement simple. Je m'attends à ce que les développeurs n'utilisent les packs de véhicules de l'Asset Store que lorsqu'ils veulent quelque chose de déjà peaufiné, réaliste ou avancé, comme le pack de véhicules d'Edy.
Regardez ce que j'ai pu mettre en place en quelques heures en utilisant un mesh gratuit téléchargé sur le web (la plupart de ce temps a été passé dans Blender à préparer le modèle) :
Et voici l'un des SUV de l'ensemble de véhicules d'Edy :
Edy travaille actuellement sur la nouvelle version de son logiciel qui apportera encore plus de nouveautés. Contactez-le directement pour plus de détails.
Il y a beaucoup de détails techniques fantastiques sur les véhicules que j'aimerais partager avec vous, mais, pour l'instant, jetons un coup d'œil sur les nouveaux gadgets WheelCollider. Cela vous donnera une idée du fonctionnement de la suspension.
Dans l'image ci-dessus, le cercle et le diamètre de la roue sont indiqués en vert, le segment de la course de la suspension en orange et la sphère du point d'application de la force en vert. Sur le segment de la course de la suspension, il y a des marques pour la position de compression maximale, la position d'abaissement maximal et la position cible.
Comme on peut s'y attendre, la roue ne peut se déplacer qu'entre les positions de compression maximale et d'abaissement maximal. La position cible (également appelée position de repos dans le jargon technique) se situe exactement à l'endroit où le poids suspendu est équilibré par la force du ressort, c'est-à-dire la position où se trouve la roue lorsque le véhicule est simplement posé sur une surface plane. Cela peut sembler difficile à régler, mais en fait, la position de compression maximale est celle où votre roue se trouve à l'origine dans le maillage.
Ensuite, vous spécifiez la distance de suspension et la position cible en tant que fraction de la distance de suspension. Juste deux flotteurs pour les dominer tous, ce n'est pas grand-chose ! Vous ai-je dit que le nouveau gadget pour les roues met désormais à jour la rotation et la position à partir des données de simulation dès la sortie de la boîte ? Vous n'avez même pas besoin d'ajouter la géométrie réelle des roues et d'écrire le code de positionnement des roues pour prévisualiser vos paramètres. Tout est intégré.
PhysX3 est désormais prêt à fonctionner sur des cœurs multiples, car le modèle de calcul interne est organisé en tâches qui peuvent être exécutées sur différents cœurs. Le SDK se charge de tout le multithreading, en prenant lui-même en charge toutes les dépendances et en garantissant une décomposition optimale des tâches.
D'après ce que nous avons vu jusqu'à présent, il est raisonnable de s'attendre à un doublement des performances, simplement parce que la base de code est meilleure et que le multithreading est amélioré. Dans certains cas, l'amélioration est spectaculaire et peut aller jusqu'à décupler.
Les ninjas de la performance intéressés par plus de données devraient visiter le blog de Pierre Terdiman. Il est le principal développeur du SDK PhysX.
Les nouvelles fonctions ressemblent à celles d'Unity, mais dans certains cas, le comportement est différent, les paramètres n'ont pas la même signification ou, dans certains cas, les anciens comportements ne sont plus pris en charge. Ainsi, la physique Unity 5.0 n'est pas 100% compatible avec Unity 4.x. Préparez-vous à réajuster vos anciens projets et à réécrire une partie de votre code physique lors de la migration depuis les versions précédentes d'Unity.
Il y a beaucoup plus de détails sur la physique dans Unity 5 que je ne peux partager dans cet article. N'hésitez pas à poser des questions dans les commentaires, ou si vous visitez notre conférence de développeurs Unite 2014 cette année, assistez à mon exposé approfondi sur la physique dans Unity 5.0 et venez dire bonjour et discuter.