Élargir la boîte à outils de la robotique : Changements physiques dans Unity 2022.1

Simulez des robots sophistiqués et conscients de l'environnement avec les nouveaux outils de capteurs de force à dynamique inverse. Explorez la dynamique avec le débogueur de physique entièrement remanié. Tirez parti des améliorations de performances en matière d'interpolation, de requêtes par lots, etc.

Le débogueur physique est un outil essentiel pour comprendre le fonctionnement interne du moteur physique, ainsi que pour donner un sens au comportement particulier observé dans un projet. Un bon débogueur est un outil essentiel pour créer une physique convaincante, moderne et riche. Dans cette optique, nous avons entièrement remanié l'interface utilisateur et ajouté quelques fonctionnalités intéressantes.

Pour faire tenir plus d'informations dans le même espace, nous avons regroupé les propriétés dans des onglets, puis nous les avons développés avec les propriétés nouvellement ajoutées.

Auparavant, les composants Rigidbody et ArticulationBody disposaient d'une section "Info" repliable dans l'inspecteur, que vous pouviez développer pour afficher des informations supplémentaires, telles que la vitesse linéaire actuelle. Cependant, une fois étendu, la performance globale de l'éditeur s'est considérablement dégradée. En outre, il était auparavant difficile de comparer les paramètres de différents corps, car il fallait ouvrir deux panneaux de l'inspecteur. Pour résoudre ces problèmes, nous avons déplacé toutes les propriétés dans l'onglet "Info" de la fenêtre du débogueur de physique, où les propriétés sont affichées pour chacun des objets sélectionnés, de sorte que vous pouvez facilement les comparer côte à côte.

Les points de contact peuvent désormais être visualisés, ainsi que la normale de contact et la distance de séparation.

Les requêtes physiques, telles que Physics.Raycast ou Physics.CastSphere, font normalement partie d'un comportement physique personnalisé, tel que les contrôleurs de personnages ou de véhicules personnalisés. Ils sont invisibles et difficiles à déboguer. Pour aider à cela, cette version offre une visualisation optionnelle des requêtes de physique.

Jusqu'à présent, Unity disposait d'outils qui ne prenaient en charge que ce que l'on appelle la dynamique directe : étant donné un ensemble d'objets et les forces qui leur sont appliquées, il s'agit de calculer leurs trajectoires. Bien que cela soit incroyablement utile, nous voulions élargir notre boîte à outils robotique. Ainsi, Unity 2022.1 ajoute la prise en charge de la dynamique inverse : étant donné un objet et une trajectoire souhaitée, calculez les forces qui provoquent cette trajectoire lorsqu'elle est simulée.

Cet effort s'étendra sur plusieurs versions, au fur et à mesure que nous le construirons de manière itérative. Dans Unity 2022.1, nous exposons un ensemble de fonctions permettant de calculer les composantes de la force totale appliquée aux ArticulationBodies qui doivent être neutralisées avant d'appliquer la force externe qui les entraînera sur la trajectoire souhaitée. D'autres concepts intéressants seront exposés dans les versions ultérieures, tels que la force articulaire nécessaire pour contrer l'impulsion appliquée par le solveur. Nous vous invitons à l'essayer et à nous faire part de votre avis sur le forum.

En particulier, les nouvelles fonctions sont les suivantes

• obtenir la force actuelle appliquée au corps par l'entraînement. Il s'agit d'une indication de l'intensité des efforts déployés par un lecteur pour atteindre la cible souhaitée. Elle dépend de la rigidité et de l'amortissement de l'entraînement, ainsi que de la position et de la vitesse actuelles de la cible delta ;
• obtenir les forces articulaires nécessaires pour contrebalancer les forces de gravité, de Coriolis et centrifuges agissant sur le corps ; et
• obtenir la force articulaire nécessaire pour atteindre l'accélération souhaitée.

Rigidbody utilise à la fois l'interpolation et l'extrapolation pour donner une impression de mouvement fluide tout en simulant à une fréquence relativement basse. En interne, cette fonction est mise en œuvre en calculant les poses de transformation à chaque mise à jour. Dans le cas de l'interpolation, les deux dernières poses simulées sont utilisées pour calculer une nouvelle pose transformée pour cette image. En cas d'extrapolation, la dernière position et la dernière vitesse simulées sont utilisées à la place. Cependant, comme il est conçu pour être léger, nous ne communiquons pas ces poses au moteur physique. Les poses ne sont présentées qu'aux systèmes extérieurs à la physique (par exemple, les graphiques et l'animation). C'est pourquoi, par exemple, un raycast ne détectera pas un corps à la position interpolée.

Pour éviter que la physique ne remarque les changements de transformation, le mécanisme consistait à appeler Physics.SyncTransforms() à chaque mise à jour juste avant l'écriture de la pose, suivi d'un appel de méthode interne pour effacer toutes les mises à jour de transformation pour la physique. Cela a entraîné deux types de problèmes :

Si une scène a au moins un corps interpolé, tous les changements de transformation de tous les composants physiques ont été synchronisés avec le moteur physique à chaque mise à jour (même s'ils ne sont nécessaires qu'une fois par FixedUpdate) ; et

Si une modification a été apportée à une transformation comportant un composant Rigidbody avec interpolation, l'interpolation pour cet objet s'est interrompue car la modification de la transformation effectuée par l'utilisateur a été propagée au moteur physique et a modifié la dernière pose simulée (la pose n'est pas stockée séparément - il s'agit simplement de la pose utilisée par le moteur physique à ce moment-là).

Pour résoudre ces problèmes, nous avons mis à jour le code d'interpolation afin qu'il n'ait pas besoin de synchroniser toutes les transformations pour chaque image. Cette modification améliore également les performances ; le nouveau code d'interpolation s'exécute plus rapidement qu'auparavant (en fonction de la complexité de la scène).

Une section du forum est dédiée à la discussion de divers aperçus expérimentaux de la technologie physique, et certains des changements mis en œuvre dans cette version y ont vu le jour :

• De nombreux projets, en particulier les plus importants, utilisent souvent de nombreuses couches de GameObject, de sorte que la matrice qui décrit les combinaisons de couches et produit des paires de contacts pour la physique devient également assez volumineuse. Dans cette version, nous mettons en évidence la ligne et la colonne actuellement sélectionnées afin d'en faciliter l'utilisation.

• Une articulation est utilisée pour relier deux corps rigides et définit les contraintes sur leur mouvement relatif. Depuis Unity 2020.2, une articulation peut également être utilisée pour lier un Rigidbody à un ArticulationBody. Pour ce faire, chaque classe commune a reçu une propriété supplémentaire qui est indiquée dans l'inspecteur. Il est impossible d'établir un lien avec Rigidbody et ArticulationBody en même temps, de sorte que l'affichage des deux options lorsque l'une d'entre elles a déjà été définie occupe de l'espace vertical sans raison. Désormais, seule la propriété qui a été définie est affichée.

• Un corps rigide cinématique est un type particulier de corps qui peut influencer d'autres corps, sans que rien d'autre ne l'affecte. À cet égard, il est analogue à un collisionneur statique, à l'exception du fait qu'il est destiné à être déplacé fréquemment. Les cas d'utilisation typiques sont les contrôleurs de personnages, la physique pilotée par l'animation, la simulation de poignets en réalité virtuelle (VR), etc. Il est contrôlé par la définition d'une cible cinématique que le corps atteindra en une seule image de simulation. La principale différence avec le collisionneur statique est que la cible cinématique n'est pas atteinte par téléportation instantanée (changement de pose), mais en calculant les vitesses linéaires et angulaires nécessaires pour atteindre l'objectif en une seule image, et en les transmettant ensuite au solveur. De cette manière, le mouvement peut contribuer correctement aux matrices jacobiennes des contraintes et, par conséquent, toute chaîne articulaire attachée réagira correctement (pas de problèmes). Dans cette version de Unity, nous présentons une nouvelle méthode pour définir à la fois la position et la rotation de l'objectif cinématique en une seule opération.
• La modification des contacts, introduite dans Unity 2021.2, permet de modifier les détails des points de contact générés par la phase étroite, juste avant qu'ils ne soient utilisés pour créer des contraintes de contact pour le solveur. Dans cette version, nous avons ajouté de nouvelles entrées pour les vitesses des corps dans une paire de contacts, pour des cas d'utilisation avancés tels que cet exemple de friction anisotrope personnalisée.
• La version PhysX a été mise à jour en 4.1.2, la dernière de la gamme 4.x à ce jour. Il s'agit d'une version mineure, qui ne corrige donc que les bogues et les pannes critiques. Les notes de version sont disponibles ici.
• Lorsqu'un corps dynamique chevauche un collisionneur, le solveur vise à trouver une impulsion corrective qui les sépare tout en satisfaisant toutes les contraintes. En interne, cette impulsion est calculée pour chaque point de contact d'une paire, mais nous ne disposions que d'une valeur globale qui renvoyait une somme totale pour tous les points. Avec cette version, nous exposons une nouvelle propriété de la structure ContactPoint qui permet de récupérer les impulsions pour chaque point de contact.
• Nous suivons de près les réactions de la communauté des roboticiens au sujet du composant ArticulationBody. Pour faciliter la création et l'ajustement du comportement de certaines petites pièces de robot, nous avons ancré les poignées de limite d'articulation dans l'espace d'écran afin qu'elles n'occultent plus les collisions dans la scène.

• Les requêtes par lots en physique ont été le résultat d'une semaine de travail d'Unity et ont été livrées directement pour permettre certains cas d'utilisation, mais avec des fonctionnalités minimales. Ils continuent d'évoluer, avec de nouvelles fonctionnalités pour permettre encore plus de cas d'utilisation, tels que ceux avec des modèles de threading plus sophistiqués, et les types de requêtes sont plus diversifiés. Dans cette version particulière, nous permettons aux requêtes par lots d'être exécutées sur n'importe quelle scène physique, et nous ajoutons un nouveau type de requête par lots(Physics.ClosestPointCommand).
• Pour qu'un maillage soit utilisable avec MeshCollider, il doit d'abord être cuit. La cuisson est un processus coûteux de production des structures de recherche spatiale nécessaires à la détection des collisions. Normalement, il se produit implicitement chaque fois que la propriété mesh d'un MeshCollider est modifiée, et il s'exécute sur le thread principal, bloquant tout autre travail jusqu'à ce qu'il soit terminé. Dans Unity 2019.3, nous avons exposé une méthode thread-safe pour effectuer un bake hors du thread principal à la demande. L'objectif était de permettre la création de maillages procéduraux plus sophistiqués, puisqu'il était désormais possible de jobifier la génération du contenu et la cuisson du maillage, ce qui permettait d'obtenir un taux d'utilisation des threads beaucoup plus élevé. Toutefois, cette fonction présentait un inconvénient particulier : elle ne permettait que la cuisson avec les options de cuisson par défaut. Dans cette version, nous corrigeons ce problème en exposant une nouvelle variante de Physics.BakeMesh qui prend en charge la cuisson avec n'importe quelle option de cuisson.

Nous sommes impatients de voir ce que vous allez créer avec les nouvelles API de dynamique inverse et le débogueur de physique remanié ! Téléchargez dès aujourd'hui la dernière version d'Unity 2022.1 et participez à la conversation sur le forum robotique et le forum de prévisualisation de la physique.