Etude des structures de données au coeur des algos 3D des FPS.(BL2)

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

2. 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)…

3. 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

4. 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

5. 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 !

6. Comment afficher rapidement un univers immense ?

7. 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).

8. 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

9. 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

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

11. 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.

12. Scène de test (60.000 polygones, 4000m2)

13. Algorithme à base de quadtrees

14. 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

15. Chaque feuille contient une liste de polygones Exemple de quadtree

16. 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)

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

18. 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…

19. Algorithme à base d’Octrees

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

21. Construction récursive

22. Construction récursive

23. Construction récursive

24. Construction récursive

25. Construction récursive

26. Detection des collisions • Legende ici ! • A quoi correspondent les couleurs ?

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

28. Algorithmes à base d’arbre BSPs

29. Principe • Etc…

30. Algorithme à base de portails

31. Principe (statique) • Découpage du monde en Secteurs • Quand on modélise l’univers, on le découpe en secteurs • Les secteurs sont mitoyens lorsqu’ils 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

32. 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

33. Avantages/Inconvénients • N’affiche que ce qui est visible • Nécessite une modélisation ad hoc du monde • Impossible de l’utiliser avec notre scène de test • Non intégré au moteur 3D, mais tutorial de démonstration des principes, en 2D.

34. Modélisation des pièces • Information dans un fichier annexe : syntaxe • Ce n’est pas toujours simple, problèmes liés à la concavité des pièces et des coins.

36. Synthèse

37. 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

38. En d’autres termes • Quadtree : dans les jeux = circuit de voitures, • ET modèle numérique de terrain + frustum = LOD • Octree : dans les jeux style Lara • BSP : le plus utilise quake like, unreal,6 optimisations multiples (arbres équilibrés, etc…) • Portails : peu utilisés en tant que tels souvent rajouter sur un algo lancer de rayon

39. Quatrees (simples) Utilisés dans les jeux de voiture • en complément du frustum dans les terrains numériques • niveau de détail dynamique

40. ca depend du type de camera

41. Octrees (efficaces) Dans les jeux à la 3eme personne Efficaces avec les collisions Pour des mondes en hauteurs

42. Arbres BSP (optimaux)... 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 ... Portails (mélangés)