TER BL21 Étude des structures de données au cœur des algorithmes 3D des jeux vidéos de type FPS. (BL2) Encadrant :Participants : Michel BUFFA Jean-François FOURMOND Stéphane MARIANI Xavier MEDIONI Jean-François RIGHI Maîtrise dinformatique

TER BL22 Introduction Contexte : cours de synthèse dimage très intéressant… mais seulement 6 séances –Programme de TPs/Mini projet limité, –Envie den savoir plus, –Choix du TER avec notre encadreur Sujet du TER : étude des structures de données des algorithmes 3D dans les jeux de type FPS (Doom, Quake, Unreal)… Edit : « nos propres algorithmes » à éviter structure de données à préciser

TER BL23 Doom 3 (sortie annoncée en 2004)

TER BL24 Unreal Tournament (1999)

TER BL25 Quake III (1999)

TER BL26 Introduction (suite) Intérêt avant tout pédagogique –Écriture dun « vrai » moteur 3D –Utilisation dOpenGL/C++/… et des maths ! –Découverte dalgorithmes et de structures de données nouveaux, non naïfs, –Réutilisation de nos travaux par Mr Buffa en tant que tutoriaux/programmes dexemples

TER BL27 Remarque importante La plupart des illustrations sont issues du moteur 3D que nous avons développé pour ce TER : –Fonctionnalités multiples (texture mapping, éclairages, etc…), – lignes de code, –C++/OpenGL/SDL, –On a notre propre environnement de test !

TER BL28 Plan de la présentation Afficher un univers immense, comment faire vite ? Présentation de 4 algorithmes liés à des structures de données adaptées, avec leurs implémentations Comparaison/synthèse de ces algorithmes Conclusion

TER BL29 Comment afficher rapidement un univers immense ?

TER BL210 Notre scène de test (60000 polygones, + de 8000m2 (2 terrains de foot) )

TER BL211 Univers immense ? Exemples : un bâtiment, un circuit, une ville, une région... Un tel univers peut contenir des millions de polygones : on ne va pas tous les afficher ! Rapidement = 60 images/s au moins ! Pour aller vite : ne dessiner que ceux qui sont visibles (dans le champ de vision de la caméra).

TER BL212 Le champ de vision sappelle le frustum En 3D, cest lespace compris entre les 6 plans. Calculer la partie visible = frustum culling

TER BL213 Exemple dalgorithme naïf Tester tous les polygones ? Beaucoup trop long. Si lunivers est statique, plaquer une grille avec des cases de taille égales. Pré-calcul : on associe une case à chaque polygone. On ne dessine que les polygones dont les cases sont dans le champ de vision.

TER BL214 Illustration de lalgorithme précédent vue de dessus : les cases visibles sont grisées Champs de vision

TER BL215 Mais ce nest pas aussi simple ! Une simple grille ne suffit pas ! Ce nest pas efficace et on a aussi envie aussi de : –Calculer des collisions, –Avoir des algos pour tous les types denvironnement –Ne pas afficher ce qui se trouve « derrière un mur », etc… Les quatre algorithmes que nous avons étudiés répondent à certaines de ces conditions.

TER BL216 Algorithme à base de quadtrees

TER BL217 Principe Comme une grille, sauf que les cases ne font pas toutes la même taille. On associe à chaque case les polygones quelle contient Construction –On part dune case qui fait toute la surface de lunivers –On découpe récursivement lunivers en cases de plus en plus petites. Au final, on a un « arbre de cases », chaque case étant découpée en 4 cases.

TER BL218 Exemple de quadtree

TER BL219 Comparaison grille/quadtree Intérêt : on teste dabord si les grands carrés sont visibles. Si ils ne le sont pas, on les élimine. Sinon, on considère des carrés plus petits. Beaucoup moins de tests avec le quadtree !

TER BL220 Exemple avec notre scène de test 11 fps 31 fps

TER BL221 Conclusion sur les quadtrees Surtout adaptés à des scènes sans superpositions (les polygones sont projetés sur un plan). Peu adaptés pour des bâtiments à étages : on va par exemple afficher des polygones sous le sol. Les prochains algorithmes répondent à ces limitations…

TER BL222 Algorithme à base dOctrees

TER BL223 Principe Idem quadtrees mais en 3D… Plus complexe à cause de la dimension supplémentaire! Arbre à 8 branches

TER BL224 Construction récursive profondeur 0 : Le cube contient la totalité des polygones constituant la scène

TER BL225 Construction récursive Profondeur 1 : On subdivise la scène en 8 cubes plus petits.

TER BL226 Construction récursive

TER BL227 Construction récursive

TER BL228 Construction récursive On ne construit pas de cubes vides. 385 cubes

TER BL229 Exemple avec notre scène de test Frustum non activé = Découpage de lespace inutile 4 fps (frames per second)

TER BL230 Exemple avec notre scène de test Profondeur 4 18% de la totalité de la scène affiché 28 fps

TER BL231 Exemple avec notre scène de test Profondeur 5 10% de la totalité de la scène affiché 35 fps

TER BL232 Détection des collisions On assimile le personnage à une sphère placée autour de la caméra. Rayon de la sphère paramétrable

TER BL233 Détection des collisions (suite) En rouge: Octree en collision avec le personnage En bleu : Les polygones potentiellement en collision En blanc : Les polygones en collision avec le personnage

TER BL234 Algorithmes à base darbre BSP

TER BL235 Principe Base : diviser lespace en deux de manière récursive pour obtenir un arbre binaire de partitionnement (BSP). Objectif : éliminer le traitement dune branche entière sur un test de visualisation. Inconvénient : temps de calcul extrêmement long pour obtenir un arbre équilibré nécessité de « précompiler » lenvironnement

TER BL236 Exemple Applet de démonstration

TER BL237 Fin de la récursivité On arrête la récursivité quand : la liste de faces associée à un nœud ne contient que des faces coplanaires où la longueur de la liste est inférieure à une longueur donnée (optimisation à limplémentation).

TER BL238 Fin de la compilation On associe à chaque nœud une boite englobante

TER BL239 Parcours de larbre Pendant lexécution du moteur, le parcours de larbre se fait sur un simple test de visibilité sur la boite englobante

TER BL240 Algorithme à base de portails

TER BL241 Principe (statique) Découpage du monde en Secteurs –Quand on modélise lunivers, on le découpe en secteurs –Les secteurs sont mitoyens lorsquils ont un mur commun. Deux secteurs A et B sont voisins si une partie de B est visible depuis A. Portail = partie qui relie deux secteurs.

TER BL242 Principe (dynamique) Les parties visibles par la caméra sont recalculées récursivement. Parcours de graphe non orienté en profondeur –Nœuds = les pièces –Arêtes = un portail reliant deux secteurs Une fois le graphe parcouru, on a marqué toutes les parties visibles : on les affiche.

TER BL243 Avantages/Inconvénients Naffiche que ce qui est visible Nécessite une modélisation préalable du monde –Impossible de lutiliser avec notre scène de test Non intégré au moteur 3D, mais tutorial de démonstration des principes, en 2D.

TER BL244 Modélisation des pièces Information dans un fichier annexe : syntaxe Ce nest pas toujours simple, problèmes liés à la concavité des pièces et des coins.

TER BL245 Synthèse

TER BL246

TER BL247 Quatrees (simples) Niveau de détails dynamique dans les terrains numériques Utilisés dans les jeux de voiture

TER BL248 Octrees (3D) Dans les jeux à la 3eme personne Idéal pour gérer les collisions Optimal pour des mondes en hauteur

TER BL249 Arbres BSP (optimaux) Portails (mélangés) Utilisés dans les FPS les plus fluides. Nombreux cas particuliers, donc difficiles à implémenter. En complément des arbres BSP. Technique du Lancer de rayons.

TER BL250 Conclusion Adéquation au cahier des charges : –Pas de gestion des contraintes physiques (gravité, collision) –Limplémentation de certains algorithmes na pu arriver à terme

TER BL251 Conclusion (suite) Méthode de travail : –Développement en parallèle des différents modules communs –Rencontre avec un professionnel du jeu vidéo –Fréquentes réunions avec les participants –Communication intensive avec notre encadrant –Utilisation massive de loutil Wiki

TER BL252 Conclusion (suite)

TER BL253 Conclusion (fin) Bénéfices personnels –Première expérience approfondie en programmation graphique