Manière courante d'animer le «mouvement» pour les animations de cycle de marche

Je viens de poster ceci sur les forums d'artistes de Blender avant de réaliser que j'obtiendrais probablement une meilleure réponse d'un public plus spécifique au développement de jeux, donc excuses pour la publication croisée! C'est pour les bonnes raisons :)

Je suis un programmeur essayant d'animer un personnage marchant pour un projet de jeu, en utilisant Ogre. J'ai fait un cycle de marche très simple dans Blender et je l'ai exporté vers Ogre, et ça fonctionne très bien. Enfin, je veux dire que cela fonctionne, mais il y a un terrible glissement du pied. C'est parce que je viens d'animer la marche sur place (à l'origine) dans Blender, et bien sûr je ne sais pas à quelle "vitesse de marche" cela correspond, donc quand je déplace le personnage dans le jeu le mouvement ne marche pas ' t nécessairement correspondre avec le mouvement des pieds dans l'animation.

Donc ma question est: quelle est l'approche normale pour ce genre de chose? Au travail, nous utilisons Maya, et les animateurs animent un nœud spécial 'moveTrans' qui représente la "position" du personnage (ou demandent à l'exportateur de le générer pour eux à partir du mouvement du nœud racine), alors le jeu peut lire ceci pour savoir à quelle vitesse l'animation déplace le personnage. Ainsi, dans le fichier Maya, le personnage avancera pendant un cycle et ce nœud supplémentaire les suivra par ses pieds. Je n'ai rien vu de tel dans un pays open-source, et il n'y a certainement aucune disposition pour cela dans le script Ogre Exporter. Que faites-vous normalement les gars pour cela?

Il y a deux façons de le faire: le mouvement racine ou "dans le code".

Avec le mouvement racine, vous avez essentiellement exactement ce que vous proposez avec le nœud "moveTrans". Vous utilisez le mouvement de cet objet pour déterminer la vitesse de lecture des cycles de marche. Vous pourriez être en mesure de faire une recherche inversée de toutes sortes pour comprendre que si vous voulez être à la position X, quelle image vous devez être. Mais le véritable avantage du mouvement racine est que pour obtenir des animations vraiment réalistes, vous devez tenir compte du fait que le mouvement n'est pas un véritable chemin linéaire. Les vraies personnes se déplacent à une vitesse variable dans le temps, ou peut-être qu'elles changent un peu de gauche et de droite, ou autre chose.

Mixamo a fait un bon exemple avec le contrôle de mouvement racine en utilisant Unity. Il y a une vidéo de celui-ci ici: http://vimeo.com/12052874

Maintenant, le mouvement racine a ses inconvénients. Cela peut devenir délicat avec des choses comme essayer de faire fonctionner l'animation "marche" dans les escaliers (idéalement, vous auriez un animateur d'escalade / échelle séparé et feriez tout le mouvement pour cela dans l'animation également). Je ne suis pas non plus vraiment sûr de savoir comment IK y joue vraiment, voire pas du tout.

Maintenant, le faire "dans le code" est beaucoup plus facile du côté de la programmation. Ce que je suggère de faire, c'est d'abord de s'assurer que toutes vos unités sont cohérentes. Par exemple, 1 unité en Maya et votre jeu fait 1 mètre. Ensuite, vous demandez à vos artistes d'animer un personnage qui marche (avec un mouvement vers l'avant). Utilisez-le pour déterminer la vitesse de l'animation et exporter l'animation sans la vitesse vers l'avant. Utilisez-le pour déterminer la vitesse de lecture de l'animation. Donc, si l'animation de marche à une vitesse de 1x est de 5 m / s et que vous voulez que le joueur tourne à 7 m / s, vous jouez simplement à 7/5 = 1,4x de vitesse. Si votre modèle est agrandi ou réduit, multipliez le taux de lecture de l'animation par l'inverse de l'échelle. Un mec à mi-hauteur devra marcher deux fois plus vite pour se déplacer au même rythme qu'un gars à l'échelle 1x.