Etude des structures de données au coeur des algos 3D des FPS.(BL2) Vos noms ici, encadreur, etc…

Introduction Contexte : cours de synthèse d’image très intéressant… mais seulement 6 séances –Programme de TPs/Mini projet limité, –Envie d’en savoir plus, –Choix du TER avec notre encadreur Sujet du TER : étude des structures de données et des algorithmes dans les jeux 3D de type FPS (Doom, Quake, Unreal)…

Introduction (suite) Intérêt avant tout pédagogique –Ecriture d’un « vrai » moteur 3D, y compris l’implémentation de nombreux concepts vus en cours.. –Utilisation d’OpenGL/C++/… et des maths ! –Découverte d’algorithmes et de structures de données nouveaux, non naïfs, –Rencontre avec un développeur de jeux vidéo, –Réutilisation de nos travaux par Mr Buffa en tant que tutoriaux/programmes d’exemples

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

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…), –12000 lignes de code, –Conception objet pensée vers l’extensibilité (pour pouvoir changer les algorithmes de rendu facilement), –C++/Open GL, –Notre plate-forme de test !

Comment afficher rapidement un univers immense ?

Univers immense ? Rapidement = 60 images/s au moins ! 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 ! Pour aller vite : ne dessiner que ceux qui sont visibles (dans le champ de vision de la caméra).

Le champ de vision s’appelle le frustum En 3D, c’est l’espace compris entre les 6 plans. Calculer la partie visible = frustum culling

Exemple d’algorithme Un univers 3D = des millions de polygones, Si l’univers est plat, il suffit de plaquer une grille dont chaque case fait par exemple 10m2 Il suffit, quand on se déplace, de ne dessiner que ce qui se trouve dans les cases qui coupent le champs de vision. Si on a pré-calculé l’association polygones/case, et si l’univers est statique, on a rapidement la liste des cases visibles et donc la liste des polygones visibles

Illustration de l’algorithme précédent Champs de vision Partie visible Partie non visible

Mais ce n’est pas aussi simple ! Une simple grille ne suffit pas ! Ce n’est pas efficace et on a aussi envie aussi de : –Calculer des collisions, –Gérer les niveaux de détails, –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.

Scène de test ( polygones, 4000m2)

Algorithme à base de quadtrees

Principe Comme une grille, sauf que les cases ne font pas toutes la même taille. –Permet la gestion des niveaux de détails… On associe à chaque case les polygones qu’elle contient Construction –On part d’une case qui fait toute la surface de l’univers –On découpe récursivement l’univers en cases de plus en plus petites. Au final, on a un « arbre de cases », chaque case étant découpée en 4 cases

Exemple de quadtree Chaque feuille contient une liste de polygones

Comparaison grille/quadtree Beaucoup moins de tests avec le quadtree ! Très utilisé pour représenter des modèles numériques de terrain (gestion dynamique du niveau de détails, pas implémenté dans notre TER)

Exemple avec notre scène de test Ici une image avec une autre profondeur (sanbs quad), et comparer les perfs…

Conclusion sur les quadtrees Surtout adapté à des scènes 2D/2D et demie (grilles d’élévation, modèles numériques de terrains) Peu adaptés pour des bâtiments à étages, étant donné qu’on ne considère que les projections des polygones au sol… quoique… Les prochains algorithmes répondent à ces limitations…

Algorithme à base d’Octrees

Principe Idem quadtrees mais en 3D… Plus complexe à cause de la dimension supplémentaire!

Construction récursive

Detection des collisions Legende ici ! A quoi correspond ent les couleurs ?

Résultats Bien meilleur nombre d’images/s qu’avec les quadtrees, Très intéressant pour la détection de collisions …

Algorithmes à base d’arbre BSPs

Principe Etc…

Algorithme à base de portails

Principe Découpage du monde en Secteurs (pièces d’un bâtiment par exemple) –Quand on modélise l’univers, on le découpe en secteurs, –Les secteurs sont reliés entre eux (mitoyens) lorsqu’ils ont une partie commune, cela forme un graphe Portail = partie qui relie deux secteurs voisins, –Par exemple une porte et un mur

Principe (suite) Entre chaque image, on va calculer les parties visibles de l’univers Recherche des secteurs visibles = parcours de graphe non orienté –Nœuds = les pièces –Arêtes = partie commune entre deux secteurs (le lien entre deux pièces) Une fois le graphe parcouru, on a les relations de voisinages –Deux secteurs sont voisins lorsque depuis l’un on peut voir une partie de l’autre…

Avantages/inconvénients Complémentaire des algos précédents Nécessite une modélisation ad hoc du monde –Impossible de l’utiliser avec notre scène de test Algo non intégré au moteur 3D, mais programmes/tutoriaux de démonstrations des principes, en 2D…

les pièces Info dans un fichier annexe pas toujours concaves pb des coins besoin d’aide à la création

Synthèse

Heighmap autre facon de creer un monde Pour illustrer la différence Quadtree/Octree Si il y a une montagne les quadtrees montrent leurs limites screen

En d’autres termes Quadtree : circuit de voitures, modèle numérique de terrain… pas de superposition de polygones… Octree : Tomb Raider (utilisé aussi pour les collisions), etc… simple et efficaces BSP : quake like, unreal, etc…, optimisations multiples (arbres équilibrés, etc…) Portails : simple mais peu utilisé tels quels Souvent : mix de tous les algos (quake…)

Conclusion