Articles taggues ‘collision’

Animation de l’Artillerie

Artillery of WinThatWar!

Original : Fisher Body craftmen

L’animation des véhicules est un savant mélange d’animation faite à la main et d’animation procédurale. C’est par ce dernier type d’animation que j’aimerai commencer, et voici les éléments concernés :

> Le déplacement du véhicule est supporté par le moteur physique du jeu. Ainsi, le véhicule suit l’inclinaison d’une grille virtuelle, un volume de collision, ou plus simplement : un plan déformé, simulant le relief du terrain.

> L’Artillerie a également besoin de pouvoir tirer à différentes portées et de différents angles. Ainsi les articulations concernant la rotation du canon sont animées par le code (ce que nous appelons la « logic ») pour que le tir s’ajuste précisément à la position de la cible par rapport à celle de l’Artillerie.

> Les chenilles de sont elles aussi animées, ce qui permet d’accompagner le mouvement du véhicule. Cet effet est obtenu en déplaçant dynamiquement, en jeu, les coordonnées UV du modèle en fonction de la vitesse de déplacement du véhicule.

Pour rappel : les coordonnées UV sont la correspondance entre coordonnée 3D (xyz) et 2D (uv) qui sert à indiquer où et comment les textures se « dessinent » sur le modèle. Dans le cas des chenilles, on dirait plutôt que les UV « glissent »sur la 3D pour donner l’impression de roulement.

Artillery caterpillar continuous track

Toutes les autres animations sont gérées en amont par l’animateur.

L’animateur a donc la liberté d’utiliser toutes les autres articulations qui sont à sa disposition, à l’exception des 2 articulations gérées par le moteur que nous avons abordées plus haut : rotation horizontale de la tourelle et soulèvement vertical du canon.

Dans le cas de l’artillerie, voici les  éléments créés « à la main », avant que la « logic » n’intervienne :

> L’animation de l’installation. Le moment où le véhicule se met en position de siège est assez lent, et transmet bien l’idée d’une arme puissante, qui prend du temps à se préparer mais qu’on imagine destructrice. La désinstallation, elle, est beaucoup plus courte.

> Création de l’amorti et d’une onde qui traverse tout le véhicule au moment où l’Artillerie tire. Cette animation s’achève par le soulèvement des gardes-boue, et sera ensuite synchronisée avec un effet d’onde de choc soulevant de la poussière.

animation joints and curves

 

Vient le moment du tir. C’est là que nous rajoutons l’effet de particule servant à matérialiser le projectile, qui prendra la forme d’une boule de plasma.

Pour finir, l’animation de mort de l’Artillerie est simulée en utilisant un moteur physique, appelé Mass FX. Celle-ci est pré-calculée dans le logiciel de modélisation 3D puis retravaillée par l’animateur pour atteindre le résultat souhaité.

Cette animation est bien sûr accompagnée d’un nuage de fumée et d’une projection de débris tout autour du véhicule. La destruction de l’Artillerie, seule, étant peu impressionnante pour l’oeil du joueur :

dislocation

Cela couvre à peu près l’ensemble de la vie de l’Artillerie. De sa sortie d’usine à sa mort sur le champ de bataille.

Ce post consacré à l’animation constitue la première partie d’un article en deux parties. Le prochain post sera entièrement consacré au Sound Design de l’Artillerie, qui, vous le verrez, se rapporte directement aux différentes animations que nous venons d’aborder.

Physics !

Bonjour à tous !

Ca fait un petit moment que je n’ai rien publié.  C’est que je travaillais sur notre toute nouvelle couche réseau… qui fonctionne enfin. Mais attention c’est Top Secret ! Vous pourrez tester tout ça lors de notre prochaine release 😉

Simulation physique, ok, mais pourquoi ?

La semaine dernière,  j’ai refondu le moteur physique. Dans ce vieux post, en bonus dans la vidéo, vous aviez eu le droit à un premier aperçu de la simulation physique de WTW. Mais commençons du début… A quoi ça sert ?

Dans les jeux vidéo, la simulation physique donne « du corps » aux objets, elle empêche l’interpénétration. Les tables sont posées sur le sol, les murs bloquent les personnages etc. Dans Win That War! nous avons une quantité conséquente de véhicules qui évoluent sur le terrain. J’ai initialement conçu le moteur dans cette optique : gérer des milliers de contrôleurs de véhicules. Pour l’instant pas d’effet spectaculaire, de dynamique ou de débris. Mais c’est prévu pour plus tard ! Je me suis largement inspiré de l’excellent Bullet, qui en plus d’être très performant, est OpenSource.

Voici une vue d’ensemble du fonctionnement d’Insanity.Physics:

Insanity.Physics-Overview

D’abord, on peuple la scène physique d’objets : obstacles et contrôleurs de véhicules. La simulation est itérative et s’exécute 60 fois par seconde. L’IA (path-finding) donne des consignes de vitesse aux véhicules.  Dans une première étape on détecte les collisions entre les objets, c’est-à-dire qu’on trouve les points de contact. Ensuite le « Contact Solver »,  va corriger les vitesses pour diminuer l’interpénétration entre les objets. Les chars freinent pour éviter de s’encastrer les uns dans les autres. Pour chaque point de contact, j’applique une impulsion pour repousser les 2 objets. Si tout un groupe est en collision, le solver converge vers un état ou l’interpénétration est minimale pour chaque membre du groupe. Une fois les vitesses corrigées, on en déduit les nouvelles positions et on passe à l’itération suivante.

La détection des collisions est la partie la plus complexe de la simulation :

Insanity.Physics.Collision-Overview

 

Elle est découpée en 2 phases (Broad et Narrow). Le but de la broad phase est de trouver toutes les paires d’objets potentiellement en contact. Pour chaque objet, on utilise une boite alignée comme approximation pour simplifier les tests. Si 2 boites se recouvrent les objets sont peut-être en collision. C’est la partie la plus gourmande en temps de calcul de la simulation. Une broad phase « naïve » consisterait à faire tous les tests possibles , soit un million de tests pour 1000 objets (complexité en O(n²)), ce qui est trop lent dans la pratique. Il existe de nombreux algorithmes de broad phase, dont notamment « Sweep and Prune » ou SAP, utilisé dans la plupart des moteurs physiques. Une fois les paires potentiellement en contact trouvées, c’est la narrow phase qui va tester si les objets réels contenus dans les boites sont effectivement en collision et trouver les éventuels points de contact. En général c’est une collection d’algorithmes. Il est très simple de trouver l’intersection entre 2 sphères. Mais s’il s’agit d’une boite et du terrain, il faut autre chose… J’utilise XenoCollide, pour les tests complexes.

Enfin, dernière mission du moteur : les requêtes géométriques. A tout moment on peut lancer un rayon dans la scène physique et savoir quels objets il touche. On utilise ça, notamment, pour la sélection à la souris. Il est aussi possible de demander ce qui intersecte avec n’importe quelle forme convexe. Pour la détonation des missiles,  c’est ce type de requêtes avec une sphère qui est utilisée.

Pour conclure, voici une petite vidéo qui montre l’affichage de debug de la physique. Comme vous le constaterez ça tourne plutôt bien, même avec plus de mille unités !

Sur la vidéo, on voit bien les boites de la broadphase en rouge, les formes de collision en blanc (que des sphères pour les vehicules), le terrain en jaune. Les différentes lignes rouges sont les lancés de rayons utilisés pour placer les véhicules sur le terrain, mais aussi par les ingénieurs  pour savoir s’ils peuvent syntoniser. L’affichage de debug fait beaucoup ralentir (des dizaines de milliers de lignes à afficher) d’où les saccades en début de vidéo.

Voilà, c’est tout pour aujourd’hui !

Doom

Haut de Page