Gestion de scène pour les moteurs 3D

Transcription

1 Gestion de scène pour les moteurs 3D Mémoire de recherche Nicolas Baillard Promotion : M2IRT 2009 Option : Ingiénerie des jeux vidéo (IJV) juillet 2009 ITIN 10, avenue de l Entreprise Parc Saint-Christophe Cergy-Pontoise Cedex

2

3 1. Résumé et remerciements 1.1 Résumé La gestion de scène est une technique à la base du rendu 3D moderne. Elle est apparue avec les premiers moteurs 3D, et depuis elle n a jamais cessé d évoluer et de se diversifier. Aujourd hui, les utilisations qui en sont faites sont aussi variées que les algorithmes qu elle utilise. Dans ce mémoire, après avoir décrit ce qu est la gestion de scène, son fonctionnement et son apport au domaine du rendu 3D, nous nous interrogerons sur son évolution future. Comment la gestion de scène peut-elle s adapter aux dernières générations de processeurs et de cartes graphiques? Comment peut-elle contribuer à l augmentation de la qualité des rendus 3D? Quelles nouvelles fonctionnalités peut-elle apporter aux applications 3D de demain? 1.2 Abstract Scene management is one of the base technique used by modern 3D engines. It appeared with the first 3D engines and, since then, it has constantly been improving. Today, it is used in many different ways and uses many different algorithms. In this paper, we are going to describe with details what scene management is, how it works and how 3D rendering benefits from it. Then, we will describe its possible future evolutions. How can scene management techniques be adapted to take advantage of the latest generations of processors and graphic cards? How will it increase the quality of 3D rendering? What new features will it bring to tomorrow s 3D softwares? 1.3 Remerciements Tout d abord, je tiens à remercier vivement M. Pierre Morcello d avoir accepté d être mon tuteur et de m avoir guidé et soutenu dans la réalisation de ce projet. Son expérience et sa connaissance intime du domaine m ont été très précieuses. Je remercie aussi tout particulièrement M. Florent Michel, qui encadre notre formation avec dynamisme et clairvoyance ; il a su constamment renouveler son contenu et la placer systématiquement en phase avec l évolution des technologies. Enfin, je tiens à remercier chaleureusement mon ami Arnaud Boidard pour son enthousiasme communicatif. Gestion de scène pour les moteurs 3D juillet /83

4 2. Table des matières 3. Définition du sujet La recherche sur rendu 3D Définition d un moteur 3D Définition de la gestion de scène Questions fondamentales du mémoire 5 4. Analyse de l existant Environnement Le développement des moteurs 3D Le développement des processeurs multicœurs Audit/diagnostic de l existant Le rendu 3D Le rendu temps réel Les GPU Per formance et frame rate Le pipeline graphique Structure des moteurs 3D Ce qui pose des problèmes de per formances Les techniques d optimisation utilisées aujourd hui Culling basé sur le graphe de scène Les arbres BSP Les portails Octree et quadtree Adaptativ binary tree Mélange de plusieurs systèmes de culling L occlusion dynamique Anti-portails Occlusion map Test d occlusion utilisant le GPU Niveaux de détail Imposteurs Atlas de textures Terrain Voxel Paging et chargement en tâche de fond Optimisation de l utilisation de système de rendu Cohérence temporelle Utilisations actuelles des gestionnaires de scène Critique de l existant Faiblesses des algorithmes existants Faiblesses des implémentations existantes Méthodes/démarches utilisées Description des améliorations Améliorations souhaitables Solutions possibles Choix des solutions et argumentation/justification du choix 67 2/83 Gestion de scène pour les moteurs 3D juillet 2009

5 7. Description détaillée de la solution choisie L utilisation du multithreading pour gagner en per formance Facteurs limitants l efficacité du multithreading Synthèse des résultats Enseignements tirés, apport du travail Conclusions générales, perspectives d avenir Bibliographie Webographie Terminologie Abréviations Glossaire 82 Gestion de scène pour les moteurs 3D juillet /83

6 3. Définition du sujet 3.1 La recherche sur rendu 3D La recherche sur rendu 3D en temps réel a connu, au cours de ces dernières années, un essor phénoménal. Le grand intérêt porté à ce sujet est principalement dû à l industrie du jeu vidéo, secteur très porteur et lucratif. Les progrès réalisés dans le domaine rendu 3D temps réel, qui offre des images toujours plus époustouflantes, est principalement attribué à l évolution du matériel informatique. S il est vrai que la puissance des processeurs et des cartes graphiques compte pour beaucoup, il ne faut pas pour autant occulter les évolutions du logiciel. Les programmes ont suivi les progrès du matériel de façon à mieux en tirer profit et à simplifier son utilisation. La structure des applications réalisant du rendu 3D temps réel et les algorithmes qu elles utilisent représentent désormais un domaine de recherche à part entière. Ce mémoire traite de la gestion de scène. Il s agit d une technique logicielle utilisée par les applications 3D actuelles pour optimiser le rendu. Je présenterai son utilisation, la façon dont elle s est développée et proposerai des améliorations destinées à mieux tirer profit du matériel informatique récent, en particulier les processeurs multicœurs. 3.2 Définition d un moteur 3D Un moteur 3D (3D engine en anglais) est une librairie destinée à faciliter le développement d applications 3D temps réel. Leurs domaines d utilisation sont : - les jeux vidéo, - les interfaces homme-machine, - les programmes de simulation, - la réalité augmentée, - les effets spéciaux, - l imagerie médicale, - certaines applications scientifiques. Tout programme réalisant des images en 3D repose sur un système de rendu. Il s agit d un système capable de transformer un ensemble de données dans un espace 3D en une image 2D. Les plus utilisés aujourd hui sont les implémentations d OpenGL ou de DirectX. Un système de rendu est un programme de bas niveau, compliqué à appréhender et à utiliser. Travailler avec un système de rendu implique d utiliser des données 3D sous leur forme la plus primitive : des points, des polygones, des textures et des transformations géométriques sous forme de matrices. De plus, pour l utiliser il faut prendre en compte de nombreuses contraintes liées à son implémentation et à ses limitations. Le rôle du moteur 3D est de totalement masquer le système de rendu et d offrir aux 4/83 Gestion de scène pour les moteurs 3D juillet 2009

7 développeurs une interface de haut niveau bien plus simple à utiliser. Un développeur utilisant un moteur 3D peut concevoir son application à la façon d un metteur en scène, c est-à-dire en plaçant des éléments (personnages, objets ) dans un espace à trois dimensions appelé scène et en définissant un ou plusieurs points de vue en plaçant des caméras. En plus de cette simplicité d utilisation, le moteur 3D optimise l utilisation du système de rendu, permettant ainsi de gérer des scènes toujours plus complexes sans alourdir la tâche de ce dernier. En plus du rendu, la plupart des moteurs 3D prennent en charge d autres opérations comme : - le chargement des ressources (modèles, textures ) à partir de fichiers ou d archives compressées, - la gestion de modèles animés, - la gestion de différents effets spéciaux comme les particules. Par contre, le terme moteur 3D n englobe pas d autres composantes non liées au rendu 3D mais que l on retrouve fréquemment dans les applications 3D temps réel, comme la simulation physique, la détection des collisions, la gestion du son spacialisé Une librairie incluant ces éléments en plus d un moteur 3D est appelée moteur de jeu (game engine). 3.3 Définition de la gestion de scène Un gestionnaire de scène est l un des éléments principaux qui composent un moteur 3D. Il a la charge du placement des éléments sur la scène, qu il s agisse de modèles, d éclairages ou de caméras. Au fur et à mesure que les développeurs ont voulu créer des scènes plus complexes, plus grandes et avec plus d éléments, le gestionnaire de scène est devenu de plus en plus un facteur d optimisation. Les gestionnaires de scène utilisés dans les moteurs 3D actuels sont capables de réaliser des opérations comme : - le frustum culling, c est-à-dire l élimination des éléments de la scène qui sont hors du champ de vision de la caméra ; - l occlusion culling, c est-à-dire l élimination des éléments de la scène qui sont masqués par d autres ; - la gestion de la mémoire pour ne charger que les modèles et les textures utilisés par la partie visible de la scène ; - le level of detail, c est-à-dire le rendu en mode dégradé des éléments de la scène les plus éloignés de la caméra. Toutes ces techniques d optimisation font encore l objet de recherches aujourd hui. 3.4 Questions fondamentales du mémoire Le principal objectif d un gestionnaire de scène est d optimiser la vitesse de rendu d un moteur 3D. Or, pour optimiser un système, il convient en premier lieu d identifier les Gestion de scène pour les moteurs 3D juillet /83

8 facteurs qui dégradent le plus ses performances et de s y attaquer en priorité. Avec l évolution technologique du matériel, on constate que les facteurs qui limitent les performances des applications actuelles ne sont pas les mêmes que précédemment. Quels sont, aujourd hui, les facteurs qui limitent les performances des applications 3D temps réel? Il y a encore quelques années, le facteur le plus limitant était le nombre de polygones dessinés. Envoyer au système de rendu une quantité trop importante de polygones à dessiner dégradait fortement la fluidité de l application. Pour cette raison, les gestionnaires de scènes ont été principalement développés pour optimiser le nombre de polygones envoyés au système de rendu en supprimant les parties non visibles de la scène parce que hors champ de la caméra ou masquées par d autres parties. Aujourd hui, grâce à l évolution du matériel, le nombre de polygones n est plus le facteur le plus problématique (même s il reste important). Les performances sont désormais principalement limitées par l utilisation toujours plus intensive des shaders et l occupation mémoire des textures toujours plus grandes. Les dernières recherches en matière de rendu 3D portent sur l optimisation de ces deux facteurs. Comment les gestionnaires de scène peuvent-ils contribuer dans cette situation? Les développeurs d applications 3D cherchent à rendre des scènes toujours plus grandes et plus complexes. On peut voir, par exemple dans certains jeux vidéo de dernière génération, des scènes représentant une ville entière. Cette complexification des scènes augmente considérablement la taille des graphes de scène. Cela a un impact non négligeable sur les performances de l application car l augmentation de la taille du graphe de scène implique d avantage de calculs de la part du gestionnaire de scène lui-même. Dans de telles circonstances, la gestion de scène, dont le but premier est d optimiser la vitesse du rendu, risque à contrario de devenir un des facteurs limitant les performances de l application. Du côté du matériel, le tournant technologique actuel est la démocratisation rapide des processeurs multicœurs. On trouve couramment, dans les ordinateurs récents, des processeurs dotés de quatre cœurs, et ce nombre devrait grandir exponentiellement dans les prochaines années. Cette technologie offre de nouveaux espoirs de performances aux développeurs de moteurs 3D. Un processeur multicœurs permet à une application souhaitant réaliser des calculs intensifs de répartir ces calculs sur tout ou partie des cœurs. Le temps de calcul global d une opération complexe peut s en trouver considérablement réduit, on parle alors de parallèlisme. Mais cela implique que le programme ait été spécialement conçu pour tirer parti des possibilités offertes par ces processeurs. Si le parallèlisme ne peut pas être utilisé pour optimiser n importe quel algorithme, peut-il être utilisé pour optimiser l utilisation des graphes de scène? Comment les gestionnaires de scène peuvent-ils tirer parti de cette technologie pour augmenter leurs performances? 6/83 Gestion de scène pour les moteurs 3D juillet 2009

9 4. Analyse de l existant 4.1 Environnement Le développement des moteurs 3D Les développeurs d applications 3D temps réel, et tout particulièrement l industrie du jeu vidéo, sont toujours à la recherche de solutions techniques pour produire des graphismes plus beaux, des effets plus saisissants et des scènes plus vastes et plus riches. L enjeu est conséquent, sur l année 2008 les jeux vidéos dans le monde représenteraient un marché de millions d euros pour les jeux consoles et 3 493,5 millions d euros pour les jeux PC (source AFJV etude.htm). Aujourd hui, les studios de développement de jeux vidéos ne produisent que très rarement leurs moteurs 3D eux-mêmes. Étant donné l ampleur de la tâche, ils préfèrent acheter des licences d utilisation pour des moteurs développés par les entreprises spécialisées (CryEngine, Unreal Engine, Source Engine ) ou utiliser des produits opensource (Ogre, Irrlicht ). Le plus gros de la recherche sur les techniques de gestion de scène est réalisé par les développeurs de moteurs 3D mais aussi dans le domaine universitaire où de nombreuses thèses sont disponibles sur le sujet Le développement des processeurs multicœurs Concernant les processeurs multicœurs, Intel est le fondeur qui a le plus investi dans cette technologie. Il est donc dans son intérêt d encourager le plus possible son utilisation. Malheureusement pour lui, même si cette technologie est très prometteuse, elle reste difficile à utiliser et les programmeurs qui sont formés à son utilisation sont encore trop rares. Intel cherche donc à séduire les programmeurs en leur offrant des outils de développement dédiés et opensource (on peut notamment citer la librairie Threading Building Blocks) ainsi que de la documentation. Des recherches sur l utilisation des processeurs multicœurs dans les jeux vidéos, et plus précisément dans les moteurs 3D et les moteurs physiques, ont été publiées. 4.2 Audit/diagnostic de l existant Le rendu 3D La dénomination images 3D est le nouveau nom donné à ce qu on appelait dessin ou peinture en perspective à la Renaissance. Il s agit d une technique graphique permettant de donner une impression de relief et de profondeur à un observateur placé devant une image plate. La génération d images de synthèse en 3D par ordinateur repose sur les mêmes principes de projection sur un plan que ceux utilisés dans le domaine artistique. En informatique 3D, une image est obtenue à partir d un ensemble de données numériques représentant des formes dans un espace à 3 dimensions. Un système de rendu 3D est capable de produire une image 2D à partir de cet ensemble de données et d un point de vue dans l espace. Gestion de scène pour les moteurs 3D juillet /83

10 4.2.2 Le rendu temps réel Il est possible d utiliser un système de rendu 3D pour créer des animations. Pour donner l illusion du mouvement, on crée une série d images à partir des mêmes données numériques de départ mais en les modifiant légèrement entre chaque image. Ces images peuvent ensuite être projetées sur un écran tel un film de cinéma. Le domaine de l animation 3D se scinde en deux grands ensembles : la 3D précalculée et la 3D temps réel. La 3D précalculée est utilisée dans des applications qui ne requièrent pas, ou peu, d interactivité avec l utilisateur. Par exemple un film de cinéma. C est une technique en deux temps. D abord les images d une animation 3D sont calculées et stockées. Une fois qu elles sont toutes générées, l animation peut être affichée. Avec une telle technique, le temps de calcul du rendu importe peu, seul compte le résultat. S il est nécessaire d obtenir des images de très bonne qualité, on n hésitera pas à faire travailler le système de rendu pendant plusieurs heures (voire plusieurs jours) pour obtenir une animation de seulement quelques minutes. Au contraire, la 3D temps réel est utilisée dans les applications à forte interactivité, typiquement les jeux vidéos. Dans ce type d application, les images générées par le système dépendent entièrement des actions de l utilisateur. Il est donc difficile de les calculer à l avance. En 3D temps réel, les images sont calculées au fur et à mesure qu elles sont affichées. Le temps de calcul d une image devient le facteur déterminant, s il n est pas possible d afficher suffisamment d images suffisamment vite l utilisateur perdra l illusion du mouvement. On n hésite donc pas à diminuer la qualité des images générées pour accélérer leur temps de calcul. Les différences de contrainte entre la 3D précalculée et la 3D temps réel sont tellement importantes que chacune de ces disciplines est devenue un domaine de recherche à part entière, utilisant des techniques et des algorithmes totalement différents. Dans la suite de ce mémoire, nous ne traiterons que de la 3D temps réel, qui est le domaine qui connaît aujourd hui le plus grand essor, notamment à cause du secteur des jeux vidéos Les GPU Un GPU (Graphic Processing Unit) est un micro-processeur dédié au calcul d images 3D en temps réel. Ils ont été conçus pour soulager les CPU (Central Processing Unit), c est-à-dire les processeurs principaux, d une partie des opérations nécessaires au rendu d images 3D en temps réel. Dans les années 90, le succès des premiers jeux vidéos en 3D a poussé au développement d applications capables d afficher en temps réel des images de meilleure qualité, mais les processeurs équipant les ordinateurs de l époque se sont montrés incapables de supporter une telle quantité de calculs. Certains processeurs dotés de structures et de jeux d instructions spécifiques pour le rendu 3D sont apparus (notamment la technologie MMX d Intel). Mais cette solution a été rapidement supplantée par la technique qui consiste à déléguer les calculs graphiques à un GPU séparé du CPU. Cependant, la barrière fonctionnelle entre CPU et GPU est aujourd hui de plus en plus floue. Si les GPU d autrefois étaient entièrement dédiés au calcul graphique, ceux d aujourd hui peuvent être utilisés pour toutes sortes d applications requièrant du calcul intensif (simulation physique, analyse anti-virus ). D un autre côté, le développement 8/83 Gestion de scène pour les moteurs 3D juillet 2009

11 des processeur multicœurs pourrait, dans les années à venir, permettre de produire des processeurs capables d effectuer du rendu 3D temps réel sans l aide d un GPU Per formance et frame rate Le rendu temps réel se fait par frame. Une frame est une image affichée à l écran à un instant donné. La fluidité de l application dépend du nombre de frames par seconde que le système peut afficher. On parle de frame par seconde, ou de framerate en anglais. Le framerate est le point crucial de toute application 3D temps réel. S il est trop faible, l utilisateur sera frustré. Dans certains cas, un mauvais framerate peut entraîner chez l utilisateur une cinétose, c est-à-dire une sensation de mal de mer. Maintenir un framerate suffisant tout en générant des images de bonne qualité, tel est le défi de la programmation d applications 3D temps réel Le pipeline graphique Le pipeline graphique est le processus par lequel des données géométriques vectorielles tridimentionelles (points et polygones) sont transformées en pixels qui peuvent ensuite être affichés sur un écran. Il est divisé en trois étapes appelées : applicative, géométrique et discrétisation. Une frame doit passer par ces trois étapes avant d être affichée. La phase applicative, comme son nom le laisse supposer, est purement logicielle, contrairement aux deux autres qui sont généralement implémentées matériellement sur le GPU. C est sur cette phase que le développeur d applications 3D temps réel a le plus de contrôle. Selon l application, elle peut comporter des opérations sans lien direct avec le rendu 3D, tel que de la simulation physique ou de l IA par exemple. Son rôle est d envoyer dans le pipeline graphique les données vectorielles tridimensionelles qui doivent être affichées. Le rôle de la phase géométrique est de transformer ces données vectorielles 3D en données vectorielles 2D, en réalisant des transformations mathématiques de projection. Enfin, la phase de discrétisation se charge de transformer ces données vectorielles 2D en données discrètes, c est-à-dire des pixels. Le principal problème du pipeline graphique est qu il s agit d un processus séquentiel, les données traitées doivent transiter par les trois phases l une après l autre. Une phase doit donc attendre que la phase précédente ait terminé son travail pour s exécuter. La vitesse d exécution de tout le pipeline graphique est donc pénalisée par la phase qui a le temps d exécution le plus long. Pour accélérer le rendu d une frame, le développeur d applications 3D temps réel doit en premier lieu déterminer quelle phase est la plus pénalisante et l optimiser pour réduire son temps d exécution. Lorsqu il n est plus possible de réduire le temps d exécution de la phase la plus pénalisante, la solution pour accélérer le rendu consiste à implémenter des optimisations dans les phases situées en amont de celle-ci de façon à ce qu elles lui envoient moins de données à traiter. Pour cette raison, la phase applicative influence beaucoup les performances globales de l application. En effet, c est elle qui donne des données à traiter aux deux autres phases. Si elle envoie moins de données à traiter dans le pipeline graphique, le temps d exécution des deux autres phases s en trouvera considérablement réduit. C est ici que les techniques de gestion de scène entrent en jeu. Gestion de scène pour les moteurs 3D juillet /83

12 4.2.6 Structure des moteurs 3D Les phases de géométrie et de discrétisation sont implémentées dans un programme appelé système de rendu ou renderer. Les implémentations d OpenGL ou de DirectX sont des systèmes de rendu parmi les plus utilisés. Un développeur d applications 3D temps réel qui utilise un système de rendu n a besoin de réaliser que la phase applicative, c est-à-dire celle qui envoie des données vectorielles tridimensionelles dans le pipeline graphique. Malgré cela, l utilisation d un système de rendu reste parliculièrement délicate et fastidieuse. D une part les données 3D sont représentées sous une forme particulièrement primitive (polygones, points, couleurs, textures ), d autre part certains effets tels que les ombres ou la transparence sont très complexes à réaliser. Pour cette raison, les développeurs d applications 3D temps réel préfèrent placer une couche logicielle supplémentaire entre le système de rendu et leur application : un moteur 3D. Image 1 Structure d une application 3D temps réel Les moteurs 3D masquent la complexité du système de rendu aux yeux du développeur. Celui-ci n a plus à manipuler les données 3D sous forme de points et de polygones, mais peut utiliser des objets de plus haut niveau. Il peut construire son application à la façon d un metteur en scène, en plaçant des éléments (des modèles, des animations, des éclairages, des effets spéciaux ) sur une scène virtuelle. En plus de cela, les moteurs 3D offrent, en général, les services suivants : - import de modèles créés dans des logiciels de modélisation 3D (3DS Max, Maya ), - gestion des modèles animés par squelettes ou morphing, - gestion de différents effets spéciaux (éclairages, ombres, transparence ), - choix du système de rendu à utiliser (entre OpenGL ou DirectX selon la plateforme par exemple). Les moteurs 3D actuels offrent tous une API fortement basée sur la programmation orientée objet. On y trouve toujours les mêmes types d objets, même si leur dénomination et leur utilisation varie d un moteur à l autre. Scène Tout d abord la scène. C est un espace à 3 dimensions représenté par un repère orthonormé d axes X, Y et Z. C est dans cet espace que l utilisateur du moteur 3D peut placer différents types d éléments (décors, personnages, effets spéciaux ) qui seront dessinés à l écran. Dans tous les moteurs 3D, la scène est gérée par un objet appelé gestionnaire de scène. Cet objet a la charge de maintenir une liste de tous les éléments présents sur la 10/83 Gestion de scène pour les moteurs 3D juillet 2009

13 scène afin de les envoyer au système de rendu lorsqu une frame doit être dessinée. En pratique, dans les moteurs 3D actuels, le gestionnaire de scène fait bien plus que cela. De nombreuses optimisations peuvent y être implémentées, nous les décrirons dans la suite de ce mémoire. Nœud Ensuite les nœuds (node). Ce sont des objets qui ont une position et une orientation sur la scène. L utilisateur peut les placer, les orienter et les faire bouger avec toute une panoplie de fonctions mathématiques offertes par le moteur 3D. Graphe de scène Les nœuds sont rangés dans une structure hiérarchique qui prend la forme d un arbre. Un nœud peut avoir plusieurs enfants mais seulement un parent. Ainsi, une transformation géométrique (translation ou rotation) appliquée sur un nœud se répercute sur ses descendants, ce qui permet de propager l opération à un groupe de nœuds. Cette structure hiérarchique est appelée graphe de scène. Une utilisation assez évidente du graphe de scène est la modélisation d un système solaire. Le nœud racine correspondrait au soleil. Les nœuds de chaque planète seraient des enfant du nœud soleil, et les nœuds des lunes seraient des enfants des nœuds de leur planètes respectives. Ainsi une rotation appliquée au soleil entraîne une rotation de toutes les planètes et de leurs lunes. La gestion de graphe de scène est confiée au gestionnaire de scène. Image 2 Graphe de scène représentant une partie du système solaire Gestion de scène pour les moteurs 3D juillet /83

14 Maillages Un maillage (mesh) est un objet qui peut être dessiné en 3D. Concrètement c est un ensemble de points, de polygones et de textures. Un maillage ne peut pas être placé directement sur la scène, il n a pas de position et d orientation, il faut utiliser des nœuds pour cela. Par exemple, pour réaliser une scène comportant trois personnages identiques, il faut un maillage qui représente le personnage et trois nœuds auxquels on va associer notre maillage. Image 3 La scène (à droite) comporte trois personnages identiques. Au niveau du moteur il n existe qu un seul objet maillage et trois objets nœud, un pour chaque personnage. Maillages animés Tout comme les maillages, les maillages animés sont composés de points et de polygones, mais possèdent en plus des informations permettant de changer dynamiquement la position des points. Typiquement, les maillages animés sont utilisés pour les personnages, pour faire bouger leurs membres ou modifier l expression de leur visage. Il existe deux techniques permettant d animer un modèle : les squelettes et le morphing. Les squelettes sont surtout utilisés pour faire bouger les membres des personnages (souvent la mâchoire aussi pour les faire parler). La technique consiste à mettre des os et à affecter un coefficient d influence aux sommets (vertex) du modèle par rapport aux os. Quand les os bougent, les sommets suivent. Cette opération se fait dans le logiciel de modélisation 3D et cela s appelle le skining. Il est généralement possible de placer des nœuds sur les os d un maillage animé de façon à ce que le nœud suive le déplacement de l os. Cette technique est utilisée pour fixer des éléments sur les membres d un personnage en mouvement, par exemple une arme tenue dans la main ou un casque porté sur la tête. Dans le cas du morphing les sommets transitent chacun depuis leur position initiale vers leur position finale selon une interpolation linéaire. Particules Les émetteurs de particules sont la base de la plupart des effets spéciaux visibles dans les applications 3D temps réel. Il s agit de systèmes capables de créer un grand nombre de petits objets, appelés particules, dans la scène. Selon le cas, ces objets peuvent être des modèles 3D, 2D ou simplement des points. En réglant de nombreux paramètres, 12/83 Gestion de scène pour les moteurs 3D juillet 2009

15 comme le nombre de particules émises, la fréquence d émission, la durée de vie des particules et leur apparence, il est possible de créer toute sorte d effets visuels (fumée, flamme, éclair, sabre laser ). Lumière Différents types de sources de lumière peuvent également être placées sur la scène. Sans source de lumière, rien n est visible. Dans la réalité, nous percevons les objets qui nous entourent grâce à la lumière qui se refléchit dessus et atteint les cellules de la rétine. Cette réflexion est différente selon la source de lumière et la nature de l objet sur lequel elle se réfléchit. De plus, la lumière reflétée sur les objets de notre environnement va indirectement éclairer d autres objets. Pour obtenir des images en 3D un tant soit peu réalistes, le système de rendu doit reproduire ces phénomènes. Malheureusement, calculer l éclairage d une scène en utilisant les lois de l optique demande bien trop de calculs pour pouvoir être utilisé en 3D temps réel (la 3D précalculée, elle, ne s en prive pas!). On utilise donc des algorithmes d éclairages approximatifs. La recherche sur l éclairage en 3D temps réel a beaucoup progressé ces dernières années. Détailler le fonctionnement des algorithmes d éclairage est hors du contexte de ce mémoire. Image 4 Cette image à été créée en rendu précalculé grâce au moteur de rendu Maxwell qui simule la physique de la lumière d une façon très précise. Obtenir ce type d image en temps réel est aujourd hui impossible. Shaders Les shaders sont des programmes capables d affecter le fonctionnement du pipeline graphique. Ils peuvent être utilisés pour obtenir des effets de rendu particuliers sur tout ou partie d un maillage, voire d une scène entière. On distingue principalement les sommets shaders et les pixels shaders. Les vertex shaders interviennent au niveau de l étape géométrique. Ils peuvent modifier la façon dont certains sommets de la scène seront traités par le pipeline graphique. Gestion de scène pour les moteurs 3D juillet /83

16 Les pixels shaders interviennent au niveau de l étape de discrétisation. Ils peuvent modifier la couleur finale de certains pixels de l image. Les shaders sont généralement exécutés sur le GPU. Ils bénéficient ainsi de l architecture fortement parallèle de ce dernier, ce qui leur donne de bonnes performances. Les shaders sont écrits par l utilisateur du système de rendu dans des langages de programmation spécialisés. Les effets qu ils permettent de réaliser sont très variés. Ils peuvent par exemple être utilisés pour : - créer des textures avec des propriétés d éclairage particulières (peau, eau, lave ), - répéter des motifs sur une surface ou un volume (un carrelage sur un plan, un immeuble avec plusieurs étages sur un parallépipède ), - créer des effets météorologiques (brouillard, neige, pluie ). La liste ci-dessus n est pas exhaustive. Image 5 Dans la démonstration technique de Nvidia, Nalu daughter of the deep sea, les cheveux de la sirène sont crées et animés grâce à un vertex shader (détection de collision comprise). Leur couleur est calculée grâce à un pixel shader. 14/83 Gestion de scène pour les moteurs 3D juillet 2009

17 Caméra Le but de la création d une scène 3D est qu elle puisse être dessinée sous différents points de vue. Pour définir ces points de vue, on place des caméras sur la scène. De nombreux paramètres peuvent être utilisés pour définir la focale de la caméra et son champ de vision. Ces paramètres détermineront la portion de la scène qui sera visible sur le rendu et la facon dont la perspective y sera restituée. Dans certains cas, plusieurs caméras peuvent être utilisées pour rendre différentes parties d une même image. Image 6 Le jeu Portal, de Valve, utilise plusieurs caméras situées sur la même scène pour rendre différentes parties de l image vue par le joueur. Surface de rendu Il s agit du buffer de pixels dans lequel le rendu sera écrit. La plupart du temps, ce sera tout ou partie de la surface d un écran. Mais il est aussi possible de faire un rendu dans un buffer qui ne sera pas affiché sur l écran, mais à la place utilisé comme texture dans un autre rendu. Cette technique de render to texture est utilisée pour réaliser certains effets d éclairages et d ombrages. File de rendu La file de rendu, file de rendu en anglais, est une file d attente dans laquelle le gestionnaire de scène place les éléments qui doivent être envoyés au système de rendu pour Gestion de scène pour les moteurs 3D juillet /83

18 dessiner la prochaine frame. Certains ajustements sont effectués dans la file de rendu avant d envoyer les éléments au système de rendu. Par exemple, la plupart des systèmes demandent à ce que les éléments transparents leurs soient envoyés après tous les autres de façon à pouvoir mixer leurs couleurs avec celles des éléments opaques déjà dessinés. La file de rendu se charge alors d envoyer les éléments dans le bon ordre. Certaines optimisations concernant l utilisation du système de rendu peuvent être implémentées au niveau de la file de rendu. Nous les décrirons par la suite. Gestion du temps Le but de la 3D temps réel étant de créer des images animées, une base de temps est nécessaire. C est en déplaçant les éléments présents sur la scène un peu entre chaque frame que l on crée l illusion du mouvement. Or tout joueur de jeux vidéos sur PC sait que le nombre de frames par seconde est tout sauf constant. Il peut varier du simple au double selon la puissance de l ordinateur sur lequel l application fonctionne. Il peut aussi varier pendant l exécution de l application selon la somme de calculs demandée au système. Pour assurer la cohérence des mouvements, le moteur 3D utilise l horloge de l ordinateur, via le système d exploitation. Séquence de rendu d une frame Un moteur 3D fonctionne comme une boucle. Chaque frame rendue correspond à un tour de cette boucle. Les étapes nécessaires pour rendre une frame sont les suivantes : - D abord s exécute tout le code de l application qui ne dépend pas du moteur 3D. Acquisition des commandes que l utilisateur a entrées au clavier, à la souris et/ou au joystick. Exécution de l IA et de la simulation physique, si l application en utilise une. A partir des données calculées par l IA et/ou la physique, l application va placer des éléments sur la scène, ou déplacer ceux qui s y trouvent déjà. Par exemple, dans un jeu vidéo où le joueur contrôle un personnage au joystick, si l application détecte que le joueur a poussé le joystick vers l avant, elle va déplacer le personnage vers l avant sur la scène et déclencher une animation de son maillage pour donner l impression qu il marche. - Ensuite le moteur 3D entre en action. Le gestionnaire de scène liste les éléments qui doivent être dessinés et les place dans la file de rendu. - La file de rendu envoie les données géométriques de ces éléments au système de rendu. - Le système de rendu calcule l image et l affiche. Dans la plupart des applications actuelles, toutes ces opérations sont exécutées successivement. Cependant, sur les machines équipées de plusieurs processeurs, ou de processeurs multicœurs, il est possible d exécuter certaines opérations en parallèle. Par exemple, pendant que le moteur 3D et le système de rendu fonctionnent sur un processeur pour calculer la frame en cours, la physique et l IA peuvent être calculées sur les autres processeurs pour préparer la frame suivante. 16/83 Gestion de scène pour les moteurs 3D juillet 2009

19 4.2.7 Ce qui pose des problèmes de performances Malgré l évolution constante de la puissance des CPU et des GPU, les applications 3D temps réel sont toujours sujettes à des problèmes de performances. Les images produites par ces dernières sont encore loin de rivaliser en qualité avec les images produites en 3D précalculée. Afin de pouvoir proposer des techniques d optimisation, il convient d abord de lister les différents facteurs de limitation des performances des applications 3D temps réel. Le nombre de polygones Il est longtemps resté le principal facteur limitant. Pour augmenter la qualité et le réalisme des images 3D, il est nécessaire d y mettre plus de détails. Pour ce faire, il faut dessiner la scène avec plus de polygones, de façon à mieux rendre la forme des objets. Image 7 Deux modélisations d un même personnage de jeu vidéo. La première offre beaucoup de détails et utilise un nombre conséquent de polygones. La seconde est une version simplifiée qui en utilise beaucoup moins. On parle de modèle high poly et low poly. Dans les jeux vidéos, les premiers sont généralement utilisés pour les scènes cinématiques faites en rendu précalculé. Les autres sont utilisés pour le jeu lui-même qui fonctionne en rendu temps réel. Le temps de traitement d une frame augmente avec le nombre de polygones que le système de rendu doit traiter pour la dessiner. Pour cette raison, les premières techniques d optimisation développées dans les moteurs 3D ont consisté à réduire le nombre de polygones qui composent une image sans altérer sa qualité. Ces optimisations sont souvent implémentées au niveau du gestionnaire de scène. Nous les décrirons dans la suite de ce mémoire. Les changements d état Les systèmes de rendu utilisés en 3D temps réel, tels que OpenGL ou DirectX, fonctionnent comme des machines à états. Ils communiquent avec l application qui les utilisent via des commandes qui font changer leur état interne. Par exemple, certaines comman- Gestion de scène pour les moteurs 3D juillet /83

20 des indiquent au système de rendu que les sommets qui lui seront envoyés par la suite seront affectés par une transformation géométrique. D autres indiquent que les sommets devront être dessinés avec une couleur ou une texture particulière. Certaines de ces commandes, en particulier le changement de la texture courante, demandent un temps d exécution non négligeable. De plus, dans le cas le plus courant où le système de rendu est implémenté sur un GPU, l envoi d une commande nécessite une communication entre le CPU et le GPU, ce qui est aussi coûteux en temps. Le rendu d une scène complexe constituée de nombreux objets peut être sérieusement affecté par l overdose de changements d états. Pour réduire ce désagrément, il convient de bien organiser la façon dont les données géométriques sont envoyées au système de rendu. Par exemple, il est possible de trier tous les polygones de la scène selon la texture qu ils utilisent. On peut ainsi envoyer tous les polygones utilisant une même texture ensemble, ce qui réduit le nombre de changements de la texture courante nécessaire. Les optimisations de ce type sont implémentées au niveau de la file de rendu. La taille des textures Pour être utilisée par le système de rendu, une texture doit être chargée dans la mémoire du GPU. Elle doit y être stockée sous forme décompressée, c est-à-dire sous forme d un ensemble de pixels (pas de JEPG, de GIF ou de PNG en mémoire). Les cartes graphiques haut de gamme sont équipées, aujourd hui, de Mo de mémoire, et cette mémoire doit contenir, en plus des textures, les polygones nécessaires au rendu de la scène. Le moteur 3D doit gérer cette mémoire en y chargeant uniquement les textures nécessaires au rendu de la frame en cours. Le transfert d une texture, depuis la mémoire de l ordinateur vers la mémoire du GPU, est une opération coûteuse en temps. Utiliser des textures plus grandes permet de dessiner la scène avec plus de détails, ce qui augmente la qualité des images rendues. Mais le rendu d une scène qui utilise trop de textures trop grandes pour être toutes logées dans la mémoire du GPU peut facilement faire chuter le framerate. De plus, le rendu de certaines scènes nécessite des textures aussi grandes que la scène elle-même, par exemple une carte routière projetée sur un terrain. De telles textures sont bien trop grandes pour être stockées entièrement dans la mémoire du GPU. Le calcul des shaders Grâce à leur grande flexibilité, l utilisation des shaders s est largement démocratisée ces dernières années. De nombreux effets visuels utilisés dans les applications récentes sont possibles uniquement grâce aux shaders. Malheureusement, leur utilisation alourdit considérablement la tâche du système de rendu. Même si les GPU actuels disposent d une puissance de calcul monstrueuse, l utilisation de shaders trop complexes, sur un trop grand nombre de polygones ou de pixels, peut faire considérablement baisser le framerate. 18/83 Gestion de scène pour les moteurs 3D juillet 2009

21 Les particules La qualité des effets créés avec des émetteurs de particules est généralement liée au nombre de particules créées. Plus il y a de particules, plus l effet sera convaincant. Le rendu d un nombre très élevé de particules par le GPU peut parfois causer des soucis de performance, mais c est au niveau du CPU que leur utilisation pose le plus de problèmes. Chaque particule doit être mise à jour à chaque frame, ce qui implique une grosse quantité de calculs. Le problème est d autant plus important lorsque la mise à jour des particules nécessite des calculs de physique (collision des particules avec leur environnement). Image 8 Dans le jeu FarCry 2 de Ubisoft, les effets de flammes et de fumée sont créés avec des particules Les techniques d optimisation utilisées aujourd hui Le but de l optimisation d une application 3D temps réel est de lui permettre de rendre des images de meilleure qualité sans augmenter la puissance du matériel sur laquelle elle fonctionne. Nous avons expliqué dans le chapitre précédent que le rendu d une frame de meilleure qualité implique un temps de calcul plus long, ce qui nuit à la fluidité, et donc au confort d utilisation. Optimiser une application 3D temps réel consiste donc à réduire le temps de rendu d un frame sans dégrader la qualité du résultat obtenu. Le temps gagné peut ensuite être mis à profit pour rendre des frames de meilleure qualité. Pour réduire le temps de rendu d une frame sans rogner sur la qualité, la première solution envisageable consiste à optimiser les algorithmes utilisés. Préférer des fonctions mathématiques plus rapides et améliorer leur implémentation permet de gagner en temps d exécution. Malheureusement, cette solution a atteint ses limites depuis longtemps. Aujourd hui, les algorithmes de rendu 3D sont au point, et, à moins d une innovation mathématique très improbable, il n est pas possible de les optimiser davantage. L autre solution consiste à réduire la quantité de travail imposée au système de rendu. Cela est possible en lui envoyant moins de données à traiter, ou en lui épargnant certaines opérations fastidieuses. Puisqu on ne veut pas dégrader la qualité, cela implique de supprimer uniquement des données, ou des opérations, n ayant pas, ou peu, d impact sur le rendu final. Idéalement, la différence entre une frame produite sans optimisation, et une frame produite avec optimisation, ne devrait pas être visible. Gestion de scène pour les moteurs 3D juillet /83

22 La suite de ce chapitre détaille plusieurs techniques d optimisation couramment utilisées. Frustum culling Le point de vue à partir duquel une scène 3D est rendue est défini grâce à un objet du moteur 3D de type caméra. Le champ de vision de la caméra est représenté par un volume, généralement de forme de section de pyramide, appelé frustum. Les polygones de la scène qui ne se trouvent pas dans les limites du frustum ne sont pas visibles par l utilisateur, il n est donc pas nécessaire de les dessiner. Ignorer ces polygones est un moyen de gagner du temps sur le rendu de la frame sans en dégrader la qualité. L opération qui consiste à ignorer les polygones qui sont hors du frustum est appelée frustum culling. En pratique, dans la plupart des applications 3D temps réel, il est rare que l utilisateur puisse voir toute la scène en même temps. Par exemple, dans un jeu vidéo où le personnage se déplace dans un labyrinthe, le joueur ne peut jamais voir le labyrinthe dans son entier. Dans une telle situation, l utilisation du frustum culling est très efficace. Image 9 Le frustum, ici en bleu, délimite la partie visible de la scène. L étape géométrique du pipeline graphique implémente toujours un système de frustum culling. Tous les polygones qui lui sont envoyés sont testés, un par un, avec le frustum. Ceux qui sont totalement à l extérieur sont ignorés, ceux qui ne sont que partiellement à l intérieur sont coupés. Si cette opération permet d optimiser le rendu, elle n est cependant pas très efficace. D une part, le test de tous les polygones avec le frustum prend un temps non négligeable, et il augmente avec le nombre de polygones à tester. D autre part, dans la pratique, l étape géométrique du pipeline graphique est implémentée sur le GPU. Si le frustum culling se fait sur ce dernier, cela veut dire qu il est nécessaire de lui envoyer l ensemble des poly- 20/83 Gestion de scène pour les moteurs 3D juillet 2009

23 gones de la scène, ce qui est très pénalisant car la communication entre le CPU et le GPU est lente. La solution consiste à effectuer le frustum culling au niveau applicatif, c est-àdire sur le CPU. Cela permet de n envoyer au GPU que les polygones nécessaires. Pour éviter de tester chaque polygone de la scène un par un avec le frustum (ce qui prendrait encore plus de temps sur le CPU que sur le GPU), on utilise des systèmes permettant d accélérer les tests comme les volumes englobants (bounding volumes) ou le partitionnement de l espace (space partitioning en anglais). Volumes englobants Une façon simple de mettre en œuvre du culling est d utiliser des volumes englobants (bounding volumes en anglais). Il s agit de volumes de formes simples, resserrés au maximum autour d un objet. Ces volumes peuvent être des sphères, des boîtes orientées ou des boîtes alignées sur les axes de la scène. Image 10 Boîte englobante resserrée autour du personnage. Les moteurs 3D calculent automatiquement des volumes englobants pour tous les maillages à partir de leurs sommets. Ils ne sont pas recalculés à chaque frame mais seulement lorsque le maillage est modifié, par exemple par une animation. Chaque nœud auquel est attaché un ou plusieurs maillages possède une boîte englobante qui est la somme de toutes les boîtes englobantes de ses maillages. La boîte englobante d un nœud prend en compte sa mise à l échelle (scale en anglais). Les boîtes alignées sur les axes sont plus faciles à calculer que les autres types de volumes englobants. En effet, il suffit de faire une itération sur tous les sommets d un maillage pour déterminer les coordonnées maximum et minimum du maillage selon les trois axes X, Y et Z. Pour cette raison, la majorité des moteurs 3D utilise des boîtes englobantes alignées sur les axes de la scène. Avant d envoyer un maillage au système de rendu, le moteur 3D teste toujours sa boîte englobante avec le frustum. Si la boîte englobante d un élément de la scène n a pas d intersection avec le frustum, alors l élément n en a pas non plus et est donc non visible. L avantage de ce système est qu il est beaucoup plus rapide de tester l intersection d une boîte englobante avec le frustum que de tester l intersection de chaque polygone de l élément avec le frustum. L inconvénient est que le système peut parfois se tromper. Il peut arriver qu une boîte englobante soit visible alors que l élément qu elle contient ne l est pas (par exemple, seul coin de la boîte englobante est visible, alors que le maillage 3D ne s étend pas jusque dans ce coin). Dans ce cas, l élément sera dessiné pour rien, mais cela arrive assez rarement. Partitionnement de l espace Le partitionnement de l espace est le découpage de la scène en un certain nombre de régions. Chacune de ces régions est représentée par un volume géométrique, et chaque polygone de la scène n appartient qu à une seule région. Ainsi, on peut tester l intersection des différentes régions par rapport au frustum. Si une région est totalement en dehors du frustum alors tous ses polygones le sont également. Le découpage de la scène Gestion de scène pour les moteurs 3D juillet /83

24 Image 11 La première image montre la scène découpée en régions (en rouge) et le frustum (en bleu). La seconde image montre ce qu il reste à la fin de l étape applicative. La dernière image montre ce qu il reste à la fin de la phase géométrique. Seule cette partie de la scène sera dessinée. en régions est calculé avant le lancement de l application et il ne change pas pendant son exécution. Le culling réalisé par partitionnement de l espace est moins précis que celui réalisé en testant les polygones un par un. Les limites des régions ne peuvent jamais parfaitement correspondre aux limites du frustum, par conséquent un certain nombre de polygones situés en dehors du frustum ne sont pas éliminés. Cette technique ne sert donc qu à dégrossir le travail pour l étape géométrique. Cependant, le gain en temps d exécution est énorme car il réduit fortement le nombre de tests d intersection avec le frustum ainsi que le nombre de polygones envoyés au GPU. La difficulté dans la mise en œuvre du partitionnement de l espace est de trouver la bonne taille pour les régions. Si elles sont trop grandes, le culling ne sera pas assez efficace car il n éliminera pas suffisamment de polygones. Si elles sont trop petites, la scène sera découpée en un nombre de régions trop important. Plus il y a de régions sur la scène, plus le CPU passe de temps pour les tester toutes, avoir trop de régions est donc contre-productif. Afin de ne pas être obligé de tester toutes les régions de la scène à chaque frame, elles sont rangées dans une structure hiérarchique. Les régions adjacentes sont regroupées en régions plus grandes, elles-mêmes regroupées en régions encore plus grandes. À chaque rendu de la scène, le système commence par tester les régions les plus grandes. Si une région n est pas dans le frustum, alors on sait que toutes ses sous-régions n y sont pas non plus, il n est donc pas nécessaire de les tester. Il existe plusieurs schémas de partitionnement de l espace. Selon les besoins de l application, certains sont plus efficaces que d autres. Occlusion culling Même s ils sont à l intérieur du frustum, certains polygones de la scène peuvent ne pas être visibles par l utilisateur s ils sont cachés par d autres se trouvant devant eux. Par exemple, si un mur se trouve entre la caméra et un personnage, ce dernier ne sera pas visible par l utilisateur (en supposant bien sûr que ce mur ne soit pas transparent). Ne pas envoyer les polygones occultés à l étape géométrique du pipeline graphique permet d optimiser le rendu. On appelle cette opération l occlusion culling. 22/83 Gestion de scène pour les moteurs 3D juillet 2009

25 Comme le frustum culling, l occlusion culling est généralement implémenté au niveau applicatif. Il peut tirer parti du partitionnement de l espace, si une région est totalement occultée, aucun de ses polygones n est visible Culling basé sur le graphe de scène Quand la scène est trop complexe et comporte trop d éléments, tester toutes leurs boîtes englobantes devient trop long et pénalise les performances. Pour limiter le nombre de tests nécessaires, on peut s appuyer sur le graphe de scène. Chaque nœud du graphe de scène possède sa boîte englobante, et elle englobe tous les maillage attachés au nœud, ainsi que toutes les boîtes englobantes des enfants du nœud. Par exemple, un personnage tenant une épée et un bouclier sera placé dans le graphe de scène avec trois nœuds : un pour le personnage lui-même, un pour l épée et un pour le bouclier. Puisque la position de l épée et du bouclier dépend de la position du personnage (si le personnage bouge, l épée et le bouclier bougent avec lui), leurs nœuds seront enfants du nœud du personnage. Image 12 Personnage tenant une épée et un bouclier. À droite, le graphe de scène correspondant. Dans ce graphe, les nœud de l épée et du bouclier sont enfants du nœud du personnage. L épée et le bouclier possèdent chacun leur boîte englobante. Elles sont comprises dans la boîte englobante du personnage. Les nœuds de l épée et du bouclier possèdent chacun leur boîte englobante. La boîte englobante du nœud du personnage, quant à elle, englobera non seulement le personnage mais aussi l épée et le bouclier. Au moment du rendu, le moteur 3D testera la boîte englobante du personnage avec le frustum. S il n y a pas d intersection, cela signifie que le personnage n est pas visible et que l épée et le bouclier ne le sont pas non plus. Il n est donc pas nécessaire de tester leur boîte englobante. Cette solution a l avantage de la simplicité. Elle n est cependant pas assez efficace pour le rendu de scènes très complexes. Dans le cas d une scène comportant un grand nombre de personnages, il est toujours nécessaire de tester les boîtes englobantes de ceux-ci une par une. Pour limiter davantage le nombre de tests, il faut recourir à une méthode de partitionnement de l espace. Gestion de scène pour les moteurs 3D juillet /83

26 Les arbres BSP BSP signifie Binary Space Partitioning, ou, en français, partitionnement de l espace binaire. Ce système permet de diviser un espace en 3D à l aide de plans de coupe pour obtenir un ensemble de régions convexes. Chacune d entre elles contenant une partie des polygones de la scène. Ces régions peuvent être rangées dans un arbre binaire, c està-dire un arbre dont chaque nœud n a que deux enfants. Chaque nœud de l arbre correspond à un plan de coupe et chaque feuille correspond à une région. Image 13 Division d une scène à l aide d un algorithme BSP étape par étape. Le plan de coupe 1 divise la scène en deux. La région A, à gauche, est convexe. Il n est pas nécessaire de la découper davantage. Le plan de coupe 1 forme le nœud racine de l arbre BSP et la région A devient une feuille. Le plan de coupe 2 divise la partie de la scène située à gauche du plan de coupe 1. Il forme ainsi deux régions convexes B et C. Le plan de coupe 2 forme un nouveau nœud de l arbre BSP et les régions B et C forment deux feuilles. 24/83 Gestion de scène pour les moteurs 3D juillet 2009

27 Les origines Le BSP date des prémices du rendu 3D sur ordinateur. À l origine, le BSP n a pas été conçu pour réaliser du culling, mais comme algorithme permettant de trier les polygones d une scène par ordre de profondeur dans un champ de vision donné. En effet, l un des plus gros problèmes posés par les systèmes de rendu de l époque était que les polygones situés en arrière plan devaient obligatoirement être dessinés avant ceux placés devant eux. Sans cela, les polygones placés derrière d autres polygones risquaient d être dessinés par dessus ces derniers! Trier les polygones par ordre de profondeur à chaque frame nécessitait trop de calculs, ce qui pénalisait sérieusement les performances. L utilisation d un arbre BSP permet de résoudre ce problème. La scène à dessiner doit être préalablement partitionnée et rangée dans un arbre BSP. Cette opération est réalisée en précalcul. Pendant le rendu, l arbre est exploré de manière récursive. A chaque nœud, la position de la caméra dans l espace est testée par rapport au plan de coupe pour savoir si elle se trouve devant ou derrière lui. Ainsi, on sait que les polygones situés du côté du plan où se trouve la caméra sont plus proches d elle que ceux situés de l autre côté. Image 14 Le plan de coupe central divise la scène en deux régions convexes. La caméra se situant dans la région A, les polygones de cette région sont forcément plus proches d elle que ceux de la région B. Si on parcourt la totalité de l arbre en explorant toujours les parties éloignées avant les parties proches, on est certain de rencontrer les régions les plus éloignées en premier, et les plus proches en dernier. Il suffit d envoyer les polygones des régions au système de rendu au fur et à mesure de l exploration de l arbre. Les régions doivent obligatoirement être de forme convexe de façon à ce que l ensemble de leurs polygones puisse être envoyé au système de rendu dans n importe quel ordre sans risque d être superposé sur l image. Il faut noter que cette utilisation du BSP n implique aucun culling. La totalité de la scène est rendue. Gestion de scène pour les moteurs 3D juillet /83

28 Frustum et oculsion culling grâce au BSP Le jeu Doom, le premier jeu de type FPS (first person shooter ou jeu de tir en vue subjective) au monde, est sorti en Son moteur de rendu, révolutionnaire pour l époque, utilise le BSP pour réaliser du culling, c est-à-dire éviter de rendre des parties non visibles de la scène. Image 15 Le jeu Doom de id Software, premier FPS au monde. Le principe est simple. Le BSP est utilisé en sens inverse, c est-à-dire pour rendre les polygones les plus proches de la caméra en premier et les plus éloignés en dernier. Pour éviter que certains polygones ne se dessinent les uns par dessus les autres, le moteur de rendu de Doom utilise un masque qui empêche un même pixel d être dessiné plusieurs fois. L arbre BSP est parcouru, en explorant toujours les parties les plus proches en premier, jusqu à ce que tous les pixels de l image finale aient été dessinés. Le rendu est alors terminé, il n est plus nécessaire de continuer à explorer l arbre BSP ni d envoyer d autres polygones au système de rendu car ils sont forcément placés derrière ceux qui ont déja été dessinés, et donc non visibles. Seule la partie visible de la scène est envoyée au système de rendu, ce qui augmente sensiblement les performances. Ce coup de génie a fait de Doom le premier jeu 3D immersif jouable sur des machines accessibles au grand public. 26/83 Gestion de scène pour les moteurs 3D juillet 2009

29 BSP + PVS PVS signifie Potentially Visible Set. Utilisé conjointement à un système de partitionnement de l espace, le PVS permet de réaliser de l occlusion culling, c est-à-dire d éliminer des parties de la scène non visibles car masquées par d autres. Pour une scène découpée en plusieurs régions par un système de partitionnement de l espace, le PVS fournit une table indiquant les régions visibles, ou non, depuis chaque région. Cette technique a été utilisée conjointement avec le BSP dans le moteur du jeu Quake, sorti en Image 16 La scène (à gauche) est divisée en trois régions A, B et C. Le PVS (à droite) est un tableau qui indique la visiblité entre ces régions. Avec l apparition des premières cartes graphiques, et l amélioration des systèmes de rendu 3D, l algorithme utilisé par Doom est devenu obsolète. Il n est plus nécessaire de trier les polygones par ordre de profondeur, les GPU possèdent un système appelé tampon de profondeur (ou Z-buffer) dédié à cette tâche. Le BSP est devenu un outil dédié uniquement au culling. Dans le moteur de Quake, le BSP est utilisé pour découper la scène en régions. Pendant le rendu, l arbre BSP est parcouru pour localiser la région dans laquelle se trouve la caméra. Ensuite le PVS est utilisé pour lister les régions potentiellement visibles par la caméra. Les régions situées derrière des obstacles bloquant la vue, typiquement des murs, sont éliminées. Chaque région possède une boîte englobante. Elles sont testées avec le frustum. Les régions dont la boîte englobante n a aucune intersection avec ce dernier sont éliminées. Seules sont rendues les régions visibles. Gestion de scène pour les moteurs 3D juillet /83

30 Image 17 La première image montre la scène entière. Chaque salle et chaque couloir correspond à une région. La seconde image montre ce qu il reste de la scène après utilisation du PVS. La dernière image montre ce qu il reste apres test d intersection entre le frustum et les boîtes englobantes des régions restantes. Les PVS sont particulièrement efficaces pour rendre des scènes d intérieur (labyrinthe, intérieur d un donjon ), là où il y a beaucoup de murs bloquant la vue. Le BSP est bien adapté pour découper ce type de scène justement en prenant appui sur les murs. L utilisation conjointe du BSP et des PVS est encore très répandue dans les jeux vidéos récents, tout particulièrement les FPS Les portails Le portal culling est une technique, plus récente que le BSP, permettant d éliminer les parties non visibles d une scène. Le principe est de découper la scène en un ensemble de régions liées entre elles par des ouvertures appelées portails. Par exemple, dans une scène représentant l intérieur d un bâtiment, chaque pièce sera une région et chaque porte et fenêtre sera un portail. Image 18 Une scène d intérieur constituée de plusieurs pièces reliées entre elles par des portes. Chaque porte correspond à un portail (en orange sur l image). Pour rendre la scène, on commence par déterminer la région dans laquelle se trouve la caméra. Ensuite, chaque portail se trouvant dans cette région est testé avec le frustum. S il y a intersection entre le portail et le frustum, cela signifie que la région se trouvant de l autre côté de ce portail est visible, au moins partiellement. Pour chaque région visible, un nouveau frustum est calculé en utilisant le portail et le frustum original. Tous les portails de la région sont ensuite testés avec ce nouveau frustum. 28/83 Gestion de scène pour les moteurs 3D juillet 2009

31 Image 19 La pièce dans laquelle se trouve la caméra est visible. Le frustum touche deux portails, les pièces situées derrières eux sont également visibles. Pour chacune de ces pièces, un nouveau frustum est calculé. Image 20 Dans cette situation, un PVS considérerait, à tort, que la pièce du haut est visible par la caméra. Un système de portail ne commet pas cette erreur. Image 21 En utilisant un algorithme similaire à celui utilisé pour déterminer la visibilité dans une scène découpée à l aide de portails, il est possible de déterminer quelles parties d une scène sont éclairées par une source de lumière donnée. Cette technique est extrêmement efficace pour les scènes d intérieur, là où il est facile de découper la scène en régions reliées entre elles par de petites ouvertures. En revanche, pour une scène d extérieur, là où il n y a pas de grands obstacles pour bloquer la vue, cette technique est totalement inefficace. Par rapport au BSP + PVS, l utilisation des portails offre de nombreux avantages. D une part le culling est plus précis. Le BSP + PVS peut, dans certains cas, déterminer qu une région est visible alors qu elle ne l est pas. Les portails eux, sont infaillibles. D autre part, mis à part le placement des portails eux-mêmes, aucun précalcul n est nécessaire avant le rendu de la scène (le calcul des PVS est une opération assez fastidieuse). Enfin, les portails sont très pratiques pour calculer l éclairage d une scène. Les moteurs 3D basés sur le BSP utilisent, le plus souvent, des éclairages statiques (où la position des sources de lumière ne change pas). Ces éclairages sont précalculés grâce à des algorithmes complexes comme la radiosité ou le lancer de rayon. Les portails facilitent le calcul d un éclairage dynamique, c est-à-dire un éclairage avec des sources de lumière en mouvement où tous les calculs doivent être faits en temps réel. Pour calculer la façon dont un objet est éclairé, il faut d abord déterminer quelles sont les sources de lumière qui l éclairent. Le principal problème est d éliminer toutes les sources de lumière occultées par le décor (typiquement une lumière placée derrière un mur). En utilisant les portails avec le champ d éclairage d une source de lumière de la même façon que le champ de vision de la caméra, on peut facilement déterminer quel objet de la scène est éclairé, par quelle source de lumière, et de quelle façon. Gestion de scène pour les moteurs 3D juillet /83

32 Octree et quadtree Un octree est un système de partitionnement de l espace qui, contrairement au BSP et aux portails, ne s appuie pas sur la géométrie de la scène pour la diviser. Pour créer un octree à partir d une scène, on commence par déterminer une boîte englobante cubique qui l englobe entièrement. Ensuite, on divise cette boîte en son centre grâce à trois plans de coupe alignés sur les axes X, Y et Z de repère de la scène. La boîte de départ est ainsi divisée en huit boîtes filles. Les polygones de la scène sont répartis entre ces boîtes de façon à ce que chacun d eux appartienne à une seule d entre elles. Chacune des boîtes filles est ensuite divisée de manière identique, et ainsi de suite. On crée ainsi un arbre dont la racine est la boîte englobante qui englobe toute la scène et dont chaque nœud possède huit enfants (d où le nom octree). Le processus de division s arrête lorqu une boîte contient un nombre suffisamment faible de polygones. Image 22 Octree. Image 23 Quadtree. L octree est un moyen efficace de réaliser du frustum culling. Au moment du rendu, l arbre est exploré de manière récursive. Pour chaque nœud, la boîte correspondante est testée avec le frustum. Si une boîte est en dehors du frustum, alors on est certain que toutes ses boîtes filles le sont aussi et il n est pas nécessaire de les tester. Le quadtree est une variante de l octree où chaque boîte n est divisé qu en quatre boîtes filles. Les boîtes ne sont pas divisées avec trois plans de coupe mais seulement deux. Elles sont divisées en longueur et en largeur, mais pas en hauteur. Dans une scène ne comportant aucun élément élevé, par exemple un terrain à peu près plat, utiliser un quadtree à la place d un octree est judicieux. Au contraire, dans une scène représentant un terrain montagneux ou une ville avec des gratte-ciel, l octree est préférable. Les octree et les quadtree sont typiquement utilisés pour des scènes d extérieur, là où le manque d éléments bloquant la vue rend le BSP et les portails inefficaces. 30/83 Gestion de scène pour les moteurs 3D juillet 2009

33 La principale difficulté de mise en œuvre des octree et des quadtree est la répartition des polygones de la scène dans les boîtes. Lorsqu une boîte est divisée, à moins d avoir beaucoup de chance, certains polygones seront à cheval sur les plans de coupe. Il faut pourtant que chaque polygone n appartienne qu à une seule boîte. Une solution consiste à couper ces polygones selon le plan de coupe, mais cela augmente le nombre total de polygones dans la scène. Il existe une variante de l octree appelée loose octree dans laquelle on accepte que les boîtes voisines se chevauchent. Il est ainsi possible d augmenter les dimensions de certaines boîtes de façon à ce qu elles puissent contenir les polygones récalcitrants. De cette façon, il n est plus nécessaire de couper les polygones, et chaque polygone appartient toujours à une seule boîte. Par contre, comme la taille des boîtes augmente un peu, l efficacité du culling diminue. Image 24 Dans un octree classique, à droite, les polygones trop grands pour tenir dans une boîte sont coupés. Dans un loose octree, à gauche, les limites des boîtes sont flexibles Adaptativ binary tree Un ABT est un système de partitionnement de l espace qui utilise des boîtes englobantes. Comme le BSP, il utilise un arbre binaire et divise la scène avec des plans de coupe en essayant de s adapter au mieux à sa géométrie. Pour créer un ABT, on commence par calculer une boîte englobante qui contient toute la scène. Ensuite, on divise cette boîte englobante en deux grâce à un plan de coupe. Les polygones de la boîte sont répartis en deux groupes selon qu ils sont devant ou derrière le plan. Pour chaque groupe de polygone, une nouvelle boîte englobante est calculée. Chaque boîte est ensuite divisée de la même façon. On crée ainsi un arbre dont chaque nœud correspond à une boîte englobante. Image 25 Construction d un ABT. L ABT peut être utilisé pour des scènes d extérieur, comme l octree. Il est souvent plus efficace que ce dernier, car les boîtes qu il crée sont resserrées autour des polygones, ce Gestion de scène pour les moteurs 3D juillet /83

34 qui augmente l efficacité du culling. Le principal problème de l ABT est que son efficacité est liée à la façon dont les plans de coupe sont déterminés lors de sa construction. Image 26 ABT bon et ABT mauvais. Un algorithme intelligent est nécessaire pour déterminer le meilleur plan de coupe pour chaque boîte. La seule solution est de tester tous les plans possibles et de choisir celui qui offre le meilleur résultat. Pour cette raison, la construction d un ABT est une opération très fastidieuse, ce qui implique qu elle soit réalisée en précalcul Mélange de plusieurs systèmes de culling Chacun des systèmes de culling que nous avons présentés a ses avantages et ses inconvénients. Les systèmes de partitionnement de l espace sont bien adaptés aux parties statiques de la scène (le décor). Mais pour les éléments mobiles (personnages, véhicules ) les boîtes englobantes sont plus simples à mettre en œuvre. Pour cette raison, les deux systèmes sont généralement utilisés conjointement. De même, les BSP et les portails sont très efficaces pour des scènes d intérieur alors que les octree et les ABT fonctionnent mieux pour des scènes d extérieur. Lorsque l on souhaite rendre une scène comportant des parties en intérieur et d autres en extérieur, il est possible de mélanger plusieurs systèmes de partitionnement de l espace. Dans ce cas, les parties utilisant différents systèmes de partitionnement sont généralement reliées par les portails. Par exemple, dans une scène composée de plusieurs bâtiments placés sur un grand terrain, l intérieur des bâtiments pourrait être rendu à l aide d un BSP et l extérieur grâce à un ABT. Chaque porte et fenêtre des bâtiments qui donne sur l extérieur est un portail L occlusion dynamique Les techniques d occlusion dynamique permettent de réaliser de l occlusion culling dans des scènes où l utilisation du BSP ou des portails n est pas possible, typiquement des scènes d extérieur. Le terme dynamique vient du fait que ces techniques ne s appuient pas sur un pré-découpage de la scène en régions ni sur un pré-calcul de visibilité poten- 32/83 Gestion de scène pour les moteurs 3D juillet 2009

35 tielle. La technique consiste à placer des occludeurs sur la scène, c est-à-dire des formes géométriques qui bloquent la visibilité. Ces occludeurs ne sont pas dessinés sur la scène, mais ils sont placés à l intérieur d éléments qui eux le sont. Par exemple, des occludeurs peuvent être placés à l intérieur des murs d une maison. Lors du rendu, le gestionnaire de scène va déterminer quels occludeurs sont en intersection avec le frustum. Les éléments de la scène qui sont dans le frustum mais qui sont totalement masqués par un occludeur, ou une combinaison de plusieurs occludeurs, n ont pas besoin d être dessinés. Les techniques d occlusion dynamique peuvent facilement être utilisées conjointement avec des techniques de partitionnement de l espace adaptées aux scènes d extérieurs comme les octree ou les ABT. Un autre aspect intéressant de ces techniques est que les occludeurs n ont pas besoin d être statiques. Si nécessaire, il est possible de les faire bouger sur la scène Anti-portails Les anti-portails sont une technique permettant de faire de l occlusion dynamique. Comme leur nom l indique, ils fonctionnent sur le principe inverse des portails. Les anti-portails font office d occludeurs. Au moment du rendu, pour chaque anti-portail présent dans le frustum, le système calcule un anti-frustum. Ces anti-frustums correspondent à des parties du frustum original qui ne sont pas visibles car masquées par des occludeurs. Image 27 Anti-frustum, en rouge, créé par le mur situé au milieu de la scène. Tout élément se trouvant à l intérieur n est pas visible. Chaque élement de la scène qui n a pas été éliminé par le frustum culling est testé avec tous les anti-frustums. Si la boîte englobante d un élément se trouve totalement dans les anti-frustums, alors l élément n est pas visible et ne sera pas dessiné. La principale difficulté pour mettre en œuvre cette technique apparaît quand un élément de la scène n est pas totalement occulté par un seul occludeur, mais par une combinaison de plusieurs occludeurs. Gestion de scène pour les moteurs 3D juillet /83

36 Image 28 Cette scène contient deux murs, chacun d eux crée un anti-frustum. La maison située derrière les murs n est pas totalement incluse ni dans l anti-frustum rouge ni dans le bleu. Par contre, elle est totalement incluse dans l union de ces deux anti-frustums et donc non visible. En effet, s il est facile de déterminer si une boîte englobante est totalement comprise dans un frustum, ce n est pas aussi facile avec un ensemble de frustums, car le volume résultant de l union de plusieurs frustums n est pas nécessairement convexe. Pour cette raison, l algorithme qui détermine si un élément est visible ou pas est souvent approximatif. Il peut, dans certains cas, considérer qu un élément est visible alors qu il est totalement occulté Occlusion map La carte d occlusion est une autre technique permettant de réaliser de l occlusion dynamique. Elle fonctionne sur le même principe que le tampon de profondeur (Z-buffer) utilisé par le système de rendu pour trier les polygones par ordre de profondeur. Lors du rendu de la scène, les occludeurs sont envoyés à un système de rendu séparé, généralement implémenté entièrement en logiciel, autrement dit n utilisant pas la carte graphique mais uniquement le CPU. Ce système de rendu va dessiner la carte de profondeur des occludeurs, c est-à-dire une image 2D dont la valeur de chaque pixel correspond à la distance entre la caméra et ce pixel. Une scène 3D simple Le tampon de profondeur Image 29 Z-buffer. Une fois que tous les occludeurs ont été rendus, le système utilise la carte de profondeur générée pour tester la visibilité des boîtes englobantes de tous les éléments de la scène 34/83 Gestion de scène pour les moteurs 3D juillet 2009

37 présents dans le frustum. Pour cela, la boîte englobante de chaque objet est dessinée par dessus la carte de profondeur en ne gardant que les pixels dont la profondeur est inférieure à celle de la carte. Si aucun des pixels de la boîte n est visible, cela signifie qu elle est entièrement occultée par les occludeurs. Par rapport aux anti-portails, cette méthode a l avantage de parfaitement gérer le cas où un élément de la scène est occulté par une combinaison de plusieurs occludeurs. Par contre, le rendu nécessaire pour créer la carte de profondeur demande beaucoup plus de calculs que la génération des anti-frustums. De même, le test d une boîte englobante avec la carte de profondeur nécessite un rendu de la boîte, ce qui nécessite aussi beaucoup de calculs. En bref, les occlusion map sont plus précises que les anti-portails, mais aussi plus coûteuses en terme de performance. La hierarchical occlusion map, ou carte d occlusion hiérarchique, est une variante de la carte d occlusion qui permet d optimiser les tests des boîtes englobantes avec la carte. Une fois que la carte d occlusion est générée, on en génère des copies avec des résolutions plus réduites (comme des mipmap). Au moment de tester une boîte englobante avec la carte, on commence par la tester avec la carte de résolution la plus faible, ce qui prend moins de temps que de la tester avec la carte de résolution maximale. Si la boîte englobante n est pas visible sur cette carte, on la teste sur une carte de résolution supérieure et ainsi de suite jusqu à la résolution maximale. Par contre, si la boîte englobante est visible sur une carte d occlusion à résolution réduite, alors elle le sera aussi sur une carte à résolution maximale, on est donc sûr que l élément sera visible et il n est pas nécessaire de continuer le test Test d occlusion utilisant le GPU Le GPU peut être utilisé pour réaliser des tests d occlusion. Le principe est le même que pour les cartes d oclusion, sauf que cette fois la carte n est pas dessinée par un système de rendu logiciel mais par le GPU lui-même. L avantage est que le GPU réalise le rendu de la carte beaucoup plus rapidement qu un système de rendu logiciel. Au moment du rendu, le CPU envoie les occludeurs au GPU qui dessine la carte. Cette dernière est gardée dans la mémoire du GPU, il n est pas nécessaire de la renvoyer au CPU. Ensuite, le CPU envoie au GPU les boîtes englobantes à tester pour qu elles soient dessinées par dessus la carte. Le CPU interroge ensuite le GPU pour savoir si des pixels de l image ont été changés par le rendu de la boîte englobante. Si ce n est pas la cas, cela signifie que la boîte est entièrement occultée et donc que l élément de la scène correspondant n est pas visible. Bien que l utilisation du GPU accélère considérablement le rendu de la carte d occlusion, ainsi que les tests des boîtes englobantes, cette technique souffre d un inconvénient majeur, elle nécessite beaucoup de communication entre CPU et GPU. Or la communication entre le CPU et le GPU est un des plus gros goulot d étranglement des systèmes de rendu. Il faut veiller à ce que le gain de performances apporté par l utilisation du GPU soit bien supérieur à la perte de performances due à la communication entre le CPU et le GPU. Un autre inconvénient majeur de cette méthode est qu elle monopolise le GPU pendant la phase applicative du rendu. Or, dans certains moteurs 3D, il arrive que le GPU soit utilisé pour calculer les phases géométriques et de discrétisation d une frame pendant que le CPU calcule la phase applicative pour la frame suivante. Le calcul d occlusion sur le GPU est particulièrement délicate. Gestion de scène pour les moteurs 3D juillet /83

38 Niveaux de détail Toutes les techniques d optimisation que nous avons présentées jusqu à présent reposent sur le même principe : réduire le nombre de polygones à dessiner en éliminant du rendu les éléments de la scène qui ne sont pas visibles, soit parce qu ils sont en dehors du champ de vision, soit parce qu ils sont masqués par d autres éléments. Or l efficacité de ces techniques dépend beaucoup de la scène qui doit être dessinée. Le rendu d une scène offrant peu d éléments bloquant, la vue de l utilisateur ne pourra pas beaucoup être optimisée par ces techniques. Par exemple, dans une scène ou l utilisateur observe une ville depuis un point élevé, même après suppression de tous les éléments non visibles, le nombre d éléments à dessiner reste trop important. Image 30 Le jeu Assassin s Creed de Ubisoft fait un usage très efficace du niveau de détail. Une solution pour alléger le rendu d une telle scène consiste à réduire le nombre de polygones des éléments visibles. Réduire le nombre de polygones d un élément diminue la qualité de son rendu. Réduire le nombre de polygones de l ensemble des éléments visibles de la scène produirait un rendu global de piètre qualité. Or, sur une scène ou beaucoup d éléments sont visibles, certains sont toujours moins visibles que d autres, par exemple parce qu ils sont plus éloignés de la caméra ou parce qu ils sont peu éclairés. Si on se contente de réduire le nombre de polygones des éléments les moins visibles, on peut alléger le rendu de la scène sans perte de qualité visible. La technique permettant de réaliser ce type d optimisation s appelle le niveau de détail (ou level of detail en anglais). Le principe est que chaque élément de la scène ne possède pas un seul maillage mais plusieurs. Chacun des maillage représente le même élément, mais avec plus ou moins de détails, et donc plus ou moins de polygones. Chaque maillage correspond à un niveau de détail pour l élément. Les maillage de faible niveau de détail sont généralement générés automatiquement, en précalcul, à partir du maillage original. 36/83 Gestion de scène pour les moteurs 3D juillet 2009

39 Image 31 Deux versions du même maillage à des niveaux de détails différents. Au moment du rendu, pour tous les éléments visibles de la scène, le moteur va déterminer leur niveau de visibilité, en fonction de différents critères, comme leur distance par rapport à la caméra, et choisir le niveau de détail qui convient. Un élément très visible sera rendu avec un fort niveau de détail, un élément peu visible le sera avec un faible niveau de détail. Si cette technique offre un gain de performance au niveau de la vitesse de rendu, elle augmente sensiblement l empreinte mémoire de l application. En effet, celle-ci doit stocker les versions dégradées de chaque maillage des éléments de la scène, en plus des versions originales. En dehors du problème de la consommation de mémoire, la difficulté de mise en œuvre de cette technique est de trouver le, ou les, bons critères pour déterminer quel niveau de détail doit être utilisé pour chaque élément visible. Le plus souvent, la distance entre la caméra et l élément est le seul critère utilisé. À cause de la perspective, les éléments éloignés apparaissent plus petits que les éléments proches, leurs détails sont donc moins visibles. De plus, il est courant, pour restituer des scènes d extérieur de grande taille, d ajouter un effet de brouillard sur les éléments éloignés, ce qui diminue encore plus leur visibilité. Cependant, il est possible qu un élément soit très éloigné de la caméra et soit malgré tout visible en détail si la caméra simule un effet de téléobjectif, par exemple dans un jeu ou le joueur utilise un fusil de sniper. Pour pallier ce problème, certains algorithmes calculent une estimation du nombre de pixels que nécessitera l élément sur l image finale et utilise ce nombre comme critère de choix du niveau de détail. Plus un élément apparaitra grand sur l image, plus il sera rendu avec un niveau de détail élevé. Enfin, un élément proche de la caméra et grand sur l image peut malgré tout être peu visible s il est peu éclairé, s il est dans l ombre d un autre élément, ou s il est presque entièrement occulté (par exemple un objet visible à travers une grille ou le feuillage d un arbre). Malheureusement, détecter ces situations est assez complexe. Pour y parvenir, certains algorithmes effectuent des tests en comparant le rendu d un même élément à différents niveaux de détail. Un élément de la scène est tout d abord rendu avec un niveau de détail moyen, puis il est rendu une seconde fois avec le niveau de détail maximal. L algorithme calcule la différence entre les deux rendus en fonction du nombre de pixels différents entre l un et l autre, et de la différence de luminance de ces pixels. Il est ainsi possible d estimer si l utilisateur percevra une différence significative entre les Gestion de scène pour les moteurs 3D juillet /83

40 deux niveaux de détail pour cet élément. Si la différence entre les deux rendus est perceptible, alors il est nécessaire de rendre l élément à un niveau de détail plus élevé. Si, au contraire, il n y a aucune différence notable entre les deux rendus, alors il est possible de restituer l élément à un niveau de détail encore plus bas Imposteurs La technique des imposteurs date des tout premiers jeux 3D. Elle consiste à remplacer un élément 3D de la scène par une image 2D. À l époque de Doom, les ordinateurs n étaient pas assez puissants pour rendre en 3D les monstres qui peuplaient les niveaux du jeu. Ils étaient donc rendus sous forme de billboards, c est-à-dire par une texture 2D appliquée sur un quad qui fait toujours face à la caméra. Pour donner l illusion de la 3D, le système choisissait parmi plusieurs textures représentant le monstre sous différents angles de vue (de face, de profil, de dos ) en fonction de la position de la caméra par rapport à lui. Image 32 Texture utilisée pour représenter un des monstres du jeu Doom. L augmentation de la puissance des ordinateurs et le développement des cartes graphiques a fait tomber cette technique en désuétude, les personnages des jeux peuvent être rendus en vraie 3D. Mais elle est cependant toujours utilisée pour rendre certains éléments de décors, comme des arbres ou des touffes d herbes. Elle peut également servir à faire du niveau de détail dans certaines scènes complexes. Image 33 Arbre représenté à l aide de deux billboards. Dans une scène où un très grand nombre d éléments sont visibles, rendre les éléments les plus éloignés en 3D, même avec un très faible niveau de détail, peut être encore trop coûteux en terme de performance. Les rendre sous forme d imposteurs est bien plus rapide. 38/83 Gestion de scène pour les moteurs 3D juillet 2009

41 Image 34 Le plugin Forests pour Ogre permet de créer des forêts extrêmement vastes. Les arbres éloignés de la caméra sont des imposteurs. Contrairement aux premiers jeux 3D où les imposteurs étaient dessinés à la main, ils sont aujourd hui générés automatiquement à partir du modèle 3D original. Ils peuvent être générés en précalcul, ou dynamiquement, pendant l exécution de l application, en faisant du rendu vers une texture (render to texture en anglais). Le modèle 3D est rendu par le GPU, mais le résultat n est pas affiché a l écran. À la place, il est stocké dans la mémoire du GPU sous forme d une texture qui peut être utilisée plus tard. La technique du niveau de détail par imposteurs fonctionne de la façon suivante. Au moment du rendu, le système détecte qu un élément de la scène est très éloigné de la caméra et qu il serait judicieux de le rendre sous forme d un imposteur. Le maillage de cet élément est rendu sous forme d une texture. Cette texture donne une image de l élément à un certain angle de vue (celui de la caméra de l application). Cette texture est appliquée sur un quad qui fait face à la caméra et l élément est rendu sur la frame de cette façon. Cette technique est extrêmement efficace lorsque de nombreux éléments de la scène utilisent le même maillage, par exemple des arbres dans une forêt, car il est alors possible d utiliser la même texture pour les dessiner tous, à condition que leur orientation par rapport à la caméra soit à peu près identique. De plus, il n est pas nécessaire de régénérer la texture pour les frames suivantes, elle peut être réutilisée plusieurs fois. La texture ne devra être régénérée que lorsque l orientation de l élément par rapport à la caméra aura changé suffisamment. Puisque les imposteurs sont utilisés pour rendre des éléments très éloignés de la caméra, l orientation de l un par rapport à l autre ne change pas très vite et la texture peut être réutilisée pour un grand nombre de frames. Gestion de scène pour les moteurs 3D juillet /83

42 Atlas de textures L atlas de textures, aussi appelé meta-texturing, est une technique qui permet de réduire le nombre de changements d état effectués sur le système de rendu. Quand on rend une scène comportant plusieurs textures, il faut demander au système de rendu de changer la texture active plusieurs fois afin de dessiner chaque polygone avec la texture qui lui est attribuée. Or les changements d état, et tout particulièrement le changement de texture active, sont des opérations assez coûteuses en performance. Le principe de l atlas de textures est de regrouper plusieurs textures différentes en une seule grande texture. Seule cette grande texture est chargée par le système de rendu et est définie comme texture active. Les multiples textures qui la composent peuvent alors être utilisées indépendamment les unes des autres sans qu aucun changement d état ne soit nécessaire. Image 35 Atlas de textures. Pour que les maillage soient dessinés correctement, il faut adapter les coordonnées de texture de leurs sommets afin de tenir compte de la position de la texture sur l atlas de textures. Cette opération est facilement réalisable avec un vertex shader. 40/83 Gestion de scène pour les moteurs 3D juillet 2009

43 Image 36 Rendu d un quad une texture simple et rendu du même quad avec un atlas de textures. Notez la modification des coordonnées de texture. Un problème lié à l utilisation de cette technique est la génération des mipmaps. Cellesci sont générées en réduisant l atlas de textures tout entier. Or les algorithmes permettant de réduire des images (certains d entre eux du moins) fonctionnent en sélectionnant plusieurs pixels voisins sur l image originale et en les fusionnant pour obtenir un unique pixel sur l image réduite. Il peut donc arriver que l algorithme génère des pixels sur la texture réduite en fusionnant des pixels appartenant à deux textures différentes sur l image originale. Cela produit des artéfacts sur les bords des textures. Cet effet est appelé texture bleeding. Une solution simple pour supprimer cet effet parasite est de laisser quelques pixels d espace entre chaque texture de l atlas de textures. Ces espaces sont remplis en dupliquant des lignes et des colonnes de pixels des textures elles-mêmes. Par contre, cette solution augmente la taille de l atlas de textures et donc la place qu il occupe dans la mémoire du GPU. Gestion de scène pour les moteurs 3D juillet /83

44 Terrain Dans le rendu de scène d extérieur, un problème couramment rencontré est celui de rendu de terrain. Un terrain est tout simplement un grand maillage représentant une surface de forme irrégulière. Image 37 Terrain 3D produit par Google Earth. Pour donner un effet naturel, le terrain doit être constitué d un très grand nombre de polygones. Le terrain fait généralement la même taille que la scène tout entière, ce qui devient très vite problèmatique dans une grande scène. Les techniques de culling et de niveaux de détail sont utilisées conjointement pour optimiser le rendu des terrains. Le terrain est divisé en plusieurs régions, typiquement à l aide d un quad tree, et chaque région est affichée avec un niveau de détail dépendant de sa position par rapport à la caméra. Mais contrairement au niveau de détail utilisé sur les autres éléments de la scène, qui utilise plusieurs versions précalculées d un même maillage, les niveaux de détail des régions d un terrain peuvent être calculés dynamiquement grâce à un algorithme appelé tessellation. La tessellation est un procédé qui permet de diviser une surface en un certain nombre de polygones. La surface est parfois appelée patch. Chaque région du terrain est un patch. Ces patch peuvent être représentés sous forme d équations mathématiques définissant des courbures, comme des courbes de Bézier, ou sous forme de carte de hauteur (heightmap en anglais), c est-à-dire un ensemble de valeurs qui donnent la hauteur du patch à intervalle régulier. En appliquant de la tesselation à un patch, on peut le transformer en un ensemble de polygones en contrôlant le niveau de détail, et donc le nombre de polygones générés. 42/83 Gestion de scène pour les moteurs 3D juillet 2009

45 Image 38 Tesselation d un modèle construit à partir de patchs. Les algorithmes de tessellation sont assez rapides pour être utilisés en 3D temps réel. Il est possible de s en servir à chaque frame pour calculer les polygones nécessaires au rendu des différentes régions visibles d un terrain. Il est aussi possible d effectuer les calculs de tessellation sur le GPU à l aide d un shader. Par contre, lorsque deux régions conjointes d un terrain sont rendues avec des niveaux de tessellation différents, leurs polygones risquent d être disjoints, ce qui crée des trous dans le terrain. Il est nécessaire d adapter alors la jointure des régions conjointes en morphant les sommets. Image 39 Différents niveaux de tesselation d un patch représentant un demi cercle. Gestion de scène pour les moteurs 3D juillet /83

46 Mega texturing Un autre problème lié au rendu de terrain est l application d une texture dessus. Il est possible d appliquer une, ou plusieurs, petites textures qui se répètent sur toute la surface du terrain. Mais, dans certains cas, on a besoin d appliquer une seule grande texture que recouvre l ensemble du terrain, par exemple pour dessiner une carte routière dessus, ou simplement pour éviter que le terrain n ait une apparence trop répétitive. Une telle texture est bien trop grande pour être stockée dans la mémoire de la carte graphique. La solution, dite du méga texturing, mise au point pour le jeu Quake 4, consiste à découper la grande texture en plusieurs petites sections de taille fixe. Seules les sections visibles sont chargées dans la mémoire de la carte graphique. Ce système fonctionne de la même manière qu un atlas de texture. Dans la mémoire de la carte graphique, un espace est alloué pour recevoir un certain nombre de sections de texture. Au moment du rendu, le système détermine quelles sections sont visibles par la caméra et charge ces sections dans la mémoire de la carte graphique. Lorsque la caméra se déplace par rapport au terrain, certaines sections du terrain entrent dans le champ de vision de la caméra pendant que d autres en sortent. Les sections qui sont devenues visibles sont alors chargées en mémoire en prenant la place des sections qui ne sont plus visibles. De cette façon, le nombre de chargement nécessaire est toujours minimal. Image 40 Seule une petite partie du terrain est visible. Seules les textures correspondantes aux sections visibles sont chargées dans la mémoire du GPU. Le système doit aussi gérer le niveau de détail dans le cas ou une grande partie du terrain est visible depuis un point de vue distant. Pour cela, au moment du découpage de la grande texture, des sections de texture sont générées avec différents niveaux de détail de la façon suivante. Tout d abord, la grande texture dans son entier est réduite pour obtenir une seule section. Cette section correspondra au niveau de détail le plus faible. Ensuite, la grande texture est divisée en plusieurs morceaux et chacun de ces morceaux est utilisé pour créer une section. Ces sections correspondront à un niveau de détail intermédiaire. Puis les morceaux eux-mêmes sont divisés et ainsi de suite. 44/83 Gestion de scène pour les moteurs 3D juillet 2009

47 Image 41 Découpage d une grande texture à plusieurs niveaux de détail. On obtient ainsi un grand nombre de sections de la grande texture, chacune représentant une partie du terrain avec un niveau de détail donné. Au moment du rendu, le système choisit le niveau de détail approprié et charge les sections correspondantes en mémoire. Gestion de scène pour les moteurs 3D juillet /83

48 Voxel Une solution totalement différente pour rendre des terrains est de les représenter non plus sous forme de polygones, mais sous forme de voxels. Le voxel est à la 3D ce que le pixel est à la 2D : une unité minimale et indivisible. Le terme voxel est la contraction de volume élement (tout comme pixel est la contraction de picture élement). Un objet en 3D peut être représenté par un ensemble de voxels disposés sur une grille régulière à 3 dimensions. La valeur d un voxel correspond à sa matière, vide, pierre, bois, brique, etc. Image 42 Une forme 3D représentée par un enssemble de voxels. Un seul voxel est grisé. Représenter un terrain grâce à des voxels plutôt que grâce à des polygones offre un certain nombre d avantages. D une part le terrain n est plus forcément une surface, il peut comporter des volumes de n importe quelle forme, ce qui peut être utile pour dessiner certains artefacts naturels comme des grottes et des souterrains. D autre part, il est facile de modifier le terrain dynamiquement en modifiant la matière des voxels. Par exemple, dans un jeu de guerre, un impact de bombe peut creuser un trou dans un terrain en changeant la valeur des voxels situés dans la zone d explosion (par exemple en mettant la valeur alpha à 0.0 pour vide ). 46/83 Gestion de scène pour les moteurs 3D juillet 2009

49 Image 43 Le moteur Thermite 3D (basé sur Ogre) utilise les voxels pour créer des environnements entièrement destructibles. Puisque la plupart des systèmes de rendu, ainsi que les moteurs physiques actuels utilisent des polygones et non des voxels, il est nécessaire de convertir les voxels en polygones. Plusieurs algorithmes permettent de réaliser cette opération. Le plus utilisé est le marching cube. Son principe est de traiter le terrain par groupe de huit voxels voisins formant un cube. En fonction de leur valeur, le système détermine comment le cube doit être converti en polygones. Cet algorithme peut facilement être implémenté par un sommet shader. Image 44 Conversion d un ensemble de voxels en polygones grâce à l algorithme du marching cube. Cette image montre comment différentes combinaisons de voxels non vides (fi gurés ici par des points jaunes) sont transformées en polygones. Gestion de scène pour les moteurs 3D juillet /83

50 Il est facile de réaliser du niveau de détail grâce au marching cube. À partir d un élément représenté par un ensemble de voxels, on peut calculer plusieurs maillages constitués de plus ou moins de polygones. Le meilleur niveau de détail sera obtenu en traitant tous les voxels, des versions dégradées seront obtenues en ne traitant qu un voxel sur deux, un voxel sur quatre, et ainsi de suite Paging et chargement en tâche de fond Lorque l on veut créer une application utilisant des scènes vraiment très grandes, par exemple une ville entière, un nouveau problème se pose, celui de la consommation de mémoire vive. La quantité de données représentant la scène (maillages, textures, volumes pour le moteur physique ) est bien trop grande pour être stockée intégralement dans la mémoire de l ordinateur (du moins la plupart des ordinateurs actuels). Dans la plupart des jeux, ce problème est résolu en découpant la scène en un certain nombre de sections. Chaque section est taillée pour pouvoir être chargée intégralement en mémoire. Elles ne sont reliées entre elles que par un nombre limité de passages que le joueur peut emprunter (porte, couloir, téléporteur ). Quand le joueur passe d une section à l autre, la section courante est effacée de la mémoire et la section dans laquelle le joueur s apprête à entrer est chargée à sa place. Le chargement d une section en mémoire est loin d être instantané, par conséquent, le joueur doit patienter devant un écran de chargement à chaque fois qu il change de section. En plus d être particulièrement agaçante pour le joueur, cette solution n est pas utilisable dans certaines applications. Par exemple dans un jeu multijoueurs, il n est pas envisageable qu un joueur soit bloqué parce qu il passe d une section à l autre alors que les autres joueurs peuvent encore continuer à jouer. Une solution consiste à charger les différentes sections de la scène pendant que le joueur joue. Dans ce cas, la scène est divisée en sections plus petites de façon à ce que plusieurs d entre elles puissent être contenues en mémoire simultanément. Lorque l application démarre, seule la section dans laquelle le joueur apparaît est chargée. Le joueur doit patienter pendant ce chargement. Ensuite, pendant que le joueur joue, les sections voisines de celle dans laquelle il se trouve sont chargées en mémoire. Si le système est bien règlé, d ici à ce que le joueur quitte la section dans laquelle il se trouve et entre dans une autre, celle-ci sera déjà complétement chargée en mémoire. Quand le joueur entre dans une nouvelle section, les sections chargées en mémoire qui ne sont pas voisines de cette nouvelle section sont effacées. Et les sections voisines de la nouvelle section sont chargées en mémoire à leur place. Grâce à ce système, le joueur n a plus besoin de patienter quand il passe d une section à une autre. Cette solution impose cependant un certain nombre de contraintes. D une part, le joueur ne doit pouvoir accèder qu à un nombre limité de sections (les sections voisines) à partir de la section dans laquelle il se trouve. Il ne doit pas lui être possible de se téléporter d un bout à l autre de la scène. D autre part, il faut s assurer que le joueur ne puisse pas traverser une section trop rapidement afin de laisser le temps aux sections voisines de se charger. Le chargement des sections en mémoire se fait en lisant les données des sections dans un, ou plusieurs fichiers qui peuvent être sur un disque dur ou sur un disque optique. Il est aussi possible que ces données soient téléchargées sur un réseau (streaming). Les opérations de lecture de fichiers et de communication réseau sont des opérations dites bloquantes. Quand une application demande au système d exploitation de lui fournir des données en provenance d un fichier ou d une connexion réseau, le système d exploitation peut mettre l application en sommeil le temps que les données demandées soient prêtes. Or il n est évidemment pas souhaitable de mettre une application 3D temps réel en sommeil, car le rendu ne doit pas s interrompre. Pour cette raison, le chargement des sections s effectue dans un thread séparé. Ce thread est exécuté en parallèle du reste de 48/83 Gestion de scène pour les moteurs 3D juillet 2009

51 l application. S il effectue une opération bloquante, lui seul sera mis en sommeil et le reste de l application continuera de fonctionner Optimisation de l utilisation de système de rendu Minimisation des changements d état En plus de la texture utilisée, chaque polygone d un maillage peut contenir plusieurs autres attributs. Sa couleur, sa matière, qui influencent la façon dont le polygone réagit à la lumière, un niveau de transparence, et un ou plusieurs shaders utilisés pour son rendu. Au moment du rendu, il est nécessaire d informer le système de rendu des attributs utilisés par chaque polygone. Cela se fait grâce à des commandes de changement d état. Pour dessiner un ou plusieurs polygones, une application doit d abord configurer le système de rendu pour définir les attributs à utiliser. Ensuite, elle lui envoie le ou les polygones qui doivent être dessinés avec ces attributs. Puisque chaque changement d état prend du temps, on cherche à les minimiser pour augmenter les performances de l application. Une méthode couramment utilisée consiste à grouper les polygones partageant les mêmes attributs. Ainsi, on n effectue des changements d état seulement pour chaque groupe de polygones, plutôt que pour chaque polygone. En interne du moteur 3D, les maillages dont les polygones utilisent des attributs différents (par exemples les maillages qui utilisent plusieurs textures) sont divisés en plusieurs sous-maillages, de façon à ce que tous les polygones de chaque sous-maillage partagent les mêmes attributs. Le groupement des polygones au moment du rendu s en trouve ainsi facilité. La méthode peut être améliorée par l utilisation d un état invariant. Au début du rendu de la frame, on met le système dans l état invariant en paramétrant tous ses attributs à des valeurs prédéfinies. Ensuite, pour chaque groupe de polygones à rendre, il n est nécessaire d effectuer des changements d état que pour les attributs dont les valeurs diffèrent par rapport à l état invariant. Après le rendu du groupe de polygones, les attributs qui ont été modifiés sont remis à leur valeur initiale et ainsi le système revient dans l état invariant. Si les valeurs des attributs de l état invariant sont judicieusement choisies pour être communes avec un maximum de groupes de polygones, le nombre de changements d état nécessaires sera considérablement réduit. En général, l état invariant est défini par le programmeur de l application. Mais certains moteurs 3D sont capables de calculer le meilleur état invariant possible pour chaque frame. Rendu des objets transparents Un autre problème est celui du rendu des objets transparents. Un effet de transparence en 3D peut être simulé par fusion (blending en anglais) de pixels. Lorsqu un polygone transparent est rendu, la couleur des pixels que ce polygone occupe à l écran est obtenue en combinant la couleur du polygone avec celle des pixels déjà présents sur l image en cours de rendu. Divers effets peuvent être obtenus selon la façon dont la combinaison des pixels est réalisée. Les systèmes de rendu offrent plusieurs fonctions de blending basées sur des formules mathématiques différentes. Pour obtenir l effet de transparence, il est nécessaire que les polygones situés derrière le polygone transparent soit envoyés au système de rendu avant lui. Pour cette raison, il est courant de restituer une scène en dessinant tous les objets opaques en premier, et tous les objets transparents ensuite. Mais les choses deviennent plus complexes lorsque deux polygones transparents sont situés l un derrière l autre. L effet de transparence ne sera réaliste que si le polygone le plus éloigné de la caméra est rendu avant l autre. Il est Gestion de scène pour les moteurs 3D juillet /83

52 donc nécessaire de trier les éléments transparents de la scène par ordre de profondeur par rapport à la caméra. Graphe de rendu La file de rendu est une structure dans laquelle le moteur 3D stocke tous les éléments de la scène qui doivent être envoyés au système de rendu. Seuls y sont placés les éléments qui n ont pas été éliminés par le culling et dont le niveau de détail a été sélectionné. Une fois la file remplie, diverses optimisations peuvent y être appliquées afin d optimiser l utilisation du système de rendu. Le groupement des polygones partageant les mêmes attributs, la détermination de l état invariant et l ordonnancement des polygones transparents sont effectués à ce niveau. Pour aller plus loin dans l optimisation et la minimisation des changements d état, certains moteurs 3D utilisent une structure appelée graphe de rendu. Le graphe de rendu remplace efficacement la méthode de l état invariant. Il analyse les groupes de polygones et organise leur position dans la file de rendu de façon à placer ceux dont les attributs sont presque tous similaires les uns à la suite des autres. Le nombre de changements d état nécessaires entre chaque groupe de polygone est donc minimal Cohérence temporelle La 3D temps réel est, dans la grande majorité des cas, utilisée pour produire un simulacre de la réalité. Dans la réalité, les objets ne peuvent se déplacer que de manière continue, il n est pas possible qu un objet se déplace instantanément d un point à un autre. Par conséquent, dans une application 3D temps réel, si le framerate est suffisamment élevé, la position des éléments d une scène 3D varie assez peu d une frame à l autre. Ce phénomène est appelé cohérence temporelle et peut être utilisé pour réaliser un grand nombre d optimisations à différentes étapes du rendu. Pour le partitionnement de l espace Lorsqu une scène est découpée en régions par un algorithme de partitionement de l espace, il est judicieux de s en servir pour faire du culling sur les éléments mobiles (personnages, monstres ). Si on sait en permanence dans quelle région se situe chaque élément mobile, alors il est facile de déterminer lesquels sont visibles et lesquels ne le sont pas. Seuls les éléments situés dans les régions visibles doivent être rendus. Dans une scène où les éléments mobiles sont nombreux, cette technique est plus rapide que de tester leur visibilité un par un. Par contre, quand un élément mobile se déplace, la région dans laquelle il se trouve peut changer. Il est donc nécessaire de relocaliser à chaque frame tous les éléments qui se sont déplacés. Cette opération peut s avérer très coûteuse en temps de calcul, en particulier si la scène est grande et les éléments mobiles nombreux. En prenant en compte la cohérence temporelle, cette opération peut être considérablement optimisée. Si on sait dans quelle région se trouve un élément en mouvement à la frame actuelle, alors, à la frame suivante, il est très probable qu il se trouve soit dans la même région, soit dans une des régions voisines de celle-ci. On peut donc commencer par tester la présence de l élément dans ces régions. Seulement dans le cas, peu probable, où il ne s y trouverait pas, il est nécessaire de relocaliser l élément en prenant en compte la scène entière. 50/83 Gestion de scène pour les moteurs 3D juillet 2009

53 Image 45 Si un élément mobile se trouve dans la pièce centrale à la frame courante, à la frame suivante, la probabilité qu il se trouve dans cette même pièce, ou dans une des pièces adjacentes (en rouge) est très forte. La probabilité qu il se trouve dans une autre pièce est beaucoup plus faible. Pour le culling et l occlusion Lorsqu une caméra se déplace sur une scène, sa position varie peu d une frame à l autre de façon à donner une impression de fluidité dans le mouvement. Par conséquent, le frustum lui aussi change peu, il est donc possible d exploiter la cohérence temporelle pour le culling et l occlusion. Néanmoins, dans certaines applications, l utilisateur a la possiblité de sélectionner entre plusieurs points de vue (par exemple dans un jeu de simulation automobile, le joueur peut passer à tout moment de la vue pare-brise à la vue rétro-viseur et vice-versa), ce qui détruit la cohérence temporelle. Mais cette situation peut être traitée comme un cas particulier. Lorsque la visibilité d un élément, ou d une région de la scène est testée par rapport au frustum, il est possible de savoir si cette visibilité est totale ou partielle. Si la boîte englobante d un élément de la scène est entièrement comprise dans le frustum alors la visiblité est totale, si seule une partie de la boîte englobante est à l intérieur du frustum alors la visiblité est partielle. Si le frustum change peu d une frame à l autre, alors il y a de fortes chances pour que les éléments de la scène qui étaient totalement visibles à la frame précèdente soient visibles, au moins partiellement, à la frame courante. On peut faire l hypothèse qu un élément totalement visible à une frame, sera également visible pour un certain nombre de frames suivantes. Ainsi, pendant ces frames, il ne sera pas nécessaire de re-tester sa visibilité, ce qui réduit les calculs. Bien sûr, dans certains cas, cette hypothèse se révelera fausse, et l élément qui était totalement visible à la frame précedente ne le sera plus du tout à la frame courante. Dans ce cas l élément sera rendu pour rien. Mais si le système est bien réglé, ces cas seront rares et n introduiront que très peu de calculs superflus par rapport à ceux qu ils permettent d économiser. Image 46 Les régions qui sont totalement incluses dans le frustum (en rouge) ont une forte probabilité d être visible à la prochaine frame, même si le frustum se déplace. Cette probabilité et plus faible pour les régions qui ne sont que partiellement visibles (en vert). Gestion de scène pour les moteurs 3D juillet /83

54 On peut faire l hypothèse inverse et dire qu un élément totalement hors du frustum, ou totalement occulté, donc non visible pour la frame courante, sera également non visible pour un certain nombre de frames suivantes. Cependant cette hypothèse est plus risquée que la précédente. En effet, dessiner un élément non visible n affecte pas le rendu final, alors qu oublier un élément visible le dégrade. Cependant, cette dégradation peut être considérée comme acceptable dans certaines situations, par exemple si l élément est très en arrière plan dans une scène à forte occlusion ou avec un effet de brouillard. Utilisation de la cohérence temporelle avec l occlusion calculée sur le GPU L occlusion calculée sur le GPU offre de nombreux avantages par rapport aux autres techniques de calcul d occlusion. Les anti-portails sont délicats à mettre en œuvre et parfois imprécis, les occlusions map sont précises mais nécessitent beaucoup de puissance de calcul au niveau du CPU. Cependant, le calcul d occlusion sur GPU souffre d un inconvénient majeur : le temps de latence entre le moment ou le CPU effectue une requête d occlusion au GPU, et le moment où il reçoit la réponse. Pour cette raison, l occlusion sur GPU n est pas, à l heure actuelle, une technique très populaire. Typiquement, au moment du rendu, l occlusion est utilisée de la manière suivante. La scène est découpée par un système de partitionnement de l espace, comme un octree ou un ABT, en régions. Les régions sont testées par rapport au frustum pour vérifier si elles sont dans le champ de vision de la caméra, et si elles le sont, elles sont testées par l occlusion pour vérifier qu elles ne sont pas cachées par des éléments de la scène. Si la région est visible, les éléments qu elle contient sont rendus. Implémenter un tel algorithme en utilisant de l occlusion sur GPU implique une requête au GPU pour chaque région testée, et donc un temps d attente à chaque fois, ce qui est inacceptable. Il est tout simplement impossible d utiliser efficacement l occlusion sur GPU de cette manière. La solution consiste à utiliser le phénomène de cohérence temporelle pour anticiper le résultat des requêtes d occlusion et ainsi permettre au CPU de continuer à travailler sans attendre les réponses du GPU. Pour déterminer si une région de la scène est visible ou non en anticipant le résultat de la requête d occlusion, on se base simplement sur la visibilité de cette région à la frame précédente. Si la région était visible, on considère qu elle l est toujours, et vice versa. Le CPU peut continuer à travailler en s appuyant sur cette anticipation. Il peut tester d autres régions, effectuer d autres requêtes d occlusion, et même envoyer des éléments de la scène à dessiner au GPU en attendant le résultat de la requête d occlusion qu il a effectuée (au niveau du GPU, les requêtes et les objets à dessiner sont mis dans une file d attente). Le résultat de la requête d occlusion arrivera plus tard et permettra de vérifier l exactitude de l anticipation. Si elle était correcte, alors il n y a rien de plus à faire. Si elle ne l était pas, deux cas de figure sont possibles. - Si l anticipation a déclaré que la région était visible alors qu elle ne l est pas, cela signifie que des éléments ont été rendus pour rien. Cela entraîne une perte de temps mais n a pas d impact sur le rendu final. Le système se souviendra que cette région n est pas visible de sorte que, à la prochaine frame, l anticipation ne se trompe pas. - Si, au contraire, l anticipation a déclaré que la région n était pas visible alors qu elle l est, cela signifie que des éléments visibles n ont pas été rendus, il faut donc les envoyer au système de rendu pour qu ils soient dessinés sur la frame en cours. Là aussi, le système mémorise le fait que cette région est visible pour que l anticipation lors de la prochaine frame soit correcte. 52/83 Gestion de scène pour les moteurs 3D juillet 2009

55 4.3 Utilisations actuelles des gestionnaires de scène Le gestionnaire de scène occupe une position centrale dans toute application 3D temps réel. À chaque frame, il est sollicité pour mettre à jour le graphe de scène. Après quoi, il utilise les différentes techniques décrites précèdemment pour déterminer quels sont les éléments visibles par la caméra, déterminer le niveau de détail avec lequel ils doivent être dessinés, et les envoie au système de rendu. Bien sûr, une application peut utiliser simultanément plusieurs caméras, et même plusieurs scènes. Le gestionnaire de scène peut donc être sollicité plusieurs fois par frame. Différentes techniques, couramment utilisées dans les applications 3D temps réel, s appuient sur le gestionnaire de scène pour fonctionner. Le rendu des ombres Dessiner les ombres créees par les éléments de la scène sur d autres éléments de la scène permet d augmenter considérablement le réalisme d un rendu 3D. Les techniques les plus courantes sont le shadow mapping et les shadow volumes. Image 47 Le jeu Doom 3 de id Software a été le premier à utiliser la technique des shadow volumes. Avec le shadow mapping, pour chaque source de lumière, on génère un rendu de la scène telle qu elle est vue par la lumière. On utilise ensuite le tampon de profondeur de ce rendu pour déterminer si chaque pixel de l image finale, vue par la caméra, est exposé à la lumière ou non. S il ne l est pas, il sera assombri pour donner l effet de l ombre. La technique nécessite donc un rendu de la scène supplémentaire pour chaque source de lumière. Avec les shadow volumes, pour chaque source de lumière, le système détermine quels Gestion de scène pour les moteurs 3D juillet /83

56 éléments de la scène sont éclairés par elle. Chacun de ces éléments projette une ombre, on les appelle donc des projecteurs d ombres ou shadow caster en anglais. Ensuite, pour chaque shadow caster, un volume est créé, qui correspond à la zone dans laquelle l ombre est projetée. La scène n est rendue qu une seule fois, telle qu elle est vue par la caméra. Chaque pixel de ce rendu est testé pour déterminer s il se trouve, ou non, dans un shadow volume, en fonction de quoi il sera assombri ou non. Ces deux techniques ont un dénominateur commun : elles nécessitent de déterminer quelles sont les sources de lumière qui affectent le rendu final, et ensuite de déterminer quels éléments de la scène peuvent créer des ombres à partir de ces sources de lumière. Cette tâche incombe au gestionnaire de scène. Image 48 L arbre ne se trouve pas dans le frustum de la caméra, mais il a quand même une influence sur le rendu car il projette une ombre sur le personnage et le terrain. Une source de lumière affecte le rendu final uniquement si la lumière émise peut atteindre le frustum de la caméra. Typiquement, les moteurs 3D gèrent trois types de sources lumineuses. - Les sources omnidirectionnelles, qui émettent de la lumière dans toutes les directions autour d un point donné. La zone d influence d une de ces sources correspond à une sphère. - Les spots, qui émettent de la lumière à partir d un point et dans une direction donnée, leur zone d influence correspond à un cône. - Les sources directionnelles qui éclairent la totalité de la scène dans une direction donnée. Elles sont utilisées, par exemple, pour simuler la lumière du soleil. Pour savoir si une source de lumière influence ou non le rendu final, il suffit de tester 54/83 Gestion de scène pour les moteurs 3D juillet 2009

57 l intersection de sa zone d influence avec le frustum de la caméra. Bien sûr, l occlusion doit être prise en compte. Un système de partitionnement de l espace peut faciliter cette opération. Ensuite, pour chaque source de lumière, il faut déterminer les éléments de la scène qui peuvent créer une ombre. Pour cela, on calcule, à partir du frustum de la caméra et de la zone d action de la source lumineuse, un volume dans lequel les éléments concernés doivent se trouver. Le gestionnaire de scène doit alors lister tous les éléments de la scène qui sont en intersection avec ce volume. Là encore, l utilisation d un système de partitionnement de l espace peut optimiser l opération. De plus, appliquer du niveau de détail sur les éléments créant des ombres peut accélérer le rendu de ces dernières. mage 49 À partir du frustum de la caméra et de la zone d influence de la source lumineuse, on calcule le volume en jaune. Les éléments se trouvant (même partiellement) dans ce volume créent une ombre grâce à cette source lumineuse. Quelle que soit la technique utilisée, la sollicitation de gestionnaire de scène augmente avec le nombre de lumières présentes sur la scène. Gestion de scène pour les moteurs 3D juillet /83

58 La réflexion de l environnement Le reflection mapping, aussi appelé environment mapping, est une technique qui permet à un objet 3D de refléter la scène qui se trouve autour de lui. Cette technique est souvent utilisée dans les jeux de simulation de course automobile, sur les carrosseries des voitures. Même si l effet est peu perceptible, il ajoute grandement au réalisme du rendu. Image 50 Exemple de réflexion de la scène sur la théière. L effet de réflexion est réalisé en appliquant une texture représentant la scène sur l objet qui la reflète. Cette texture est, la plupart du temps, générée par un procédé appelé cube mapping. Le principe est de créer six textures en effectuant six rendus de la scène dans toutes les directions (haut, bas, droite, gauche, devant et derrière) autour de l objet qui devra la refléter. On obtient ainsi un cube de textures qui peuvent être appliquées sur l objet. Bien évidemment, le gestionnaire de scène est sollicité pour réaliser ces rendus. L illumination globale L illumination globale est un procédé permettant de calculer l éclairage d une scène en prenant en compte l éclairage direct et l éclairage indirect de ces éléments. Dans une pièce éclairée par une ampoule, la plus grande partie de la lumière provient directement de l ampoule, c est ce qu on appelle l éclairage direct. Mais les objets éclairés par l ampoule reflétent une partie de la lumière qu ils reçoivent. Cette lumière éclaire d autres objets, c est ce qu on appelle l éclairage indirect. Calculer l éclairage direct d une scène ne demande pas beaucoup de calculs. Des algorithmes spécifiques (Gournaud, Phong ) existent depuis longtemps et sont implémentés dans la plupart des systèmes de rendu temps réel. En revanche, calculer l éclairage indirect d une scène est une opération très coûteuse en calculs. Il faut, en effet, calcu- 56/83 Gestion de scène pour les moteurs 3D juillet 2009

59 ler le chemin emprunté par la lumière en prenant en compte la réflexion sur les objets qu elle touche. En 3D temps réel, l éclairage indirect est souvent simulé par l ajout d une lumière ambiante sur la scène, c est-à-dire une lumière n ayant ni position ni direction et qui éclaire indiféremment tous les éléments de la scène. Malheureusement, cette méthode ne donne pas un résultat très réaliste. Les objets éclairés par la lumière ambiante paraissent plats, utiliser trop de lumière ambiante dans une scène fait perdre l illusion du relief. De plus, l utilisation de la lumière ambiante oblige à calculer des ombres séparément avec l un des algorithmes décrits dans le paragraphe précédent. L évolution en puissance des processeurs et des cartes graphiques permet, depuis peu, d utiliser des algorithmes de calcul de l éclairage indirect en temps réel, ce qui produit des rendus beaucoup plus réalistes. On peut notamment citer la méthode dite de la radiosité instantanée. Le principe est le suivant. À partir de chaque source de lumière présente sur la scène, on lance un certain nombre de rayons dans toutes les directions. Aux points d impact de ces rayons sur les éléments de la scène, on ajoute de nouvelles sources lumineuses avec une intensité inférieure à la source originale. Ces sources lumineuses simuleront l effet de la réflexion de la lumière de la source originale. On répète l opération un certain nombre de fois pour calculer plusieurs rebonds de lumière. La scène est ensuite rendue en tenant compte de toutes ces sources lumineuses, et sans lumière ambiante (ou très peu). Image 51 Radiosité instantanée. Plus le nombre de rayons lancés par source lumineuse est important et plus le nombre de rebonds calculés est important, plus le résultat obtenu sera réaliste. Mais la quantité de calculs nécessaires augmentera également. On a recours à des calculs statistiques pour limiter le nombre de rayons lancés en ne gardant que les plus pertinents. La cohérence temporelle peut aussi être utilisée pour se resservir des sources lumineunes calculées d une frame à l autre. La radiosité instantanée reste cependant très coûteuse à cause du nombre important de sources lumineuses que le système de rendu doit prendre en compte. Une nouvelle technique de rendu, idéale pour dessiner des scènes avec un grand nombre de sources de lumière, est de plus en plus utilisée : le defered shading. Cette technique reprend une idée proposée en 1988, mais elle n est utilisée que depuis quelques années, notamment dans le jeu Stalker de GSC Game World. Le principe est de différer le calcul de l éclairage à la toute fin du rendu. Tout d abord l image est rendue entièrement sans aucun éclairage (sauf la lumière ambiante, si elle est utilisée). Elle est stockée dans un buffer du GPU. Ensuite, pour chaque source de lumière, un volume correspondant à sa zone d action est calculé et envoyé au GPU. Le GPU teste alors la présence de chaque pixel de l image pour voir s il se trouve dans un, ou plusieurs, de ces volumes. Pour savoir si un pixel se trouve ou non dans un volume, il suffit de calculer ses coordonnées dans l espace 3D. Ce calcul est effectué à partir des coordonnées 2D du pixel sur l image et du tampon de profondeur. Les pixels affectés par les sources de lumière sont éclaircis, ce qui restitue Gestion de scène pour les moteurs 3D juillet /83

60 l effet de l éclairage. Le principal avantage de cette technique est que l éclairage n est calculé que pour les pixels visibles sur l image finale. De plus, tous les éclairages sont calculés ensemble. Le deferred shading est donc indiqué pour rendre des scènes comportant beaucoup de sources lumineuses. Il peut aussi être utilisé pour rendre les ombres calculées à l aide de shadow map ou de shadow volumes. Mais l implémentation du deferred shading sur les GPU actuels pose quelques difficultés, notamment au sujet de l anti-aliasing. Malgré tout, les résultats obtenus grâce à cette technique restent impressionnants. Il est probable que les performances des prochaines générations de GPU facilitent l usage de cette technique. L autre facteur limitant les avantages de la radiosité instantanée est le gestionnaire de scène lui-même : il est très sollicité par les nombreux lancers de rayons. 4.4 Critique de l existant Les techniques de gestion de scène apportent des solutions à de nombreux problèmes rencontrés par les créateurs d applications 3D temps réel. Mais elles sont malheureusement une importante source de contraintes pour eux. Un gestionnaire de scène idéal serait théoriquement capable : - d offrir un culling efficace pour n importe quel type de scène (intérieur, extérieur ) avec n importe quel point de vue, - de déterminer les niveaux de détails minimaux pour chaque élément visible de la scène sans entraîner de dégradation de l image finale, - d être sollicité un grand nombre de fois à chaque frame sans ralentir l application. Hélas, le gestionnaire de scène idéal n existe pas, du moins pas encore. Chacune des techniques présentées dans la partie qui précède impose des limitations. Les créateurs d applications 3D temps réel doivent prendre en compte ces limitations dans la conception leurs programmes, mais aussi dans le design de leur scène Faiblesses des algorithmes existants Le BSP Le système BSP + PVS, bien qu assez ancien, est encore très utilisé aujourd hui. Il a l avantage d être supporté par la quasi-totalité des moteurs 3D existants, mais il impose de sérieuses limitations. Il n est efficace que pour des scènes composées de petites régions séparées par des murs, typiquement des scènes d intérieur. Il est inadapté pour les grandes scènes d extérieur et celles comportant peu d occlusion. Les designer qui imaginent des scènes pour des moteurs 3D utilisant le BSP doivent prendre en compte cette contrainte. Cela complique leur travail et bride leur créativité. De plus, le BSP ne sait pas tirer parti des capacités du matériel actuel. Il a été conçu pour découper une scène en un ensemble de petites régions convexes pour pallier les défauts des systèmes de rendu de l époque. Aujourd hui cette fonctionnalité est devenue inutile. Elle est même devenue un facteur dégradant les performances. Rendre une scène découpée en régions signifie envoyer au système de rendu les polygones de chaque région séparément. Rendre beaucoup de petites régions fait perdre du temps en communication avec le GPU. Avec les cartes graphiques actuelles, à nombre de polygones égal, il est 58/83 Gestion de scène pour les moteurs 3D juillet 2009

61 bien plus rapide de rendre une scène constituée de peu de grosses régions qu une scène constituée de beaucoup de petites régions. Enfin, un autre inconvénient du BSP est qu il ne fonctionne que pour des scènes statiques. L arbre BSP d une scène est déterminé en précalcul, il ne peut pas être modifié pendant l exécution, par conséquent le BSP n est pas adapté aux scènes dynamiques où tout peut bouger. Par exemple, un jeu comportant un environnement destructible, ou le joueur peut détruire des murs et des bâtiments, ne peut pas fonctionner avec un BSP. Les portails Par rapport au BSP, le système des portails résout certains problèmes. Une scène découpée avec des portails est constituée de régions plus grosses, et les portails font une meilleure utilisation de l occlusion que le PVS. Cependant, tout comme le BSP, il n est efficace que pour des scènes d intérieur avec beaucoup d occlusion. Un autre inconvénient majeur de ce système est que son efficacité dépend énormément de la façon dont les portails sont placés sur la scène. Pour obtenir de bonnes performances, les portails doivent être disposés de façon intelligente pour profiter au maximum de l occlusion sans créer trop de petites régions. Le plus souvent, les portails sont placés à la main par les designers. Au sujet des scènes dynamiques, les portails offrent un peu plus de souplesse que le BSP. Il est possible d ajouter ou de supprimer des portails sur une scène pendant l exécution de l application. Dans un jeu offrant un environnement destructible, si le joueur fait exploser un mur, il est possible de créer dynamiquement un portail reliant les deux pièces séparées par ce mur à l endroit où il a été détruit. Mais cette solution reste tout de même très insuffisante. Les octree Les octree divisent la scène en régions, de façon régulière, sans s appuyer sur les éléments qui la composent. Ils peuvent donc être utilisés pour n importe quel type de scène (intérieur ou extérieur ). Ils sont aussi bien adaptatés aux scènes dynamiques, en particulier les loose octree dans lesquels il est très facile de localiser des éléments mobiles. Mais leur plus grosse lacune est qu ils ne savent pas tirer parti de l occlusion. En terme de culling, ils sont donc beaucoup moins efficaces que le BSP et les portails. Il est possible d utiliser les octree conjointement avec un système d occlusion dynamique comme les occlusion map ou les anti-portails, ou encore l occlusion sur GPU. Mais les octree offrent de piètres performances avec l occlusion. Les régions d un octree ne sont pas resserrées autour des éléments qu elles contiennent. Par conséquent, le système d occlusion peut facilement se tromper et dire qu une région est visible alors qu en réalité aucun élément qui s y trouve ne l est. La probabilité de rendre des éléments non visibles est donc élevée. Ce phénomène est encore plus fréquent avec un loose octree. Les ABT Tout comme les octree, les ABT peuvent être utilisés pour tout type de scène. Mais, contrairement à ces derniers, ils tiennent compte des éléments de la scène pour la diviser en régions. Ils doivent être précalculés et fonctionnent mal avec des scènes dynamiques. Le principal avantage des ABT sur les octree est qu ils fonctionnent très bien avec un Gestion de scène pour les moteurs 3D juillet /83

62 sytème d occlusion dynamique puisque les régions d un ABT sont resserrées autour des éléments qu elles contiennent. L occlusion dynamique Les algorithmes d occlusion dynamique : occlusion map, anti-portails et occlusion sur GPU, ont l avantage d être très souples d utilisation. Ils peuvent fonctionner avec tout type de scène, ce qui les rend très intéressants pour les situations où il n est pas possible d utiliser un système de partitionnement de l espace qui prend en compte l occlusion (BSP ou portails). Malheureusement, ils sont tous les trois assez difficiles à mettre en œuvre. Les occlusion map demandent beaucoup de calculs, ce qui risque de ralentir l application si elles sont utilisées avec une scène complexe ou s il est nécessaire de faire de nombreux rendus depuis différents points de vue. Les anti-portails ne sont pas très précis, et donc peu efficaces. Ils gèrent très mal les situations où un élément de la scène est occulté par une combinaison de plusieurs occludeurs. Ils ne sont donc utilisables que dans des scènes comportant des occludeurs de grande taille et peu nombreux. Enfin, l occlusion sur GPU ne peut être utilisée que grâce à la cohérence temporelle, ce qui n est pas toujours possible Faiblesses des implémentations existantes Les applications 3D temps réel récentes utilisent toujours plus de techniques de rendu (ombrage, cube map, illumination ) qui s appuient sur le gestionnaire de scène, ce qui augmente sa sollicitation. Les scènes rendues sont toujours plus grandes, ce qui augmente la quantité de données que le gestionnaire de scène doit traiter à chaque sollicitation. Le scènes rendues sont toujours plus riches et diversifiées, ce qui oblige le gestionnaire de scène à utiliser des algorithmes plus complexes. Pour toutes ces raisons, la gestion de scène coûte de plus en plus chère en quantité de calculs. En tant que l un des composants principaux des moteurs 3D, le gestionnaire de scène fonctionne sur le CPU. C est donc sur ce dernier que pèse l augmentation de la quantité de calculs nécessaires à la gestion de scène dans les applications 3D actuelles. Or, le CPU est également utilisé pour presque toutes les autres parties de ces applications : gestion des animations, chargement en tâche de fond, simulation physique, intelligence artificielle, réseau, et bien d autres Aujourd hui, les performances des applications 3D temps réel ne sont plus forcément limitées par la puissance du GPU, mais aussi par celle du CPU. Les fondeurs ont de plus en plus de difficultés à augmenter la fréquence d horloge de leurs processeurs, en raison du dégagement thermique que cela entraîne. Il n est pas possible d espérer, du moins pas dans les prochaines années, que l augmentation de la vitesse des CPU suffira à répondre aux besoins des applications 3D temps réel de demain. 60/83 Gestion de scène pour les moteurs 3D juillet 2009

63 5. Méthodes/démarches utilisées Pour trouver des informations quant aux possibles évolutions des moteurs 3D en général, et des gestionnaires de scène en particulier, je me suis attardé sur les sites web des fabricants de matériels, cartes graphiques et processeurs. Ces fabricants, tout particulièrement Intel et Nvidia, ont bien compris que pour mieux vendre leurs produits, ils devaient aider les développeurs à les utiliser. Ils publient donc une grande quantité d articles, certains écrits par eux-mêmes, d autres écrits par des développeurs qui ont utilisé leurs produits avec succès. Les articles et ouvrages qui m ont servi de références sont listés en annexe. Gestion de scène pour les moteurs 3D juillet /83

64 6. Description des améliorations L évolution des techniques de gestion de scène doit permettre de lever les limitations évoquées précédemment. Il faut que les gestionnaires de scène de demain soient capables de s adapter à n importe quel type de scène de façon à ne pas brider la créativité des artistes qui les dessinent. Pour cela, ils devront utiliser des techniques de culling, d occlusion et de détermination du niveau de détail plus polyvalentes, et donc, plus consommatrices en calcul. D autre part, ils devront être capables de supporter une sollicitation toujours plus importante sans ralentir l ensemble de l application. Par conséquent, les nouveaux gestionnaires de scènes devront pouvoir exploiter toute la puissance de calcul du matériel actuel. 6.1 Améliorations souhaitables Généraliser l usage des occlusion map Le phénomène de l occlusion est présent dans la quasi-totalité des scènes 3D complexes (à l exception de quelques cas particuliers comme le survol d un terrain par exemple). Mais les techniques d occlusion statique, comme les PVS et les portails, ne sont pas toujours capables de l exploiter. En fait, ces systèmes ne fonctionnent que s il est possible de découper la scène en régions bien délimitées par des occludeurs, ce qui n est pas toujours le cas. Seule l occlusion dynamique permet d exploiter ce phénomène dans n importe quel type de scène. Préférer l occlusion dynamique à l occlusion statique libère les artistes qui dessinent les scènes d une grande contrainte puisqu ils n ont plus à se préocuper de la facon dont leurs scènes seront découpées. Il est ainsi possible de créer des environnements virtuels plus variés. Pour utiliser l occlusion de manière efficace, un système de partitionnement de l espace qui crée des volumes resserrés autour des éléments de la scène est nécessaire. L utilisation d un ABT, ou d un système équivalent, s impose. Parmi les différentes techniques d occlusion dynamique que nous avons présentées, celle des occlusion map est la plus efficace et la plus souple d emploi, même si elle nécessite une quantité de calculs non négligeable. N importe quel type de géométrie peut être utilisé comme occludeur. Il est possible de précalculer ces occludeurs automatiquement à partir de la scène elle-même, ce qui évite au designer de la scène de les placer lui même. Il suffit de prendre les éléments les plus gros de la scène, donc ceux qui ont le plus de chance de contribuer à l occlusion, et d en faire un maillage à un niveau de détail extrêmement faible. Mutualiser occlusion map et détermination du niveau de détail Un autre avantage des occlusion map est qu elles peuvent être utilisées pour déterminer efficacement le niveau de détail avec lequel un élément doit être rendu. En effet, les occlusion map permettent d estimer précisément le nombe de pixels que l élément occupera sur l image finale. Mais, contrairement à l occlusion sur GPU, il est possible de savoir si ces pixels sont tous groupés ou éparpillés. Le premier cas se produit, par exemple, si un personnage se tient derrière un muret, il peut être à moitié visible, mais il doit quand même être rendu 62/83 Gestion de scène pour les moteurs 3D juillet 2009

65 Image 52 À visibilité égale, le personnage de droite peut être dessiné avec moins de détails que le personnage de gauche. avec un niveau de détail élevé. Le second cas se produit si le personnage est derrière un feuillage ou une grille, il peut être rendu alors avec un niveau de détail plus faible. Mutualiser occlusion map et radiosité instantanée A priori, les techniques des occlusion map et de la radiosité instantanée n ont pas grand chose en commun. Mais il est intéressant de constater qu elles nécessitent toutes deux les mêmes données en entrée : une version de la scène ne comportant que les éléments les plus importants avec un niveau de détail très faible. La radiosité instantanée utilise les polygones de la scène pour faire de la détection de collision par lancer de rayon. Plus le nombre de ces polygones est important, plus chaque lancer de rayon demande de calculs. Utiliser une version low poly de la scène pour réaliser les lancers de rayon accélèrerait le processus sans pour autant dégrader la qualité du résultat final. Les données correspondant à la version low poly de la scène peuvent donc être partagées par les deux techniques. Utiliser un système de partitionnement de l espace dynamique Un système de partitionnement de l espace qui s adapte à la géométrie de la scène, comme un ABT, est nécessaire pour maximiser l efficacité de l occlusion. Les ABT fonctionnent très bien avec une scène statique, mais pas avec une scène dynamique où les éléments bougent. Calculer un ABT pour une scène donnée demande beaucoup de calculs et prend du temps. Il n est pas possible de recalculer entièrement l ABT d une scène à chaque frame pour prendre en compte les déplacements des éléments. L utilisation de la cohérence temporelle permet de résoudre ce problème. On sait que les éléments de la scène bougent peu d une frame à l autre. Lorsque les éléments contenus dans une boîte englobante de l ABT bougent, cette boîte se déforme, ainsi que la boîte parente de celle-ci. Calculer la déformation des boîtes dont les éléments ont bougé ne demande que très peu de calculs. Cette opération peut être réalisée à chaque frame et ainsi l ABT peut s adapter au mouvement des éléments de la scène. Gestion de scène pour les moteurs 3D juillet /83

66 Image 53 Lorsque les éléments contenus dans un ABT se déplacent, les boîtes englobantes de ce dernier se déforment. Lorsqu elles sont trop déformées, il faut les recalculer. Le problème est que, au bout d un certain temps, lorsque les boîtes se seront trop déformées, l ABT ne sera plus optimal. Les boîtes englobantes ne seront plus resserrées autour des éléments qu elles contiennent. Elles contiendront trop d espace vide, ce qui détériorera l efficacité du culling et de l occlusion. Mais grâce à la cohérence temporelle, on sait que cette détérioration ne sera pas immédiate mais progressive : plus le temps passe et plus l ABT se détériore. La solution est de recalculer l ABT par petits bouts. Quand une partie de l ABT s est trop détériorée, le système la redécoupe en boîtes englobantes en s appuyant sur la géométrie des éléments. Ainsi, l ABT n est jamais recalculé dans son entier, mais morceau par morceau. À chaque frame, il est possible de recalculer une partie de l ABT. La cohérence temporelle nous garantit que cette partie ne se détériorera pas immédiatement, il ne sera donc pas nécessaire de la recalculer à la frame suivante. On pourra, à la place, recalculer une autre partie. De cette façon, l ABT reste toujours à peu près optimal sans demander trop de calcul à chaque frame. Parallèliser Le gestionnaire de scène a besoin de toujours plus de puissance de calcul pour pouvoir utiliser des techniques plus exigeantes (occlusion map, ABT dynamique ) et répondre à une sollicitation toujours plus importante. La rapidité des CPU n a que peu augmenté ces dernières années. Les fondeurs prévoient qu ils auront de plus en plus de mal à augmenter la vitesse de fonctionnement de leurs processeurs. Ainsi, pour augmen- ter leur puissance de calcul, se tournent-ils vers une autre solution : le parallèlisme. Il s agit de découper le travail en plusieurs tâches séparées et de faire travailler plusieurs processeurs en même temps, chacun sur une tâche. Le travail ainsi réparti entre plusieurs processeurs qui calculent en parallèle est finalisé beaucoup plus rapidement que s il était réalisé par un seul processeur. Image 54 Quand plusieurs tâches sont exécutées en série, le temps d exécution total est la somme du temps d exécution de chaque tâche. La difficulté de cette technique réside en ce qu il faut pouvoir découper le travail en tâches indépendantes pouvant être réalisées simultanément. Ce n est pas toujours possible. 64/83 Gestion de scène pour les moteurs 3D juillet 2009

67 Image 55 Quand plusieurs tâches sont exécutées en parallèle, le temps d exécution total est celui de la tâche la plus longue. Un programme ne peut tirer bénéfice du parallèlisme que s il a été conçu pour cela. Même s il fonctionne sur un ordinateur doté de plusieurs processeurs, un programme qui n a pas été conçu dans cette optique ne gagnera pas en performance, car en fait, il ne fonctionnera seulement que sur l un d entre eux. Les programmeurs devront adapter leurs applications s ils souhaitent tirer parti du parallèlisme, ce qui, dans la plupart des cas, signifie réécrire entièrement l application. Le parallèlisme représente le principal espoir pour les développeurs d obtenir le gain de performances dont ils ont besoin. Les processeurs multicœurs sont de plus en plus répandus dans les ordinateurs personnels, et le nombre de cœurs qu ils contiennent va augmenter rapidement dans les prochaines années. De plus, les processeurs ne sont plus les seules unités de calcul disponibles à l intérieur de nos ordinateurs. Les GPU, qui contiennent depuis longtemps déjà un nombre important de cœurs, peuvent aujourd hui être utilisés pour faire des calculs autres que du rendu 3D. Les gestionnaires de scène sont de bons candidats pour le parallèlisme. Ils sont sollicités plusieurs fois à chaque frame par l application. Chaque sollicitation est indépendante des autres. Elles pourraient donc toutes être traitées parallèlement plutôt que chacune à la suite l une de l autre comme c est actuellement le cas. Chaque sollicitation pourrait même être découpée en plusieurs tâches capables d être exécutées en parallèle, ce qui diminuerait leur temps de traitement. - La recherche des régions visibles d un ABT peut être découpée en plusieurs tâches qui travaillent chacune sur des parties différentes de l arbre. - La génération d une occlusion map peut être découpée en plusieurs tâches qui rendent chacune un certain nombre d occludeurs. - Le lancer d une multitude de rayons pour faire de la radiosité instantanée peut être découpée en plusieurs tâches qui traitent un rayon chacune. Le gestionnaire de scène peut ainsi générer à lui seul une multitude de tâches indépen- Gestion de scène pour les moteurs 3D juillet /83

68 dantes. Ainsi, plus l ordinateur sur lequel il fonctionne possède de processeurs (ou de cœurs de processeurs), plus le gestionnaire de scène sera performant. 6.2 Solutions possibles Exploiter les processeurs multicœurs Un processeur multicœurs est un ensemble de processeurs gravés au sein de la même puce. Un ordinateur doté d un processeur multicœurs est donc équivalent, à quelques détails près, à un ordinateur équipé de plusieurs processeurs. Le système d exploitation se charge de répartir l exécution des différents programmes qui fonctionnent entre les différents cœurs. Un programme n a aucun moyen de prédire sur quel cœur il sera exécuté, ni à quel moment. Un même programme peut utiliser plusieurs cœurs en même temps à condition qu il ait été découpé en plusieurs fils d exécutions, appelés threads en anglais. Les threads correspondent à différentes parties du programme qui peuvent être exécutées simultanément. En général, un cœur ne peut exécuter qu un seul thread à la fois, mais sur certains processeurs multicœurs récents qui bénéficient de la technologie Hyper Threading, chaque cœur peut exécuter simultanément deux threads. Pour exploiter au maximum les performances de l ordinateur sur lequel il fonctionne, un programme a intérêt à créer plusieurs threads et à répartir son travail, ses tâches, entre ces différents threads. Cette approche convient parfaitement aux gestionnaires de scène. Chaque sollicitation d un gestionnaire de scène pourrait entraîner la création d une tâche, qui, à son tour, pourrait créer d autres tâches si nécessaire. L écriture d un programme composé de plusieurs threads est un exercice délicat. Le programmeur doit veiller à ce que l exécution d un thread ne puisse jamais perturber celle des autres, ce qui peut s avérer complexe lorsque plusieurs threads doivent manipuler les mêmes données. Pour cette raison, il est extrêmement difficile de modifier un programme existant, non conçu pour fonctionner avec plusieurs threads, pour en faire un programme multithreadé. Il est souvent plus simple, et plus sûr, de réécrire ce programme entièrement en prenant en compte les contraintes du multithreading dès la conception. Adapter les moteurs 3D existants pour les rendre capables d exploiter la puissance des processeurs multicœurs nécessitera de revoir leur structure en profondeur, un travail long et périlleux qui risque de décourager programmeurs et entreprises qui voudraient s y frotter. Exploiter le GPU Les GPU actuels sont en fait des processeurs multicœurs contenant un très grand nombre de cœurs. Même si leur fonction première est le rendu 3D, il est possible de les programmer pour leur faire faire autre chose. On parle alors de GPGPU pour General Purpose GPU ou GPU à usage général en français. Cette technique est utilisée par certaines applications qui nécessitent une très grande puissance de calcul, par exemple pour faire de la cryptanalyse ou en traitement du signal. La société Kaspersky, spécialisée en sécurité informatique, a récemment testé l utilisation du GPU pour faire de l analyse de données et de la détection de virus. Elle a obtenu un gain de performance d environ % en faisant les calculs sur un GPU haut de gamme plutôt que sur un processeur de dernière génération. 66/83 Gestion de scène pour les moteurs 3D juillet 2009

69 Conscient du potentiel de leurs produits dans des domaines autres que la 3D, les fabricants de GPU ont mis à disposition des programmeurs des interfaces applicatives dédiées au GPGPU. On peut notamment citer la technologie CUDA de Nvidia, qui ne fonctionne que sur les GPU de cette marque. Par ailleurs, le consortium Khronos, déjà connu pour être responsable d OpenGL, vient de mettre au point OpenCL, une norme universelle destinée au GPGPU qui aura l avantage d être supportée par tous les fabricants de GPU. OpenCL devrait même dépasser le domaine des GPU et être capable d utiliser le Larabee d Intel et le processeur Cell d IBM. Mais, à l heure actuelle, aucune implémentation d OpenCL n est encore disponible. Le principal problème posé par la programmation des GPU est qu elle ne fonctionne bien que pour des programmes extrêmement parrallèlisables, typiquement des programmes qui doivent traiter une multitude d informations de manière identique. L architecture des GPU ne permet pas aux différents cœurs d exécuter des instructions différentes simultanément. Si deux programmes, fonctionnant sur deux cœurs d un même GPU, ont besoin d exécuter une suite d instructions différentes (par exemple à cause d une branche conditionnelle dans le programme), l un des cœurs sera mis en sommeil pendant que l autre travaillera, avant d être réveillé pour travailler à son tour pendant que l autre sera en sommeil. Par conséquent, la programmation sur GPU ne sera réellement efficace que si tous les cœurs du GPU exécutent le même programme. Sur les GPU récents, les cœurs sont regroupés en blocs, appelés warp. Les cœurs d une même warp sont contraints d exécuter les mêmes instructions mais sont indépendants des cœurs situés dans les autres warps, ce qui atténue quelque peu la contrainte évoquée précédemment. D autre part, les cœurs des GPU ne supportent pas les appels de fonction récursifs. Toutes ces contraintes ne semblent pas compatibles avec la gestion de scène, puisque les algorithmes utilisés par ces derniers font un fort usage de la récursivité. Bien que la puissance de calcul des GPU soit très allèchante, développer un gestionnaire de scène qui les utilise sera difficile, et le résultat ne sera pas optimal. 6.3 Choix des solutions et argumentation/justification du choix La solution consistant à utiliser les processeurs multicœurs semble être la plus prometteuse. Les algorithmes utilisés par les gestionnaires de scène pourront facilement être parallèlisés et répartis dans plusieurs threads. De plus, modifier un moteur 3D de façon à ce qu il puisse utiliser des threads pourrait bénéficier non seulement à la gestion de scène, mais aussi à l ensemble du moteur, voire même à l ensemble de l application. La solution consistant à effectuer la gestion de scène sur le GPU ne semble pas être une bonne voie de recherche, du moins pas pour le moment. Outre le fait que les contraintes de la programmation sur GPU sont difficilement compatibles avec les algorithmes utilisés par la gestion de scène, il faut savoir que cette technologie n en est encore qu à ses balbutiements. La spécification d OpenCL vient à peine d être publiée, aucune documentation n est disponible et il n existe encore aucune implémentation utilisable. La technologie CUDA, quant à elle, semble vouée à disparaître dans un avenir proche du fait de sa non-portabilité. Il est probable que, dans les années à venir, cette technologie évoluera, à la fois sur le plan du matériel et celui du logiciel, et offira de nouvelles perspectives. Mais aujourd hui, elle ne représente pas une solution viable pour la gestion de scène. La technologie du multithreading, quant à elle, existe depuis de nombreuses années. Gestion de scène pour les moteurs 3D juillet /83

70 Elle est bien antérieure à l apparition des processeurs multicœurs. Ses tenants et aboutissants sont connus, elle est largement documentée, elle est implémentée dans tous les systèmes d exploitation modernes. C est donc la solution consistant à utiliser les processeurs multicœurs qui sera développée dans le reste de ce mémoire. 68/83 Gestion de scène pour les moteurs 3D juillet 2009

71 7. Description détaillée de la solution choisie 7.1 L utilisation du multithreading pour gagner en performance Process et thread Tous les systèmes d exploitation modernes utilisent des processus et des threads comme unité d exécution. Un processus correspond à un programme en cours d exécution. Le système se charge d allouer de la mémoire à chaque processus et leur permet d accéder aux ressources de l ordinateur (système de fichiers, réseau, carte graphique ). Pour éviter que les applications puissent se perturber les unes les autres, le système veille à ce qu un processus ne puisse pas accéder à la mémoire d un autre processus et aussi que plusieurs processus ne puissent pas accéder à la même ressource simultanément. Un thread correspond à un fil d exécution au sein d un processus. Chaque processus possède au moins un thread. Les threads d un même processus partagent la mémoire de celui-ci sans restriction. Image 56 Process et thread. Lorsqu on veut qu un programme fasse plusieurs choses simultanément, deux méthodes sont possibles : le multiprocessing et le multithreading. La première consiste à créer plusieurs processus pour le programme, la seconde à créer plusieurs threads. Le multithreading est la solution privilégiée car les différents threads peuvent communiquer via la mémoire qu ils partagent, ce qui est très rapide. Au contraire, plusieurs processus ne peuvent communiquer que par le biais du système d exploitation, ce qui est plus complexe et plus lent. Cependant, le multiprocessing est parfois privilégié dans certaines applications qui ont des contraintes de sécurité importantes (par exemple certains navigateurs web). Le fait qu un processus ne puisse pas accèder à la mémoire des autres permet de limiter la portée d une éventuelle faille de sécurité. Dans le cas des applications 3D temps réel, le multithreading est la meilleure solution. Multitâches et ordonnancement Un système d exploitation est dit multitâches s il est capable de faire fonctionner simultanément plusieurs applications sur un même machine. Les systèmes d exploitation modernes sont tous multitâches, or ils fonctionnent sur des processeurs qui ne le sont pas. Un processeur classique ne peut exécuter qu un seul thread à la fois, et le nombre de threads que peut exécuter simultanément un processeur multicœurs est limité par le nombre de cœurs qu il possède. Si le nombre de programmes qui fonctionnent sur l ordinateur est supérieur à la capacité du processeur, ce qui est généralement le cas, le système d exloitation doit partager le temps du processeur entre les différents threads. L ordonnanceur est l élément du système d exploitation qui est chargé de cette répartition. Tous les systèmes d exploitation modernes disposent d un ordonnanceur préemptif, ce Gestion de scène pour les moteurs 3D juillet /83

72 qui veut dire qu il peut interrompre à tout moment un thread en cours d exécution pour permettre à un autre thread de s exécuter. Les threads s exécutent chacun leur tour sur le processeur, on parle de temps partagé. L ordonnanceur donne la main à un thread qui s exécutera sur le processeur pendant un certain laps de temps avant que l ordonnanceur ne l interrompt pour donner la main à un autre thread. L exécution d un thread peut être interrompue prématurément si celui-ci effectue un appel système, c est-à-dire une requête au système d exploitation pour accéder à une ressource de l ordinateur. La lecture ou l écriture d un fichier sur le disque dur, l envoi ou la réception de données sur une connexion réseau, ou l attente d un certain nombre de millisecondes, sont des exemples d appels système. On parle aussi de requêtes bloquantes car quand un thread en utilise une, son exécution sera interrompue et ne reprendra pas avant la complétion de la requête par le système d exploitation. Lorsqu un thread est interrompu par l ordonnanceur celui-ci doit être capable de relancer son exécution plus tard. Un thread n est rien de plus qu une suite d instructions qui s exécutent sur le processeur du système. Pour pouvoir interrompre l exécution d un thread et la relancer ultérieurement, il est nécessaire de sauvegarder l état du processeur au moment où l exécution du thread est interrompue et de le restaurer au moment où on la relance. Cette opération est appelée changement de contexte. La faiblesse majeure des systèmes préemptifs est que le changement de contexte est fastidieux et fait perdre du temps. Puisqu un thread peut être interrompu à tout moment, il n est pas possible pour l ordonnanceur de savoir quelles informations il est nécessaire de sauvegarder, il doit donc sauvegarder tous les registres du processeur à chaque fois. Si le nombre de threads qui fonctionnent sur l ordinateur dépasse de beaucoup la capacité du processeur, l ordonnanceur perdra beaucoup de temps en changements de contexte, ce qui peut dégrader les performances de tout le système. L exclusion mutuelle La principale difficulté posée par la programmation multithreading est de préserver l intégrité des données manipulées par les threads. En effet, il ne faut pas qu un thread puisse modifier des données présentes en mémoire pendant qu un autre est en train de les lire. De même, il ne faut pas que deux threads modifient les mêmes données en même temps (par contre, plusieurs threads peuvent lire simultanément les mêmes données sans que cela ne pose de problème). La solution à ce problème s appelle l exclusion mutuelle. Le principe est que, lorsqu un thread utilise des données auxquelles d autres threads peuvent accèder, il les verrouille, et il ne les déverrouillera que lorsqu il aura fini de les utiliser. Pendant que les données sont verrouillées, aucun autre thread ne peut y accèder. Un thread qui veut utiliser des données verrouillées doit attendre qu elles soient déverrouillées. Il existe deux mécanismes permettant d utiliser l exclusion mutuelle : les opérations atomiques et les mutex. Les opérations atomiques sont des instructions spécifiques du processeur dont l exécution ne peut être interrompue. Une opération atomique peut successivement lire, tester et écrire une donnée en mémoire en garantissant qu aucun autre thread n accèdera à cette donnée pendant l opération. Les opérations atomiques sont très faciles à utiliser mais ne peuvent manipuler que des données de petite taille, c est-à-dire les types de données gérées par le processeur. Les mutex sont des objets qui peuvent être dans deux états : verrouillé et déverrouillé. Le mutex garantit qu il ne peut être verrouillé que par un seul thread à la fois. Si un thread a verrouillé un mutex, alors tout autre thread qui essaiera de verrouiller le mutex 70/83 Gestion de scène pour les moteurs 3D juillet 2009

73 sera mis en sommeil jusqu à ce que le premier thread déverrouille le mutex. Le mutex lui-même ne manipule aucune donnée, il ne sert qu à indiquer un état, c est au programmeur de décider de sa signification. Un mutex peut par exemple être utilisé pour indiquer que certaines données sont utilisées par un thread et que, par conséquent, aucun autre thread ne doit tenter d y accéder tant que le mutex n est pas déverrouillé. L avantage des mutex est qu ils peuvent être utilisés pour protéger des données de n importe quelle taille, contrairement aux opérations atomiques. Si l exclusion mutuelle est indispensable au bon fonctionnement de tout programme multithreadé, elle peut dégrader sérieusement les performances de ces derniers si elle n est pas utilisée correctement. Quand le multithreading est utilisé pour augmenter les performances d une application, il faut veiller à ce que les threads ne passent pas leur temps à se disputer l usage des mutex, sinon ils passeront plus de temps à attendre qu à travailler. Le multithreading à l heure des processeurs multicœurs Sur un ordinateur muni d un unique processeur, non multicœurs, la seule utilité du multithreading est de donner l impression à l utilisateur que son système exécute plusieurs actions simultanément, bien que techniquement ce ne soit pas le cas. Mais grâce aux processeurs multicœurs, le multithreading peut servir à augmenter les performances des applications, puisqu il est possible d effectuer réellement plusieurs actions simultanément. Une application peut répartir son travail dans différents threads, avec l espoir que ces threads seront exécutés simultanément sur des cœurs différents, et ainsi effectuer toutes ces tâches parallèlement plutôt que les unes à la suite des autres. Il faut cependant faire attention à ne pas créer trop de threads, car cela surchargerait l ordonnanceur et ralentirait l application. Créer un thread pour chaque tâche n est donc pas une bonne solution. La meilleure solution consiste à créer autant de threads qu il y a de cœurs disponibles sur l ordinateur et à répartir les tâches entre eux de manière dynamique. On appelle ces threads les threads de travail. L application crée des tâches qui sont mises dans une file d attente pour ensuite être exécutées par l un des threads. Grâce à ce système, plus l ordinateur possède de cœurs, plus l application peut créer de threads de travail et plus les tâches peuvent être exécutées parallèlement. En d autre termes, les performances de l application augmentent proportionnellement avec le nombre de cœurs du processeur. Puisque le nombre de cœurs disponibles sur les processeurs augmentera au fur et à mesure que ces derniers évolueront, l application gagnera en performance avec chaque nouvelle génération de processeurs. Gestion de scène pour les moteurs 3D juillet /83

74 Pour que le système soit efficace, il faut que les threads de travail gardent la main sur le processeur aussi longtemps que possible. Lorsque l ordonnanceur interrompt l un d entre eux, c est toute l application qui est ralentie. Pour cette raison, il ne faut surtout pas que l un de ces threads effectue une opération bloquante, sinon il sera mis en sommeil par l ordonanceur immédiatement. Le programmeur doit veiller à ne pas utiliser d appel système dans les tâches de son application. Au contraire, les opérations bloquantes doivent être exécutées dans un thread séparé créé spécialement pour cet usage. On appelle cela un thread d attente. De même, dans une tâche, il est hors de question d attendre la libération d un mutex car cela aussi est une opération bloquan- te. Il est préférable d utiliser des opérations atomiques ou des spins mutex. Quand un thread attend la libération d un spin mutex, il n est pas mis en sommeil par l ordonnanceur, il continue à s exécuter sans rien faire, en bouclant sur des instructions inutiles, jusqu à ce que le spin mutex se libère. Cette particularité rend les spins mutex très pratiques, mais ils ne doivent être utilisés que pour encadrer les sections de code très courtes, sans quoi, les threads qui attendent leur libération risquent de monopoliser le processeur très longtemps pour ne rien faire. Image 57 Répartition des tâches dans les threads. De plus, l ordonnanceur ne peut pas mettre en sommeil un thread pendant que celui-ci tient un spin mutex, s il le faisait, tous les threads qui attendent la libération de ce mutex pourraient monopoliser inutilement le processeur indéfiniment. Pour cette raison, un thread qui tiendrait un spin mutex pendant de longues périodes risquerait de perturber tout le fonctionnement de l ordonnanceur. Enfin, certaines des librairies utilisées par les applications 3D temps réel ne sont pas conçues pour fonctionner avec des threads. C est le cas, par exemple, d OpenGL. Dans une application 3D multithreadée, il faut s assurer que toutes les fonctions d OpenGL sont exécutées à partir du même thread. Il ne faut donc pas les appeler dans des tâches. En général, une application multithreadée utilise un thread principal, celui qui est créé automatiquement par le système au lancement de l application, pour utiliser les différentes libraries dont elle a besoin. Les tâches ne sont utilisées que pour les calculs faits en interne dans l application. Parallèliser la gestion de scène Pour améliorer les performances d un moteur 3D grâce au multithreading, il faut commencer par déterminer quelles sont les opérations réalisées par le moteur qui peuvent être parallélisées efficacement. Une opération peut être parallèlisée si elle peut être dé- 72/83 Gestion de scène pour les moteurs 3D juillet 2009

75 composée en plusieurs tâches exécutables indépendamment les unes des autres et en utilisant pas, ou peu, d exclusions mutuelles. Paralléliser la totalité du moteur est sans intérêt. D après le principe de Pareto, statistiquement, lorsqu une cause produit un effet, seul 20 % de la cause est responsable de 80 % de l effet. Si on applique ce principe à un programme dont on souhaite augmenter les performances, on peut dire que la cause est le code du programme, et l effet le temps de calcul engendré par l exécution de ce code sur le processeur. On peut donc estimer que seul 20 % du code d un moteur 3D est responsable de 80 % de son temps d exécution. Il suffit de détecter et de parallèliser ces 20 % de code pour obtenir un gain de performance significatif. La gestion de scène peut représenter une part significative du temps d exécution d un moteur 3D dans le cas où des scènes complexes sont utilisées. Or, les algorithmes utilisés par les gestionnaires de scène se prêtent bien au jeu de la parallèlisation. Non seulement ces algorithmes peuvent facilement être découpés en tâches, mais en plus ces tâches n ont presque pas besoin d exclusion mutuelle. La plupart des opérations réalisées par le gestionnaire de scène consistent à faire des recherches dans le graphe de scène ou dans l arbre du système de partitionnement de l espace. C est par exemple le cas du frustum culling effectué pour chaque rendu où des lancers de rayons utilisés pour la radiosité instantanée. Effectuer plusieurs recherches dans un arbre simultanément ne nécessite pas d exclusion mutuelle puisque les différentes tâches ne font que lire les données de l arbre mais ne les modifient pas. La génération des occlusion map est aussi un bon canditat pour la parallèlisation. Cette opération consiste à rendre un grand nombre de polygones dans un tampon de profondeur. Une opération qui consiste à accumuler un ensemble de données (dans notre cas les polygones) pour obtenir un résultat (le tampon de profondeur) est appelée une réduction. Une réduction parallèlisée fonctionne de la manière suivante. La liste des polygones est découpée en plusieurs fragments. Chaque fragment est traité par une tâche qui va dessiner ses polygones dans un tampon de profondeur qui lui est propre. Ensuite les tampons de profondeur créés par les différentes tâches sont combinés pour obtenir le tampon de profondeur final. Cette combinaison peut aussi s effectuer de façon parallèle, par exemple en divisant le tampon en sections qui sont chacune combinées par une tâche différente. Structure d un moteur 3D multithreadé Un moteur 3D conçu pour le parallèlisme serait constitué des éléments suivants : - Un thread principal. Il se charge de créer les tâches et de synchroniser tous les autres threads. Il contient la boucle principale du moteur 3D et le point d entrée de l application. Le reste de l application s exécute également dans ce thread. - Plusieurs threads de travail. Ils se chargent d exécuter les tâches crées par le thread principal, ou les tâches créées par d autres tâches. Leur nombre dépend du nombre de cœurs disponibles sur l ordinateur. - Un thread de rendu. Il se charge d utiliser le système de rendu puisque l utilisation de ce dernier n est pas parallèlisable. - Un thread de chargement. Il est responsable du chargement des données dont l application a besoin en effectuant, par exemple, des accès au disque dur ou des téléchargements via une connexion réseau. Ces opérations étant bloquantes, il est nécessaire de les effectuer dans un thread séparé. Gestion de scène pour les moteurs 3D juillet /83

76 Image 58 Structure du moteur Bien sûr, le moteur 3D n est pas le seul composant de l application qui peut bénéficier du parallèlisme. D autres composants que l on retrouve souvent dans les applications 3D temps réel, comme l intelligence artificielle ou la simulation physique, pourraient également créer des tâches qui s exécuteraient dans les threads de travail. Afin de ne pas surcharger l ordonnanceur du système d exploitation, il vaut mieux que ces composants utilisent les mêmes threads de travail que ceux du moteur 3D plutôt que de créer les leurs. 74/83 Gestion de scène pour les moteurs 3D juillet 2009

77 7.2 Facteurs limitants l efficacité de multithreading Problèmes liés aux allocations de mémoire Lorsqu un processus est créé, le système d exploitation met à sa disposition une certaine quantité de mémoire dans laquelle il pourra allouer les structures de données dont il a besoin pour fonctionner. Si le processus est mulithreadé, le système d allocation doit empêcher deux threads d effectuer des allocations en même temps. Si cela se produisait, il y aurait un risque que les espaces alloués se chevauchent, ce qui entraînerait inévitablement une corruption des données. Pour cela, le système d allocation est protégé par un mutex. Ce mutex peut sérieusement dégrader les performances d une application multithreadée dans le cas où les différents threads de cette application effectueraient souvent des allocations, car ils iraient se disputer l usage du système d allocation sans arrêt (seules les allocations dynamiques sont concernées par ce problème, les allocations statiques ne le sont pas car chaque thread dispose de sa propre pile). La solution la plus simple, et la plus efficace, est de faire très peu d allocations en dehors du thread principal, mais ce n est pas toujours possible. Une autre solution est d utiliser un système d allocation spécialement conçu pour les applications multithreadées. Ce type de système d allocations fonctionne en partageant la mémoire du processus entre les différents threads de façon à ce que deux threads ne puissent pas allouer de données au même endroit, il n est donc plus nécessaire d utiliser un mutex. Malheureusement, ces systèmes d allocation n utilisent pas la mémoire d une manière aussi optimale que les systèmes d allocation classiques. Problèmes liés au cache Les limitations de la mémoire cache est un facteur qui dégrade énormément les performances des programmes, multithreadés ou non. Le processeur d un ordinateur ne peut pas accéder directement à l ensemble de la mémoire. Quand il a besoin de travailler sur des données stockées dans celle-ci, il doit d abord transférer ces données depuis la mémoire vers le cache, ce qui fait perdre du temps. Par contre, une fois les données présentes en cache, le processeur peut y accéder instantanément. Il existe plusieurs techniques de programmation permettant d optimiser l usage du cache, les décrire sort du cadre de ce mémoire. Mais l utilisation du multithreading sur des processeurs multicœurs génère de nouveaux problèmes liés au cache, en particulier le problème dit du faux partage (false sharing en anglais). Dans un processeur multicœurs, chaque cœur possède son cache. Le cache divise la mémoire en blocs appelés lignes de cache. Lorsque le processeur a besoin d une donnée en mémoire, il va déterminer dans quelle ligne se trouve cette donnée et copier la ligne entière dans le cache. Le false sharing intervient dans le cas où deux données totalement indépendantes l une de l autre et utilisées simultanément par deux threads différents fonctionnant sur deux cœurs différents, se trouveraient malencontreusement stockées dans la même ligne de cache. Lorsque le premier thread modifie sa donnée, le processeur considère que c est toute la ligne qui a été modifiée. Si le second thread possède une copie de cette ligne dans son cache, et même s il n utilise pas la donnée modifiée par le premier thread, le processeur va invalider cette ligne. La ligne sera copiée depuis le cache du premier thread vers la mémoire, pour ensuite être copiée depuis la mémoire vers le cache du second thread. Et cette opération fastidieuse se répètera à chaque fois que l un des threads modifiera une des données présentes dans la ligne, d où une perte de temps importante. Dans les processeurs multicœurs récents, les cœurs partagent un cache de haut niveau au sein du processeur en plus de leur cache indépendant, ce qui réduit l impact du false Gestion de scène pour les moteurs 3D juillet /83

78 sharing. Pour synchroniser une ligne de cache utilisée par deux cœurs, il n est plus nécessaire de la copier en mémoire, la copier dans le cache de haut niveau suffit, ce qui est beaucoup plus rapide. Malgré cela, il est conseillé aux programmeurs d applications multithreadées de prendre en compte le problème du false sharing dans la conception de leurs programmes et de s arranger pour que des données indépendantes les unes des autres ne soient pas stockées dans les mêmes lignes de cache. Problèmes liés aux systèmes de rendu L utilisation du système de rendu est une des opérations réalisées par le moteur 3D qui consomme le plus de temps. Il pourrait sembler intéressant de la parallèliser pour l accélérer. Ce n est malheureusement pas possible. Les systèmes de rendu actuels (du moins les plus utilisés, OpenGL et DirectX) ne sont pas conçus pour être utilisés par plusieurs threads différents. Et pour cause, il n y a qu un seul GPU. Même dans un ordinateur équipé de plusieurs GPU qui travaillent de concert (technologie SLI ou CrossFire), du point de vue du système d exploitation il n existe qu un seul GPU virtuel. Il n est pas possible que plusieurs threads communiquent avec le GPU simultanément. Si l on voulait que plusieurs threads puissent utiliser le GPU, il faudrait mettre un mutex sur ce dernier, ce qui fait perdre tout son intérêt à une éventuelle parallèlisation du rendu. La prochaine mouture de DirectX pourra être utilisée dans plusieurs threads simultanément. Certaines opérations, comme le chargement de ressources ou la création de listes de commandes pour le GPU, pourront être threadées. Mais en interne, la communication avec le GPU restera mono thread. Cette évolution de DirectX est bienvenue, mais il ne faut pas en attendre un gain de performance énorme. De plus, le problème majeur de DirectX est que ce système de rendu est la propriété de Microsoft et que, par conséquent, il ne fonctionne que sur les systèmes d exploitation de ce dernier, et il ne sera possible de profiter du nouveau DirectX que sur les plus récents de ces systèmes. Du coté d OpenGL, les améliorations facilitant l usage du multithreading se font attendre. Le consortium Khronos a le plus grand mal à mettre tous ses participants d accord, ce qui explique l évolution très lente de la norme. Heureusement, l évolution du matériel semble anoncer la mort prochaine de DirectX et d OpenGL, du moins dans leur forme actuelle. L avenir nous promet des GPU totalement programmables dans lesquels les applications 3D temps réel pourront charger le système de rendu qu elles désirent. Il ne sera donc plus nécessaire de se conformer à des normes, les développeurs auront une totale liberté d utilisation du GPU. Une solution qui permettra non seulement de créer des systèmes de rendu atypiques, par exemple des systèmes utilisant le raytracing ou les voxels, mais surtout, libérera les développeurs de la dictature de Microsoft et des caprices de Khronos. 76/83 Gestion de scène pour les moteurs 3D juillet 2009

79 8. Synthèse des résultats Notre étude de la gestion de scène a commencé par une analyse exhaustive des techniques existantes. Nous avons également étudié la façon dont la gestion de scène est utilisée au sein des moteurs 3D. Enfin, nous avons détaillé les forces et les faiblesses des différentes techniques présentées. Il est apparu que la gestion de scène est aujourd hui à un tournant de son évolution. Les techniques existantes, que nous avons présentées, peuvent être classées en deux catégories. D un côté, les techniques obsolètes qui sont encore très utilisées car bien maîtrisées et efficaces, mais trop limitées et incapables de répondre aux besoins des applications 3D de demain. D un autre coté, les techniques en avance sur leur temps qui offrent des possibilités intéressantes, mais demandent encore trop de puissance de calcul pour être utilisées couramment. D autre part, nous avons vu que, dans les moteurs 3D récents, le gestionnaire de scène est de plus en plus sollicité. Il est donc clair que les futurs gestionnaires de scène nécessiteront une puissance de calcul plus importante que celle dont ils disposent aujourd hui. Nous avons brièvement présenté les processeurs multicœurs et la programmation sur GPU qui sont deux technologies récentes, mais disponibles dans les ordinateurs actuels, et qui pourraient offrir la puissance dont les futurs gestionnaires de scène et, plus généralement, les futurs moteurs 3D auront besoin. Après avoir analysé les possibilités et les contraintes de ces deux techniques, nous avons démontré que l utilisation des processeurs multicœurs est la meilleure solution. Nous avons décrit leur fonctionnement et la manière dont les applications peuvent les utiliser pour gagner en performances. Nous avons signalé les pièges liés à leur usage et auxquels les programmeurs doivent prendre garde. Enfin, nous avons présenté une solution réalisable, permettant d augmenter la puissance de calcul accessible aux moteurs 3D, ce qui autorisera l utilisation de techniques de gestion de scène plus puissantes et le développement d applications 3D offrant des scènes plus complexes et variées. Gestion de scène pour les moteurs 3D juillet /83

80 9. Enseignements tirés, apport du travail Ce mémoire a été pour moi une bonne opportunité d approfondir mes connaissances concernant le rendu 3D temps réel. J ai acquis une bonne vision d ensemble du fonctionnement d un moteur 3D et de la probèmatique liée à son amélioration. J ai d ailleurs l intention de travailler dans ce domaine une fois mes études terminées. J ai réalisé le potentiel de la programmation parallélisée et j ai eu l occasion d étudier son fonctionnement en détail. Ces techniques sont encore très nouvelles, il a été difficile d accéder à de la documentation pertinente. Mon expérience de la programmation embarquée et temps réel m a été utile. Elle m avait permis de découvrir le fonctionnement des systèmes d exploitation multitâches et donné l occasion de travailler sur des programmes multithreadés. Je ne savais rien du fonctionnement des processeurs multicœurs ni de la manière de les utiliser. Ce mémoire m a permis de combler cette lacune et d approfondir mes connaissances dans ces domaines. J envisage de continuer à me spécialiser dans ces techniques prometteuses et d en faire l atout de mon insertion professionnelle à venir. 78/83 Gestion de scène pour les moteurs 3D juillet 2009

81 10. Conclusions générales, perspectives d avenir La gestion de scène a encore énormément à apporter au domaine du rendu 3D temps réel. Certes, les algorithmes utilisés aujourd hui sont dépassés. Certes, les possiblités restent trop restreintes et ne permettent pas aux créatifs de restituer tous les environnements qu ils imaginent. Mais des algorithmes plus performants existent déjà. Ils nécessitent une puissance de calcul telle que seuls les développements des processeurs multicœurs et de la programmation parallélisée vont pouvoir la satisfaire. Cette évolution est autant un défi qu une révolution. La technologie du parallélisme en elle-même n est pas une nouveauté, elle était déjà utilisée sur les super calculateurs pour accélérer des opérations très longues (cryptanalyse, calculs scientifiques, etc.). Mais son utilisation dans l informatique temps réel n en est encore qu à ses prémices. C est sur elle que repose l avenir des moteurs 3D. Il va s agir d en appréhender tout le fonctionnement, d en apprivoiser les difficultés et d en affuter les atouts. Penser en parallèle ouvre une nouvelle ére de la programmation. Ce sera pour la 3D un tremplin vers de nouveaux sommets, ainsi que pour l ensemble de l informatique temps réel. Gestion de scène pour les moteurs 3D juillet /83

82 11. Bibliographie Woo M., Neider J., Davis T, Shreiner D., OpenGL 2.0 Guide officiel, Campus Press Junker G., Pro Ogre 3D programming, 2006, Apress Blaess C., Programmation système en C sous Linux, 2003, Eyrolles Ficheux P., Kadionik P., Linux temps réel, Linux magazine nº 52 juillet-aout 2003, Diamond Éditions Petazzoni T.,Comprenez et maîtrisez le multithreading, Linux magazine nº 63 juilletaout 2004, Diamond Éditions Petazzoni T., Decotigny D, Conception d OS : balade au fil des threads, Linux magazine nº 69 fevrier 2005, Diamond Éditions Herlihy M, Shavit N., The art of multiprocessor programming, 2008, Elsevier Reinders J., Intel Threading Building Blocks, 2007, O Reilly Kumar S., Interactive scenegraph performance analysis, diagnosis and enhancement, 2005, Iowa State University Hofmann J.S., The Render Graph: A Data Structure to Aid in the Interactive Display of Scene Graph Data, 2003, University of Illinois at Urbana-Champaign Kautz J., Pattanaik S., An Interactive Perceptual Rendering Pipeline using Contrast and Spatial Masking, 2007, Eurographics Symposium on Rendering Zigo F., Real-time global illumination of dynamic scenes, 2008, Comenius University 80/83 Gestion de scène pour les moteurs 3D juillet 2009

83 12. Webographie Jeux vidéo : vers les consoles nouvelle génération, Association Française pour le Jeu Vidéo, GPU Gems 2, Nvidia, developer.nvidia.com/object/gpu_gems_2_home.html Parallel Programming and Multi-Core, Intel, software.intel.com/en-us/articles/multicore/technical-article CUDA 2.0 Programming Guide, Nvidia, developer.download.nvidia.com/compute/ cuda/2_0/docs/nvidia_cuda_programming_guide_2.0.pdf OpenCL Core API Specification, Khronos, Computer Graphics, Wikipedia, en.wikipedia.org/wiki/computer_graphics Octree, Wikipedia, en.wikipedia.org/wiki/octree Quadtree, Wikipeida, en.wikipedia.org/wiki/quadtree Binary Space Partitioning, Wikipedia, en.wikipedia.org/wiki/binary_space_partitioning Gestion de scène pour les moteurs 3D juillet /83

84 13. Terminologie 13.1 Abréviations ABT : Adapativ binary tree ou abre binaire adaptatif. C est un système de partitionnement de l espace utilisant les boîtes englobantes et un arbre binaire (voir page 31). API : Application Programming Interface ou interface de programmation. C est un ensemble de fonctions, procédures ou classes mises à disposition des programmes informatiques par une bibliothèque logicielle, un système d exploitation ou un service leur permettant d utiliser ces derniers. BSP : Binary Space Partitioning ou partitionnement de l espace binaire. C est un système de partitionnement de l espace basé sur un arbre binaire (voir page 24). CPU : Central Processing Unit ou Unité centrale de traitement. C est le composant principal d un ordinateur, celui qui interprète les instructions et traite les données. FPS : First Person Shooter, jeu de tir à la première personne ou jeu de tir en vue subjective. GPU : Graphics Processing Unit ou Unité de traitement graphique. C est un microprocesseur présent sur les cartes graphiques au sein d un ordinateur ou d une console de jeux vidéo. Il se charge des opérations d affichage et de manipulation des données graphiques. IA : Intelligence artificielle. LOD : Level Of Detail ou niveaux de détail. C est un algorithme qui permet d augmenter ou de réduire la qualité des éléments d une scène 3D en fonction de leur visibilité (voir page 36). PVS : Potentially Visible Set. C est un algorithme qui, utilisé conjointement avec un système de partitionnement de l espace, permet de connaître les régions visibles de l espace partitionné à partir d une région donnée (voir page 27). 82/83 Gestion de scène pour les moteurs 3D juillet 2009

85 13.2 Glossaire Anti-crénelage (anti-aliasing) : L anti-crénelage est une méthode permettant d éviter le crénelage, un phénomène qui survient lorsqu on visualise certaines images numériques dans certaines résolutions. Courbe de Bézier : Courbes polynomiales paramétriques inventées par l ingénieur Pierre Bézier. Elles sont utilisées en informatique pour décrire des images vectorielles. Discrétisation (Rasterisation) : Étape du rendu par laquelle des données vectorielles (des polygones en 2D) sont transformées en données discrètes (pixels). Interpolation : Produire des valeurs intermédiaires et les intercaler depuis une position initiale vers une position finale. Librairie ou bibliothèque logicielle : Un ensemble de fonctions, procédures ou classes pouvant être utilisées par des programmes. Mipmap : Une technique d application des textures qui permet d améliorer la qualité de l affichage. Cette technique fonctionne en précalculant plusieurs versions réduites d une texture et, au moment du rendu, en choisissant la version la mieux adaptée en fonction de la taille de l objet texturé sur l image finale. Quad : Polygone de forme carrée ou rectangulaire. Récursivité : Lorsqu une fonction d un programme s appelle elle-même, on parle d appel récursif ou de récursivité. Tampon (Buffer) : Une zone de mémoire permettant de stocker temporairement des données. Texture : Une image qui peut être appliquée sur un volume 3D. Il s agit la plupart du temps d images à deux dimensions, mais des textures à une ou à trois dimensions sont parfois utilisées. Thread : Fil d exécution. Gestion de scène pour les moteurs 3D juillet /83