Blender pour le jeu video
Le comportement des objets de notre monde
Un objet dans le Game Engine possède généralement une double représentation : d'une part la représentation graphique qui est identique à ce que l'on voit dans la 3D Viewet d'autre part une représentation physique qui est spécifique au Game Engine. Dans le cas de la représentation physique, on parle de modèle physique. Celle-ci est gérée automatiquement par Bullet, le moteur physique du BGE, et détermine le comportement de l'objet dans l'environnement du jeu, c'est-à-dire ses interactions avec les autres objets et personnages. L'ensemble des modèles physiques constitue le Physics World (monde physique) qui est spécifique à chaque scène.
L'affichage de la physique n'est pas visible sauf si l'on active l'option Show Physics Visualization du menu Game dans barre de menu principale. C'est une option de développement (debugging) qui sera souvent indispensable pendant la création du jeu. Alors que le moteur graphique du BGE s'appuie sur l'énorme puissance de calcul des cartes graphiques, le moteur physique tourne uniquement sur le processeur central de l'ordinateur du joueur et la question de l'optimisation est donc déterminante. Beaucoup d'options physiques ont un impact sur la performance du jeu et choisir les bonnes options pour les bons objets est crucial.
Comme nous l'avons vu dans le chapitre précédent, l'utilisation du moteur physique est indispensable pour toute détection de contact ou de collision.Créer une réalité avec les types de physique d'objet
Nous créons donc véritablement une simulation de monde : l'enjeu va être de lui donner assez de "réalité" pour que le joueur y croit, et que l'immersion dans l'univers du jeu ne soit pas cassée, tout en demandant au moteur physique le minimum de calculs, ce qui nous garantit une fluidité de jeu. Un jeu trop gourmand devenant injouable, à cause des ralentissements qu'il provoque, retombe sur le même défaut : le joueur "décroche" parce que l'immersion ne fonctionne plus et qu'il est distrait par le problème technique.
Nous visons donc un compromis technique : juste assez de réalisme physique pour donner l'illusion que le monde est crédible ! Pour cela, nous devrons choisir avec attention le "type" de physique que nous attribuons à chacun de nos objets.
Afin de définir le meilleur type possible, il est important de bien définir à l'avance ce que l'on attend de l'objet en question. Par exemple :
- L'objet est-il un élément qui intervient dans le jeu ?
- L'objet fait-il partie de l'interface ?
- L'objet est-il un élément de décor ?
- Est-ce un personnage ?
- L'objet doit-il pouvoir être déplacé, et si oui avec quelle méthode ?
Les options physiques se trouvent dans l'onglet Physics de l'éditeur des propriétésProperties. Le point de départ est le type d'objet (Physics Panel> Physics Type), qui va changer la façon dont se comportent nos objets.
Des objets indépendants et sans interactions avec No Collision
Ce type est le plus simple : l'objet n'a aucune représentation physique. Cela signifie qu'un tel objet ne peut interagir avec aucun autre objet du jeu, car il est "invisible" au moteur physique. Exemples d'utilisation typiques : affichage d'information, détails graphiques secondaires, version high poly (maillage dense) d'un objet dont on utilise une version low poly (maillage léger) pour le moteur physique.
Des éléments de décor avec une physique Static
Nous utiliserons ce type pour des objets immobiles ou animés qui ne sont pas influencés par les autres objets de l'environnement. Exemple : le sol et les murs d'une pièce ou un ascenseur.
D'un point de vue technique, on peut considérer que ces objets ont une masse infinie : aucune force ne peut les faire bouger. En particulier, ils sont insensibles à la gravitation. En pratique, cela veut dire que ces objets ne bougent que s'ils sont animés ou déplacés à l'aide d'actuators ou de scripts Python. Le moteur physique tient compte de leurs nouvelles positions pour calculer les effets sur les autres objets.
Attention, il y a des optimisations du moteur physique spécifiques aux objets statiques. L'une d'elles est que les objets statiques ne se collisionnent pas entre eux : une collision éventuelle ne provoque aucun effet, et il n'est donc pas possible de détecter le contact d'un objet statique avec un autre objet statique.
Des objets mobiles en type Dynamic
Ce type s'applique à des objets qui ont une masse et peuvent bouger sous l'effet de la gravité ou de forces, mais ne peuvent pas tourner ou basculer, du moins pas sous l'effet des contacts avec les autres objets du monde physique. Plus précisément, ils restent parallèles à eux-même tant que l'on ne leur impose aucune rotation via d'une brique logique ou via Python.
Ce n'est donc pas un comportement physiquement réaliste, mais c'est utile pour les objets de type joueur ou PNJ* (Personnage Non Joueur) qui a priori ne doivent pas basculer, ou des objets secondaires tels que par exemple, une caisse ou un tonneau que le joueur peut pousser mais qui ne se renverseront pas.
Le fichier dynamics.blend montre ce genre d'objet en action.
Des objets réalistes avec la physique Rigid Body
Ce type d'objets est le plus physiquement réaliste : ils roulent et basculent comme les objets réels. Ils sont aussi les plus coûteux en calculs. À n'utiliser que pour des détails qui rendent le jeu réaliste : par exemple des projectiles rebondissant sur les murs de la salle, ou les briques d'un mur qui s'écroulent (attention, très gourmand en calcul !).
Ils sont explicités dans le fichier rigidbodies_vaults.blend
Des objets mous avec Soft Body
La physique Soft Body convient pour des objets mous, par exemple des tissus ou des choses organiques, qui se déforment sous un impact.
À utiliser avec précaution car ce type d'objets a de nombreuses limitations :
- Techniquement, le moteur physique considère ces objets comme des surfaces déformables et non pas comme des volumes mous. Cela convient pour une tenture mais beaucoup moins pour une masse molle.
- Aucune détection n'est possible sur ces objets : ils collisionnent avec l'environnement mais les détecteurs ne les voient pas.
- Ils n'ont pas de position ni d'orientation précise.
- Ils ont la fâcheuse tendance à traverser les sols !
L'exemple softbodies1.blend montre l'utilisation pour un tissu.
L'exemple softbodies2.blend montre une utilisation pour des objets gélatineux.
Des objets occultant avec Occlude
Ce type d'objets fait partie des options avancées d'optimisation que nous ne décrirons pas ici.
Référez-vous au chapitre Ignorer les objets hors champ de la section Travailler le rendu du jeu pour voir cet aspect plus en détail. Sachez juste qu'un objet de type Occlude cache les objets qui sont derrière lui et évite d'envoyer au moteur graphique les objets qui sont ainsi entièrement cachés.
Des objets détecteurs d'autres objets avec Sensor
Plus haut, nous avons dit que les objets statiques ne peuvent pas entrer en collision entre eux pour des raisons d'optimisation. Cependant, les objets de type Sensor sont semblables aux objets statiques (ils ne sont pas soumis à la gravité) tout en étant capables de détecter les objets statiques et dynamiques. Ces objets sont uniquement utilisés pour la détection : ils n'opposent aucune résistance et seront en général rendus invisibles.
Exemples d'utilisations :
- Une zone de détection de passage dans le jeu (comme une porte).
- Une ou plusieurs zones de "contacts" autour du joueur, par exemple pour détecter à quel endroit celui-ci est touché par un projectile lancé par des ennemis. Dans ce cas nous définirons plusieurs objets Sensors parentés au joueur, par exemple un pour la tête, un pour le torse et un pour les jambes. Un système de scoredéduira plus ou moins de points suivant le sensorqui aura détecté le contact avec le projectile. Un autre exemple est d'avoir un sensor qui définit à partir de quelle distance les PNJ* (ou seulement les ennemis) repèrent le personnage joueur.
Dans le fichier dynamics.blend, la sortie est un sensor qui met fin au jeu.
Définir un chemin de déplacement avec Navigation Mesh
Un objet de type Navigation Mesh (abrégé NavMesh) est utilisé pour la navigation des PNJ. Il sera associé à un autre objet et lui servira de carte de manière à l'aider à trouver un chemin dans un niveau. Nous traiterons plus amplement de l'utilisation de cette option dans le chapitre Recherche de chemin automatique à la fin de cette section.
Des personnages avec la physique Character
Le type Character est spécialement conçu pour les personnages joueurs et non joueurs (PNJ) : le moteur physique applique une mécanique simplifiée qui évite de nombreux soucis, comme par exemple traverser le sol. Le chapitre suivant est entièrement dédié à ce type très important pour beaucoup de jeux.
Modifier la physique dans le détail, avec les options des types d'objets
Les objets physiques ont plus ou moins d'options, suivant le type utilisé, qui nous permettront d'affiner leur comportement.
Définir la masse de nos objets, avec l'attribut Mass
Ce réglage nous permet de définir la masse d'un objet dynamique, son unité est le kilogramme. Plus un objet a de masse, plus il est lourd, ce qui va bien sûr modifier la façon dont il va réagir à certaines forces du monde ou d'objets environnants.
Des objets "fantômes" avec la case à cocher Ghost
Lorsque l'option Ghost est activée, l'objet permet à la logique de collision de fonctionner mais la collision ne produit pas de résultat visible. L'objet ne renvoie alors aucune force aux objets avec lesquels il entre en collision. Autrement dit, la collision ne produit pas de choc, et les autres objets passent au travers des objets Ghost.
Il ne faut pas confondre cette option avec le type No Collisioncar l'objet est présent dans le monde physique et peut donc être détecté par des Sensors de collision (rappelez-vous, il y a collision même si celle-ci ne produit aucune force).Nous utilisons rarement l'option Ghost pour des objets statiques, car le type Sensor est normalement plus adapté et déjà tout prêt. Nous nous en servons donc plutôt pour des effets sur des objets qui ont déjà des physiques plus complexes. Ainsi, un exemple d'utilisation est l'effet passe-muraille : le personnage joueur acquiert temporairement un super pouvoir qui lui permet de traverser un obstacle, il va retrouver sa physique habituelle, mais temporairement il n'entre plus en collision avec le monde.
Vous l'aurez deviné, en Python les objetsSensorssont d'office de typeGhost.# True rend l'objet invisible pour le moteur physique,# False rend l'objet visible pour le moteur
my_object.game.use_ghost = True
Des objets que l'on heurte mais que l'on ne voit pas avec le bouton Invisible
Cette option désactive la représentation graphique de l'objet : seule la représentation physique existe. L'objet n'est donc pas affiché dans le jeu, mais il peut entrer en collision avec d'autres. Parmi les objets dont la représentation graphique n'est pas souhaitable, on peut citer :
- L'objet low poly (maillage léger) qui représente le modèle physique d'un objet graphique high poly (maillage dense).
- Un volume de détection d'intrusion, typiquement un objet Sensor.
L'invisibilité d'un objet n'est pas définitive. Cette option ne détermine l'invisibilité qu'au moment du démarrage du jeu. Ensuite, l'invisibilité se contrôle grâce à l'actuator Visibility ou grâce à Python :
# True rend l'objet invisible, False rend l'objet visible
my_object.hire_render = True
Des objets détectables avec la case à cocher Actor
L'objet est détecté par les Sensors Near et Radar. Mais cette option est obsolète, car on peut faire mieux et plus finement avec l'option Collision Mask que nous allons expliquer ci-dessous.
Une gestion des collisions plus fine avec les Collision Groupet Collision Mask
Cette série de boutons fait partie des options avancées du moteur de jeu de Blender : Ils permettent de choisir finement quels objets entrent en collision avec quels autres.
L'intérêt d'utiliser les groupes de collision est double :
- Ils réduisent le nombre de collisions parasites détectées par les Sensors.
- Ils réduisent sensiblement le travail du moteur physique, puisqu'il doit calculer moins de collisions.
Les boutons Collisions Group(groupes de collisions) définissent à quel groupe l'objet appartient : c'est nous qui choisissons à notre guise la signification des groupes en sélectionnant des cases. Les boutonsCollision Mask (masques de collision) définissent avec quels autres groupes d'objets notre objet sélectionné peut entrer en collision. Une collision ne peut avoir lieu entre deux objets que si au moins un groupe de l'un est également présent dans le masque de l'autre et réciproquement.
On peut donc définir ainsi des groupes d'objets qui ne réagissent qu'à certains autres groupes (ceux qui sont présents − case enfoncée − dans leurs masques). Par défaut, les objets appartiennent tous au premier groupe et entrent en collision avec tous les masques de groupes. Autrement dit, tous les objets se heurtent. Un cas pratique, pour un personnage joueur, serait par exemple d'avoir un groupe de collision qui détecte les PNJ amicaux, et un autre qui détecte les PNJ hostiles.
Des dynamiques de forces pour les jeux avec des véhicules
Les paramètres de Velocity (vitesse),Damping (amortissement) et Anisotropic Friction (anisotropie frictionnelle) pour les objets de type Dynamicet Rigid Bodyvous permettront d'affiner la physique de vos véhicules, et sont particulièrement utiles dans des jeux de courses de véhicules.
Des détections de collisions optimisées avec lesCollision Bounds
Ce sous-onglet permet de définir la forme exacte du modèle physique de notre objet. Cela veut dire que le modèle physique ne doit pas nécessairement correspondre au modèle graphique. L'idée est de choisir une forme simplifiée pour le modèle physique pour simplifier considérablement le calcul des collisions mais qui correspond suffisamment bien au modèle graphique, pour conserver une cohérence entre les deux.
Des formes physiques simplifiées
Le choix des formes simplifiées est limité : boîte, sphère, cône, cylindre, capsule (un cylindre complété par 2 demi-misphères). Dans le cas de la sphère, le rayon est déterminé par l'option Radius, dans le sous-onglet précédent, en-dessous de l'attribut Mass. Dans les autres cas, le BGE calcule automatiquement la dimension de la forme qui remplit au mieux le volume de l'objet.
Les formes physiques complexes dites de type Mesh
Dans certains cas, une forme simplifiée n'est pas possible, par exemple pour le sol et les murs d'une pièce, ou un objet dynamique de forme complexe. Dans ce cas le modèle physique est dit de type Mesh (maillage) et se rapproche du maillage de l'objet.
Deux types de formes complexes sont disponibles :
- Convex hull : cette forme est appropriée pour des objets dynamiques, car plus simple. Le modèle physique « emballe » le modèle graphique pour former une surface convexe.
- Triangle mesh : à réserver au objets statiques dont c'est par ailleurs le choix par défaut, car le modèle physique va reproduire exactement le modèle graphique. Il y a donc la meilleure précision possible au prix de plus de calculs, d’où l'importance de simplifier au maximum le maillage de l'objet lorsque l'on choisit ce type.
Corrigeons les imperfections avec une marge sur notre modèle physique
Quelle que soit la forme, simple ou complexe, nous pouvons de plus jouer sur le paramètre Margin: c'est une épaisseur qui est ajoutée sur toute la surface du modèle physique pour l'augmenter. Cette marge nous permet de corriger les imperfections du moteur physique. Le but principal est d'éviter qu'un objet de petite taille ne passe à travers une paroi s'il est animé d'une grande vitesse. Par défaut la marge vaut 0.06, soit 6 centimètres. Mais il faut bien constater que le paramètre Margin ne résout pas tout : s'il y a vraiment un problème physique, il faudra probablement changer le type de physique de notre objet, ou jouer avec les groupes de collisions, comme nous l'avons vu plus haut.