Gestion de détails en milieu urbain - Ikooko Studio

Gestion de détails en milieu urbain
DEMAY Nicolas
Etranges Libellules
R&D Outils
Tuteur : AYMARD Cyril
Rapport de Stage
IMAC 2
Du 11/06 au 14/09
Année Scolaire 2006-2007
Résumé
Ce rapport de stage retrace mon expérience vécue au sein de l’entreprise Etranges
Libellules au cours de l’été 2007. Le but de ce stage était de réaliser la gestion de détails
en milieu urbain. Les notions abordées sont principalement la physique des fluides et des
solides avec les équations de Navier-Stokes et la physique de Newton. Je vous présenterai
aussi ma solution basée sur un solveur de type « Stable Fluid » développé par Jos Stam.
Ce rapport vous présentera aussi les diverses technologies utilisées par l’entreprise et plus
principalement K et Kal. Vous y trouverez également les diverses idées ainsi que les choix
techniques que j’ai réalisés au cours de ce stage. Mais aussi les diverses conclusions que
j’ai faites que ce soit au niveau technique ou humain. Abstract
This report of training course recalls my experiment lived within the company Etranges
Libellules during the summer 2007. The goal of this training course be to carry out the management of details in urban environment. The concepts approached are mainly the physics
of the fluids and the solids with the Navier-Stokes equations and the physics of Newton. I
would present also my solution based on a solver of the type “Stable Fluid” developed by
Jos Stam. This report will present also various technology used by the company and more
mainly K and Kal. You will find in this report various ideas as well as the technical choices
which I carried out during training course. But also various conclusions which I made that is
at the technical or human level. Sommaire
Résumé
Abstract
Sommaire
Introduction
1.Présentation de l’entreprise
1.1. Historique
1.2. Organisation Interne
1.2.1. Déroulement des étapes de production d’un jeu-vidéo (exemple Astérix)
1.3. Secteur d’activité
1.4. Outils Logiciel : K et KAL
2. Gestion de détails : état de l’art
2.1. Introduction à la gestion de détails
2.2. Présentation de K et Kal et de leurs fonctionnalités
2.2.1. Concept généraux de Kal
2.2.2. KCore
2.2.3. Outils utiles dans Kal
2.3. Etat de l’art et orientation du stage
3. Cahier des charges et planning
4. Premières idées et premiers essais
4.1. Le système météo : le vent
4.1.1. Principe et idées générales
4.1.2. Implémentation de l’exemple
4.2. Idées et algorithmes en vrac
4.2.1. Déformations d’objets
4.2.2. Pluie, son et lumière
5.1.1. Navier-Stokes
5.1.2. “Stable Fluid”
5.1.3. Physique Mécanique
5. La dynamique des fluides, la physique mécanique et Kal
5.1. Théorie et Algorithme
5.2. Implémentation
5.2.1. Modèle de classe
5.2.2. IHM et objets implémentés
5.3. Résultats, limites et avenir
6.2. Humain
6. Bilan
6.1. Technique
Conclusion
Bibliographie
Annexes
I.Chaîne de Production
II. Image de la Démo ATI ToyShop
III. Simulation avec une force temporelle
IV. Evolution de la FluidBox au cours du développement
1
2
2
2
3
6
7
10
10
11
11
11
12
13
15
17
17
17
19
20
21
22
23
23
23
24
26
27
27
30
32
36
36
37
38
39
41
42
43
44
45
Introduction
Je souhaitais trouver un stage dans le domaine du jeu vidéo ou du cinéma d’animation
afin de me rapprocher de ce qui me plaît le plus dans la formation à savoir l’imagerie numérique composée plus particulièrement de la 3D et du temps réel. Si je me suis orienté
vers l’IMAC, c’est principalement pour pouvoir faire du développement de jeu vidéo ou du
développement dans la R&D1 pour le cinéma d’animation.
Mes expériences précédentes se sont toujours déroulées dans le milieu du Web
(stage assistant chef de projet Web chez Skandia en 2006, stage infographiste chez Maïdo
Production en 2005 etc.) et je souhaitais vraiment changer et apporter à mon CV une autre
expérience professionnelle que celle offerte dans le domaine du Web. En effet les stages
dans ce domaine relèvent plus de la production et n’ont pas d’autres intérêts que l’approche
humaine du travail en entreprise. C’est pour cela que je souhaitais intégrer une équipe de
R&D afin d’entrer dans un tout nouveau milieu et d’apprendre de nouvelles compétences.
Malheureusement il est très difficile de trouver un stage dans ce domaine pour une
durée maximum de 3 mois et demi. Mais la société Etranges Libellules proposait un stage
en R&D outil et a bien voulu m’accueillir pour une durée de 3 mois.
L’intitulé du stage est donc gestion de détail en milieu urbain en R&D outils. Ce terme
signifie que le but est de développer un outil utilisable par l’entreprise pour ensuite l’intégrer
dans différents jeux. La gestion de détail concerne la possibilité de faire bouger et réagir
divers petits ou moyens objets du décor en fonction de divers événements.
Tout au long de ce rapport, je vous expliquerai les différentes idées ainsi que la solution que j’ai mise en œuvre pour gérer ces détails. Ce rapport suivra le plan suivant, nous
vous présenterons tout d’abord l’entreprise qui m’a accueillie, à savoir Etranges Libellules.
Puis, nous ferons un état de l’art sur les différentes technologies approchées. Pour ensuite
voir le planning et les premières idées ainsi que l’implémentation, à proprement parlé, de
notre système. Enfin nous ferons le bilan de ce stage avant de conclure.
1
Recherche et Développement
0
1
1. Présentation de l’entreprise
1.1. Historique
Etranges Libellules a été fondée en 1994 et se concentre sur la création graphique.
Elle participe alors au succès de nombreux titres tels la série des Alone in The Dark, VRally, Need For Speed, Devil Inside, Arx Fatalis.
En 1997, Etranges Libellules se tourne vers le développement de jeux et lance la collection Gunul et Cléo en 1999. Kirikou -PSX PC- en 2001 ; La Panthère Rose – PSX PC- en
2002 en Europe et en 2003 USA et Japon. Suivent Astérix XXL sur PS2, Game Cube et PC
en 2003 et 2004 puis Astérix XXL2 : Mission Las Vegum PS2 et PC en 2005.
En 2006, Etranges Libellules a été choisie par Luc Besson pour réaliser les jeux
vidéo basés sur son film d’Animation Arthur et les Minimoys. Pour l’occasion Etranges Libellules a installé un studio à Paris et travaille en étroite collaboration avec les équipes du
film.
Aujourd’hui Etranges Libellules prépare d’autres jeux encore confidentiels sur DS, PSP
(PlayStation Potable), Xbox360, Wii, PS3, PS2 et PC.
La grande force d’Etranges Libellules est d’avoir su mettre en place une chaîne de
production efficace pour produire des titres de très grande qualité sur les plateformes actuelles et à venir.
Etranges Libellules est dirigée par Jean Marie Nazaret, fondateur de la société et par
Edith Protière qui dirigea pendant 10 ans un studio de production au sein d’Infogrames /
Atari.
1.2. Organisation Interne
Un studio de développement de jeu vidéo est composé de multiples corps de métier
que l’on peut regrouper en 3 parties.
Tout d’abord les graphistes. Ce sont eux qui prennent en charge la réalisation de
tous les objets que l’on voit à l’écran, à savoir les décors, les personnages, les interfaces ou
encore les vidéos.
0
2
Il y a aussi les codeurs et designer. Ce sont les personnes qui « design » le jeu et
les niveaux (on parle de game-designer et de level-designer). On parle aussi de « codeur
scénarique » car ce sont eux qui créent l’histoire à l’intérieur du jeu. Ils développent les
comportements des ennemis et du personnage, les mécanismes de jeu, les bonus, etc. Ils
ont pour responsabilité toute la partie «Gameplay2» qu’ils codent grâce au logiciel et aux
plug-ins développés par les programmeurs.
Nous avons donc enfin les programmeurs qui, quant à eux, doivent développer les
outils nécessaires aux codeurs pour réaliser le ou les jeux. En effet, les programmeurs
développent des outils qui seront communs à différents projets et d’autres qui seront bien
spécifiques à un seul jeu.
Il y a évidemment différents postes à l’intérieur de ces 3 domaines comme par exemple ceux qui réalisent les vidéos, ceux qui s’occupent des animations des personnages,
les graphistes qui s’occupent de réaliser les textures, les level-designer, les programmeurs
en R&D et bien d’autres encore.
Mais ces 3 domaines sont les plus importants avec bien évidemment le dernier qui
est le domaine administratif, RH, comptabilité, administration réseau et secrétariat.
Cela fait donc beaucoup de monde pour réaliser un jeu vidéo. Les domaines sont
très variés puisqu’ils passent par l’enregistrement de son, le montage vidéo, le codage en
langage de programmation, l’utilisation d’outils graphiques 2D et 3D ainsi que la réalisation
du jeu sous le logiciel adéquat.
1.2.1. Déroulement des étapes de production d’un jeu-vidéo
(exemple Astérix).
La première étape pour réaliser un jeu vidéo est de réunir les idées. En effet, il
faut imaginer l’univers (décors, personnages, monstres) ainsi que les phases de gameplay
(niveau sous-marins, aérien, nouveau style de combats). Durant cette étape du développement, toutes les équipes peuvent participer et fournir des idées. Elles seront ensuite validées par le réalisateur du jeu vidéo comme pour un film.
Une fois l’univers validé, il faut passer des illustrations et des schémas 2D aux personnages 3D. Il faut aussi commencer à développer les outils pour gérer les différentes
phases de gameplay.
2
D’après la définition des Cahiers du cinéma, « concept omniprésent dans le monde du jeu vidéo, le game play est la
manière dont un jeu implique celui qui s’y adonne. D’un jeu très beau mais peu prenant, on dira que ses concepteurs en
ont négligé le gameplay ». Ou ailleurs : « le moteur d’un film, ce sont les images. Dans un jeu vidéo, le moteur émotionnel qui fait que le joueur reste devant le jeu c’est le gameplay, qui est déjà un scénario en soi : il propose un objectif,
vous donne les moyens de l’atteindre et place des obstacles devant votre route ». 0
3
Les graphistes ont donc la charge de créer, texturer et animer les personnages ainsi
que les décors. Tandis que les programmeurs développent des outils tels que les potions,
les comportements des romains ou encore les divers mécanismes du jeu.
C’est alors aux codeurs d’entrer en action. Ils font les réglages sous le logiciel de
développement (régler les niveaux des potions, le pathfinding3 des romains et les liaisons
entre les différents mécanismes.) Ils construisent littéralement les niveaux en ajoutant les
personnages dans les décors en créant les différentes étapes de jeu.
Une fois ces étapes réalisées, le jeu passe en phase de débogage. Cela signifie qu’il
va être testé par les testeurs internes mais aussi par l’éditeur et par les différentes équipes
afin de trouver les divers bugs et améliorations que l’on pourrait apporter. Vous trouverez
ci-dessous une représentation schématique de la chaîne de production d’un jeu vidéo chez
Etranges Libellules.
Le schéma suivant vous montre clairement comment un jeu vidéo est produit.
0
4
3
La recherche de chemin, couramment appelée pathfinding, est un problème de l’intelligence artificielle. Il consiste à
trouver comment se déplacer dans un environnement entre un point de départ et un point d’arrivée en prenant en compte
différentes contraintes.
0
5
Chaine de Production d’un jeu vidéo
1.3. Secteur d’activité
Le secteur du jeu vidéo regroupe principalement 2 types d’entreprises principalement.
Les studios de développement qui conçoivent et réalisent les jeux. Leur production
est un exemplaire unique, le master, qu’ils vendent avec les droits associés à un éditeur. Les
studios sont à la fois des entreprises de création et des centres de recherche-développement. Ils sont généralement des PME (de 5 à 200 personnes), indépendantes ou intégrées
à des sociétés éditrices.
Les éditeurs sont chargés de la production (au sens du cinéma : initiative, financement, détention des droits de propriété intellectuelle), du marketing et de la promotion. C’est
leur label (Electronic Arts, Ubisoft) qui figure sur les jeux.
Il y a aussi les fabricants de consoles qui sont d’abord des industriels de l’électronique.
Ils conçoivent un système informatique dédié au jeu vidéo, le font fabriquer (Microsoft) ou
le fabriquent eux-mêmes (Sony), en assurent le marketing et la distribution. Ils exercent de
plus une activité d’éditeur.
4
ELB est un développeur de jeux vidéo, la plupart de ces titres ont été édités par
Atari.
Mon stage s’inscrit donc dans le domaine du jeu vidéo mais plus particulièrement
dans le secteur R&D. En effet, il ne s’agissait pas d’aider à la conception d’un jeu vidéo en
particulier mais bien d’aider à développer de nouveaux outils pour réaliser des jeux vidéo.
La tâche n’est donc pas la même.
La R&D du jeu vidéo se compose aussi en 2 pôles. Un pôle de développement
d’outils logiciels ou plug-in pour aider à la production comme par exemple le développement
de plug-in pour Maya ou d’outils de compression de fichier.
Le deuxième pôle, lui, est consacré au développement de ce que l’on appelle « le
moteur » du jeu vidéo. Ce moteur va donner tous les outils et permettre de créer le monde
du jeu (graphisme, mécanisme de jeux, physique, son, etc.…). Ce moteur a aussi pour
tâche de faire fonctionner le jeu sur les différentes plateformes. (Les plateformes, ce sont
les consoles sur lesquelles est commercialisé le jeu.) Or, 3 nouvelles plateformes sont sorties ces 2 dernières années et elles demandent donc un nouveau moteur. Cela signifie qu’il
y a beaucoup de travail dans le domaine de la R&D dans les jeux vidéo en ce moment.
4
ELB : Etranges Libellules
0
6
1.4. Outils Logiciel : K et KAL
ELB a développé sa propre chaîne de production. C’est-à-dire que l’entreprise a
elle-même développé son moteur et son éditeur respectivement appelés « K » et « KAL
». Ce dernier est donc à première vue un logiciel de création de jeux vidéo permettant
d’importer, modifier, configurer des personnages et d’autres objets 3D. Le but est de simplifier l’intégration et le suivi des ressources graphiques, sonores et scénariques. L’idée est
simple, l’éditeur scénarique fonctionne “sur” le moteur de jeu en utilisant et paramétrant
toutes ses fonctionnalités en temps réel. Cette architecture rend beaucoup plus souple le
réglage du jeu. Elle permet de coder/tester/régler tout en jouant.
Lorsque le jeu est en édition, l’éditeur scénarique (KAL) est directement branché
sur le moteur du jeu (K). L’interface graphique de KAL permet d’éditer intuitivement les
paramètres du moteur (K) et ce alors même que le jeu est en train de “tourner”. Le moteur
(K) et son éditeur (KAL) peuvent accueillir des extensions (plugins). A chaque K-plugin correspond un KAL-plugin permettant l’édition intuitive de ses paramètres.
KAL intègre aussi des outils de retouches simples (édition d’objets, de faces, de vertex d’UVs, etc.) pour éviter de trop fréquents “aller-retour” avec les logiciels de création de
ressources graphiques et sonores. Le but n’est pas de réinventer un logiciel de création 3D
ou sonore mais encore une fois d’optimiser et d’assouplir la chaîne de production.
Le schéma ci-après vous montre le comportement de K et Kal en mode édition.
0
7
K et Kal en mode édition
0
8
Lorsque le jeu tourne sur une plateforme, l’éditeur scénarique (KAL) et ses plugins
sont tout simplement “débranchés”. Le moteur du jeu (K) et ses plug-ins continuent de fonctionner normalement.
0
K en mode runtime
K et Kal sont donc les outils principaux de réalisation au sein de l’entreprise ELB. Mais
bien évidemment d’autres logiciels de création 3D ou 2D sont utilisés tel que Maya, Photoshop ou encore After Effect. Il y a aussi des logiciels de création sonore comme CoolEdit
et SoundForge. En ce qui concerne la programmation, c’est Visual C++ qui est utilisé. Les
postes de travail sont équipés en Windows Xp et en réseau. Les serveurs sont gérer avec
Unix Debian et pour des raisons de confidentialité, les postes utilisateurs n’ont pas accès à
internet, seul 5 postes spécifiques et en libre service ont accès au web en plus de ceux des
chefs d’équipe.
Maintenant que nous avons vu l’environnement technique et humain de l’entreprise
nous allons passer plus en détail sur déroulement du stage, c’est-à-dire les différentes recherches et les développements réalisés.
9
2. Gestion de détails : état de l’art
2.1. Introduction à la gestion de détails
Le stage s’intitule donc gestion de détails en milieu urbain. Il faut donc séparer et
analyser ce qu’est la gestion de détails et ce qui correspond au milieu urbain.
Tout d’abord, la gestion des détails, c’est la gestion du comportement de tous ces
objets de petite ou moyenne taille qui font partie du décor et qui rendent la scène plus réaliste et convaincante. Le milieu urbain est là pour caractériser et mieux définir ces objets.
En effet, ici nous aurons principalement des objets comme des canettes, des feuilles, des
poubelles, des arbres, des fontaines, etc.
Le but de ce stage est donc de pouvoir configurer le comportement du décor, de
l’environnement pour le rendre plus dynamique, plus réaliste pour le joueur. La question
est donc de savoir comment configurer cet environnement ou plutôt configurer cet environnement par rapport à quoi ? A quelles valeurs ?
La solution est d’utiliser un système physique qui pourrait simuler divers événements
auxquelles réagiraient ces objets. Celui-ci pourrait être spécifié en un système météo où les
événements seraient le vent, les précipitations et la température. Mais un tel système demande que chaque objet ait un comportement bien différent (l’écoulement et les jets d’eau
d’une fontaine, les différents types d’éclairage pour les enseignes, les mouvements d’un
drapeau sous l’effet du vent.)
Les compétences pour mettre en place un tel système sont très diverses et variées.
On retrouve la géographie, la physique, l’aérodynamique, la biologie. Pour la suite du
stage, nous allons principalement nous attarder sur les domaines liés à la physique et à
l’aérodynamique.
Nous avons aussi une contrainte supplémentaire qui est le fait que nous développons pour le domaine du jeu vidéo et que cette gestion de l’environnement a pour vocation
de pouvoir s’effectuer en temps réel.
De nombreux aspects de cette gestion de détail ne seront pas présentés dans ce
rapport car nous n’avons pas pu tout essayer. Mais ces aspects ne sont pas à négliger et
des fonctions telle que la gestion de l’éclairage ou encore la gestion des bruitages peuvent
apporter beaucoup de réalisme et de dynamisme à ces petits objets du décor.
1
0
2.2. Présentation de K et Kal et de leurs fonctionnalités
2.2.1. Concept généraux de Kal
Voici les termes couramment utilisés dans KAL :
Les objets : ce sont tout simplement tous les éléments visibles par le joueur,
c’est tout ce qui possède une représentation graphique dans Kal : les personnages, les
objets du décor, les items, etc.
Les vies : ce sont les comportements que l’on peut attribuer à un objet afin
qu’il puisse effectuer des actions au cours du jeu. Ces vies peuvent avoir de multiples
fonctions : déplacer l’objet (le héros, les ennemis), modifier un objet en temps réel (un
émetteur de particules), etc.
Les groupes : ils permettent de regrouper des objets afin de pouvoir effectuer des actions communes sur l’ensemble de ces objets, ou plus généralement de
regrouper les objets par zones dans l’espace afin de pouvoir effectuer des traitements par
lots plus facilement (dans le cas des collisions par exemple).
Les entités: chaque entité est une façon de percevoir un projet Kal. Les entités les plus courantes sont :
- L’entité objet : l’entité par défaut qui permet de travailler sur les
objets et les vies.
- L’entité vertex5 : permet de travailler sur les vertex des géométries
des objets. Dans ce mode, on peut créer/supprimer/modifier
des vertex
- L’entité face et l’entité edge : Même chose que pour l’entité vertex
2.2.2. KCore
KCore est le noyau de K. Il s’occupe de la boucle de jeu et introduit les notions de
modules, services, groupes, vies, Hooks et composants. Il contient toutes les briques qui
permettront d’ajouter des fonctionnalités à K que ce soit sous la forme de modules multiplateformes ou de plugins de vies ou de groupes.
Le module est une brique sur laquelle s’appuie K pour fonctionner. Ces modules
implémentent la gestion des autres notions telles que les services, le graphisme, les sons,
les interactions de l’utilisateur et bien sur la boucle de jeu.
5
Un sommet dans le langage infographique
1
1
Le service permet d’avertir un objet qui s’est référencé auprès de lui d’un changement. Tous les objets de KCore ont aussi la possibilité de faire des requêtes directes au
service. Les services seront par exemple : le service collision, le service déclenchement,
etc.
Les groupes ont pour but de ranger les Hooks et de définir quelles sont les vies
que l’on peut attacher aux Hooks du groupe. Les groupes sont organisés de manière
hiérarchique, assimilable à une dérivation. C’est à dire qu’un groupe « hérite » des propriétés de son parent.
Les vies ont pour but d’animer, de déplacer, d’interagir, bref de rendre vivant l’objet
auquel elles sont attachées. Elles peuvent être appliquées aux groupes et aux Hooks.
Le Hook peut être vu comme un point d’accroche dans K. Cette accroche permet
de faire une association entre les différentes entités qui le composent : les composants et
la vie qui lui est associés
Un composant peut être considéré comme une entité élémentaire de données
réutilisables et partageables. Un composant, peut par exemple, être un objet graphique ou
un paramètre de collision. Il existe des composants pour les vies, les Hooks ainsi que les
groupes.
2.2.3. Outils utiles dans Kal
Pour l’instant la gestion de détail se fait principalement avec les outils Fx (qui se
trouvent dans le module graphique de K). Parmi ces outils Fx nous retrouvons : FxRain,
FxClouds, FxTrail, FxParticle, etc. Ces outils permettent de simuler un mouvement d’un
objet, une flamme qui bouge sous le vent ou même des feuilles qui tombent d’un arbre.
En ce qui concerne un véritable service physique, il n’est pour l’instant qu’en phase
de recherche et n’est pas du tout utilisé en production. Le service physique permet pour
l’instant de créer 2 types d’objets (cinétique ou solide) et de voir les collisions entre ces
objets ainsi que l’effet de la gravité.
Voici les principales pistes de développement qui m’étaient fourni par Kal.
1
2
2.3. Etat de l’art et orientation du stage
L’état de l’art va se décomposer en plusieurs parties. Une partie concernera les différents documents liés à la simulation de l’environnement réaliste (gestion de pluie, gestion
de poussière, de vent). Une seconde partie est composée de documents sur la simulation
de mouvement de tissu et sur la physique et à la dynamique de fluides.
Dans la première partie de cet état de l’art, j’ai pu découvrir de nombreuses réalisations visant à simuler l’environnement dans lequel nous vivons. Ce domaine est en pleine
expansion grâce à la puissance des nouvelles machines. Mais justement ce domaine (la
simulation de l’environnement) est un domaine très « gourmand » en ressource et en temps
de calcul, il est donc non temps réel pour la plupart. Parmi ces réalisations, on peut citer la
vidéo ToyShop d’ATI (2006) ou la méthode « Dynamic Modeling and Rendering of Grass
Wagging in Wind » (2005) ou encore le papier « Real-Time Simulation of Dust Behavior
Generated by a Fast Traveling Vehicle » (1999). Toutes ces réalisations utilisent des données et des formules physiques pour simuler l’environnement. ATI essaie d’optimiser les
temps de calcul en utilisant à la fois le matériel mais aussi en simplifiant les algorithmes.
Dans cette deuxième partie, nous allons justement nous attarder sur ces formules
physiques et sur les méthodes afin de les simplifier pour essayer de les rendre temps réel.
Le document « Physically Based Real-time Animation of Curtains » présenté par Microsoft
en 2000 explique l’utilisation d’un système masse-ressort pour simuler le rideau et un système d’émission de particule pour simuler le vent. Le point critique dans cette simulation
est l’émission de particule pour simuler le vent. En effet, c’est cette méthode qui est la plus
coûteuse et la moins adaptée au temps réel. Actuellement, c’est la méthode la plus utilisée
pour simuler le vent, on la retrouve dans de nombreuses réalisations. Le vent peut être
assimilé à un fluide et j’ai donc décidé de m’orienter dans cette direction, en cherchant s’il
n’existait pas de solution de simulation de fluide en temps réel. La technique de Jos Stam
- « Real-Time Fluid Dynamics for Games » présenté en 2003 propose un solveur simple et
efficace pour la simulation de fluide en temps réel.
1
3
Cet état de l’art présente brièvement le chemin de raisonnement que j’ai suivi tout au
long de ce stage. Le but était de trouver une solution pour gérer les détails en milieu urbain.
Nous avons fait le choix en début de stage de ne pas s’orienter vers la gestion de la lumière
et du son mais principalement vers le mouvement de ces objets et éventuellement leurs
déformations. C’est dans cet esprit qu’a été fait cet état de l’art, afin de trouver comment
appliquer un mouvement et une déformation à des objets du décor urbain. La phase de recherche a duré pendant plusieurs semaines afin de trouver la méthode que j’allais utiliser.
Cependant, au cours du développement, il y a eu des phases de recherche principalement
en ce qui concerne la physique (des fluides ou mécanique).
Durant les premières semaines et donc en même temps que cet état de l’art, j’ai
développé un petit exemple de ce que pourrait faire ma solution.
1
4
3. Cahier des charges et planning
Le stage a été prévu par ELB de la manière suivante. Le sujet est donné puis le
stagiaire dispose entre 3 et 4 semaines pour faire des recherches sur ce sujet et proposer
une idée d’amélioration ou d’ajout dans le logiciel Kal et/ou le moteur K. Puis le stagiaire
présente ses recherches à l’équipe qui l’oriente et le conseille. La suite du stage concerne
le développement de la solution.
Voici le planning prévisionnel qui a été fait avant la présentation de mes recherches.
- Apprentissage environnement KAL (test sur les fonctionnalités existantes).
- Apprentissage environnement de développement Visual C++.
- Implémentation d’un petit exemple de simulateur de vent sur un objet.
(Modification des valeurs du vent avec une visualisation temps réel des
transformations de l’objet.)
- Implémentation du modèle météo.
- Implémentation d’un exemple de vent et un objet de type tissu
- Implémentation d’un exemple de pluie utilisant ParticleNodeFx
- Implémentation d’un exemple de poussière/fumée utilisant ParticleNodeFx.
- Implémentation d’un objet fixe test. (En fonction du temps)
- Implémentation d’un objet mobile test. (En fonction du temps)
- Implémentation d’un rideau de pluie (gestion de la lumière et effet de droplet.)
- Implémentation de plusieurs objets mixtes avec occlusion.
- Test de performance sur environnement à grande échelle.
Après la présentation, le choix de travailler principalement avec la technique de gestion des fluides et principalement avec les équations de Navier-Stokes a changé le planning.
1
5
Diagramme de Gantt du planning final
1
6
4. Premières idées et premiers essais
4.1. Le système météo : le vent
4.1.1. Principe et idées générales
Comme dit précédemment, l’environnement prend en compte de nombreux éléments
dont le vent. Le vent est l’élément que l’on retrouve partout et le plus souvent, il influe sur la
plupart des objets, a lui seul, il sait donner une dynamique, un réalisme à une scène. C’est
pour cela, alors même que mes recherches n’étaient pas encore terminées, que je me suis
intéressé au vent.
L’idée était donc de développer un plug-in K/KAL pouvant gérer le vent. Celui-ci serait limité à un seul objet afin de simplifier la tâche. En effet, la réalisation complète de ce
modèle aurait demandé diverses implémentations comme un Z-buffer6 (afin de déterminer
la position des objets face au vent), un système de détection d’occlusion (pour simuler le fait
qu’un objet soit caché par un autre ou non), ainsi qu’un système de déformation de l’objet
(c’est cette partie qui a été implémenté dans notre exemple).
1
7
Différentes étapes de réalisation d’un système de vent
6 En infographie, le Z-buffer ou tampon de profondeur est une méthode employée dans le cadre de l’affichage d’une
scène 3D. Le Z-Buffer permet de gérer le problème de la visibilité qui consiste à déterminer quels éléments de la scène
doivent être rendus, lesquels sont cachés par d’autres et dans quel ordre l’affichage des primitives doit se faire.
Cette chaîne de réalisation se devait d’être temps-réel mais aussi réaliste. Il fallait
donc optimiser les algorithmes comme le z-buffer et l’occlusion afin d’avoir le plus de temps
possible pour les déformations (qui coutent le plus de temps de calcul car elles doivent être
réalistes).
De plus, La déformation des objets n’est pas la même pour tous les objets. En effet,
il y aura les objets non déformables mais friables, les objets poreux, les objets qui peuvent
se courber. La solution était que chacun de ces objets possède sa propre liste de comportement et dans ce cas, le système météo (de vent dans notre exemple) jouerait le rôle de
machine à état que l’utilisateur configurerait à sa guise.
1
8
Machine à état du système météo
4.1.2. Implémentation de l’exemple
Notre exemple sera un plug-in K/Kal permettant de charger un objet et de lui appliquer
des déformations en fonction du vent. Le vent sera paramétré directement par l’utilisateur.
Il a donc fallu créer un plug-in K constitué des classes suivantes :
- CKGrpWind pour créer le groupe
- CKHkWind pour créer le Hook
Il a aussi fallu créer le plug-in Kal correspondant avec les classes :
- CKalGrpWindDesc pour décrire le groupe
- CKalHkWindDesc pour décrire le Hook
Le but de ce plug-in est de déformer un objet. Il faut donc tout d’abord le charger.
Les objets graphiques utilisés par K et Kal sont des .kif . On utilise donc les méthodes de
chargement qui existe au sein de Kal. Ces objets .kif sont composés de bones7, de géométries et de textures. Les bones sont utilisés pour les animations, tandis que les géométries
définissent l’objet graphique (comparable à son enveloppe) et les textures s’appliquent sur
les géométries. La solution qui a été choisie pour réaliser ces déformations et de les appliquer directement sur la géométrie de l’objet.
Code
GetKGLObject()->GetGeometryList->GetElement(ui32CurrentGeomet
ryElement)->GetVertices();
La déformation d’objet directement au niveau des géométries est quelque chose
qui n’est pas souvent fait dans Kal. En effet cela demande beaucoup de temps de calcul
puisqu’il faut parcourir tous les vertex de l’objet.
Pour le moment, la déformation d’objet comme pour l’herbe sous le vent est gérée
principalement avec une méthode de deshortogonalisation du repère. C’est à dire que l’on
fait osciller Y. Ainsi les objets se retrouvant à Y=0 ne subissent pas d’oscillation mais plus Y
est grand, plus l’objet est soumis à l’oscillation. Cette méthode n’est pas la plus réaliste mais
permet d’avoir un rendu beaucoup plus rapide.
7 Signifie os. En infographie on utilise des bones pour animer des objets de la même façon que nos os..
1
9
Interface Kal et déformation de notre objet
2
0
4.2. Idées et algorithmes en vrac
Durant cette phase de recherche, j’ai émis différentes hypothèses et idées pour réaliser la gestion de l’environnement. Mais bien évidemment je n’ai pu explorer toutes ces
pistes, cela ne veut pas dire que ce sont de mauvaises pistes ou des pistes moins intéressantes. C’est simplement dû à un choix ainsi que par les différentes contraintes comme la
durée du stage ainsi que le contexte du jeu-vidéo et donc du temps réel. Cette partie est
donc dédiée à toutes ces idées qui n’ont pas été approfondie par la suite.
Nous pourrions aussi voir différents éléments visant à rendre les scènes plus réalistes au niveau de l’environnement. Nous pourrions donc développer différents éléments tels
que le vent, la pluie, les nuages afin d’avoir plusieurs « briques » et différentes images pour
rendre le stage plus concret.
Il y a de nombreuses solutions pour améliorer le rendu de l’environnement dans les
jeux vidéo. Il va donc falloir faire un choix sur ceux que nous pouvons développer durant la
période du stage.
Le vent sera notre cible privilégiée mais nous aborderons aussi la pluie avec la gestion des « splashes8 »ainsi que de l’éclairage en temps réel.
4.2.1. Déformations d’objets
En ce qui concerne les déformations des objets en temps réel, plusieurs possibilités
s’offraient à moi. L’algorithme de « Free-Form Deformation (FFD) » par exemple, ou encore
l’algorithme de déformation des vertex en fonction de leurs normales (qui a été utilisé dans
notre plug-in exemple). Cet algorithme déforme les vertex ou plutôt leur affecte une rotation
en fonction de la direction du vent et de leurs normales.
La résistance des objets à subir une déformation a été testée avec un algorithme
de bounding volume (boîte englobante). Cela signifie que chaque vertex ne pouvait se déplacer hors d’une certaine boîte englobante. Cet algorithme est une version très simplifiée
d’un système « masse ressort » qui aurait pu être utilisé dans ce cas.
Un autre algorithme de déformations, plutôt orienté pour les tissus, est le « free-ends
» qui constitue le fait de trouver les extrémités d’un tissu (bouts libres) puis d’utiliser un algorithme récursif pour appliquer le mouvement au reste de l’objet.
Il y avait aussi la possibilité de modifier les bones plutôt que les géométries. Mais il
aurait fallu que les bones soient adaptés aux déformations que nous voulions faire subir à
l’objet et surtout que la modification des bones puisse directement être faite dans Kal.
4.2.2. Pluie, son et lumière
Cette partie regroupe des idées plus globales qui n’ont pas été implémentées dans
notre système au final.
Tout d’abord, les lumières n’ont pas été implémentés du tout, et pourtant l’ajout de
lumière contribue beaucoup à l’ambiance d’une scène. L’ajout d’une gestion de la lumière
pour des objets de type détails comme des panneaux lumineux ou des réverbères serait
très intéressant. On peut imaginer un éclairage dynamique produit par ces objets qui bougeraient en fonction du vent ou d’autres paramètres.
8 Impact de gouttes d’eau
2
1
En ce qui concerne le son, je pense que c’est une bonne solution pour avoir une
scène encore plus réaliste et immerger le joueur. En effet, donner un son à chaque élément de détail et de pouvoir modifier ce son en fonction de paramètre comme le vent,
l’écrasement de cet objet ou son déplacement rajouterait du réalisme à la scène.
La pluie, quant à elle, n’est pas un élément de détail mais plutôt un événement qu’il
serait bon d’intégrer dans une gestion de détails. Il est rare dans les jeux vidéo que la pluie
soit un élément important, elle est souvent simplement représentée par des traits tombant
devant l’écran et cela suffit souvent aux joueurs pour comprendre qu’il y a de la pluie. Mais
une gestion plus approfondie de cet événement en rajoutant l’effet d’un sol mouillé, que
certaines zones sont protégées par des parapluies ou des arbres apporterait plus de réalisme.
2
2
Exemple de pluie modélisé avec un FxParticle9
La solution qui a été retenue est la dynamique des fluides. En effet, ce système
est global, c’est-à-dire qu’il s’applique à n’importe quel type d’objets avec n’importe quel
paramètre. Il nous permet de simuler des forces comme la gravité ou le vent, mais il permet
de mettre ces objets dans différents milieu, comme un milieu aérien ou aquatique. Pour
simuler des fluides et leur mouvement en informatique, la technique la plus utilisée est la
résolution des équations de Navier-Stokes.
9 Le réalisme de la pluie aurait pu être amélioré avec l’application de la texture d’environnement sur chaque particule
ainsi que le rajout d’animation de type « splash » des gouttes au contact d’un objet.
5. La dynamique des fluides, la physique mécanique et
Kal
5.1. Théorie et Algorithme
5.1.1. Navier-Stokes
Les équations de Navier-Stokes permettent de décrire le mouvement d’un fluide. Elles
gouvernent par exemple les mouvements de l’air, de l’atmosphère, les courants océaniques,
l’écoulement de l’eau dans un tuyau et de nombreux autres phénomènes d’écoulement de
fluides.
Il existe de multiples façons de noter ces équations. Mais dans notre cas, il y a 2
notations qui nous intéressent particulièrement.
2
3
La première nous donne l’évolution des vélocités et la seconde l’évolution de la densité. En effet, ce sont ces 2 valeurs qui nous intéressent le plus dans notre cas. La vélocité
représente un champ de vecteur qui associe un vecteur direction à chaque point de l’espace.
La densité, quant à elle représente la quantité de fluide à chaque point.
Bien évidemment ces équations peuvent être complexifiées afin de réaliser des
modèles beaucoup plus complexes comme l’aérodynamisme des ailes d’un avion ou d’un
pont. Mais ici, ces 2 notations nous suffisent surtout que l’on souhaite utiliser ces équations
en temps réel. De plus, la forme de ces équations nous intéresse car nous allons pouvoir
faire directement une analogie avec notre algorithme.
5.1.2. “Stable Fluid”
Pour implémenter ces équations et les traduire en un algorithme temps réel, nous
avons utilisé la méthode de Jos Stam « Stable Fluid » présentée dans son papier intitulé :
« Real-Time Fluid Dynamics for Games ».
Stam conseil de commencer le développement par la mise en place de l’algorithme
pour résoudre l’équation de la densité (la deuxième). En informatique, on est obligé de discrétiser, on ne peut pas représenter chaque particule de l’espace. C’est pour cela que la
première étape consiste à voxeliser l’espace (le discrétiser en voxel10). Il faut prendre soin
de bien diviser l’espace dans le bon ordre, afin de pouvoir rapidement accéder au voisin de
chaque voxel.
Revenons à notre équation de densité (la deuxième) cette équation dit que la densité
à un instant t dépend de 3 choses :
- Le premier terme de l’équation signifie que la densité suit un champ de
vélocité.
- Le deuxième terme de l’équation signifie que la densité se diffuse.
- Le dernier terme signifie que la densité augmente avec les sources de
fluide (comme par exemple une cigarette ou une cheminée).
Schéma de résolution du solveur de densité
Comme vous pouvez le voir sur ce schéma, nous allons implémenter l’équation dans
l’ordre inverse de sa notation.
10 Le voxel (contraction de « volumetric pixel ») est un pixel en 3D
2
4
Passons maintenant à l’équation de vélocité (la première). Comme pour la phase de
densité nous pouvons voir que la vélocité à un instant dépend de 3 choses :
- Le fait que la vélocité bouge autour d’elle-même (« Self-Advection »).
- Le fait que la vélocité se diffuse (la viscosité).
- Le fait que la vélocité augmente avec les sources (mouvement d’objets
par exemple).
Mais il y a une étape en plus pour implémenter cette équation, il faut qu’il y est conservation de la masse (propriété des fluides réel).
L’implémentation est donc simplifiée par le fait de pouvoir réutiliser les fonctions
développées lors de la phase de densité pour la phase de vélocité.
Il ne reste plus maintenant qu’à initialiser les fonctions avec des valeurs données
par l’utilisateur et l’algorithme produira un fluide avec un mouvement réaliste. Mais nous ne
nous arrêtons pas là. En effet, le but est de pouvoir gérer des détails (des objets) et non du
fluide. Le fluide est juste un moyen pour gérer ces objets. Pour cela, on utilisera une propriété importante de l’algorithme de Stam, à savoir les collisions ou plus particulièrement
le fait qu’un voxel soit occupé par du fluide ou non. Cette propriété va nous permettre de
pouvoir placer des objets au milieu du fluide et de voir d’une part le comportement du fluide
mais dans un autre temps le comportement de ces objets.
2
5
Schéma de représentation de l’algorithme de notre solution
Pour que nos objets réagissent au mouvement du fluide, il faut qu’il récupéré les valeurs de mouvement de ce fluide mais aussi qu’il ait des paramètres pour caractériser leurs
déplacements. Ces paramètres proviennent de la physique mécanique.
5.1.3. Physique Mécanique
La physique mécanique, ou la physique de Newton, nous donne les formules qui
décrivent le déplacement d’un objet au cours du temps. Dans notre cas, nous cherchons à
déplacer ces objets avec un minimum de paramètre mais tout en gardant le plus de réalisme possible.
Regardons la loi de Newton :
Cette équation signifie que la somme des forces appliquées à un objet est égale à sa
masse multipliée par son accélération. Dans notre cas, les forces qui s’appliquent à notre
objet sont le poids, la force de frottement avec le fluide ainsi que la poussée d’Archimède.
De plus, dans notre cas l’objet subit aussi une force de pression du fluide.
Le problème avec la physique et le mouvement dans le jeu vidéo est les contraintes
de FPS11 et le fait que le temps entre 2 frames consécutives puisse être différent (ralentissement ou autre). De ce fait, les formules vues précédemment ne peuvent être applicables littéralement. Les formules m’ont principalement aidé pour connaître les paramètres
nécessaires à déplacer un objet et comment ces paramètres influent sur le mouvement
(diminution ou augmentation.)
Schéma de modélisation des forces sur un objet dans le fluide
11 Frame par Second : Images affichées par seconde en français.
2
6
Toute la difficulté réside dans le fait de trouver la bonne approche pour que l’utilisateur
puisse configurer les paramètres de l’objet simplement et obtenir le mouvement souhaité,
tout en s’inspirant des lois de la physique mais en les détournant pour le jeu vidéo.
Voilà, nos objets peuvent se déplacer maintenant mais nous avons voulu rajouter le
fait de pouvoir leur faire faire une rotation. En effet, un arbre va réagir au fluide non pas en
se déplaçant mais bien en se courbant (rotation). Là aussi, il existe un outil physique : le
moment d’une force .
Avec M le moment, F la force et d la distance entre le pivot et le point d’application
de la force. Or dans notre cas il n’y a pas de point d’application à proprement dit. C’est plus
une zone d’application, on ne peut donc pas appliquer non plus les équations du moment à
notre modèle mais nous allons nous en inspirer.
Maintenant que nous avons fait tous ces rappels théoriques et algorithmiques, nous
allons entrer dans le vif du sujet, à savoir l’implémentation et les choix que j’ai fait par rapport au modèle physique.
2
7
5.2. Implémentation
5.2.1. Modèle de classe
Il a donc fallu réaliser un plug-in K ainsi que son plug-in Kal correspondant pour implémenter ce système. Notre plug-in est donc constitué d’un groupe (CKGrpFluidBox pour
K et CKalGrpFluidBoxDesc pour Kal). Ce groupe contient 3 Hooks (CKHkFluidBox, CKHkForce et CKHkPhysicObject). A termes, ce plug-in serait transformé en un service auquel
les différents objets pourraient souscrire ou non. Mais pour des raisons de simplicité et de
contrôle, le choix d’un plug-in a été préférable. En effet, toutes les fonctionnalités peuvent
être faites au travers d’un plug-in et la création d’un nouveau service aurait été plus une
perte de temps qui ne nous était pas permise (la durée du stage n’est que de 3 mois.)
Revenons à nos classes à proprement parlé, le groupe est là pour pouvoir créer les
différents Hooks mais aussi pour assurer la communication entre ces Hooks (la FluidBox
a besoin de recevoir les informations des Forces tout comme les Objets physiques doivent
recevoir les informations de la FluidBox).
12 Le moment d’une force est l’aptitude d’une force à faire tourner un système mécanique autour d’un point donné,
qu’on nommera aussi pivot.
La FluidBox permet de gérer les fluides, c’est ici que les équations de Navier-Stokes
sont calculées. Elle possède aussi les fonctions afin de communiquer avec les autres
classes du groupe (forces et objets physiques). Cette classe est la plus importante de toutes
: elle permet de définir l’espace de travail ainsi que les conditions initiales. De plus, toutes
les informations passent par cette classe.
CKHkForce permet de créer et de gérer les forces. Les forces donnent un mouvement au fluide. En effet, ici les forces n’agissent pas directement sur les objets mais
agissent d’abord sur le fluide. Dans cette classe, on retrouvera les différents types de forces
implémentées (3 pour le moment).
La classe Physic Object permet de créer les objets qui vont réagir avec notre boite de
fluide. C’est aussi ici que l’on utilise la physique mécanique pour simuler les mouvements
de ces objets. Cette classe est aussi très importante car c’est dans celle-ci que l’on effectue
tous les calculs pour faire bouger, déformer, translater l’objet. Pour l’instant, il n’y a que 2
types d’objets possibles (déplaçable et non déplaçable) mais par la suite une multitude
d’objet pourrait être rajouté. La classe Physic Object est typiquement une classe qui serait
implémentée par le GameProgramming. En effet, pour chaque jeu, il y aurait de nouveaux
objets qui auraient besoin d’utiliser les FluidBox et le GameProgramming serait en charge
de développer ces classes. Dans notre cas cette classe a été faite afin de pouvoir illustrer
l’utilisation de notre outil.
2
8
Schéma des classes des plug-ins K et Kal FluidBox
Maintenant que nous avons vu l’organisation au niveau des classes, nous allons descendre d’un niveau et regarder l’organisation au niveau des fonctions.
Tous ces objets sont des Hooks et possèdent donc les fonctions communes à tous
les Hooks, à savoir l’enregistrement, l’initialisation, la destruction ainsi que les fonctions
permettant de gérer la vie rattachée au Hooks (start, stop et update). K possède aussi un
système permettant de sauvegarder l’état d’un objet, c’est à dire de sauvegarder les valeurs des variables de l’objet. Ces fonctions m’ont été très utiles afin de pouvoir réaliser mes
diverses démonstrations. Voilà en ce qui concerne les fonctions communes à toutes nos
classes. Passons maintenant aux fonctions spécifiques.
Tout d’abord, dans la classe FluidBox, on retrouvera toutes les fonctions liées à la
résolution des équations de Navier-Stokes. Ces fonctions sont principalement mathématiques et ne sont accessibles que par la classe. Si dans le futur d’autres systèmes avaient
besoin de ces fonctions, nous pourrions les intégrer à la classe KMath qui est un annuaire
des fonctions mathématiques disponibles dans K. On retrouve aussi dans la classe KMath
les fonctions permettant de savoir si un objet est à l’intérieur d’une FluidBox ou si une Force
est à l’intérieur d’un FluidBox.
Ensuite dans la classe Force, on retrouve les fonctions permettant de créer nos types
de forces (3 pour le moment). Cette classe est principalement dédiée à l’interface, puisque
c’est l’utilisateur qui va paramétrer la force comme il le souhaite. Les calculs seront faits au
niveau de la FluidBox.
Et enfin, la classe Physic Object possède des fonctions spécifiques. En effet, à
l’intérieur de cette classe, il y a une machine à état qui définit si un objet est dans une boîte
de fluide ou non. On retrouve donc dans cette classe les fonctions qui permettent de gérer
cette machine à état. On retrouve aussi les fonctions qui nous permettent d’appliquer un
mouvement à un objet (translation et rotation).Ces fonctions sont aussi d’ordre mathématique puisqu’elles s’inspirent de la physique, mais nous ne pourrions pas les intégrer dans
KMath car elles sont spécifiques au mouvement d’objet à l’intérieur d’un fluide. De plus,
elles sont très liées aux paramètres que nous avons choisi d’utiliser pour définir nos objets
physiques. Ces paramètres sont la masse, le volume et la porosité13. Ces paramètres sont
suffisants pour la modélisation que nous voulons faire mais surtout ils ne demandent pas
trop de temps à être configuré par l’utilisateur. En effet, le volume se calcule automatiquement, la masse est quelque chose de concret, il ne reste que la porosité à vraiment régler
pour l’utilisateur. On retrouve aussi les fonctions permettant de gérer les collisions entres les
différents objets physiques.
13 Capacité d’un objet de laisser passer ou non un fluide
2
9
Bien évidemment toutes ces classes possèdent aussi des fonctions afin de gérer leur
IHM14 correspondantes. Nous allons maintenant regarder le fonctionnement et la mise en
place par l’utilisateur de ces classes.
5.2.2. IHM et objets implémentés
Commençons tout d’abord par une explication du fonctionnement de notre plug-in.
Tout d’abord, il faut placer les FluidBox là où nous en avons besoin, par exemple, dans une
rue pour simuler le vent ou dans un couloir. Ensuite, il faut positionner les forces là où nous
voulons qu’elles agissent. Pour le moment, nous n’avons que 3 types de force (sphérique,
linéaire et temporelle) :
- sphérique signifie que la force sera émise dans toutes les directions avec
la même puissance.
- linéaire c’est-à-dire que l’utilisateur choisit une seule direction pour
sa force.
- temporelle donne la possibilité à l’utilisateur de configurer la direction et
la puissance de sa force en fonction du temps.
Une fois que l’utilisateur a positionné ses forces, il doit les paramétrer. Enfin, l’utilisateur
peut maintenant placer ses objets où il le souhaite. Il ne reste plus qu’à configurer ces objets
et lancer la simulation.
Bien évidemment, pour réaliser cela le plus simplement possible il faut créer une IHM
intuitive pour que l’utilisateur puisse accéder et modifier rapidement les informations qu’il
souhaite.
En ce qui concerne la FluidBox, elle est représentée par une boîte divisée en voxels.
De plus, l’utilisateur peut en modifier la taille, le nombre de division en x,y,z, la densité et
la viscosité. Il peut aussi choisir s’il veut un affichage en fil de fer ou plein ou encore pas
d’affichage du tout de sa FluidBox.
Ensuite pour les Forces, il faut pouvoir choisir le type de la force. En fonction du type
de force choisie, l’IHM est différente. Si la force est sphérique, alors l’utilisateur ne pourra
modifier que la puissance de cette force. Si elle est linéaire, il pourra choisir une puissance
différente en x,y,z et si elle est temporelle, il pourra modifier, via une courbe, la puissance
de la force en x,y,z en fonction du temps. De plus, chaque force a la possibilité d’émettre
du fluide (remplir la FluidBox). L’outil force est vraiment celui avec lequel l’utilisateur pourra
modifier le plus de chose. Cela lui permettra de réaliser des effets à sa guise comme par
exemple du vent grâce à la Force de type temporelle.
14 Interface Homme Machine
3
0
Il reste enfin les Physic Objects qui ont comme paramètres leur masse et leur porosité mais aussi la possibilité de les fixer avec un seuil de résistance. Cela signifie que
l’objet ne subira pas de translation tant que son seuil de résistance n’est pas dépassé. Cette
fonctionnalité est utile pour simuler le mouvement des arbres, par exemple. En ce qui concerne les objets déplaçables, l’utilisateur peut configurer leur vitesse de déplacement. Ceux
du personnage sont gérés grâce à des fonctions d’inputs qui peuvent récupérer les actions
effectuées par le joueur sur un clavier ou un pad.
3
1
IHM de l’outil force
5.3. Résultats, limites et avenir
Rappelons tout d’abord les contraintes qui étaient de réaliser une solution temps réel
et de donner un mouvement réaliste à ces objets. La première partie de ces résultats montrera le fonctionnement de la FluidBox sans objet. Puis, nous inclurons des objets et des
décors de niveau afin d’étudier le comportement de ces objets.
3
2
Première image de fumée
Voici la première simulation de fumée obtenue avec notre système. Ici, la fumée est
représentée par les voxels de la FluidBox qui sont colorisés en blanc et dont l’alpha augmente avec la densité du fluide. L’algorithme de calcul des équations de Navier Stokes est
en N315 pour un cube. En effet il faut parcourir tous les voxels à chaque itération. Cela nous
fait donc un parcours en Nx*Ny*Nz, avec Nx le nombre de division en largeur, Ny le nombre
de division en hauteur et Nz en profondeur. On voit donc le problème majeur qui est la discrétisation de la FluidBox. En effet, plus il y aura de voxel, plus les calculs seront long.
15 Définit la complexité de l’algorithme. Ici la complexité est de l’ordre du cube.
3
Simulation de fumée a t=1, t=2, t=4 et t=8 seconde.
Les images ci-dessus ont été simulées avec une boîte de fluide de 10*10*10 voxels
et tournent avec une vitesse de 27 FPS donc suffisant pour du temps réel. Sur la 4ème image, on voit clairement que le fluide entre en contact avec la boîte et ne peut s’échapper de
celle-ci. C’est un choix que j’ai fait pour simplifier les traitements, mais on peut facilement
imaginer développer d’autres types de boîte, laissant sortir le fluide ou encore faisant rentrer
de l’autre coté, le fluide sorti.
Comme dit précédemment, le principal problème vient du temps de calcul des équations de Navier-Stokes qui est en N3. En effet, on parcourt tous les voxels à chaque itération. Or nous pourrions imaginer une version qui calculerait les équations de Navier-Stokes
uniquement pour un certain nombre de voxels sujets à un changement. En effet, à chaque
itération tous les voxels ne sont pas forcément modifiés. Cette version fait entrer en compte
la notion d’octree16. Cette implémentation est aussi plus complexe et nous n’avons pensé
à cette solution que trop tard dans le développement et nous n’avons pas pu appliquer de
modifications profondes du projet en cours.
16 Un octree est une structure de données de type arbre dans laquelle chaque nœud peut compter jusqu’à huit enfants.
3
Pour finir avec la FluidBox, il faut juste savoir que les équations mises en place permettent de simuler du vent et de la fumée (comme dans l’exemple ci-dessus), mais elles
permettent aussi de simuler des liquides tel que de l’eau ou encore du feu. Avec plus de
temps, j’aurais aimé essayer de réaliser des simulations de feu et d’eau mais cela n’était
pas réellement dans l’idée du stage.
Maintenant que nous avons le cœur de notre système qui fonctionne (les FluidBox),
nous allons pouvoir intégrer les forces et les objets. En ce qui concerne les forces, le choix
a été fait de pouvoir en implémenter 2 au départ (linéaire et temporel) et finalement nous
avons intégré une troisième force (sphérique) afin de montrer les multiples possibilités qui
peuvent être mise en place. Je ne vais pas ici toutes les énumérer, mais simplement montrer un exemple que nous aurions pu imaginer. Celui-ci consiste en une force qui se déplace
sur un axe ou suivant une courbe dessinée par l’utilisateur. On pourrait aussi imaginer le fait
de lier une force un objet pour simuler les pas du héros dans le sable par exemple. Nous
avons aussi fait le choix de laisser lier les forces et l’émission de fluide. Cela signifie qu’une
force peut générer en même temps une vélocité et une densité. Cela nous permet par exemple de représenter directement une créature qui souffle de l’air ou qui crache du feu.
Passons maintenant aux objets. Tout d’abord, nous avons limité les objets que l’on
peut placer dans le FluidBox à des objets graphiques. Mais cela n’est pas restrictif. Par la
suite nous pouvons très simplement ajouter d’autres éléments en tant qu’objets pouvant interagir avec une FluidBox. Je pense tout particulièrement aux outils Fx et à l’outil ParticleFx
qui pourrait par exemple simuler les mouvements d’une flamme dans l’air ou encore la
direction de la pluie lorsqu’il y a du vent. Mais le principal objet est bien évidemment l’objet
graphique. Nous avons créé donc 2 types d’objets (déplaçables ou non) et nous avons configuré ces objets pour qu’ils réagissent aux mouvements du fluide lorsqu’ils sont en contact
avec celui-ci. Ainsi les arbres oscillent sous le vent, le personnage a du mal à avancer en
cas de vent très fort ou encore les caisses se déplacent sous la force du vent.
Ces mouvements se doivent d’être le plus réaliste possible, mais il faut toujours
respecter la contrainte du temps réel. Il a donc fallu adapter les formules de la physique,
d’une part, pour les problèmes cités précédemment mais aussi pour une question de performance. En effet, le but est de pouvoir gérer de multiples objets sans baisse de FPS sachant
qu’il y a un coût minimum afin de détecter si l’objet est dans la FluidBox ou non et le volume
qu’il occupe.
3
4
Image provenant de la démonstration finale
Sur cette image, il y a 11 objets graphiques (les arbres, les caisses ainsi qu’Astérix),
3 forces, (1linéaire et 2 sphériques) et la boîte de fluide a une discrétisation de 40*3*15 ce
qui fait 1800 voxels. Il y a, de plus, tout un décor de niveau chargé. La simulation fonctionne
avec environ 11 FPS. Cependant, la même scène avec une FluidBox de seulement 10*1*5
fonctionne a 36 FPS. Cela nous prouve que le nombre d’objets n’est pas la donnée la plus
coûteuse en temps de calcul. Mais, pour le moment, afin d’avoir un mouvement plus réaliste, il est conseillé d’augmenter la discrétisation de la FluidBox. Cependant, avec un peu
plus de temps, il y a possibilité de modifier encore les fonctions de déplacement et de rotation de l’objet afin de l’affiner malgré une moindre discrétisation.
Toutes ces images et ces simulations ont été réalisées sur un pc portable équipé d’un
Pentium 4 de 3GHz avec 1Go de RAM et une carte graphique ATI Mobility M10.
Nous allons maintenant passer au bilan et à la conclusion.
3
5
6. Bilan
6.1. Technique
D’un point de vue technique, je n’aurais pas pu espérer mieux au niveau du contenu
de ce stage. En effet, j’ai vraiment appris de nombreuses choses que ce soit au niveau de
la programmation ou en physique qu’au niveau des environnements de travail (découverte
de Visual C++). C’est la première fois que j‘approchai un moteur de jeux vidéo et cela est
intéressant, j’ai pu observer de nombreuses fonctionnalités à défaut de pouvoir toutes les
utiliser. Il y a tellement d’outils déjà implémentés à l’intérieur d’un moteur qu’il est parfois
difficile de savoir si ce que l’on est en train de faire n’existe pas déjà quelque part dans le
moteur. Le fait de travailler aussi directement avec un logiciel tel que Kal aide grandement
la tâche, les fonctions que l’on crée sont directement accessibles et ce que l’on code est directement configurable en temps réel. La découverte de K et de Kal a vraiment été quelque
chose d’intéressant et d’instructif pour moi.
Quant à la phase de recherche, elle m’a apporté de nombreuses connaissances sur
le milieu de la physique mais aussi de la simulation que ce soit de la pluie, du vent, la déformation de tissu, toutes ces techniques sont vraiment très intéressantes et il y a de très
nombreux articles traitant de ces sujets. La phase de recherche n’a pas été un point négatif,
bien au contraire. Le fait de pouvoir lire et même utiliser des travaux de grosses équipes de
recherche comme celles d’ATI, Nvidia, Microsoft ou encore Maya a vraiment été très bénéfique.
L’utilisation de Visual C++ a été un peu difficile au début mais une fois les fonctions utiles et basiques maîtrisées il s’avère être un puissant outil de développement avec
de nombreuses fonctions de débogages qui m’ont bien aidé au cours du développement.
L’apprentissage de Kal a aussi été un peu compliqué au début. Ce logiciel a tellement de
possibilités qu’il est difficile de les maîtriser toutes. D’ailleurs, chaque membre de l’entreprise
maîtrise plus ou moins bien certains outils de Kal, mais ils ne maîtrisent pas tous le logiciel
entièrement. Aujourd’hui, encore, il a certains outils dans Kal que je n’ai jamais utilisé et
dont le fonctionnement m’est complètement inconnu.
Et même si le développement a parfois été difficile, voir casse tête, je pense notamment au réglage des translations et des rotations pour les objets. Les apports techniques de
ce stage ne peuvent être que mis en avant et rien que pour cela, je ne remercierais jamais
assez, Etranges Libellules de m’avoir offert ce stage.
3
6
6.2. Humain
Le bilan humain, quant à lui, est plus mitigé. Même si le stage est en R&D, je
m’imaginais rejoindre une équipe et travailler sur ce projet avec l’aide d’autres personnes.
Mais en réalité la philosophie des stages en programmation chez Etranges Libellules est
bien différente.
En effet, j’ai été le seul maître à bord, c’est-à-dire, que j’ai mené le projet du début à
la fin. Cela n’est pas un mal au contraire mais ça apporte finalement plus d’inconvénients
que d’avantages. En effet, je n’ai pas réellement découvert l’entreprise puisque je n’ai travaillé avec aucune équipe en particulier et que mes réalisations ne visent en aucun cas une
production. De plus, même à l’intérieur de l’équipe R&D moteur, je ne sais pas comment ils
travaillent ni même sur quoi ils travaillent. Mise à part le fait de ne pas se sentir intégrer à
l’entreprise, la condition de stagiaire est clairement définie. Nous n’appartenons à aucune
équipe, ni à aucune production, les journées sont donc parfois longues sans avoir la possibilité de parler de ce que l’on fait.
Je ne blâme pas mon tuteur de stage, qui au contraire m’a aidé à chaque fois que
j’en avais besoin et m’a écouté à chaque fois. Je suis plus déçu de la vision que porte
l’entreprise sur le stagiaire. Le stage se termine donc sans que je n’ai fait aucune rencontre ni même pris contact avec quelqu’un dans l’entreprise. Je viens de passer 3 mois à
l’intérieur d’une entreprise que je connais moins que les anciennes où j’ai passé moins de
temps. Je comprends aussi qu’il y ait une politique de confidentialité et de production qui
empêche les diverses équipes de donner plus de temps au stagiaire mais je pense que c’est
dommage de perdre une part si importante du stage qui est la rencontre entre un étudiant
et une entreprise.
3
7
Conclusion
Ce stage m’a permis de m’immerger intégralement dans le milieu du jeu vidéo et
celui de la R&D. En effet, les étapes de recherche et de développement sont les majeures
parties de mon stage. Cela n’a pas été facile tous les jours, que ce soit lors des phases de
recherche où l’on ne trouve pas de pistes intéressantes et où l’on remet en question notre
idée de départ ou pendant les phases de développement où l’on reste coincé lors d’une
étape critique sans trouver la solution. Mais ces difficultés ne m’ont pas découragé et finalement à la fin du stage, j’ai un système plus complet que ce que nous imaginions au départ.
Pour ma part je suis très content d’avoir découvert le milieu de la R&D en entreprise,
cela m’a donné une autre vision que celle que j’avais eue lors des projets tutorés (Projet
Eyestracking). Le domaine du jeu vidéo lui aussi a été très intéressant avec la découverte
du moteur K et du logiciel Kal mais il est vrai que maintenant j’aimerais aussi découvrir les
différents outils utilisés dans le milieu du cinéma d’animation.
En effet lors de mes recherches, j’ai découvert que beaucoup des papiers que je lisais traitaient d’applications liées au domaine du cinéma d’animation qui n’a pas les mêmes
contraintes que le jeu vidéo. Dans le cinéma d’animation, on cherche le réalisme avant le
temps réel.
Malgré le bémol du bilan humain, je suis très content d’avoir fait ce stage, il va me
permettre d’ajouter de réelles compétences à mon CV et m’a aussi permis de pouvoir orienter mon projet professionnel et ma future recherche de stage pour la troisième année.
3
8
Bibliographie
[1]. Hans Petter Langtangen – « The Diffpack Implementation of a Navier-Stokes Solver
Based on the Penalty Function Method » - The Diffpack v1.4 Report Series -1996.
[2]. F. Bridault, C. Renaud, F. Rousselle – « Vers un modèle de flamme temps-réel » - Laboratoire d’Informatique du Littoral / Université du Littoral Côte d’Opale – 2003.
[3]. Jos Stam – « Real-Time Fluid Dynamics for Games » - Alias | wavefront – 2003.
[4]. Michael Ash – « Simulation et visualisation d’un fluide 3D » - LIFO – 2005.
[5]. Olivier Génevaux Arash Habibi Jean-Michel Dischler – « Simulating Fluid-Solid Interaction » - 2003.
[6]. Nick Foster Ronald Fedkiw – « Practical Animation of Liquids » - 2001.
[7]. Robert Bongart – « Efficient Simulation of Fluid Dynamics in a 3D Game Engine » - Master of Science Thesis – 2007.
[8]. Frank Losasso Frédéric Gibou Ron Fedkiw – « Simulating Water and Smoke with an
Octree Data Structure » - 2004.
[9]. Centre de documentation de l’institut géographique national – « L’espace urbain en 3D
: Reconstruction et modèles » - 2007.
[10]. Project-Team EVASION – « Virtual environments for animation and image synthesis of
natural objects » - INRIA – 2006.
[11]. Fabrice NEYRET – « Créer, Simuler, Explorer des Univers Naturels sur Ordinateur »
- Journées de l’Association Francophone d’Informatique Graphique - 2006.
[12]. Changbo Wang, Qunsheng Peng – « Realistic simulation of nature scene » - 2004.
[13]. Natalya Tatarchuk – « Real-Time rain rendering in city environnements » - Eurographics Workshop on natural phenomena – 2006.
[14]. Huamin Wang Peter J. Mucha Greg Turk – « Water Drops on Surfaces » - 2005.
[15]. Paul Richmond – « Real Time Droplet Animation on a Glass Pane » - 2005.
[16]. A. Kolb L. Latta.C. Rezk-Salama – « Hardware-based Simulation and Collision Detection for Large Particle Systems » - Graphics Hardware – 2004.
[17]. Pierre Rousseau Vincent Jolivet Djamchid Ghazanfarpour – « Rendu réaliste de pluie en
temps-réel » - Journées de l’association Francophone d’Informatique Graphique – 2006.
[18]. Lifeng Wang Zhouchen Lin Tian Fang Xu Yang Xuan Yu Sing Bing Kang – « Real-Time
Rendering of Realistic Rain » - Microsoft Research – 2006.
[19]. Kshitiz Garg Shree K. Nayar – « Photorealistic Rendering of Rain Streaks » - 2006.
[20]. JIM X. CHEN XIAODONG FU EDWARD J. WEGMAN – « Real-Time Simulation of
Dust Behavior Generated by a Fast Traveling Vehicle » - ACM Transactions on Modeling
and Computer Simulation, Vol. 9, No. 2, - 1999.
[21]. Changbo Wang Zhangye Wang, Qi Zhou Chengfang Song Yu Guan Qunsheng Peng
– « Dynamic Modeling and Rendering of Grass Wagging in Wind » - 2005.
[22]. Frank Perbet Marie-Paule Cani – « Animating Prairies in Real-Time » - 2000.
3
9
[23]. Ying-Qing XU Chiyi CHENG Jiaoying SHI Heung-Yeung SHUM – « Physically Based
Real-time Animation of Curtains » - Microsoft Research – 2000.
[24]. Rafael Montenegro Gustavo Montero, José Maria Escobar Eduardo Rodriguez José
Maria Gonzalez-Yuste – « An Efficient Package for 3-D Wind Simulation » - 2002.
[25]. Criss Martin Ian Parberry – « Real Time Dynamic Wind Calculation for a Pressure
Driven Wind System » - 2006.
[26]. M. Keckeisen S. Kimmerle B. Thomaszewski M. Wacker – « Modelling Effects of Wind
Fields in Cloth Animations » - 2004.
[27]. Thomas Di Giacomo Stéphane Capo François Faure – « An interactive forest » 2001.
[28]. Crytek – « CryEngine2 Feature » - 2007.
[29]. Stephen Chenney – « Flow Tiles » - Eurographics/ACM SIGGRAPH Symposium on
Computer Animation - 2004.
[30]. Fabrice Fries – « Propositions pour développer l’industrie du jeu vidéo en France »
- Rapport Ministériel – 2003.
4
0
Annexes
I. Chaîne de Production
II. Image de la Démo ATI ToyShop III. Simulation avec une force temporelle
IV. Evolution de la FluidBox au cours du développement
4
1
I. Chaîne de Production
4
2
II. Image de la Démo ATI ToyShop
4
3
III. Simulation avec une force temporelle
4
4
IV. Evolution de la FluidBox au cours du développement
4
5