Quand une animation doit toucher le monde
Par Oleg Sidorkin, directeur technique et cofondateur de Cinevva
Une animation de marche sait comment les jambes bougent. Elle ne sait pas qu’un pied vient d’atteindre une marche. Une animation de préhension sait comment le bras bouge. Elle ne sait pas où se trouve cette serrure précise, ni que quelqu’un a déplacé la tasse.
C’est le problème qui vient après le rigging automatique d’un personnage : faire en sorte que l’animation réagisse à la scène pendant l’exécution du jeu. Nous avons implémenté une couche expérimentale de correction dans le runtime Three.js de Cinevva. Elle lit la pose produite par l’animation, interroge la scène et ajuste les articulations du personnage avant le rendu de l’image.
Les exemples ci-dessous exécutent ce code dans votre navigateur. Aucune requête de génération de mouvement n’est effectuée dans la boucle de chaque image.
Essayez la différence
La démo démarre automatiquement. Choisissez un exemple et désactivez puis activez les Corrections. Le personnage de gauche présente la pose de base ; celui de droite reçoit la correction en direct. Mettez la démo en pause et faites glisser la timeline pour examiner un instant précis. Faites glisser la souris dans l’une ou l’autre des vues pour tourner autour du personnage, utilisez la molette ou le pincement pour zoomer, et faites glisser avec le bouton droit pour déplacer la vue. Les deux caméras restent synchronisées afin que vous puissiez examiner le même contact exactement sous le même angle.
Chaque exemple utilise la même grenouille riggée automatiquement par Cinevva. L’exemple de marche joue Marche issue de la bibliothèque universelle d’animations, retargetée au moyen du même code que celui utilisé par Auto Rigger. Les deux vues jouent le véritable clip ; celle de droite y ajoute des corrections de terrain en temps réel. Les autres exemples conservent la référence Idle intégrée et leurs contrôleurs d’interaction.
Le contrôleur de marche planifie une foulée à l’avance. Il prédit la position de la marche mobile au moment où le pied se pose, centre toute la plante du pied de la grenouille dans la zone d’atterrissage et fait passer la prochaine phase d’oscillation au-dessus des hauteurs futures des marches. Il préserve la cadence et la forme de l’oscillation du clip de la bibliothèque tout en ajustant la longueur de la foulée. Le bassin commence son transfert de poids et son changement de hauteur avant l’atterrissage ; l’IK place ensuite les membres sur les cibles planifiées et affine le contact visible de la plante du pied.
Activez Plan des pas pour afficher le contour des plantes de pied à leurs positions d’atterrissage prévues ainsi que les trajectoires d’oscillation en pointillés. Trajectoire du bassin compare le mouvement du corps, tandis que Enregistrer la trace du bassin conserve les mesures. Ce planificateur gère actuellement les marches mobiles connues de la démo. Il signale les atterrissages impossibles ; la navigation sur un terrain arbitraire et les forces physiques d’équilibrage relèvent de responsabilités distinctes du moteur.
Grimper à une échelle transfère un membre à la fois tandis que trois points de contact restent fixés à leurs barreaux. L’échelle descend pour maintenir le grimpeur dans le champ. Des cibles explicites pour les chevilles et les mains positionnent les contacts, tandis que des guides pour les coudes et les genoux orientent les flexions à l’écart de l’échelle. Le mouvement du corps et la séquence des contacts sont définis manuellement ; il ne s’agit pas d’un planificateur d’escalade automatique.
Ce qui est implémenté
| Fonctionnalité | Ce que fait actuellement le runtime |
|---|---|
| Sol irrégulier | Recherche un point d’appui pour chaque pied, aligne la normale calibrée de sa plante et ajuste la hauteur du bassin. |
| Pieds ancrés | Maintient un contact d’appui par rapport à la surface qui le soutient. |
| Plateformes mobiles | Déplace ce contact avec un support en translation ou en rotation. |
| Cibles pour les mains | Résout la position d’un bras vers une position et une orientation dans l’espace global, avec un poids de fusion. |
| Objets tenus | Déduit la cible du poignet à partir de la pose souhaitée de l’objet et d’une transformation de prise fixe. |
| Cible hors de portée | Limite la résolution et signale que le personnage doit être repositionné. |
Il s’agit d’un prototype de runtime à activer explicitement. Les exemples interactifs présentent l’implémentation ; ils ne signifient pas que tous les jeux générés par Cinevva l’activent automatiquement.
Un pied ancré a besoin d’un repère
Notre système de retargeting existant corrige déjà une partie du glissement des pieds lors du transfert d’un clip entre des personnages aux proportions différentes. L’ancrage au sol en temps réel dispose d’une autre donnée d’entrée : la surface sur laquelle le personnage se tient à cet instant.
Lorsqu’un pied entre en phase d’appui, la nouvelle couche enregistre son point de contact dans les coordonnées locales de l’objet qui le soutient. Sur un sol statique, le pied reste en place pendant que le corps bouge. Sur une plateforme mobile, le même point enregistré se déplace avec la plateforme. Un ancrage uniquement dans les coordonnées globales laisserait le pied en arrière.
Le bassin se déplace ensuite dans une plage de hauteur limitée, accessible aux deux jambes, et chaque jambe est résolue vers la cible de son pied. Un premier test a révélé une défaillance subtile : le lissage du bassin à la limite de la portée laissait brièvement un pied flotter sur une pente. Le lissage reste désormais dans la plage réalisable.
La grenouille a révélé une autre erreur de calibration : toucher le point le plus bas d’un orteil ne signifie pas que la plante du pied repose correctement. Sa démo ajuste maintenant un plan d’appui à chaque maillage de pied posé, en calibrant à la fois sa position et sa normale. La régression rendue mesure trois contacts distincts de la plante ainsi que le point le plus bas de la surface pendant toute l’animation Idle.
Le contrôle partagé de l’appui corporel estime le centre de masse à partir de segments corporels pondérés et inclut des charges d’objets portés à titre d’illustration. Les exemples en position debout et en extension l’utilisent pour guider le bassin vers les pieds chargés. Pendant la marche, le planificateur de pas contrôle le transfert de poids anticipé ; une correction statique de centrage sur la zone d’appui ne doit pas contrarier le mouvement planifié. Les diagnostics affichent toujours le centre de masse estimé et les contacts d’appui. La marche signale un Transfert de poids planifié, tandis que l’échelle indique que les forces de préhension ne sont pas encore vérifiées.
La marche a toujours besoin d’informations temporelles. Le jeu fournit un poids pour chaque pied : l’intensité avec laquelle il doit être considéré comme ancré à cet instant. Un pied en phase d’oscillation doit être libéré. Le jeu fournit également l’allure, le déplacement du personnage et le dégagement nécessaire au-dessus de la marche suivante. Ces décisions ne sont pas déduites par le solveur IK.
Placez la clé dans la serrure, puis résolvez la position de la main
Orienter le poignet vers une serrure ne suffit pas. La clé possède une longueur, un axe d’insertion et un décalage de prise. Sa pointe peut manquer la serrure même lorsque le poignet atteint parfaitement sa cible.
Dans la démo, la séquence d’interaction définit la position et la rotation souhaitées de la clé. La prise nous indique où le poignet doit se trouver pour y placer la clé. Le bras est ensuite résolu vers cette pose du poignet. La clé réelle reste attachée à la main résolue, y compris lorsque la position demandée est hors de portée.
L’exemple Cible hors de portée illustre volontairement cet échec. Le membre ne s’étire pas pour donner artificiellement l’impression que la mesure est satisfaisante ; le runtime signale que le personnage doit être repositionné.
Cet exemple comporte des phases d’approche, d’insertion et de rotation définies manuellement. Il ne planifie pas encore la prise des doigts et ne vérifie pas la forme de la clé par rapport à l’espace intérieur de la serrure.
Verser est aussi un problème d’orientation
L’exemple de versement maintient le bec du récipient au-dessus de la tasse tout en inclinant le récipient autour de celui-ci. À mesure que le récipient tourne, la position nécessaire du poignet change. Le même mécanisme de ciblage de la main suit cette pose changeante.
Le flux bleu est un effet visuel activé pendant l’inclinaison. Il ne s’agit pas d’une simulation de fluide. Son rôle ici est de rendre l’alignement visible : sans correction, il manque la tasse ; avec correction, il tombe dans la zone de réception.
Où la correction s’exécute
Dans un jeu, la séquence est la suivante :
Déplacer le personnage → évaluer l’animation → appliquer les décalages de pose → résoudre les contacts avec la scène → mettre à jour les mouvements secondaires → effectuer le rendu.
Le runtime expose cette fonctionnalité par l’intermédiaire de createAnimator, avec une configuration sceneIK facultative. Les jeux transmettent les poids des contacts, les cibles des mains et l’état d’appui au sol à update. Il peut également encapsuler un mixer d’animation Three.js existant.
Chaque rig nécessite une calibration pertinente des pieds et des prises. La correspondance des noms d’os nous conduit au bon membre, mais une articulation de cheville ne correspond pas au dessous d’une chaussure. Cette version utilise un point d’appui calibré par pied ; elle ne modélise pas encore l’ensemble de la zone d’appui allant du talon aux orteils.
Les techniques sous-jacentes possèdent des équivalents reconnus dans l’IK à deux os de Unity et les solveurs IK d’Unreal. Notre implémentation est une petite couche de correction côté moteur, conçue autour des besoins de nos personnages riggés automatiquement.
Ce que nous avons vérifié — et ce qu’il reste à faire
La première phase de vérification comprenait 14 tests numériques et d’intégration, ainsi que huit scénarios rendus et échantillonnés sur 3 840 images. Nous avons vérifié les supports mobiles, le contact avec les pentes, les pistes d’animation constantes, les transformations de coordonnées, les limites de portée et l’intégration de l’animateur au runtime. L’automatisation du navigateur a également comparé le canevas avec les corrections activées et désactivées, et testé la mise en page étroite.
Les mesures vérifient l’erreur entre les membres et leurs cibles. Elles ne prouvent pas que chaque partie du maillage skinné est exempte de collisions, ni que le résultat paraît naturel sur tous les personnages. Les exemples sont volontairement assez simples pour être examinés en même temps que ces valeurs.
Les prochaines couches porteront sur la planification des pas, un meilleur appui des plantes de pied, l’extension de tout le corps, la préhension avec les doigts et des phases d’interaction tenant compte des collisions. La simulation physique des liquides constitue encore un système distinct.
Pour l’instant, le résultat utile est concret : une animation peut conserver son mouvement sous-jacent tandis que ses pieds et ses mains réagissent à la scène à chaque image. Cela donne à un personnage riggé automatiquement un point de départ pour interagir avec le monde qui l’entoure.