THÈSE. Présentée devant. l Université de Rennes 1. pour obtenir. par. Romain Cavagna

Transcription

1 N o d ordre: 3699 THÈSE Présentée devant l Université de Rennes 1 pour obtenir le grade de : Docteur de l Université de Rennes 1 Mention Informatique par Romain Cavagna Équipes d accueil : FTR&D/TECH/IRIS/IAM et BUNRAKU École Doctorale : MATISSE Composante Universitaire: IFSIC Titre de la thèse : Gestion de Contenu et Optimisation de Qualité pour la Diffusion en Flux de Contenu 3D. soutenue le 20 décembre 2007 devant la commission d examen M. : Guy Lorette Président MM. : Pascal Guitton Rapporteurs Djamchid Ghazanfarpour MM. : Christian Bouville Examinateurs Kadi Bouatouch Jérôme Royan

2

3 Table des matières Résumé Introduction Motivations Objectifs Contributions et organisation du document partie I Étude des méthodes de visualisation de contenus 3D en local et en réseau Étude d un système de visualisation interactive en local Introduction Les représentations multi-niveaux de détails Les techniques basées image Les techniques basées points Les techniques basées simplification polygonale La sélection du niveau de détail Quelques techniques de sélection L adaptabilité aux ressources du système de visualisation Le filtrage de visibilité Conclusion Étude d un système de visualisation interactive en réseau Introduction La répartition des traitements de sélection des données et les différents modes d échange des données Exemples d échanges en mode "push" Exemples d échanges en mode "pull" L adaptabilité aux ressources du terminal et du réseau Adaptation aux ressources effectuée côté serveur Adaptation aux ressources effectuée côté client L optimisation des échanges de données Conclusion Les architectures pour environnements virtuels distribués Introduction La structuration de la base de donnée de l EV Le maintien de la cohérence de l EV Les techniques de partitionnement Le filtrage des échanges de messages

4 2 Table des matières 3.4 Quelques critères d évaluation des performances d un EV La scalabilité La capacité de coopération Conclusion Les réseaux de pairs à pairs Introduction Les principes généraux Quelques exemples de réseaux pairs à pairs Les réseaux pairs à pairs spatialement organisés VAST Solipsis Conclusion Conclusion partie II Distribution de contenus 3D dans un réseau de pairs à pairs spatialement organisé. 81 Introduction Le support des expérimentations Introduction Le simulateur La qualité de visualisation L interface de visualisation Les différents modes de fonctionnement Les expérimentations Le contenu 3D expérimental Le P BT ree (Progressive Building Tree) Conclusion La visualisation d un contenu 3D Introduction La structuration du contenu Présentation générale L arbre de description des niveaux de détails (LODDT ) Le contenu d un nœud de LODDT Le découpage du LODDT en sections L exploitation du contenu Le client de visualisation La sélection des NDDs L optimisation de la visualisation Quelques résultats

5 Table des matières 3 7. La distribution d un contenu 3D Introduction L architecture de distribution de contenus Les différents types de pairs L espace de connectivité La distribution des requêtes La sélection des pairs-serveurs Le protocole de communication L adaptation aux ressources du réseau L étude temporelle du transfert des niveaux du P BT ree L optimisation du découpage du LODDT L auto-répartition de la BP e du ps L auto-répartition de la BP e du ps à l initiative des pc L auto-répartition de la BP e du ps à l initiative du ps Les résultats de l équi-répartition de la BP e du ps effectuée par les pc Une taxonomie de l auto-répartition de la BP e du ps L auto-scalabilité du réseau de pairs à pairs L augmentation virtuelle de la BP e du P M Les résultats qui montrent l auto-scalabilité du réseau pairs à pairs L ajustement de la BP e du ps en fonction de la BP t souhaitée Les limitations actuelles et les perspectives La définition d une QgV dans le réseau pairs à pairs La dynamicité de la mise à jour des contenus de l EV Conclusion Conclusion Conclusion et perspectives Contributions Perspectives Glossaire

6 4 Table des matières

7 Résumé La révolution annoncée du monde Internet donne aujourd hui naissance à de très nombreux Environnements Virtuels (EV s) dans des domaines variés tels que les jeux, le divertissement, le commerce et la communication. Effectivement, avec l apparition proche d un Web 2.0., dont la représentation ne se limiterait plus à l interface 2D actuelle, l utilisation d une troisième dimension devrait permettre l apparition de nombreuses applications avec de nouvelles possibilités d interaction. Cependant, malgré les nombreux travaux effectués dans ce domaine, il apparait qu aucun des EV s actuels n est réellement scalable en nombre d utilisateurs et en complexité de l environnement, ce qui ne permet pas d envisager leur utilisation comme support de ce nouveau service. Dans cette thèse, nous proposerons une solution à ce problème en présentant les bases d un EV réellement scalable en nombre d utilisateurs et en complexité de l environnement. Ainsi, après avoir recencé les différents travaux liés à cette problématique, nous présenterons le simulateur temps réel que nous avons mis en œuvre. Celui-ci nous permet de valider les différents concepts que nous présentons dans cette thèse. Ensuite, nous décrirons notre client de visualisation qui dispose de propriétés d auto-adaptation aux ressources du terminal et l architecture de distribution de contenus pairs à pairs auto-scalable que nous proposons d utiliser et qui permet une auto-répartition de la ressource réseau disponible.

8 6 Résumé.

9 Introduction Motivations L intérêt croissant pour les Environnements Virtuels (EV s) donne aujourd hui naissance à de très nombreux projets dans des domaines variés tels que les jeux, le divertissement, le commerce et la communication. La figure 0.1 présente une cartographie de ces différents domaines. Fig. 0.1: Cartographie des domaines d application des EV s [1]. La plupart des EV s sont spécialisés dans un ou plusieurs domaines d application de la figure 0.1. Second Life [2] est l un des seuls EV s généraliste dans lequel de très nombreuses applications peuvent être mises en place. Cependant, malgré les nombreux travaux effectués dans ce domaine, il apparaît qu aucun des EV s actuel n est réellement scalable en nombre d utilisateurs et en complexité de l environnement, ce qui ne permet pas d envisager de les utiliser comme support de la mise en place d un web 3D. Actuellement, les débits nécessaires sont disponibles sur Internet et les contenus existent mais aucune architecture de distribution ne permet d exploiter cette ressource.

10 8 Introduction. Les différents EV s connus reposent sur une architecture plus ou moins centralisée dont l exemple le plus probant est Google Earth [3] avec plus de serveurs répartis dans le monde entier. L utilisation et le dimensionnement d une architecture de distribution de contenus centralisée implique des coûts très importants de mise en place et de maintenance des serveurs, ce qui pénalise grandement les fournisseurs de contenus ou les opérateurs qui disposent de moyens plus modestes et qui souhaitent fournir un service à grande échelle. Ainsi, dans cette thèse, notre contribution principale sera de proposer une approche globale de la mise en œuvre d un EV réellement scalable et peu coûteux en mise en place et en maintenance. Comme nous le montrerons dans la suite, la forte contrainte de scalabilité et de qualité globale que nous nous imposons implique de considérer le processus de visualisation et de distribution de contenus dans son ensemble. Objectifs L objectif principal de cette thèse est de poser les bases d un EV réellement scalable que ce soit en complexité de l environnement ou en nombre d utilisateurs connectés. Ainsi, celui-ci devra à l avenir permettre l exploitation et la distribution des contenus disponibles actuellement sur Internet (pages Internet, modèles 3D, flux audio et vidéo, etc.) avec un coût de mise en œuvre et de maintenance le plus faible possible. Pour décrire l approche globale que nous proposons, nous montrerons, à travers l exemple d un contenus 3D échelonnable que nous avons utilisé pour nos expérimentations, qu il est possible de le distribuer et de le visualiser efficacement en respectant les contraintes que nous nous sommes fixés. De façon additionnelle, nous montrerons que la stratégie que nous présentons pour ce contenu 3D est adaptable directement pour tous les contenus échelonnables. Contributions et organisation du document Dans cette thèse, nous nous intéresserons en particulier à la diffusion en flux de contenu 3D. Ainsi, dans la première partie, nous présenterons dans l ordre les travaux suivants. Nous décrirons les travaux antérieurs dans le domaine des systèmes de visualisation interactive de contenus 3D en local. Après avoir montré quelques limitations de ces systèmes de visualisation en local, nous décrirons les systèmes de visualisation interactive de contenus 3D en réseau. Ensuite, les différentes architectures pour EV s de la littérature seront présentées. Enfin, nous présenterons les réseaux de pairs à pairs qui constituent l un des éléments essentiels de notre stratégie. La deuxième partie de cette thèse sera consacrée à la description des outils que nous avons mis en œuvre pour évaluer les performances de l architecture de visualisation et de distribution de contenus que nous proposons d utiliser. Dans l ordre, les éléments que nous décrirons sont les suivants. Nous présenterons le simulateur que nous avons mis en place pour évaluer les performances du client de visualisation et de l architecture de distribution de contenus que nous proposons. Nous décrirons en particulier un contenu 3D échelonnable qui nous servira de support pour nos expérimentations. Nous présenterons ensuite l architecture du client de visualisation que nous avons implémenté qui dispose, comme nous le montrerons, de propriétés d auto-adaptation aux ressources matérielles et réseau du terminal de visualisation. Nous décrirons de façon détaillée l architecture de distribution de contenus que nous proposons d utiliser. Nous montrerons

11 Introduction. 9 ensuite, pour l exemple de contenu 3D que nous avons choisi, la méthode de distribution des données que nous avons mise en place. Ces différents points donneront lieu à la présentation de résultats qui mettent en valeur les différentes propriétés de notre architecture de visusalisation et de distribution de contenus. Nous montrerons les limitations actuelles de l architecture que nous proposons et les perspectives d optimisation qui peuvent être rapidement envisagées. Enfin, après avoir fait une synthèse de différents éléments de thèse, nous la concluerons en présentant quelques perspectives applicatives intéressantes.

12 10 Introduction.

13 Première partie Étude des méthodes de visualisation de contenus 3D en local et en réseau.

14

15 Introduction L objet de cette partie est de présenter de manière progressive les différents travaux effectués ayant rapport avec l objectif que nous nous sommes fixé, c est à dire proposer les bases architecturales d un Environnement Virtuel (EV ) de taille et de complexité non finies permettant à un nombre illimité d utilisateurs d y naviguer. Un EV est un environnement dans lequel de nombreux utilisateurs peuvent naviguer et interagir les uns avec les autres. Il est constitué de nombreux objets multimédias tels que des vidéos, du son, des images, des pages Web, et des modèles 3D auxquels nous nous intéresserons plus particulièrement dans cette thèse. L ensemble des objets multimédias présents dans l EV constituent la scène virtuelle. Dans le premier chapitre nous commencerons par présenter les techniques existantes permettant la visualisation interactive de scènes complexes en local. Nous montrerons que ces techniques ne permettent pas de garantir une visualisation interactive pour tous les types de matériel de visualisation (PC fixes, PC portables, PDAs, portables, etc.) et que le stockage de la base de données de visualisation pose certaines difficultés. Pour pallier ces contraintes, nous montrerons dans le deuxième chapitre qu il est nécessaire de distribuer les données de visualisation et certains des traitements en utilisant un réseau. Le deuxième chapitre sera donc consacré aux systèmes de visualisation interactive en réseau. Dans le troisième chapitre nous présenterons les différentes architectures pour environnements virtuels qui existent. En effet, ces travaux concernent la gestion des mises à jour de l environnement virtuel et la gestion du partage des objets plutôt que l échange de données de visualisation qui constitue la base de notre travail. Malgré l éloignement relatif de l objectif que nous nous sommes fixé dans cette thèse et de ceux qui ont conduit à la mise en place de ces différentes architectures, ce chapitre permettra de présenter quelques uns des points essentiels à tout EV ainsi que les limitations induites par l utilisation d architectures plus ou moins centralisées. En effet, ces architectures posent le problème de la capacité de stockage et de transmission des serveurs de données. Le quatrième et dernier chapitre de cette partie présentera ce que nous considérons comme une solution au problème du passage à l échelle, c est à dire l utilisation des réseaux pairs à pairs. Un réseau pairs à pairs est une architecture qui permet à chaque terminal de prendre une part active aux traitements requis. Les réseaux pairs à pairs sont utilisés pour la communication et la collaboration, les calculs distribués, le support de distribution Internet et la distribution de contenus. Dans ce chapitre nous présenterons ces différents types de réseaux pairs à pairs, et nous mettrons en valeur deux architectures intéressantes qui nous semblent alors les plus adaptées pour résoudre notre problématique de distribution de contenus 3D. En conclusion, nous présenterons une synthèse des travaux évoqués dans cette partie de façon à mettre en valeur les éléments essentiels sur lesquels s appuient notre réflexion.

16 14 Introduction.

17 1. Étude d un système de visualisation interactive en local 1.1 Introduction Dans ce premier chapitre, on présente rapidement les différents travaux qui permettent la visualisation interactive de scènes complexes en local. Les scènes auxquelles nous nous intéressons sont des scènes constituées uniquement de modèles 3D. La plupart du temps, ces scènes représentent une très grande quantité de données, ce qui ne permet pas de les charger complètement dans la mémoire vive du matériel de visualisation. Nous ne nous intéressons donc, dans cette partie, qu aux techniques de rendu en sur-capacité mémoire (Out-Of-Core Rendering). Parmi celles-ci, les représentations multi-niveaux de détails permettent de visualiser des scènes complexes sans charger complètement les modèles 3D dans la mémoire vive du matériel de visualisation. De plus, et c est très intéressant pour garantir une certaine interactivité, elles permettent d adapter la complexité des modèles visualisés. En effet, un problème récurrent en informatique graphique est que la complexité d un modèle visualisé est parfois si grande qu il est impossible de le visualiser de façon interactive, c est à dire avec une vitesse de rafraîchissement supérieure à 15 images par secondes. Fig. 1.1: Modèle de la statue de David de Michel-Ange composé de 2 milliards de polygones et représentant environ 32 GB de données [4]. Par exemple, la figure 1.1 représente la statue de David de Michel-Ange composée de 2 milliards de polygones et représentant 32 GB de données. Cette statue a été scannée dans le cadre du projet Michel-Ange [4]. La figure 1.2 représente un modèle de Boeing 777 composé de 350 millions de polygones et représentant entre 30 et 60 GB de données [5]. Ces deux modèles ne peuvent être affichés de façon interactive car les capacités d affichage des cartes graphiques actuelles sont de l ordre du million de polygones. Si ces modèles sont affichés sans traitements préalables, la fréquence de rafraîchissement sera très faible (à peine quelques

18 16 Étude d un système de visualisation interactive en local Fig. 1.2: Modèle de Boeing 777 composé de 350 millions de polygones et représentant entre 30 et 60 GB de données [5]. images par secondes). De plus, si ces modèles sont texturés, la mémoire texture de la carte graphique peut rapidement être saturée, ce qui peut entrainer un ralentissement supplémentaire à cause de leurs chargements/déchargements. Pour résoudre ces problèmes, différentes techniques ont été proposées. Nous les décrirons dans la première section. Ces techniques permettent de simplifier et de structurer différemment un modèle original de façon à prendre en compte le Point de Vue (P dv ) de l observateur. Une fois que les modèles originaux ont été simplifiés et structurés au mieux en fonction de leur type (au sens sémantique : villes, terrains, statues, etc.), il est nécessaire d utiliser une fonction de sélection adaptée. Les fonctions de sélection permettent de sélectionner les représentations et les Niveaux De Détails (NDDs) les plus adéquats. Nous considérons un NDD comme étant un modèle simplifié d un objet donné. La deuxième section présentera quelques unes des fonctions de sélection. Celles-ci permettent, en utilisant des méthodes de rendu adaptatif, de maintenir la fréquence de rafraîchissement de l image au dessus d un seuil critique, ce qui est indispensable si l on souhaite garantir une certaine interactivité. Enfin, avant de conclure, nous présenterons dans la dernière section de ce chapitre quelques travaux sur le filtrage de visibilité. Il est important de noter que les traitements que l on a cité précédemment peuvent être fait soit avant, soit pendant la visualisation de manière à déterminer précisément les objets visibles ou potentiellement visibles selon un P dv donné. Le filtrage de visibilité peut être effectué soit indépendamment, soit en complément des autres traitements pour diminuer la complexité du modèle à afficher. 1.2 Les représentations multi-niveaux de détails Pour permettre la visualisation de modèles 3D complexes, plusieurs types de représentations multi-niveaux de détail peuvent être utilisées. On note qu aucune de ces techniques n est réellement universelle et ne peut donc être adaptée à l ensemble des modèles 3D qui peuvent être visualisés. Suivant le type de modèles qui peuvent constituer une scène virtuelle (ville, terrain, statue, etc.), il est nécessaire d utiliser une technique adaptée. Parmi les différentes techniques que nous allons présenter dans cette section, on distingue les trois catégories suivantes :

19 Les représentations multi-niveaux de détails 17 Les techniques basées images qui consistent à remplacer tout ou une ou plusieurs parties du modèle visualisé par une image. Ces techniques sont intéressantes pour limiter le nombre de polygones affichés. Les techniques basées points qui consistent à visualiser des modèles avec des points plutôt qu avec des polygones, ce qui est intéressant pour visualiser des modèles très complexes et difficilement simplifiables. Les techniques basées simplifications polygonales qui consistent à simplifier un modèle polygonal selon des critères spécifiques. Ces techniques permettent, avec une structuration adaptée des données de ces modèles, de les simplifier ou de les raffiner (ie. rajouter ou supprimer des polygones) selon le P dv de l observateur. On note qu aucune des techniques que nous allons présenter ne peut être utilisée de façon idéale pour tous les types de modèles 3D. Selon les contraintes de visualisations fixées par le matériel graphique et par l application, il parait donc inévitable d envisager une utilisation simultanée de ces différentes techniques en tenant compte du type de modèle 3D que l on souhaite visualiser Les techniques basées image Une première solution, pour limiter la complexité géométrique d une scène, consiste à substituer tout ou une ou plusieurs parties de la géométrie du(des) modèle(s) par une ou plusieurs images. Les techniques basées images permettent donc de réduire considérablement le nombre de polygones qui vont être affichés. On peut lister deux méthodes couramment utilisées : les "billboards" qui sont des polygones texturés dont la projection est toujours parallèle au plan de la projection de la vue. Cette technique est souvent utilisée pour des objets qui sont symétriques autour d un axe ou d un point (arbres, flammes, explosions, fumées, etc.). les imposteurs qui permettent de substituer la géométrie lointaine en utilisant une image issue d un rendu limité à la géométrie à substituer. Les "billboards" sont en général utilisés pour remplacer des objets géométriques situés loin de l observateur et correspondent à un faible niveau de détails. En 2003, Décoret et al. [6] ont introduit les nuages de billboards dans le but d effectuer une simplification drastique des modèles 3D tout en conservant un excellent rendu visuel. Un exemple classique consiste à représenter une forêt ou des bâtiments simples par des nuages de billboards, ce qui permet de diminuer considérablement le nombre de polygones qui sont rendus tout en conservant une très bonne qualité de visualisation. Les modèles 3D sont simplifiés en utilisant un ensemble de plans auxquels sont associés des textures transparentes. Les différentes techniques utilisant les imposteurs sont présentées de manière chronologique dans la liste suivante avec, tout d abord, les imposteurs images simple : Les imposteurs simples ont été introduits par Maciel et Shirley [7] en Pour réduire la complexité géométrique de la scène, un rendu de la région à substituer est effectué avant la visualisation et ce pour différents P dv s. Suivant le P dv de l utilisateur, l imposteur adéquat est sélectionné et affiché. Pour éviter les effets de sauts engendrés par cette technique ainsi que pour diminuer le nombre d imposteurs qui doivent être stockés en mémoire graphique, Schaufler et al. [8] ont proposé une technique permettant de calculer les imposteurs en temps réel. Ceux-ci restent valides tant que la différence entre la direction du P dv courant et celle utilisée pour le calcul de l imposteur ne dépasse pas un certain seuil. Étant

20 18 Étude d un système de visualisation interactive en local donné que le calcul de ces imposteurs est très coûteux, il est nécessaire de déterminer le seuil de façon à ce que les imposteurs ne soient pas recalculés trop souvent, de manière à ce que la fréquence de rendu n en soit pas affectée. Les caches hiérarchiques d images ont été développés indépendamment par Schaufler [9] et Shade et al.[10] en Pour limiter les calculs d imposteurs, ceux-ci sont organisés en une arborescence d images qui correspondent chacune à des zones spécifiques de la scène. Les imposteurs parents sont générés par composition des imposteurs fils. Le problème pour les deux techniques que nous venons de présenter est que les imposteurs images simples et les caches hiérarchiques d images ne tiennent pas compte de la "profondeur", il en résulte des problèmes de parallaxe et d écrasement dues au remplacement d une représentation 3D par une représentation 2D. La figure 1.3 présente ces artéfacts. Fig. 1.3: A gauche : Visualisation d un problème de parallaxe si un imposteur est vu selon un angle différent [11]. On constate que les deux imposteurs (point de vue A et B) sont très différents et que le passage de l un a l autre est nettement visible. A droite : visualisation du problème d écrasement [12] si la "profondeur" n est pas prise en compte. La "profondeur" peut être prise en compte en utilisant des imposteurs multi-couches par exemple. Plusieurs solutions ont étés proposées pour résoudre les problèmes d écrasement et de parallaxe. On les présente dans la liste suivante : Les imposteurs multi-couches ont été proposés par Schaufler [13] et Shade [14] en Dans le cas des imposteurs multi-couches, plusieurs polygones parallèles sont utilisés pour représenter un seul imposteur. Au lieu d utiliser un seul polygone par imposteur, les imposteurs multi-couches sont constitués d un ensemble de polygones parallèles mais à des profondeurs différentes par rapport au P dv. Ainsi, sur chaque polygone sont projetées les parties du groupe d objets qui sont à une distance similaire par rapport au P dv. Autrement dit, les pixels d un imposteur classique sont distribués sur de multiples couches suivant une valeur de profondeur. La figure 1.3 représente un cas d utilisation des imposteurs multicouches avec un nombre variable de couches. Une extension de cette idée est la notion de textures à profondeurs multiples : les LDIs (Layered Depth Image) [14] qui associent plusieurs profondeurs à un même pixel (cf figure 1.4). Les imposteurs maillés furent présentés en 1999 par Décoret et al. [15]. En utilisant une géométrie tridimensionnelle comme support de la projection des imposteurs, ils ont améliorés la technique des imposteurs multi-couches. La géométrie sur laquelle sont projetés

21 Les représentations multi-niveaux de détails 19 les imposteurs correspond en fait au maillage de la carte de profondeur de manière à ne conserver que les surfaces visibles depuis un domaine de vue. Les imposteurs basés points ont été introduits par Wimmer en 2001 [16]. Les imposteurs basés points combinent les imposteurs et la représentation basée point qui est présentée plus en détail dans la sous-section suivante. Pour cette méthode, les supports des imposteurs ne sont plus des polygones ou un maillage, mais un nuage de points. Cette méthode permet principalement de contrôler la résolution des points d un imposteur suivant le P dv de l observateur. Fig. 1.4: Cette figure représente les différentes techniques basées imposteurs [14] qui ont été présentées dans cette sous-section. Ces différentes techniques permettent de représenter des modèles avec plus ou moins de fidélité, ce qui permet d en déduire que certaines sont plus ou moins adaptées en fonction de la distance entre le modèle et l observateur. Les LDIs permettent de compenser les problèmes de parallaxe et d occulation. Chacune des techniques que nous avons présentées dans cette sous-section sont plus ou moins bien adaptées en fonction du P dv de l observateur et de sa distance par rapport au modèle (cf figure 1.4). En effet, les deux premières techniques que nous avons présentées sont relativement bien adaptées quand le modèle est situé loin de l observateur. Les autres techniques que nous avons décrites sont plus performantes et permettent donc de représenter plus fidèlement des modèles situés près de l observateur.

22 20 Étude d un système de visualisation interactive en local Les techniques basées points Marc Levoy et al. [17] furent les premiers à proposer l utilisation du point comme nouvelle primitive d affichage. L idée est que, pour des objets complexes constitués de millions de polygones très petits, la notion de connectivité et de cohérence n a plus d intérêt pour le rendu. Elle devient même une charge de traitement inutile, le rendu au niveau point suffit. Après conversion du modèle polygonal en modèle basé point par échantillonnage 3D, les points sont projetés dans le plan image, ce qui permet un gain significatif au niveau du processus de rastérisation. En effet contrairement à un polygone, un point se projette sur un pixel unique. Afin d éviter l apparition de "trous", un filtre gaussien radialement symétrique est appliqué pour chaque pixel afin de déterminer la contribution de chacun des points du modèle à un pixel donné. La figure 1.5 présente à droite une représentation très détaillée d un œil de la statue de David en utilisant la technique Q-Splat introduite par Rusinkiewicz et al. [18] en Fig. 1.5: A gauche : Parcours de l arbre Q-Splat et présentation des éléments qui composent chacun de ses nœuds. A droite : Représentation très détaillée d un œil de la statue de David en utilisant la technique Q-Splat [18]. La technique Q-Splat consiste à représenter un modèle basé points sous la forme d une arborescence où chaque noeud est constitué du centre d une sphère, de son rayon, d une normale, de la largeur d un cône de normales [19] et éventuellement d une couleur. La technique utilisant la largeur d un cône de normales a été proposée par Shirman en 1993 [19] pour déterminer plus vite l orientation d un patch par rapport à l observateur, chaque patch étant constitué d un ensemble de points et de normales associées. La représentation Q-Splat peut être produite à partir de polygones, de voxels, ou d un nuage de points. Lors de la visualisation, un parcours de cette arborescence est effectué de la racine vers les nœuds. Dès qu un nœud n est plus visible, il n est pas affiché, et le parcours de cette branche s arrête. Si la représentation d un nœud est suffisamment détaillée par rapport au critère de qualité choisi, ce nœud est affiché et le parcours de cette branche s arrête, sinon le parcours de cette branche continue. La figure 1.5 présente le contenu de chacun des nœuds de l arbre Q-Splat ainsi que la façon dont il est parcouru. Rusinkiewicz utilise la plupart des techniques de filtrage de visibilité, à savoir la technique de suppression des faces arrières (BackFace Culling) et la technique de suppression des faces hors de la pyramide de vue (Frustrum Culling). En revanche, il a choisi de ne pas utiliser la technique de filtrage de visibilité (Occlusion Culling) celle-ci étant trop coûteuse en regard des gains obtenus. Nous présenterons plus en détail les différentes techniques de filtrage de visibilité dans la section 1.4.

23 Les représentations multi-niveaux de détails Les techniques basées simplification polygonale Les techniques basées simplification polygonale sont de loin les techniques les plus utilisées. De nombreux travaux ont été effectués dans ce domaine. La plupart des représentations peuvent être converties avec plus ou moins de précision en modèles polygonaux, ce qui permet d exploiter au maximum les fonctions câblées des cartes graphiques actuelles. On présente donc ces différentes techniques de manière plus détaillée, et en particulier celles que l on a utilisé pour nos expérimentations. Malgré la puissance de traitement des cartes graphiques actuelles, certains modèles polygonaux sont trop complexes pour être rendus en temps réel avec celles-ci. Plusieurs approches sont envisageables pour pallier ces limitations. Parmi celles-ci, nous distinguons notamment les trois suivants : L enrichissement des données brutes des polygones de manière à apporter plus de détails visuels en utilisant des techniques d illumination ou de placage de textures. Ces techniques pourront être utilisées sur des maillages simplifiés de manière à obtenir un rendu visuel équivalent (si le P dv n est pas trop rapproché). La prise en compte de la géométrie du modèle de manière à éliminer les parties cachées selon le point de vue de l observateur. Pour limiter le nombre de polygones à afficher, il est intéressant de s appliquer à ne rendre que ceux qui sont effectivement visibles. L adaptation de la complexité géométrique des objets rendus en fonction du P dv de l observateur. Effectivement, on note que l on a tout intérêt à diminuer la complexité des objets situés loin de l observateur de façon à éliminer les détails non perceptibles. Plus précisément, on va chercher à adapter la complexité globale de la scène de manière à obtenir une qualité de visualisation optimale. Dans les deux sous-sections suivantes, nous présenterons respectivement les principes de la simplification polygonale ainsi que différentes méthodes qui ont été proposées Principes généraux Il existe actuellement un très grand nombre de techniques de simplification polygonale. Ces techniques peuvent être classées selon différentes caractéristiques liées aux critères que l on s impose. Une première classification peut être effectuée en distinguant les méthodes qui prennent ou non en compte le P dv de l observateur. Parmi les méthodologies prenant en compte le P dv de l observateur, on distingue celles qui sont : indépendantes de la vue. Dans ce cas les NDDs sont statiques. Le processus de simplification calcule plusieurs NDDs pour chaque objet de la scène. Le calcul des NDDs se fait indépendamment de la direction d observation. Lors du rendu temps réel, un N DD approprié est sélectionné pour chacun des objets. Généralement, la sélection est effectuée en prenant en compte la distance entre l objet considéré et le P dv de l observateur. Lorsque l observateur se rapproche de l objet, et qu un NDD plus détaillé doit être affiché, le NDD courant est entièrement remplacé par un N DD ayant un niveau de détails supérieur. Les N DDs sont statiques. dépendantes de la vue. A l inverse du cas précédent, les NDDs sont dynamiques. les différents N DDs sont remplacés par une seule représentation dynamique du modèle [20,

24 22 Étude d un système de visualisation interactive en local 21]. Le modèle visualisé est regénéré en temps réel à chaque P dv de l observateur, et à chaque point de vue de l observateur correspond une seule et unique représentation du modèle. Cette méthode permet de prendre en compte la direction d observation. La figure 1.6 présente deux exemples de représentations dépendantes de la vue. Fig. 1.6: A gauche : le terrain visualisé est de plus en plus simplifié à mesure que la distance par rapport à l observateur augmente. La pyramide de vue est matérialisée en rouge et la pyramide d anticipation en bleu [22]. A droite : la sphère est simplifiée drastiquement du côté ou les faces sont cachées. Le détail est conservé du côté ou les faces sont visibles. La pyramide de vue est matérialisée en jaune [23]. Les techniques prenant en compte le P dv permettent d adapter la complexité de la scène et donc en particulier le nombre de polygones qui sont affichés. Dans le cas des méthodes "dépendantes de la vue", il n y a pas de redondances de représentations car chaque objet est caractérisé par une seule représentation structurée d une façon particulière (ie. en général une arborescence). La représentation d un objet est structurée de façon à ce que chaque NDD puisse être généré de façon incrémentale à partir d un N DD plus grossier. Les méthodes de simplification "dépendantes de la vue" sont donc moins coûteuses en quantité de données. Les méthodes de simplification peuvent aussi être caractérisées par la manière dont la fidélité au modèle initial est évaluée selon une métrique d erreur. Effectivement, si les bases de données sont très grandes, il n est pas envisageable que l utilisateur sélectionne manuellement les N DDs qui doivent être appliqués aux différents modèles en fonction des P dv S possibles. Il est donc nécessaire d utiliser une métrique qui permette de les sélectionner implicitement. On distingue alors deux types de stratégies pour définir la métrique de simplification : La simplification basée fidélité qui est une technique basée sur un critère de fidélité par rapport au modèle initial. L algorithme, tout en respectant ce degré de fidélité, simplifie le modèle initial en réduisant le nombre de polygones. La simplification basée sur le nombre de polygones qui est une technique prenant en compte le nombre de polygones dont le modèle simplifié doit être composé. L algorithme se charge alors d effectuer la simplification en maximisant la fidélité du modèle tout en respectant le nombre de polygones demandés. On note que l utilisation de ces différentes techniques de simplification est dépendante du type d applications que l on souhaite mettre en place. En effet, certaines applications comme la CAO nécessitent une grande fidélité, alors que d autres, comme les jeux, privilégient l interactivité. Étant donné que la fréquence de rafraîchissement est directement dépendante du nombre de

25 Les représentations multi-niveaux de détails 23 polygones affichés, on préférera utiliser une technique de simplification "basée sur le nombre de polygones" pour mettre en place des applications nécessitant une forte interactivité. On note qu il existe plusieurs types de modèles polygonaux qui ont des caractéristiques topologiques différentes. les variétés (ou manifold) qui peuvent être avec ou sans bord. Une variété topologique de dimension n, ou n-variété, est un espace topologique séparé, localement homéomorphe à un espace vectoriel réel de dimension n. Le bord d une variété à bord est une variété de dimension n 1. Ainsi, un maillage est une 2-variété si toutes ses arêtes sont communes à exactement deux faces, et à 2-variété de bord si pour quelques arêtes on ne trouve qu une seule face. Le bord d une 2-variété à bord est une 1-variété. Par exemple une sphère pleine, ou boule, est une 3-variété de bord et la sphère est une 2-variété. La figure 1.7 montre un exemple de 2-variété de bord. Chacun des sommets internes est partagé par une surface fermée de triangles connexes. les non-variétés (ou non-manifold) qui correspondent à tous les maillages qui ne sont pas des variétés. On présente quelques exemples de maillages qui ne sont pas des variétés dans la figure 1.7. Fig. 1.7: A gauche : Une représentation 2D manifold avec bord (en vert). Un ou deux triangles partagent chacune des arêtes et chacun des sommets internes est partagé par une surface fermée de triangles connexes. A droite : plusieurs exemples de maillages non-manifold : (a) une arête est partagée par trois triangles, (b) un sommet interne est partagé par des surfaces de triangles non connexes, (c) un "T-Vertex" [23] Les techniques de simplifications polygonales se réfèrent souvent à des structures de type "variétés". Les algorithmes de simplifications peuvent donc être séparés en deux catégories selon leurs façons de respecter la topologie : Les algorithmes préservant la connectivité du modèle. Ils préservent la structure topologique du modèle, évitant ainsi la disparition de trous lors de la simplification. Cependant, cette contrainte peut, dans le cas d objets complexes, limiter la simplification et ainsi engendrer un modèle simplifié composé d un nombre de polygones assez important. Les algorithmes modifiant la connectivité du modèle. Ces algorithmes ont l inconvénient de supprimer les trous dans le cas d une simplification drastique du modèle. On note que ces simplifications peuvent générer des modèles simplifiés très peu fidèles aux modèles initiaux. On en déduit qu il est nécessaire d utiliser la technique permettant une simplification optimale compte tenu du type d application que l on souhaite mettre en place. Presque toutes les méthodes de simplification de la littérature se basent sur quatre mécanismes de réduction de polygones : l échantillonnage, la subdivision adaptative, la décimation et la fusion de sommets.

26 24 Étude d un système de visualisation interactive en local L échantillonnage consiste à échantillonner la géométrie du modèle initial à l aide d un ensemble de points sur la surface 2D du modèle, ou à l aide de voxels sur une grille 3D superposée au modèle [24, 25]. Ensuite, l algorithme effectue une triangulation de cet ensemble de sommets afin d obtenir une surface 3D. La densité d échantillonnage, qui peut être régulière ou non, influera directement sur la fidélité du modèle simplifié par rapport au modèle initial. La subdivision récursive crée une approximation très simple du modèle initial, appelée "maillage de base". Ce modèle de base est constitué de triangles ou de quadriques qui sont des formes géométriques pouvant être facilement subdivisées récursivement. Le processus de subdivision est appliqué jusqu à ce que le modèle subdivisé approche le modèle initial selon un critère global ou local si on vise une approximation dépendante de la vue. Cette technique n est pas réellement adaptée si le maillage initial est constitué d angles aigus ou de plis [26]. La décimation introduite par Clark [27] est une technique itérative qui supprime en plusieurs passes des sommets du maillage. A chaque passe, des sommets sont supprimés et une triangulation du trou résultant de la suppression est effectuée (cf figure 1.8). Le processus est effectué jusqu a ce qu aucun sommet ne puisse être supprimé. On note qu avec les algorithmes de décimation la topologie de la scène est conservée. La fusion de sommets consiste à fusionner deux ou plusieurs sommets d un modèle triangulé en un sommet unique, qui peut ensuite être fusionné avec d autres sommets. Les triangles dont les sommets ont été fusionnés sont alors dégénérés. Ils peuvent donc être supprimés, réduisant ainsi le nombre de polygones constituant le modèle. On note que certains algorithmes fusionnent uniquement des sommets partageant une même arête, plus couramment appelé la contraction d arête [20] (cf figure 1.8). Suppression de point Contraction d arête V Vj V Vi Ajout de point Dédoublement de point Fig. 1.8: A gauche : description de l opérateur de simplification "suppression de point" et de l opérateur associé "ajout de point". A droite : description de l opérateur de simplification "contraction d arête" et de l opérateur associé "dédoublement de point". [22] Dans la suite, on présente quelques unes des méthodes de simplification polygonale que l on retrouve dans la littérature. Nous les présenterons de façon à mettre principalement en valeur celles qui sont dépendantes de la vue et celles qui ne le sont pas. Effectivement, nous considérons que les méthodes de simplifications polygonales dépendantes de la vue sont plus adaptées aux contraintes d interactivité que nous nous sommes fixés. Les méthodes dépendantes de la vue permettent, comme on l a dit, d adapter la complexité de la scène et, en particulier, le nombre de polygones. Ce qui est intéressant si l on souhaite garantir une fréquence de rafraîchissement de l image (cf section 1.3.2).

27 Les représentations multi-niveaux de détails Quelques méthodes Étant donné le nombre très important de travaux réalisés sur la simplification polygonale, nous ne présenterons que les méthodes les plus caractéristiques. Certaines de ces méthodes s appliquent à des "variétés" et d autres à des "non-variétés". Parmi celles que nous avons choisi de présenter, on présente tout d abord les méthodes non réversibles qui permettent de diminuer la complexité d un maillage. Ces méthodes ont la particularité de pouvoir être appliquées en temps réel : La décimation de maillages triangulaires proposée par Schroeder et al. [28] est une des premières solutions permettant la simplification d un modèle polygonal. L algorithme de décimation qu ils proposent effectue plusieurs passes sur chaque sommet du maillage. A chaque passe, il teste pour chaque sommet s il peut être supprimé et il ne supprime que ceux qui ne modifient pas la topologie du maillage. Si un sommet est supprimé, le trou généré est retriangulé et l algorithme est de nouveau appliqué et ce jusqu à ce qu aucun sommet ne puisse être supprimé. La simplification de surface utilisant une erreur quadratique a été proposée par Garland et Heckbert [29] en Cet algorithme est un algorithme de simplification basé sur la fusion de sommets. Celui-ci est dépendant du P dv, très rapide et robuste, et assure une bonne fidélité par rapport au modèle initial. Cette méthode permet de fusionner des sommets qui sont connectés par une arête ou qui sont éloignés d au plus une distance seuil t. La contribution majeure de cette publication porte sur une nouvelle façon d évaluer l erreur géométrique entre le maillage simplifié et le maillage initial appelée L erreur quadrique (ou en anglais "The Quadric error metric"). Cette fonction d erreur est calculée pour chaque sommet à l aide d une matrice représentant la somme des distances au carré entre le sommet et les plans définis par les triangles voisins. La fusion de sommets. proposée par J. Rossignac et P. Borrel [30] en 1992 est un algorithme robuste permettant de simplifier des maillages qui ne sont pas des variétés. L algorithme débute en affectant à chaque sommet une importance perceptuelle basée sur deux facteurs qui sont la taille des faces adjacentes et la courbure du modèle. Une grille régulière 3D permet de discrétiser l ensemble du modèle, et tous les sommets de chaque cellule de la grille sont fusionnés en fonction des paramètres évoqués précédemment. La résolution de la grille détermine la qualité du modèle simplifié, ainsi les triangles dont tous les sommets ont été fusionnés sont dégénérés et disparaissent. Dans la continuité de ses travaux portant sur la reconstruction automatique, Hoppe [31] proposa une méthode de simplification basée sur l optimisation de maillage. A partir d un maillage initial, une fonction d énergie est minimisée de manière à générer un maillage optimisé. Trois transformations peuvent être effectuées de manière itérative avec cet algorithme : la contraction d arêtes, le dédoublement d arêtes, et l inversion d arêtes. La figure 1.9 présente ces différentes transformations.

28 26 Étude d un système de visualisation interactive en local Fig. 1.9: A gauche : Opérateurs de simplification utilisés par Hoppe et al. pour l optimisation de maillage. A droite : Exemples de maillages optimisés avec la technique de Hoppe [31]. Les méthodes que nous venons de présenter sont très efficaces pour diminuer la complexité d un maillage, mais la plupart du temps, elles ne prennent pas en compte le P dv de d observateur. Les méthodes que nous présentons ensuite le prennent en compte systématiquement. Ces méthodes ont la particularité d être réversibles (ie. il est possible de passer d un NDD à un autre sans recharger complètement une nouvelle représentation) et hiérarchiques. Effectivement, une méthode dépendante de la vue s appuie sur une structuration hiérarchique de laquelle est extrait un modèle adapté au P dv de l observateur. Il est possible de passer d un NDD à un autre car ils sont tous conservés dans une arborescence hiérarchique précalculée. Les méthodes de génération de la structure hiérarchique sont basées sur le calcul d une erreur. La simplification dépendante du point de vue proposée par Luebke et Erikson [21] est parmi les premiers algorithmes de simplification produisant une représentation dépendante du P dv. Les NDDs sont représentés sous la forme d un arbre unique appelé Vertex Tree. Chaque nœud de l arbre correspond à un sommet issu de la fusion des sommets fils. Pendant la visualisation, les nœuds devant être regroupés ou développés sont déterminés en fonction de l aire projetée des triangles partageant le sommet correspondant au nœud. A la suite de ses travaux sur l optimisation de maillage, Hoppe [20] proposa une nouvelle représentation arborescente se basant sur la contraction d arêtes : Les maillages progressifs. Un maillage progressif est constitué d un maillage de base simplifié, obtenu en appliquant une série de contractions d arêtes sur le maillage initial, et d un ensemble de dédoublements de sommets qui permettent de raffiner le maillage initial (cf figure 1.8). En 1997 Hoppe [32] adapta cette méthode aux simplifications dépendantes du P dv, selon un principe relativement similaire à l algorithme de Luebke et Erikson [21]. La figure 1.10 présente quelques exemples de maillages progressifs [20] à différents niveaux de raffinement.

29 Les représentations multi-niveaux de détails 27 Fig. 1.10: Exemples de maillages progressifs [20] à différents niveaux de raffinement. Le terrain est raffiné en utilisant le Frustum Culling avec la pyramide de vue représentée en jaune. La méthode des complexes simpliciaux progressifs, proposée par Popovic et Hoppe [33] en 1997, permet la simplification d un maillage quelconque (n importe quelle dimension, qui ne respecte pas forcement l équation d Euler, non-orientable, non-régulier). Cette solution, comme celle du maillage progressif, propose une représentation d un maillage sous la forme d un modèle de base (un point unique) auquel est associé une séquence de raffinements permettant de reconstruire le modèle initial. Les complexes simpliciaux progressifs conservent tous les avantages des maillages progressifs mais avec une meilleure fidélité. Les ondelettes géométriques sont des modèles à ondelettes issus d une généralisation de l analyse multi-résolution figurant déjà implicitement dans les approximations polynomiales de surface (B-spline). Ces modèles ont ouvert la voie à la construction de nouvelles bases d ondelettes (dites de deuxième génération) définies pour des surfaces quelconques [34, 35]. Les surfaces de subdivisions sont crées en raffinant itérativement un maillage de contrôle M 0 pour produire une séquence de maillage M 1, M 2, etc. ayant un nombre croissant de faces et qui convergent vers une surface limite M. Chaque étape du raffinement consiste en deux étapes : la subdivision et le lissage. La subdivision indique comment vont être découpées les faces du maillage obtenues à l étape précédente. Dans le cas des ondelettes, la subdivision est régulière afin d éviter les singularités (triangles dégénérés). Le lissage consiste à appliquer des coefficients d ondelette aux sommets afin de modifier le maillage obtenu à l étape précédente de façon à le faire converger vers la surface souhaitée. La figure 1.11 montre comment les ondelettes apportent le détail qui permet de compléter la subdivision. Ces figures sont issues des travaux de O. Aubault sur les ondelettes de subdivision [22], qui sont un cas particulier des ondelettes géométriques de P. Gioia [36, 37]. Elles permettent un affichage dépendant du P dv de l observateur (cf figure 1.6). La fusion de polygones est une technique de simplification adaptée aux grands environnements urbains proposée par J. Royan, C. Bouville et P. Gioia [38] en A partir d une représentation 2D 1 2 de bâtiments (prisme modélisé par une emprise au sol et une hauteur), une représentation hiérarchique est générée. Chaque nœud de l arborescence correspond à un prisme, celui-ci résultant de la fusion des prismes représentant l emprise au sol des

30 28 Étude d un système de visualisation interactive en local Fig. 1.11: A gauche : exemple d une subdivision un vers quatre. Les points rouges représentent les nouveaux sommets. A droite : principe de modélisation par ondelettes ; on souhaite approcher une surface (a) à partir de sa version grossière (b). La version grossière est subdivisée en quatre nouvelles faces par l ajout de trois sommets (c). La position de ces sommets est modifiée par l ajout d un déplacement (le coefficient) (d) sur ces sommets. Ces opérations sont effectuées récursivement afin d obtenir la résolution souhaitée [22]. bâtiments fils et leur hauteur. Une erreur métrique spécifique est associée à chaque prisme de manière à ordonner le processus de fusion et ce pour conserver au mieux certaines caractéristiques sémantiques telles que la disposition des rues, les bâtiments de taille élevée, etc. L erreur métrique correspond à une différence de volume entre les prismes des bâtiments fils et le prisme du bâtiment père. Cette représentation hiérarchique permet une visualisation dépendante du P dv de l observateur. La figure 1.12 présente le principe du calcul de l erreur métrique, ainsi qu une vue de la ville de Rennes en utilisant cette technique. Fig. 1.12: A gauche : principe du calcul de l erreur métrique basée sur la différence de volumes et spécifique aux bâtiments 2D 1 2 [39]. A droite : exemple de survol du modèle de Rennes (35000 bâtiments, 25 images par seconde) [40]. Chacune des techniques que nous avons décrites dans les points précédents présentent des avantages et des inconvénients. Globalement, les différences les plus notables tiennent au fait qu elles peuvent ou non être appliquées en temps réel et qu elles sont plus ou moins adaptées

31 La sélection du niveau de détail 29 suivant le type de modèle que l on souhaite simplifier. Une autre différence importante est liée à leur dépendance ou non par rapport au P dv. Ainsi, les méthodes dépendantes du P dv, tout en permettant d afficher un modèle de façon adaptée, nécessitent des traitements supplémentaires pour le mettre à jour. Pour les expérimentations que nous avons mis en œuvre par la suite, nous avons choisis d utiliser la technique P BT ree (Progressive Building Tree) de Royan [38] adaptée aux grands environnements urbains à cause la dépendance entre les nœuds de sa hiérarchie. Effectivement, du fait de son encodage incrémental, il est nécessaire de disposer des nœuds parents pour décoder les nœuds fils. Nous montrerons par la suite que cette contrainte pose le problème de la transmission ordonnée des nœuds s ils sont transmis via un réseau. En effet, comme nous l avons montré, certaines techniques n imposent pas cette contrainte et les raffinements peuvent être appliqués indépendamment de leur ordre d arrivée (ondelettes géométriques par exemple [36, 37]). Une fois que les simplifications ont été effectuées sur le modèle initial et qu une représentation dépendante du P dv a été générée, il est nécessaire de déterminer judicieusement les N DDs à afficher selon le P dv l observateur. Dans la section suivante, nous allons présenter quelques unes de ces techniques de sélection. 1.3 La sélection du niveau de détail Selon un principe d adaptation à la vue, et une fois qu une représentation multi-niveaux de détail a été générée, il est nécessaire d effectuer une sélection adaptée des NDDs à afficher. La sélection des N DDs se fait en fonction du P dv de l observateur et éventuellement des capacités du système de visualisation ou d un critère d erreur absolu (CAO par exemple). Dans les deux sous-sections suivantes, nous présenterons respectivement quelques techniques de sélection et les principes proposés par Funkhouser et al. [41] concernant l adaptabilité aux ressources du matériel graphique Quelques techniques de sélection Plusieurs solutions ont été proposées dans la littérature pour effectuer la sélection du niveau de détail pendant la visualisation. Parmi celles-ci, on retrouve : la sélection basée distance, qui est l une des plus souvent utilisée. La sélection du N DD à afficher est faite en tenant compte de la distance entre l observateur et l objet. La figure 1.13 montre un exemple de sélection des N DDs en fonction d une distance. La direction d observation n a pas d influence sur la sélection du N DD.

32 30 Étude d un système de visualisation interactive en local r1 r2 r3 Noeud LOD r? LOD0 LOD1 LOD2 LOD3 Fig. 1.13: La partie gauche montre comment fonctionne la sélection basée distance pour des NDDs discrets. On note que le quatrième niveau est vide donc quand l objet est très loin de l observateur, il n est pas affiché. La partie droite montre un nœud du graphe de scène et, si nécessaire, un seul des NDDs du nœud est affiché [39]. la sélection basée sur l aire du projeté. Une autre façon courante de sélectionner les NDDs consiste à projeter les boites englobantes sur le plan de projection de manière à pouvoir mesurer leurs aires projetées (du moins une estimation). Effectivement, si l aire projetée dépasse un certain seuil, l objet doit être raffiné et ce jusqu a ce que l objet soit affiché au plus haut NDD. Schmalstieg et Tobler [42] ont développé une méthode rapide pour calculer l aire projetée d une boite englobante. Le principe est de détecter la silhouette de la boîte et, une fois que les sommets de la silhouette ont été obtenu, de calculer l aire grâce aux projetés de ces sommets (cf figure 1.14) dans l image. Fig. 1.14: En haut, les trois cas de la projection d une boite qui montre 1, 2 ou 3 faces (d après Schmalstieg et Tobler [42]). En bas, Les triangles obtenus permettent le calcul de l aire. L aire d un triangle formé par les points p,q et r se calcule par Aire( pqr) = 1 2 (p r) (q r). la sélection basée sur le projeté d une erreur qui consiste à spécifier une erreur géométrique entre un modèle avant et après raffinement. Cette erreur est alors projetée dans l image, afin de déterminer si elle est supérieure à une tolérance τ en pixels dans l image. Si tel est le cas, le raffinement est effectué. La figure 1.15 présente un exemple du calcul de l erreur géométrique lors d un ajout ou d un déplacement de sommet pour un maillage.

33 La sélection du niveau de détail 31 Fig. 1.15: A gauche : projection de l erreur géométrique dans le plan image. Si l erreur projetée est supérieure à un seuil τ de tolérance, le raffinement est effectué. A droite : rappel du principe général du calcul de l erreur géométrique lors d un ajout ou d un déplacement de sommet pour un maillage. L erreur correspond au vecteur qu il est nécessaire d appliquer au sommet résultant de la subdivision [22]. la sélection basée perception dont le principe repose sur la perception par l utilisateur des objets constituant la scène [43, 44, 45, 46, 47]. Par exemple, Funkhouser et Séquin [48] ont fait plusieurs suggestions concernant l importance (par exemple, un mur est plus important que la pendule sur le mur), le déplacement, et le point de focalisation de l objet. Idéalement, la fonction de sélection la plus adaptée doit s appuyer sur des critères perceptifs, mais ce type d approche est plus coûteux en temps de calcul et ne peut donc pas être utilisée pour tous les modèles. De plus, l importance perceptuelle d un objet est liée à des critères sémantiques difficiles à évaluer sans l assistance d un opérateur. On choisi donc la méthode de sélection la plus adaptée en fonction du modèle, de l application et du système de visualisation. Par exemple, on n utilisera pas la sélection basée perception avec des mobiles qui ont une puissance de calculs limitée et une taille d écran qui contraint fortement le rendu adaptatif L adaptabilité aux ressources du système de visualisation Comme nous l avons présenté dans les sections précédentes, de nombreux travaux ont consisté à générer des représentations multi-niveaux de détails et à proposer des techniques de sélection de ces N DDs durant la visualisation temps réel. Funkhouser et al. [41] furent les premiers à proposer une solution de sélection des N DDs qui permette de maintenir une fréquence de rafraîchissement au dessus d un seuil critique. La plupart des algorithmes de sélection proposés jusque là étaient des algorithmes de type réactifs, c est à dire que l adaptation de la sélection des N DDs se fait après le rendu. L algorithme de Funkhouser et al. [41] est quant à lui de type prédictif. L adaptation de la sélection des N DDs est effectuée avant le rendu et ce de manière à garantir une fréquence d affichage supérieure au seuil minimal. Cette solution est basée sur l équilibre entre deux fonctions heuristiques : la fonction de coût, et la fonction de bénéfice. Soit le tuple (O, L, R) correspondant à un objet O rendu avec un niveau de détail L selon un algorithme de rendu R. La fonction de coût Cost(O, L, R) estime le temps de rendu du tuple (O, L, R), et la fonction de bénéfice Benef it(o, L, R) estime

34 32 Étude d un système de visualisation interactive en local la contribution perceptuelle du tuple (O, L, R). Si S est l ensemble des tuples correspondant aux objets de la scène, l approche choisie afin de déterminer la modélisation optimale d une scène consiste à : Maximiser Avec S Benefit(O, L, R) S Cost(O, L, R) T empsrenducible (1.1) Funkhouser et al. séparent bien les deux étapes principales du processus de rendu, à savoir les traitements associés à chaque objet 3D (transformation des coordonnées, calcul de lumière, découpage,...), et les traitements associés à chaque pixel de l image (rasterisation, tampon de profondeur, transparence, plaquage de texture,...). Ces deux étapes étant effectuées en parallèle dans le processus de rendu, la fonction de coût correspond donc à la fonction de coût maximale de ces deux étapes : Cost(O, L, R) = max { C1 P oly(o, L) + C 2 V ert(o, L) C 3 P ix(o) (1.2) Où C 1, C 2, C 3 sont des coefficients constants spécifiques à l algorithme de rendu et à la machine de visualisation. P oly(o, L) et V ert(o, L) correspondent respectivement au nombre de polygones et de sommets composant l objet O au niveau de détail L. Enfin, P ix(o) correspond au temps pris par l étape de rendu associé aux pixels pour l objet O. La fonction de bénéfice dépend, quant à elle, des facteurs suivants : la surface de l objet projeté dans l image (Size(O)) : Plus un objet projeté couvre une surface importante dans l image, plus sa contribution à la qualité visuelle est importante. la fidélité du modèle (Accuracy(O)) : Cette fidélité du modèle simplifié par rapport au modèle initial est inversement proportionnelle à l erreur géométrique entre le modèle simplifié et le modèle original, d où : Accuracy(O, L, R) = 1 Error (1.3) la sémantique d un objet (Importance(O)) : Certains objets de la scène ont une importance inhérente au type d application qu il est envisagé de mettre en œuvre. Par exemple, certains monuments d une ville sont des points de repère essentiels lors d une navigation urbaine, et doivent donc augmenter en conséquence la fonction de bénéfice. la focalisation (F ocus(o)) : Les objets qui apparaissent dans la portion de l écran ou l utilisateur regarde doivent augmenter la fonction de bénéfice. Certains capteurs visuels permettent de déterminer la portion de la scène sur laquelle se focalise l observateur, si tel n est pas le cas, le centre de l écran est pris comme portion de référence. la vitesse de déplacement dans l image (Motion(O)) : Plus un objet se déplace vite dans l image, plus il apparaît de manière floue pour l observateur. l hystérésis (Hysteresis(O, L, R)) : Le fait de visualiser un objet à différents N DDs lors de rendus successifs peut être gênant pour l observateur. Ainsi, la fonction de bénéfice est réduite proportionnellement à la différence entre le N DD courant et ceux des rendus précédents.

35 Le filtrage de visibilité 33 Ainsi, on obtient la fonction de bénéfice suivante : Benef it(o, L, R) = Size(O) Accuracy(O) Importance(O) F ocus(o) Motion(O) Hysteresis(O, L, R) (1.4) Il est ainsi possible, de manière heuristique, de tendre vers une complexité maximale de la scène avec une qualité visuelle optimale. Hoppe [20] et Schmalstieg [49] se sont basés sur le principe des coûts-bénéfices afin d obtenir une qualité visuelle optimale. Michael Wimmer et al. [50] ont quant à eux, proposé une solution littérale grâce à l utilisation de N DDs continus. L intérêt principal des travaux de Wimmer et al. [50] est d avoir permi de résoudre le problème de façon polynomiale. La résolution du problème NP-Complet proposée par Funkhouser étant effectivement très coûteuse en temps de calculs. 1.4 Le filtrage de visibilité Le traitement de la visibilité est un problème fondamental apparu dès les débuts de l informatique graphique [51, 52]. La majorité de ces travaux développés dans les années 1970 se concentrait sur la détermination des portions de scène visibles pour rendre une scène selon un P dv donné (Hidden Surface Removal). On considère ce problème comme étant actuellement résolu pour les applications temps réel, notamment grâce au matériel graphique qui exploite l algorithme du tampon de profondeur (ou Z-Buffer) [53]. D autres algorithmes comme l élimination des faces arrière (BackFace Culling) ou l élimination des faces situées en dehors de la pyramide de vue (Frustum Culling) peuvent s appliquer en amont de l algorithme du tampon de profondeur afin de limiter la complexité de la scène qui doit être rendue. On note que la plupart des algorithmes que l on vient de décrire sont câblés dans les cartes graphiques actuelles, ce qui permet un rendu très rapide. Malgré cela, certaines scènes très complexes continuent à poser problème. Les travaux actuels consistent donc, majoritairement à proposer des techniques qui tiennent compte de l occultation (Occlusion Culling). Effectivement, certains polygones peuvent être cachés par d autres situés plus près de l observateur. Par exemple dans une ville : si l on se déplace au niveau du sol, les bâtiments proches de l observateur vont occulter une grande partie des bâtiments situés derrière ceux-ci. Les différentes techniques d élimination de faces pouvant être appliquées avant le pipeline de rendu sont illustrées dans la figure Les polygones qui sont éliminés en utilisant les techniques d élimination de faces ne sont ni découpés ni transformés, ce qui diminue d autant le traitement.

36 34 Étude d un système de visualisation interactive en local Fig. 1.16: Les trois types de techniques d élimination des faces [40] : arrières (BackFace Culling), hors de la pyramide de vue (Frustum Culling), et occultées (Occlusion Culling). Dans cette section, nous ne décrirons pas de manière détaillée les techniques qui prennent en compte l occultation car ces techniques ne constituent pas le cœur de notre problématique. Malgré tout, ces techniques présentent un intérêt certain si l on souhaite visualiser des scènes très grandes et très complexes. C est pourquoi, nous allons tout de même décrire rapidement les différentes stratégies qui peuvent être utilisées pour prendre en compte l occultation et ainsi éviter de calculer le rendu de polygones qui sont invisibles dans l image visualisée. Tout d abord il est important de noter que certaines techniques utilisent les fonctionnalités des cartes graphiques. Comme on l a dit en introduction, l algorithme éprouvé du tampon de profondeur, par exemple, est pré-câblé dans la plupart des cartes graphiques. Grâce à ces implémentations en dur, les temps de calculs sont considérablement diminués. La première différentiation que l on peut faire entre les différents algorithmes de détection des occlusions est donc caractérisée par l utilisation ou non du processeur graphique. On note ensuite que les calculs effectués par les algorithmes de détection des occlusions peuvent être des types suivants : surestimé, qui est le type de calcul est le plus répandu. Dans ce cas, les algorithmes surestiment l ensemble des objets visibles en s assurant que tous les objets réellement visibles y sont compris. approché. Une autre stratégie consiste à calculer une visibilité approchée, ce qui signifie que certains objets visibles ne seront peut être pas pris en compte. Cependant, il est important de noter que ces techniques sont mieux adaptées au filtrage de visibilité en temps réel et que, de additionnelle, ces algorithmes sont généralement plus faciles à mettre en oeuvre. Selon que la scène soit statique ou dynamique, deux sortes de calculs de visibilité peuvent être effectués. Effectivement, le calcul de visibilité peut être soit : précalculé et ce seulement si la scène n est pas dynamique. Cette technique est intéres-

37 Le filtrage de visibilité 35 sante, bien que limitée aux scènes statiques, car le calcul de visibilité est très coûteux. Un précalcul de la visibilité permet de ne pas ajouter une tâche supplémentaire à effectuer en parallèle du processus de rendu. effectué en temps réel. Le calcul de visibilité temps réel est adapté à tous les types de scènes (dynamiques ou statiques). Etant donné le coût important de ce calcul, les algorithmes de calcul de visibilité temps réel sont généralement des calculs approchés. Il est possible d appliquer deux stratégies différentes au filtrage de visibilité, elles-aussi dépendantes de la dynamicité de scène. Ainsi, il est possible d effectuer le filtrage de visibilité à partir : d un point. Les premiers algorithmes calculaient les objets visibles depuis un P dv donné. Le filtrage de visibilité à partir d un point peut être effectué en temps réel ou précalculé et permet de déterminer la visibilité pour des scènes statiques ou dynamiques. d une région. Dans le cas des scènes statiques, le calcul de visibilité à partir d une région trouve tout son intérêt. Cette technique permet d augmenter la durée de validité d un calcul de visibilité en calculant la visibilité pour tous les points d une région aussi appelée cellule de vue (View Cell). Ce calcul est très coûteux et peut difficilement être effectué en temps réel. Si ce calcul est effectué en temps réel, ce sera au dépend d autre tâches car il sera nécessaire de mettre à contribution le processeur graphique. Ensuite, suivant le degré de finesse que l on souhaite avoir pour le filtrage de visibilité, il est possible de calculer la visibilité : de région à région (region-to-region), d objet à region (object-to-region), d objet à point (object-to-point), et toutes les autres combinaisons sont possibles. Plus la sélectivité du calcul de visibilité est grande, plus le calcul est coûteux. C est pourquoi en général pour tous les calculs temps réel on préfère effectuer un calcul approché. Enfin, il est important de noter que le filtrage de visibilité est dépendant du type de scène. Ainsi, suivant que la scène soit "d intérieur" ou "d extérieur", les stratégies de calcul de visibilité vont différer. Un exemple de technique particulièrement bien adaptée aux environnements intérieurs est la technique des Cellules-Portails [54] (CP ) (Cells-Portals). Dans les bâtiments, le cloisonnement des pièces définit naturellement des régions de vue. Ces régions sont liées entre elles par des ouvertures (ie. qui correspondent aux portes et aux fenêtres). Après extraction des informations essentielles tels que les ouvertures, la connectivité, la topologie des pièces, etc. les méthodes de calculs de visibilité détectent si d autres pièces sont visibles à travers ces ouvertures. Il est ainsi possible de limiter l affichage des polygones à ceux concernant la pièce courante (ie. pièce ou se situe l observateur) et ceux étant liés aux pièces visibles au travers des ouvertures. De la même façon, la technique des Groupes Potentiellement Visibles (GP V ) (Potentially Visible Sets) [54, 55] est bien adaptée aux scènes urbaines en extérieur (elle peut aussi être utilisée pour les scènes d intérieur). Cette technique permet d associer une liste de bâtiments visibles pour différentes zones proches du sol. Nous ne rentrerons pas dans les détails de ces deux techniques, mais on note tout de même qu un certain nombre d algorithmes ont été proposé de manière à effectuer ces mêmes calculs de visibilité en temps réel [56]. Une remarque importante que l on peut faire est que l utilité de la visibilité précalculée est aujourd hui contestable du fait de l implémentation de fonctions câblées dans le hardware des

38 36 Étude d un système de visualisation interactive en local cartes graphiques actuelles. Il est ainsi possible d effectuer des requêtes de visibilité directement vers la carte graphique, et donc de déterminer en temps réel si des objets sont visibles. On note aussi que dans la plupart des cas, une bonne gestion des NDDs et de l élimination des faces hors de la pyramide de vue (Frustum Culling) suffit pour afficher des scènes complexes de façon très acceptable. Malgré tout, du fait de l hétérogéneité des systèmes de visualisation présent actuellement sur Internet (PCs fixes moins récents, mobiles, etc.), il n est pas possible d écarter les techniques de filtrage de visibilité précalculée si l on souhaite proposer des services accessibles au plus grand nombre d utilisateurs. 1.5 Conclusion Pour conclure ce chapitre, nous allons nous appuyer sur le diagramme de flux proposé par Funkhouser [48] qui décrit les sept opérations essentielles à tout système complet de visualisation interactive en local. La figure 1.17 présente ce diagramme de flux. Fig. 1.17: Diagramme de flux décrivant les opérations effectuées lors de la visualisation. Les sept opérations définies par Funkhouser [48] forment un système complet de visualisation interactive en local. On distingue deux branches : l une permettant de gérer le rendu en sur-capacité mémoire et l autre la sélection et le rendu. Les différentes opérations peuvent éventuellement être effectuées de façon asynchrone. Les sept opérations de Funkhouser sont décrites dans les points suivants. Ainsi, pour chaque image, le système effectue ces différentes opérations éventuellement de façon asynchrone : L interface utilisateur interagit avec l utilisateur afin de sélectionner un P dv. La sélection des objets visibles sélectionne l ensemble des objets visibles selon le P dv de l observateur. La sélection des représentations choisit le niveau de détail et la méthode de rendu pour chaque objet visible. La notion de niveaux de détail permet de limiter le nombre de polygones à afficher et donc d obtenir un rendu plus rapide. Le rendu affiche les objets potentiellement visibles avec la représentation et la méthode de rendu sélectionnées (cf section 1.2 : rendu basé image, points, polygones). Les premiers points que nous venons de décrire sont essentiels, mais ils ne sont pas caracté-

39 Conclusion 37 ristiques du rendu en sur-capacité mémoire contrairement aux points suivants : L anticipation sélectionne l ensemble des objets à charger en mémoire pour produire le P dv. Une technique de chargement anticipé (les données potentiellement visibles dans un futur proche) permet de minimiser le décalage temporel dû aux accès disque. La gestion de cache choisit les objets à ajouter ou à retirer de la mémoire cache locale. Funkhouser introduit cette gestion de mémoire permettant de conserver les données déjà chargées afin de limiter les accès sur le disque dur. Le chargement charge et met à jour les données depuis la base de données. Dans ce chapitre nous avons décrit tout ou partie de ces sept opérations ainsi que de nombreuses techniques adaptées à certaines d entre elles (ie. sélection des représentations, sélection des objets visibles, méthodes de rendu, etc.). De façon additionnelle, nous avons montré comment générer des représentations géométriques scalables et dépendantes du P dv de l observateur. Ce qui nous permet implicitement de mettre en valeur les limitations inhérentes à tout matériel de visualisation. Les deux limitations principales que l on peut mettre en valeur sont : les capacités de calcul et de rendu qui sont très différentes suivant le type de matériel de visualisation utilisé (PC fixes, PC portables, mobiles, etc.). Ainsi, certains matériels de visualisation n ont pas forcément suffisamment de puissance de calcul pour effectuer la totalité des opérations nécessaires à l affichage de scènes très grandes et très complexes. La puissance de calcul du matériel de visualisation est répartie dans deux processeurs : le processeur graphique qui s occupe du rendu. Il peut éventuellement être utilisé pour d autres tâches (au dépend du rendu). Certains des traitements que doit effectuer le processeur graphique sont pré-cablés dans le hardware du matériel graphique, ce qui permet de les effectuer beaucoup plus rapidement que s ils étaient faits de façon logicielle. Par exemple, l élimination des faces arrière (BackFace Culling) est un traitement qui est très souvent pré-câblé. le processeur central qui s occupe de toutes les autres tâches (chargement, décompression, sélection des représentations, sélection des N DDs, etc.). Il est très fortement mis à contribution pendant la visualisation. La puissance de calcul du processeur graphique et du processeur central n est pas forcément corrélée. Un matériel de visualisation peut disposer d un processeur graphique très puissant et d un processeur central de faible capacité, et inversement. Les limitations d un matériel de visualisation peuvent donc venir soit d un seul des processeurs, soit des deux. la capacité de stockage. L un des objectifs que nous nous sommes fixés est de permettre aux utilisateurs de naviguer dans des scènes virtuelles de taille non finie. Si on prend en compte cette contrainte, on constate aisément qu un matériel de visualisation sera toujours limité par sa capacité de stockage que ce soit en mémoire graphique, en mémoire vive ou en mémoire de masse. La mémoire graphique est utilisée la plupart du temps pour stocker les textures qui vont être affichées. Si la mémoire graphique est saturée, les textures excédentaires sont stockées en mémoire vive et rechargées au moment de leur affichage. Si de très nombreux transferts entre ces deux mémoires doivent être effectués, le rendu en sera affecté (ie. la fréquence de rafraîchissement diminuera). La mémoire vive est utilisée principalement pour stocker les représentations qui doivent être visualisées. Les représentations stockées en géneral sous une forme compressée dans la mémoire de masse sont décompressées pour être stockées dans la mémoire vive. Si la mémoire vive est saturée, la mémoire virtuelle est mise à contribution. La mémoire

40 38 Étude d un système de visualisation interactive en local virtuelle est un sous ensemble de la mémoire de masse et sa taille est fixée par l utilisateur. L utilisation de la mémoire virtuelle ralentit considérablement la visualisation, car le procédé de lecture/écriture des données en mémoire vive est beaucoup plus long. Si la mémoire vive et la mémoire virtuelle sont saturées, il n est en général pas possible d effectuer la visualisation car la scène ne peut pas être chargée complètement. La mémoire de masse est utilisée pour le stockage à long terme des données de visualisation. Malgré la taille croissante des supports actuels (disques durs, DVDs, etc.), il est toujours possible d en atteindre la limite si la base de données de visualisation est très grande. De plus, étant donné l hétérogénéité des capacités de stockage des matériels de visualisation (PC fixes, PC portables, PDAs, mobiles, etc.), cette limite est d autant plus réelle. De façon additionnelle, même si le matériel de visualisation dispose de suffisamment de mémoire de masse, l utilisateur peut souhaiter que celle-ci ne serve pas uniquement au stockage de la base de données de visualisation. La taille des différentes mémoires n est elle aussi pas forcément corrélée. Les limitations d un matériel de visualisation en local peuvent donc venir d au moins l une de celles-ci. En général, la mémoire vive est celle qui est le plus souvent saturée. Pour pallier certaines de ces limitations, il est possible d utiliser quelques unes des techniques que nous avons présentées dans ce chapitre. Premièrement pour ce qui est du rendu lui même, les différentes méthodes de rendu que l on a présentées (méthode de rendu basée image, points, polygones, le tout avec NDDs ou non) sont plus ou moins adaptées suivant le type de modèle que l on souhaite visualiser (au sens sémantique : ville, terrain, statues, etc.). La méthode de rendu basé polygones est la plus répandue actuellement, elle permet la visualisation de pratiquement tous les types de modèles. La méthode de rendu basé points permet à moindre coût de visualiser des objets très complexes, comme des statues par exemple, qui peuvent être composées de plusieurs millions de polygones. La méthode de rendu basé image peut être utilisée avec n importe quel matériel de visualisation, même ceux disposant de très faibles capacités. Cependant, cette méthode nécessite le chargement de nombreuses textures dans la mémoire graphique si l on souhaite compenser efficacement les artéfacts d écrasement et de parallaxe qui lui sont souvent associée, ce qui peut entrainer une saturation de la mémoire graphique. On note que les textures peuvent aussi être utilisées pour augmenter le réalisme si on utilise le rendu basé polygones. On en déduit donc qu un choix judicieux de la méthode de rendu et de la représentation d objet utilisée permet la visualisation de n importe quel modèle 3D avec n importe quel matériel de visualisation actuel. Effectivement, après avoir choisi la méthode de rendu adéquate, compte-tenu des capacités du matériel de visualisation (ie. sélection des représentations), l utilisation des N DDs avec cette méthode permet d adapter la complexité du modèle rendu en fonction du P dv de l observateur (ie. sélection des NDDs et fitrage de visibilité). Si la méthode choisie est bien adaptée au matériel de visualisation : la mémoire graphique, la mémoire vive, le processeur graphique et le processeur central ne seront pas surchargés. On note cependant que dans ce cas il est nécessaire de faire intervenir un opérateur pour définir des profils qui seront plus ou moins adaptés aux capacités des différents matériels de visualisation disponibles. De plus, même en choisissant au mieux la méthode de rendu, il est impossible de paramétrer la sélection des NDDs de façon à ce que le rendu soit optimal quelque soit le P dv de l observateur (ie. la complexité de la scène visualisée varie drastiquement suivant le P dv de l observateur). Une contrainte importante que nous nous sommes fixés est de permettre une visualisation interactive de la scène 3D. Comme on l a dit précédemment, pour qu un système de visualisation soit considéré comme réellement interactif il faut qu il soit en mesure de garantir une fréquence de

41 Conclusion 39 rafraîchissement de l image au dessus d un seuil critique (au dessus de 15 et jusqu à 70 images par seconde suivant le type d application envisagé). Nous avons présenté dans ce chapitre plusieurs méthodes de rendu adaptatif qui permettent de répondre à cette contrainte. Seulement, on note que ces méthodes sont très coûteuses en temps de calcul (ie. le processeur central peut rapidement être surchargé) et il est donc essentiel de se poser la question de leurs efficacité réelle. Le rapport t p+t r t r avec t p temps de pré-traitement, t r temps de rendu avec pré-traitement et t r temps de rendu sans pré-traitement permet de déterminer l efficacité réelle de ces méthodes. Si ce rapport est supérieur à 1, la méthode est considérée comme inefficace et trop coûteuse compte tenu de la capacité du processeur central. Etant donné l hétérogénéité des matériels de visualisation, ces méthodes peuvent être considérées comme efficaces pour un matériel de visualisation et trop coûteuse pour un autre. Il apparait donc que certains matériels ne sont pas en mesure de garantir une visualisation interactive en local. Tous les systèmes de visualisation en local doivent stocker l ensemble de la base de données de visualisation dans la mémoire de masse. Plusieurs problèmes peuvent se poser à ce propos. La taille de la base de données est parfois très grande. Deux cas de figure peuvent poser problème : soit il n y a pas assez de mémoire de masse pour stocker l ensemble de la base de données, soit l utilisateur ne souhaite pas que la base de données prenne autant de place dans sa mémoire de masse. La base données doit fréquemment être mise à jour. Ce cas de figure impose à l utilisateur d effectuer lui même les mises à jour, ce qui peut poser problème aux néophytes et faire perdre du temps aux autres. Les accès à la base de données sont parfois contraints (sujet à des droits d auteur). Si la base de données est totalement répliquée, il est possible que l utilisateur trouve des solutions pour contourner les différentes protections mises en place. En résumé, un système de visualisation en local n est pas adapté pour fournir un service au plus grand nombre d utilisateurs possibles. Les points bloquants sont qu il n est pas possible de garantir une visualisation interactive avec n importe quel matériel de visualisation et que le stockage de la base de données de visualisation pose certaines difficultés. Dans le chapitre suivant nous présenterons une première ébauche de solution à ces problèmes. L utilisation du réseau permet de mettre à contribution un serveur distant pour effectuer certains traitements et pour stocker la base de données de visualisation. A partir de maintenant, du fait de l utilisation du réseau, le matériel de visualisation est appelé terminal de visualisation. Ainsi, nous monterons dans la suite que les techniques de visualisation intéractive en réseau permettent à n importe quel type de terminal de visualisation d afficher n importe quelle scène 3D de façon interactive. Nous montrerons aussi que la mémoire de masse est moins mise à contribution. De même, la mise à jour de la base de données et la gestion les droits d accès sont facilités.

42 40 Étude d un système de visualisation interactive en local

43 2. Étude d un système de visualisation interactive en réseau 2.1 Introduction Nous avons vu dans le chapitre précédent que la navigation dans des scènes virtuelles de très grande taille pose certains problèmes si on utilise un système de visualisation interactive en local. Le stockage de la base de données de visualisation pose certaines difficultés et certains matériels de visualisation ne peuvent pas garantir une visualisation interactive. Nous montrerons dans ce chapitre que l utilisation du réseau permet de pallier ces difficultés. A partir de ce chapitre, le matériel de visualisation est nommé terminal de visualisation du fait de l utilisation du réseau. On note que nous ne nous intéresserons pas pour l instant aux différentes architectures réseaux qui existent dans la littérature et nous supposerons que nous sommes un cas d utilisation d une architecture client-serveur classique. Dans un contexte client-serveur, les données sont centralisées sur le serveur. La centralisation des données sur le serveur permet de répondre aux problèmes soulevés dans le chapitre précédent, à savoir le stockage, le contrôle d accès et les mises à jour de la base de données de visualisation. Dans ce chapitre, nous présenterons plus particulièrement les solutions au problème de stockage de la base données de visualisation en présentant les différentes techniques de visualisation interactive en réseau. Nous montrerons aussi que le serveur peut éventuellement prendre une part active aux différents traitements que nous avons évoqués dans le chapitre précédent (ie. sélection des représentations, sélection des N DDs, etc.). En prenant une part active à ces traitements, le serveur décharge considérablement le terminal de visualisation, ce qui lui permet de garantir une visualisation interactive. Parmi les différents systèmes de visualisation interactive en client-serveur, on distingue deux types d architectures : l architecture de rendu distant (remote rendering). Dans ce cas, le rendu est effectué sur le serveur qui transmet ensuite le résultat au client pour qu il l affiche. l architecture de streaming adaptatif des données (adaptative data streaming). Dans ce cas, le rendu est effectué sur le client après qu il ait reçu les données nécessaires transmises par le serveur. Dans les deux cas, à cause de l utilisation du réseau, il est nécessaire de prendre en compte les paramètres suivants : la latence, qui correspond au temps que met un paquet de données à effectuer un allerretour entre deux terminaux (i.e. dans notre cas entre le client et son serveur). le débit, qui est la capacité de transfert en octets entre deux terminaux. la fiabilité, qui correspond à la quantité de données perdues ou endommagées durant leur transport. Le remote rendering est aujourd hui en général utilisé pour visualiser des résultats de simulation très complexes effectuées sur un ou plusieurs serveurs de calcul. Les modèles générés pendant

44 42 Étude d un système de visualisation interactive en réseau une simulation représentent souvent une quantité de données très importante, on préfère donc effectuer le rendu directement sur le(s) serveur(s) plutôt que de transmettre au client l intégralité de ces données (et qu ainsi ce soit le client qui effectue le rendu). Des protocoles spécifiques comme V N C (Virtual Network Computing) [57] peuvent être utilisés pour permettre à n importe quel type de terminal client d interagir avec le(s) serveur(s) et de visualiser les résultats de simulation. Le rendu distant présente un avantage certain s il est utilisé dans ce cas. Malgré cela, compte-tenu des contraintes que nous nous sommes fixés, nous ne retenons pas cette architecture et nous nous intéresserons plus particulièrement à l architecture de streaming adaptatif des données. Effectivement, nous souhaitons mettre en place une application de visualisation interactive accessible à un grand nombre de clients, ce qui n est pas compatible avec le rendu distant. Pour qu une application soit considérée comme interactive, il faut que la fréquence de rafraîchissement de l image soit supérieure à un seuil critique. La fréquence de rafraîchissement de l image doit se situer au dessus de 15 et jusqu à 70 images par seconde suivant le type d application (CAO, jeux videos, etc.). Si on utilise une architecture de rendu distant (et ce en ne tenant pas compte de la latence du réseau), il faut que le serveur effectue au moins autant de rendus par seconde que la fréquence de rafraîchissement minimum souhaitée par le client. Si on souhaite fournir un service à grande échelle, ce qui est notre objectif, cette méthode est trop coûteuse en ressources pour le serveur car il doit effectuer le rendu pour tous les clients qui y sont connectés. Le processeur graphique du serveur risque d être très rapidement saturé. Nous nous concentrerons donc, dans ce chapitre, à l étude des architectures de streaming adaptatif des données. Dans la première section, nous présenterons la manière dont peuvent être répartis certains traitements (sélection des représentations, sélection des objets visibles, filtrage de visibilité, etc.) entre le client et le serveur. Nous montrerons ensuite que cette répartition conditionne le mode d échange des données entre le client et son serveur. Dans la deuxième section, nous présenterons les différents travaux qui ont été effectués concernant l adaptation aux ressources du terminal de visualisation et du réseau. Ces travaux permettent de garantir une visualisation interactive. Dans cette section, nous montrerons que l adaptation aux ressources peut être effectuée côté client ou côté serveur. Nous montrerons aussi que l adaptation aux ressources effectuées côté serveur permet de garantir une visualisation interactive avec des terminaux de visualisation de très faible capacité. Dans la troisième et dernière section, nous nous intéresserons à quelques protocoles d échanges des données spécialement adaptés au transport des données de visualisation. Étant donné que chaque échange de données entre le client et son serveur a un coût, il est nécessaire de compresser efficacement les données, de les structurer dans des messages adaptés et d utiliser un protocole de transport adéquat. Enfin, en conclusion de ce chapitre, nous présenterons les gains apportés par l utilisation d un système de visualisation en réseau en particulier pour les terminaux de visualisation ayant des capacités limitées. Nous montrerons aussi que l utilisation d une architecture client-serveur classique entraine certaines limitations en nombre d utilisateurs. De façon additionnelle, la centralisation des données ne permet pas de résoudre complètement le problème de stockage de la base de données de visualisation. 2.2 La répartition des traitements de sélection des données et les différents modes d échange des données Comme nous l avons présenté en introduction, nous nous intéresserons dans ce chapitre uniquement aux architectures client-serveur classiques. Avec l émergence d Internet, de nombreux travaux ont porté sur l accès en ligne (ie. via un réseau) à des représentations 3D statiques.

45 La répartition des traitements de sélection des données et les différents modes d échange des données 43 La figure 2.1 présente une architecture client-serveur classique. Le serveur fournit les données nécessaires à la visualisation sur les terminaux clients. Fig. 2.1: Topologie d une architecture client-serveur classique. Les clients sont tous connectés au même terminal (ie. le serveur) qui fournit les données nécessaires à la visualisation. Comme on l a montré dans le chapitre 1, différents traitements peuvent éventuellement être effectués avant le rendu de façon à améliorer la qualité de la visualisation (ie. en particulier en permettant d afficher des modèles 3D complexes sans les charger complètement dans la mémoire vive du matériel de visualisation). Parmi ceux-ci on distingue la sélection des représentations et des N DDs (cf sous-section 1.2) et le filtrage de visibilité (cf sous-section 1.4). Concernant la sélection des représentations, celle-ci peut être effectuée selon des critères divers tels que la qualité de l image, la fréquence de rafraîchissement de l image, la bande passante disponible, etc. Le filtrage de visibilité permet, quant à lui, d afficher uniquement les faces visibles selon le P dv de l observateur (BackFace Culling, Frustum Culling, etc.). Parmi ces différents traitements, certains peuvent être effectués indifféremment par le serveur ou par le client. Nous verrons dans cette section que le mode de transmission utilisé entre le client et le serveur est directement lié au choix de la répartition de ces traitements. La première stratégie pour distribuer des contenus 3D a consisté à transmettre des représentations complètes aux clients qui, après les avoir reçues, sont en mesure de les visualiser complètement. Chaque client se charge de tous les traitements liés à la visualisation, le serveur est uniquement un serveur de données. Pour cet usage, des langages de modélisation spécifiques ont été créé : le V RML [58] (Virtual Reality Modeling Language) et X3D [59]. Ces deux langages, et surtout X3D, ont été conçus pour les applications Web et ils se basent donc tous les deux sur une architecture client-serveur classique. Ces langages définissent un format de description de scènes multimédia intégrant des fonctions d interaction(s) et d animation(s) basées sur une notion étendue d événements. Le chargement des données se fait sous la forme de fichiers textuels éventuellement compressés selon une méthode générique (gzip). Ces fichiers peuvent comporter des liens conditionnels afin de charger d autres fichiers si un événement précis intervient. Pour permettre la visualisation de scènes complexes, une notion de N DDs a été introduite dans ces formats mais leur chargement ne peut pas être effectué progressivement. Cela implique, si la scène est très vaste, de transmettre des fichiers d une taille parfois trop conséquente. On note qu un principe communément admis sur Internet est de permettre une visualisation immédiate des contenus sélectionnés, ce qui n est évidemment pas possible dans la plupart des cas si on utilise cette stratégie. Effectivement, celle-ci introduit un délai dépendant de la quantité de données qui doit être chargée pour pouvoir visualiser la scène. De plus avec ces formats il n y a pas de réversibilité au niveau de la gestion des NDDs : une fois qu un NDD est chargé, il ne peut pas être supprimé de la mémoire vive même si on le supprime du graphe de scène. Cette absence de réversibilité pose problème si l utilisateur souhaite visualiser une grande scène, la mémoire vive

46 44 Étude d un système de visualisation interactive en réseau de son terminal de visualisation peut être amenée à saturation. Comme on vient de l expliquer dans le paragraphe précédent, V RML et X3D présentent certains désavantages liés surtout à l absence de progressivité et de réversibilité des N DDs. Ainsi, pour permettre la visualisation de scènes vastes et complexes à travers un réseau, il est nécessaire d utiliser des représentations structurées de façon adéquate. C est pourquoi on a privilégié, par la suite, les représentations progressives (ie. avec N DDs) pouvant être transmises de façon incrémentale (sans redondance d informations d un N DD à un autre) en fonction du P dv de l observateur. Avec ce type de représentations, il est possible d y adjoindre des stratégies de filtrage de visibilité (précalculé ou non) (cf section 1.4). De l utilisation des représentations progressives et de la répartition des différents traitements (ie. sélection des représentation, sélection des N DDs, filtrage de visibilité, etc.) découle deux stratégies d échange des données ([60]). Si le mode "Push" est choisi, la sélection des représentations et des NDDs ainsi qu une partie des traitements liés au filtrage de visibilité (Frustum Culling, etc.) sont effectuées par le serveur. Le client envoie régulièrement au serveur les informations concernant son P dv, et le serveur détermine la(les) représentation(s) qui est(sont) la(les) plus adaptée(s) (imposteurs, N DDs géométriques, etc.), le(s) objet(s) de la scène doit(doivent) être raffiné(s) en priorité et le(s) élément(s) doit(doivent) être transmis. Le client effectue la visualisation après avoir reçu les données transmises par le serveur. Si le mode "Pull" ou "On-demand" est choisi, le client effectue tous les traitements luimême (ie. sélection des représentations et des N DDs et filtrage de visibilité). En fonction de l évolution de son P dv et des données dont il dispose dans sa mémoire, le client demande au serveur les données dont il a besoin pour effectuer la visualisation. le serveur n a qu un rôle de serveur de données. Suivant le type d application que l on souhaite mettre en place et surtout suivant le type de terminaux cibles, l un ou l autre des modes de transmission seront utilisés. Si les terminaux cibles sont des terminaux de faible capacité (mobiles par exemple), on préfère utiliser le mode "push" car dans ce cas le serveur prend à sa charge la plus grande partie des traitements. On note cependant que le mode "push" présente une limitation en nombre de clients qui peuvent être servis, notamment à cause des traitements supplémentaires que serveur prend en charge. Parmi les traitements que le serveur prend en charge, il y a bien sûr les traitements liés à la sélection des NDDs et éventuellement le calcul des modèles 3D mais aussi ceux liés aux contextes des clients. Effectivement, pour limiter les effets dus à la latence du réseau, il est courant que le serveur effectue une prédiction de mouvement pour transmettre juste à temps au client les données dont il aura besoin. D autres techniques prennent en compte le contenu des caches des clients pour ne pas effectuer de transmissions redondantes (ie. ne pas envoyer des données encore présentes dans le cache du client distant). Ces différentes optimisations ont un coût et limitent d autant la capacité de service des serveurs fonctionnant avec ce mode de transmission. C est pourquoi, si les terminaux cibles ont des capacités suffisantes on préfèrera utiliser le mode "pull". On considère en effet que si les terminaux disposent de suffisamment de capacités, ils peuvent effectuer eux mêmes les traitements de sélection et de filtrage de visibilité. Si les clients prennent à leur charge ces traitements, le serveur, n ayant plus qu un rôle de serveur de données, peut servir un nombre beaucoup plus grand d utilisateurs. Le serveur n est limité en nombre de clients qu il peut servir que par la bande passante qui lui est alloué. L utilisation du mode "pull" présente un intérêt particulier si l on souhaite fournir un service à grande échelle (ie. application web comme Google Earth [3] ou Msn Virtual Earth [61] par exemple). Effectivement, il n est pas nécessaire de déployer autant de serveurs que si l on proposait une application en mode "push", ce qui diminue

47 La répartition des traitements de sélection des données et les différents modes d échange des données 45 d autant le coût de mise en place et de maintenance de ces mêmes serveurs. Pour illustrer le mode "push" et le mode "pull", nous allons présenter quelques exemples d implémentations dans les sous-sections suivantes Exemples d échanges en mode "push" En mode "push", comme nous l avons décrit précédemment, le serveur effectue la sélection des représentations et des N DDs ainsi qu une partie des traitements liés au filtrage de visibilité. De leur côté, les clients se chargent de maintenir le serveur informé de l évolution de leurs P dv s respectifs dans la scène. Le serveur, en fonction du P dv de chacun des clients, détermine les données qui leurs sont nécessaires et les transmets. Ce mode de transmission est intéressant pour les terminaux de faible capacité (ie. terminaux mobiles) car le serveur prend à sa charge une grande partie des traitements. Dans cette sous-section nous ne décrirons que les travaux de Aubault, Gioia et Bouville [62] concernant la transmission de données à base d ondelettes géométriques (cf sous-section 1.2.3). On note que de nombreux autres travaux ont été effectués dans ce domaine, mais celui-ci nous semble suffisamment représentatif pour montrer les particularités de la distribution de contenus 3D en mode "push". Dans le cas de la transmission d ondelettes géométriques proposée par Aubault, Gioia et Bouville [62], chaque client transmet au serveur les informations concernant son P dv ainsi que des informations concernant le contenu de son cache. Le serveur, de son côté, maintient une copie des caches des clients connectés. La figure 2.2 montre cette architecture réseau et les échanges de données entre le client le serveur. Fig. 2.2: Architecture réseau proposée dans [62]. Le client maintient le serveur informé de l évolution de son point de vue et des données qui sont stockées dans son cache. Le serveur transmet sans redondance les données qui sont nécessaires au client. Au niveau du serveur, la connaissance du contenu du cache des clients permet d éviter des retransmissions inutiles si les clients disposent déjà des données nécessaires. Effectivement, il est judicieux de garder au niveau du client, et ce pendant une durée déterminée, des coefficients qui ont déjà été appliqués. Effectivement, l utilisateur peut, dans certains cas, revenir rapidement à une position antérieure. Les coefficients stockés de façon supplémentaire peuvent aussi servir à l anticipation. Le terminal de visualisation n a à sa charge que la reconstruction du maillage et la gestion de son cache. Le serveur s occupe d effectuer la sélection des NDDs et s il le faut il

48 46 Étude d un système de visualisation interactive en réseau ne transmet que les raffinements nécessaires (ie. il tient compte de ceux qui sont stockés dans le cache du client). Comme on l a rapidement expliqué dans la sous-section 1.2.3, à partir d un maillage de base il est possible en subdivisant ses faces et en déplaçant les sommets de converger vers un nouveau maillage raffiné en fonction du P dv de l observateur. Les coefficients d ondelettes sont appliqués aux différents sommets lors de la subdivision du maillage. Dans le cas d utilisation que l on présente, les coefficients d ondelettes sont compressés sous la forme d un "zero-tree". Ainsi, ils peuvent être transmis de manière progressive et appliqués indépendamment les uns des autres. La figure présente un exemple de subdivision de maillage en utilisant les ondelettes de subdivision [22] qui sont un cas particulier des ondelettes géométriques [36, 37]. Le serveur effectue une sélection des raffinements qui doivent être transmis aux clients en fonction de leurs P dv s et du contenu de leurs caches respectifs. La figure 2.3 présente un exemple de reconstruction adaptative d un modèle de "Feline" et de terrain. Fig. 2.3: Exemple de reconstruction adaptative d un modèle de "Feline" et d un modèle de terrain en utilisant la technique de streaming proposée par Aubault, Gioia et Bouville [62]. A gauche : Le modèle de "Feline" complet (a) et partiellement reconstruit (b). A droite : vue d un modèle de terrain selon l observateur (c) et vue du dessus des raffinements reconstruits en fonction du contenu du cache en utilisant le Frustum Culling (d). A gauche, le modèle de "Feline" est montré complet (a) et partiellement reconstruit (b). La reconstruction partielle est effectuée en fonction dup dv de l observateur, le serveur ne transmet que le maillage de base et les coefficients d ondelettes nécessaires pour effectuer cette reconstruction partielle. Dans le cas du maillage de terrain, le serveur élimine les informations situées hors du champ de vision (Frustum Culling) et transmet uniquement le maillage de base et les coefficients nécessaires pour reconstruire ce P dv. Dans les deux cas, grâce à l optimisation proposée dans [62] concernant le contenu du cache des clients, le serveur n a transmis aucune donnée redondante. Pour prendre en compte la latence du réseau, le serveur peut éventuellement effectuer une estimation de mouvement de façon à ce que le client ne reçoive à l instant t envoi + t latence 2 que les données correspondantes à son nouveau P dv. On note cependant que la synchronisation des caches reste un problème délicat surtout si l observateur se déplace rapidement. En effet, il est difficile de prévoir de manière fiable le mouvement de l observateur. De plus, la variabilité

49 La répartition des traitements de sélection des données et les différents modes d échange des données 47 de la latence du réseau observée sur Internet peut elle aussi poser problème Exemples d échanges en mode "pull" En mode "pull", le client effectue préalablement la plupart des traitements (ie. sélection des représentations et des NDDs et filtrage de visibilité). Pour ce faire, il doit disposer d informations lui permettant d effectuer ces traitements, celles-ci lui sont transmises par le serveur (éventuellement directement avec le code de l application). Après avoir reçu ces données spécifiques, il est en mesure de demander précisément les représentations et les raffinements dont il a besoin pour effectuer la visualisation. Le serveur, après réception des requêtes, n a plus qu à extraire les données et les envoyer. Dans ce cas précis, le nombre de clients qui peuvent être pris en charge par un serveur est plus important, le service peut être fourni à plus grande échelle car les clients prennent en charge plus de traitements. En revanche, les clients sont obligés de stocker dans leur mémoire, et ce de manière supplémentaire par rapport au mode "push", les données qui leur sont nécessaires pour effectuer ces différents traitements. Cependant, ces données sont en général de petites tailles. De nombreux travaux ont été effectué dans ce domaine, mais nous ne présenterons que les travaux de Marvie et al [63, 64] car ceux-ci nous semblent suffisamment représentatifs pour montrer les particularités de la distribution de contenus 3D en mode "pull". Fig. 2.4: A gauche : Exemple de bâtiments (en rouge) visibles depuis une cellule PVS (en vert). A droite : Exemple d objets qui sont visibles (les lampadaires) depuis plusieurs cellules PVS différentes (la cellule rouge et la cellule verte) [63, 64]. Dans la section 1.4, nous avons rapidement présenté la technique de filtrage de visibilité GP V (Groupes Potentiellement Visibles) qui est bien adaptée aux scènes urbaines en extérieur. Cette technique permet d effectuer une sélection des objets visibles en fonction de la position de l observateur dans la scène. Quand les GP V s sont utilisés en client-serveur, ils sont en général précalculés pour éviter de surcharger le serveur. La technique des GP V s peut indifféremment être utilisée en mode "push" et en mode "pull" mais nous ne nous intéresserons, dans cette sous-section, qu à son utilisation en mode "pull". Ainsi, après avoir été précalculées, on dispose pour chacune des cellules GP V s d une liste d objets potentiellement visibles. Certains objets peuvent être visibles depuis plusieurs cellules de vue. La figure 2.4 représente à gauche (en rouge) un groupe de bâtiments visibles depuis une cellule GP V et à droite des objets visibles (les lampadaires) depuis plusieurs cellules GP V s (cellules où se situent les lampadaires et cellules adjacentes).

50 48 Étude d un système de visualisation interactive en réseau Dans un premier temps il est important que la description des cellules GP V et des objets auxquels elles sont associées soit aussi compacte que possible. Bouville et al [65] ont proposé un schéma efficace de compression à deux niveau des GP V s. Marvie et al [63, 64] ont proposé quant à eux une technique permettant d éviter que des objets visibles depuis plusieurs cellules soit transmis plusieurs fois s ils ont déjà été stocké dans le cache du client (ie. le client ne redemande pas au serveur un objet qu il stocke déjà). Ils ont introduit un nouveau type de nœud dans V RML97 et dans X3D (le nœud "SharedInline"). Une fois que les GP V s sont générés et efficacement compressés le processus de visualisation en mode "pull" peut démarrer. La figure 2.5 montre l architecture réseau et les échanges de données entre le client et le serveur. Fig. 2.5: Architecture réseau fonctionnant en mode "pull". A l initialisation le client demande les données GP V qui lui permettent de demander uniquement les objets qui sont visibles compte-tenu de son P dv. Effectivement, le client détermine seul dans quelle cellule GP V il se trouve. En mode "pull", une phase d initialisation est nécessaire de façon à ce que le client dispose dans son cache de la topologie des cellules GP V et de l index des objets contenus. Après réception de ces informations, le client peut déterminer seul dans quelle cellule il se trouve et peut donc demander au serveur uniquement les objets dont il besoin pour la visualisation. Ensuite, le client peut éventuellement effectuer des opérations de filtrage de visibilité de façon à n afficher que les objets qui sont présents dans sa pyramide de vue. Si le client change de cellule, il peut demander au serveur soit : des données supplémentaires lui permettant de charger de nouvelles cellules plus lointaines. d autres objets qui lui manquent pour effectuer la visualisation compte-tenu de l évolution de son P dv. L exemple de l utilisation des GP V en client-serveur montre bien les particularités du mode "pull". Le client prend à sa charge une grande partie des traitements, ce qui permet d alléger la charge du serveur. Ainsi, en mode "pull", le serveur est uniquement un serveur de données. Ces traitements étant peu coûteux, ils peuvent être effectués sur des terminaux de faible capacité, comme des PDAs par exemple.

51 L adaptabilité aux ressources du terminal et du réseau L adaptabilité aux ressources du terminal et du réseau Nous avons vu dans les sections précédentes quelques modes d échanges des données de visualisation. Un enjeu essentiel, si l on souhaite proposer des applications de visualisation 3D interactive en réseau, est l adaptabilité aux ressources du terminal et du réseau. Effectivement, pour qu une application de visualisation en réseau puisse être considérée comme interactive, il faut qu elle puisse garantir au niveau du client une fréquence de rafraîchissement de l image supérieure à 15 et jusqu à 70 images par seconde suivant le type d application envisagé. Dans cette section, nous allons présenter quelques uns des travaux effectués dans ce domaine. Nous montrerons qu il est possible de faire de l adaptation soit du côté du serveur soit du côté du client Adaptation aux ressources effectuée côté serveur Une première solution possible est de faire de l adaptation aux ressources côté serveur si c est le serveur qui se charge de la sélection des représentations et des NDDs (et éventuellement du filtrage de visibilité). Le serveur s occupe, en fonction des capacités du terminal distant et de la bande passante disponible, de transmettre au client distant les représentations avec les N DDs les plus adéquats compte tenu de son P dv. Cette technique n est possible que si l application fonctionne en mode "push" (cf sous-section 2.2.1). Nous présenterons quelques uns de ces travaux dans cette sous-section. Une notion intéressante a été introduite par Martin [66, 67, 68, 69, 70, 71] qui a proposée une technique de transcodage. Le transcodage est la transformation qui est utilisée pour passer d une représentation vers une autre en fonction de certains paramètres (par exemple les capacités du terminal ou du réseau). Cette transformation est en général effectuée à la volée en fonction des besoins et des capacités du client distant. Un exemple classique consiste à générer à la volée un imposteur représentant tout ou partie d un modèle en fonction du P dv de l observateur. Effectivement, il est parfois plus intéressant d utiliser un imposteur si le terminal a de faibles capacités de rendu ou si le coût de transmission de la géométrie est très important (ie. cas d un modèle avec de très nombreuses facettes par exemple). La figure 2.6 montre un exemple de transcodage.

52 50 Étude d un système de visualisation interactive en réseau Fig. 2.6: Exemple de transcodage, le modèle visualisé (a) est composé d un imposteur généré à la volée (d) et de polygones (c). L imposteur permet de remplacer les éléments dont la projection de la boîte englobante est de moindre importance (b) de façon à limiter le nombre de polygones affichés [67]. En fonction de l importance de la projection de la boîte englobante des éléments constituant le modèle (b), un imposteur est généré pour une partie de ces éléments (d) de manière à limiter la quantité de géométrie qui doit être affichée selon le point de vue de l observateur (c). Le modèle visualisé est donc constitué d un imposteur et de différents polygones (a). Nous ne rentrerons pas dans le détail des heuristiques utilisées par Martin pour déterminer quels sont les éléments qui doivent être transcodés ou pas. Globalement, l objectif est de fournir au client la meilleure représentation possible compte tenu de son P dv, de son déplacement, des contraintes de bande passante, de ses capacités de rendu et de l importance visuelle des éléments qui constituent la scène. Fig. 2.7: Un exemple d adaptation de la qualité de visualisation d une même scène en fonction de la bande passante disponible. Plus la bande passante disponible est importante, plus la qualité du rendu est proche de l original [72]. La figure 2.7 présente quelques résultats des travaux de Teler et Lischinski [72] concernant le rendu adaptatif en réseau. Pour mettre en valeur l efficacité de leur méthode, la bande passante est contrainte entre le client et le serveur. De la même façon que Funkhouser (cf. sous-section 1.3.2), Teler et Lischinski cherchent à maximiser les bénéfices apportés par l ensemble des représentations qui vont être sélectionnées et transmises par le serveur tout en respectant les contraintes du réseau. Parmi toutes les représentations disponibles, la représentation choisie pour un modèle est celle qui, visuellement, apporte le plus de bénéfices en respectant les contraintes du réseau et en tenant compte du déplacement de l observateur (ie. le serveur doit pouvoir transmettre la représentation au client dans un temps imparti). L algorithme permet donc de transmettre au client la(les) représentation(s) qui aura(auront) la plus grande importance et la plus grande

53 L adaptabilité aux ressources du terminal et du réseau 51 durée de vie selon le déplacement courant de l observateur. Il est très intéressant d effectuer de l adaptation aux ressources du côté du serveur si l on souhaite fournir un service à des terminaux de faible capacité (terminaux mobiles par exemple). Par rapport à une architecture classique fonctionnant en mode "push", les deux architectures que l on vient de présenter permettent de garantir une qualité de visualisation optimale pour chacun des clients en tenant compte de ses capacités et des caractéristiques du réseau. Cependant, le problème de la synchronisation des caches reste compliqué (ie. il reste très difficile pour le serveur d estimer ce dont aura besoin le client au moment où il recevra les données). La quantité de traitements demandés au serveur avec ce type d architecture est considérable. C est pourquoi, généralement, cette architecture n est utilisée que si le nombre de client est réduit Adaptation aux ressources effectuée côté client Une autre solution est que le client s occupe seul de faire de l adaptation aux ressources. Dans ce cas, l application doit fonctionner en mode "pull" (cf sous-section 2.2.2). Le client s occupe seul de sélectionner les représentations et les NDDs adéquats et il choisit au mieux ceux qui respectent les contraintes qu il se fixe (budget de polygones, etc.). Nous présenterons dans cette sous-section un exemple d architecture où l adaptation aux ressources se fait du côté du client. Hesina et Schmalstieg [73] ont proposé une méthode permettant de faire de l adaptation aux ressources du côté du client. Dans cette proposition, ils ont utilisé des modèles avec des NDDs continus. La figure 2.8 présente un exemple de modèle représenté sous la forme de NDDs continus. Fig. 2.8: Exemple de modèle représenté sous la forme de NDDs continus [73]. L utilisation d un modèle avec des NDDs continus permet à Hésina et al [73] de résoudre de façon polynomiale le problème NP-Complet de Funkhouser (cf sous-section 1.3.2). Le bénéfice d un NDD étant non linéaire au nombre de polygones, le client détermine quels sont les modèles qui nécessitent le plus de raffinement(s) en respectant une contrainte en nombre de polygones qui permet de garantir une fréquence de rafraîchissement au dessus d un seuil critique. De la même façon que Funkhouser, Hesina et al [73] cherchent à maximiser le bénéfice apporté par chaque modèle sans dépasser un budget de polygones. Implicitement, cette maximisation permet d ordonner les requêtes pour obtenir des N DDs supplémentaires de façon à raffiner en priorité

54 52 Étude d un système de visualisation interactive en réseau les modèles les plus importants. L ordonnancement des requêtes, et donc l ordonnancement des NDDs transmis en réponse par le serveur (ie. du moins détaillé au plus détaillé), permet à l adaptation de se faire "au mieux". Si, à cause des contraintes du réseau, certains N DDs requis ne sont pas transmis, on considère que ceux reçus à l instant t sont ceux qui pouvaient être transmis compte tenu de la bande passante disponible. Comme on l a expliqué dans la sous-section 2.2.2, l utilisation du mode "pull" permet au serveur de fournir un service à plus grande échelle. Le nombre de clients qui peuvent être servis dépend uniquement de la bande passante dont le serveur dispose. Ce type d architecture implique que les clients disposent de ressources suffisantes pour effectuer les opérations de décodage/reconstruction qui sont nécessaires, les autres opérations (sélection des représentations, sélection des N DDs et filtrage de visibilité) étant, quant à elles, très peu coûteuses. C est pourquoi l adaptation aux ressources du côté du client ne s adresse qu à des terminaux ayant des capacités suffisantes, car ce traitement se rajoutera aux autres et mettra d autant plus à contribution le processeur central du terminal de visualisation. 2.4 L optimisation des échanges de données Si l on souhaite mettre en place une application de visualisation 3D en réseau, il est nécessaire d utiliser un protocole de communication adapté. Les protocoles sont organisés en couches selon le modèle OSI (Open System Interconnection). Nous nous intéressons à celles qui sont les plus significatives pour permettre la mise en place d applications de visualisation 3D interactive en réseau : la couche dite "de transport". Les protocoles de transports sont des protocoles dits de "bas niveau" qui prennent en charge le transport des données d un point à un autre du réseau. la couche dite "applicative". Les protocoles applicatifs sont des protocoles dits de "haut niveau" qui sont liés aux applications dont ils dépendent. Pour transporter les données, les protocoles applicatifs utilisent les protocoles de transport. La figure 2.9 présente l architecture en couche de ces différents protocoles. Sur cette figure, on présente un certain nombre de protocoles que nous décrirons plus en détail par la suite. Fig. 2.9: Architecture en couche avec au dessus les protocoles dits "applicatifs" et en bas les protocoles dits "de transport" (d après [22]. Tous les protocoles de transport reposent soit sur IP [74] (Internet Protocol), soit sur IP X (Internetwork Packet exchange). IP X est un protocole de gestion de réseau conçu par Novell

55 L optimisation des échanges de données 53 [75]. Il relie l ensemble des réseaux qui utilisent les clients et les serveurs NetWare de Novell. La gestion des paquets, l ordonnancement et la vérification d erreurs sont contrôlés par un autre protocole de Novell ; le protocole SP X (Sequenced Packet exchange). Le protocole IP X est actuellement très peu utilisé, c est pourquoi nous l écartons du champ d étude de cette thèse. Contrairement à IP X, le protocole IP est universellement utilisé sur Internet et dans la plupart des réseaux locaux. Ce protocole a été adopté officiellement en 1982 par la défense américaine pour le réseau ARPANET et a ensuite été distribué gratuitement. Chaque ordinateur relié à Internet possède une adresse IP unique qui l identifie par rapport au reste du réseau. Quand des données sont transmises, elles sont découpées en plusieurs morceaux, appelés paquets. Au cours de leurs routes, les données peuvent traverser différents réseaux physiques dont les paquets n ont pas nécessairement la même taille maximale. Par exemple, les réseaux Ethernet ont un M T U (Maximum Transfert Unit) de 1500 octets. Chaque paquet est transmis indépendamment à travers le réseau et peut prendre une route différente des autres paquets. IP est un protocole sans connexion, l ordre des paquets n est pas préservé et il se peut que certains paquets n arrivent jamais à destination. Trois modes de transmission des données sont possibles : l Unicast, la transmission se fait d un terminal à un autre. le Multicast, la transmission se fait d un terminal à un ensemble d autres terminaux. Pour ce faire, les données sont envoyées à une adresse spéciale représentant le groupe. Un terminal peut se joindre à tout moment au groupe et recevoir les messages. le Broadcast, la transmission se fait d un terminal à tous les autres terminaux se trouvant sur le même réseau local. La version actuelle du protocole IP est IP v4. Une nouvelle version (IP v6) commence à être utilisée, elle permet l utilisation d adresses plus longues afin de pallier le manque d adresses IP v4 disponibles actuellement. La version IP v6 est entièrement compatible avec IP v4 et propose une gestion de la qualité du service pour le transport de données sur réseau (QoS : Quality of Service). Basés sur le protocole IP, on distingue deux protocoles très utilisés : le protocole T CP [76] (Transmisson Control Protocol) et le protocole U DP [77] (User Datagram Protocol). Le protocole T CP est le plus utilisé sur le réseau car il permet une transmission fiable et ordonnée des données. Ce protocole fonctionne en mode connecté et peut être utilisé en Unicast ou en Multicast. Contrairement à T CP, le protocole UDP est un protocole non fiable et il ne permet aucun ordonnancement des paquets. En revanche, du fait du peu de traitements effectués sur les paquets, le protocole UDP permet une transmission plus rapide des données. Effectivement, si les données transmises sont d une taille inférieure au M T U, aucune reconstruction de paquets n est nécessaire. Comme pour T CP, le protocole UDP peut être utilisé en Unicast ou en Multicast. Tous les protocoles actuels qui permettent la visualisation de scènes 3D reposent sur T CP et(ou) UDP. Certains protocoles comme F T P (File Transfer Protocol), HT T P (Hyper Text Transfer Protocol) et RT P [78] (Real Time Protocol) sont des protocoles classiques utilisés pour le transfert des données multimédia. Ils peuvent aussi être utilisés dans d autres types d applications. F T P permet le transfert de fichiers, HT T P est le protocole le plus répandu sur Internet et est compatible avec tous les navigateurs Internet et, enfin, RT P est conçu pour le transfert de données en temps réel (ie. flux audio par exemple). D autres protocoles comme OGP [79] (On-demand Graphical Protocol) et 3T P [80] (3D Transport Protocol) ont été conçus pour le transport de modèles 3D. Ils proposent d utiliser T CP et UDP de manière optimale en fonction du type de données échangées et des caractéristiques de ces deux protocoles (cf figure 2.10) :

56 54 Étude d un système de visualisation interactive en réseau le protocole T CP est fiable à 100% et permet une transmission ordonnée des données. En conséquence, la transmission des données prend plus de temps qu avec U DP. le protocole UDP est non-fiable et ne permet pas de transmettre des données de façon ordonnée. En conséquence, la transmission des données prend moins de temps qu avec T CP. Fig. 2.10: Les caractéristiques de T CP sont la fiabilité et l ordonnancement pour le transport des données, contrairement à U DP qui ne permet que le transport. Cette figure montre comment en modifiant U DP ou en utilisant parcimonieusement les deux protocoles, on peut arriver à une solution intermédiaire entre T CP et UDP [80]. Effectivement, parmi les données échangées, certaines sont indispensables et d autres non, il est donc envisageable d en "perdre" une partie et d utiliser ainsi le protocole U DP comme support de l échange de certaines données moins importantes (ou avec une durée de vie très courte). Deux stratégies différentes ont été proposées : OGP utilise le protocole U DP comme support de l échange de données. La plupart des mécanismes de T CP sont réimplémentés dans ce protocole (slow-start, retransmission rapide, détection de congestion, etc.). Cependant, OGP ne garantit pas une transmission ordonnée des données, ce qui permet un gain en performance. Effectivement, les données géométriques transmises étant de petite taille, il n est pas nécessaire de les découper pour pouvoir les transmettre. Chaque paquet IP peut être exploité indépendamment et OGP garantit un remplissage optimal de chacun d eux. 3T P utilise les protocoles T CP et UDP comme support de l échange de données. 3T P cherche à minimiser le temps de transmission des données en répartissant au mieux les données qui doivent être transmises entre ces deux protocoles. Effectivement, s il y a des pertes de paquets, l utilisation de U DP augmente la distorsion. En revanche, l utilisation de T CP n engendre pas de distorsion mais les temps de transmission sont plus longs. Plus précisément, dans 3T P le maillage de base est transmis systématiquement avec T CP et la transmission des raffinements est répartie entre T CP et UDP en tenant compte du taux de perte. L utilisation de protocoles spécifiques autorise un gain important lors de la transmission de modèles 3D, en particulier pour les représentations progressives. Par exemple, il est souhaitable de transmettre de manière plus fiable les informations de connectivité qui sont plus importantes que

57 Conclusion 55 la géométrie. De même, la plupart du temps il n est pas nécessaire de transmettre les raffinements dans un ordre particulier car ils peuvent souvent être appliqués directement (cas des ondelettes géométriques par exemple). Le choix du(des) protocole(s) de transport utilisé est directement lié à la méthode utilisée pour mettre à jour la représentation et à la nature des données qui sont échangées sur le réseau. 2.5 Conclusion Nous avons présenté dans ce chapitre, dans le cadre d une architecture client-serveur classique, les différentes stratégies d échange de données qui peuvent être envisagées entre le serveur et ses clients pour transmettre des scènes statiques. Les stratégies d échange des données découlent de la répartition de certains traitements entre le client et le serveur. Si l on souhaite mettre en place un système de visualisation interactive en réseau, la seule contrainte concerne les données qui doivent être stockées sur le serveur. En fonction de l application mise en place, les traitements nécessaires à la visualisation peuvent être effectués côté serveur ou côté client. Le tableau 2.1 présente ces différents traitements ainsi que l endroit ou ils peuvent être effectués si l on se place dans un contexte de streaming adaptatif des données. Traitements à effectuer Sur le serveur Sur le client Rendu X X Extration des données X - Envoi des données X - Encodage des données X - Gestion des flux X X Désenpaquetage - X Décodage - X Reconstruction X X Sélection des représentations X X Sélection des N DDs X X Filtrage de visibilité X X Adaptation aux ressources X X Tab. 2.1: Traitements nécessaires à un système de visualisation interactive en réseau. Les traitements spécifiques au mode "push" (cf 2.2.1) sont mis en valeur en bleu et les traitements spécifiques au mode "pull" (cf 2.2.2) sont mis en valeur en rouge. Suivant le type de terminaux cibles, on privilégiera l un ou l autre des modes de transmission ("push" ou "pull") pour mettre en place une application de visualisation interactive en réseau. Si les terminaux cibles ont de faibles capacités (terminaux mobiles par exemple) on privilégie l utilisation du mode "push" (cf sous-section 2.2.1) car, dans ce cas, c est le serveur qui prend à sa charge la plupart des traitements, ce qui décharge au maximum les clients de visualisation. Cependant, on note qu en mode "push" le problème de la synchronisation des caches reste un problème difficile à résoudre. Si le serveur ne sait pas ce que le client a dans son cache il risque d effectuer des transmissions redondantes. Si le serveur a une connaissance du contenu du cache du client, il est très difficile d envoyer les données

58 56 Étude d un système de visualisation interactive en réseau nécessaires au client "juste à temps" à cause de la latence du réseau et du déplacement de l observateur. De façon additionnelle, ce mode de transmission ne permet pas de fournir un service à grande échelle (sauf en rajoutant des serveurs) à cause de la quantité de traitements coûteux que le serveur doit prendre en charge. Si les terminaux cibles ont des capacités suffisantes (terminaux fixes par exemple) on privilégie l utilisation du mode "pull" (cf sous-section 2.2.2) car dans ce cas les clients prennent à leur charge la plus grande partie des traitements, ce qui permet au serveur d être déchargé de ceux-ci. Le serveur n a plus qu un rôle de serveur de données et sa capacité de service est limitée uniquement par la bande passante dont il dispose. Il est ainsi possible de fournir un service à plus grande échelle. Avec ce mode de transmission, il n y a aucun problème de synchronisation de cache car c est le client qui détermine ce dont il a besoin en fonction de son point de vue et de son déplacement. Etant donné l évolution actuelle des capacités des différents types de terminaux disponibles (ie. apparition de cartes graphique dans les portables, augmentation considérable de la mémoire de masse et de la mémoire vive, etc.) on considère que d ici peu la plupart d entre eux auront les capacités suffisantes pour prendre en charge l ensemble des traitements de sélection des représentations et des NDDs, de filtrage de visibilité, et d adaptation aux ressources. Dans le cadre de cette thèse, nous privilégions donc le mode "pull" qui permet avec le même serveur de fournir un service à plus grande échelle que si on utilise le mode "push". De plus, les coûts de mise en place et de maintenance des serveurs sont moins importants si on utilise une application fonctionnant en mode "pull". On note qu il n est cependant pas envisageable d écarter complètement le mode "push", car avec ce mode de transmission il est possible de mettre en place des applications de visualisation interactive avec des terminaux de très faible capacité. Dans ce chapitre nous avons montré l importance de l utilisation du réseau pour résoudre les problèmes de stockage de la base de données dans les terminaux de visualisation. Avec les méthodes que nous avons présentées, les terminaux clients stockent dans leur mémoire de masse uniquement les données qui leur sont nécessaire pour effectuer la visualisation. La centralisation de la base de données de visualisation sur le serveur permet une gestion plus facile des droits d accès et des mises à jour. Les mises à jour peuvent être effectuées directement au niveau du serveur sans impact visible pour les utilisateurs. Les droits d accès peuvent eux aussi être gérés directement au niveau du serveur ce qui en facilite la gestion. L utilisation des N DDs incrémentaux ou(et) des techniques procédurales permet d adapter la qualité de visualisation en fonction des ressources du matériel de visualisation. Ainsi, il est possible de garantir une visualisation interactive avec n importe quel matériel de visualisation. Dans le chapitre suivant, nous allons présenter quelques uns des travaux qui ont été effectués concernant la mise en place d environnements virtuels (EV ). Une contrainte que nous nous sommes fixés est la mise en place d un environnement virtuel scalable (ie. en nombre d utilisateur et en complexité de l EV ). Les travaux présentés par la suite concernent en particulier la gestion des mises à jours et des interactions dans l EV. Nous montrerons que ceux-ci donnent de nombreuses solutions pour répondre à ces deux contraintes, mais très peu de ces travaux abordent le problème crucial de l échange des données de visualisation.

59 3. Les architectures pour environnements virtuels distribués 3.1 Introduction Les premiers systèmes distribués visant à simuler une réalité virtuelle massivement partagée sont issus de la Naval Postgraduate School of Monterey (N P S) [81, 82]. Un Environnement Virtuel (EV ) est caractérisé par différents éléments essentiels. Un environnement qui peut être statique (ie. qui ne peut être modifié) ou dynamique (ie. l utilisateur peut agir sur l environnement et le modifier). Des avatars (ie. représentation des utilisateurs dans l EV ) ou des robots (ie. personnages se déplaçant dans l EV et ayant un rôle particulier). Des objets mobiles qui sont des représentations avec des caractéristiques propres (ie. par exemple véhicule se déplaçant au sol ou dans l air, etc.). Des interactions utilisateurs qui peuvent produire une modification de l EV (déplacement d objets, lancement d une animation, etc.). Par exemple, le projet SIMNET qui a été développé à la NP S dans les années 1980 est un système d entraînement militaire. Il permet d apprendre à s organiser et à simuler des situations de combat grâce à un environnement virtuel constitué de petites unités identiques. Ce projet a conduit au développement du protocole DIS [83, 84], ainsi qu un ensemble de normes définissant, entre autre, un format d échange de données ainsi qu un certain nombre d entités et leurs interactions. Le protocole DIS a ensuite servi de support à la plateforme NP SNet [85, 86]. Il est particulièrement adapté à la mise à jour de l EV et des éléments qui le composent comme d autres protocoles dévellopés par la suite : DW T P [87] et V RT P [88] par exemple. De nombreux travaux ont été effectué ensuite pour permettre d autres types d applications. Actuellement, les EV s connaissent un réel engouement dont l exemple le plus probant est Second Life [2]. Le nombre d utilisateurs de Second Life est ainsi passé de inscrits à plus de 3 millions en moins d un an et génère actuellement environ $ de bénéfices par mois pour son éditeur (Linden Lab). La figure 3.1 présente des exemples des différents éléments caractéristiques d un EV (l environnement, les avatars, les interactions utilisateurs et les objets mobiles). Ces copies d écran sont extraites de Second Life. Dans ce chapitre, nous présenterons les architectures d EV les plus significatives en mettant en valeur leurs particularités. Ainsi, des solutions intéressantes ont été proposées pour répondre aux problèmes de répartition des données de visualisation. Plusieurs stratégies d échange des mises à jour ont été mises en place pour améliorer les performances. La première section de ce chapitre présentera la répartition des données de visualisation. La deuxième section présentera quelques stratégies pour diminuer la quantité de données échangées entre les différents terminaux, en particulier les données de mise à jour de l EV. Deux approches ont été proposées qui sont le découpage du monde et le filtrage des messages. Enfin, dans la

60 58 Les architectures pour environnements virtuels distribués Environnement Avatars Objets mobiles Interactions Fig. 3.1: Les différents éléments caractéristiques d un EV (l environnement, les avatars, les interactions utilisateurs et les objets mobiles) extraits de Second Life [2]. dernière section, nous présenterons quelques éléments permettant d évaluer les performances de ces différents EV s, ce qui nous permet de conclure en mettant en valeur leurs limitations. Nous montrerons ainsi qu il apparaît qu aucune des solutions proposées ne permet pour l instant d envisager la mise en place d un EV réellement scalable (ie. en nombre d utilisateur et en complexité de l EV ), ce qui est l objectif que nous nous sommes fixés. 3.2 La structuration de la base de donnée de l EV La structure du monde définit comment les objets et les avatars y sont distribués. Deux aspects importants peuvent être pris en compte, à savoir : La façon dont est stockée la base de données de visualisation. Elle peut être stockée localement, distribuées dans plusieurs terminaux, ou stockée sur un serveur central. La façon dont les objets sont partagés entre les utilisateurs. Effectivement, certains objets peuvent être privés et donc éventuellement disponibles seulement pour un petit groupe d utilisateurs (accès restreints).

61 La structuration de la base de donnée de l EV 59 La plupart des EV s utilisent une stratégie de réplication de la base de données. Tous les terminaux disposent alors en local de l ensemble de la base de données de visualisation [81, 89, 90, 91, 92]. Les techniques mises en place au sein de ces architectures concernent principalement la gestion de l échange des messages de mise à jour de l EV et le maintien de sa cohérence, ce que nous allons présenter plus en détail dans la section suivante. RING [93] est la première architecture exploitant la gestion dynamique de scène en client-serveur à travers un réseau. Chaque utilisateur ne charge dans son cache que les données de visualisation concernant la région dans laquelle il se trouve. Si l utilisateur change de région, il charge les nouvelles données correspondant à cette région appelée zone d intérêt. Les techniques utilisées pour le chargement des données sont les mêmes (chargement anticipé, gestion mémoire évoluée) que dans la version locale [94, 95]. La figure 3.2 présente quelques uns des éléments de l architecture RIN G. Fig. 3.2: Les éléments de l architecture RIN G [93]. A gauche : Le backbone de serveurs de l architecture RING. Chaque serveur dispose de toute la base de données de visualisation et les clients se connectent au serveur qui est géographiquement le plus proche. Au milieu et à droite : les informations de visibilité GP V (d objet à region) permettent de limiter les échanges de données de mises à jour entre les serveurs. Des messages ne sont échangés qu entre les utilisateurs qui se "voient". L architecture RIN G est constitué d un backbone de serveurs reliés entre eux en pairs à pairs. Chaque serveur dispose de toute la base de données de visualisation. Les clients peuvent demander au serveur auquel ils sont connectés les données nécessaires à leur visualisation comptetenu de la région dans laquelle ils se trouvent. Les données permettant la mise à jour de l EV sont transmises à travers le backbone de serveur en tenant compte des informations de visibilité (les GP V s que nous avons présentés dans la section 1.4). Si la stratégie de réplication de la base de données est utilisée, on remarque que l on se trouve dans le même cas que celui que l on a présenté dans les chapitres précédents. Le stockage de la base de données dans le terminal de visualisation peut engendrer quelques difficultés : La mémoire de masse du terminal peut être d une taille insuffisante pour stocker l ensemble de la base de données de visualisation. Si le terminal de visualisation dispose de suffisamment de mémoire de masse, l utilisateur peut souhaiter qu elle ne serve pas uniquement au stockage de la base de données. Le stockage de la base de données dans le terminal de visualisation peut poser des difficultés de mises à jour et de contrôle d accès. La solution la plus prometteuse est donc celle proposée dans RING avec un chargement progressif des données de visualisation en fonction de la cellule dans laquelle se trouve l observateur. Seulement, cela suppose que le(s) serveur(s) disposent de suffisamment de mémoire de masse pour

62 60 Les architectures pour environnements virtuels distribués stocker la base de données, ce qui n est pas forcément évident si celle-ci est de très grande taille. Un autre problème que nous évoquerons plus en détail dans la section 3.4 est qu une architecture plus ou moins centralisée peut poser des difficultés de dimensionnement. Effectivement, le(les) serveur(s) ont une capacité de service limitée. Si le nombre d utilisateurs dépasse cette capacité de service, il est nécessaire de rajouter un(des) serveur(s) pour répondre à cette demande. Cela pose le problème de la scalabilité réelle de ce type d architectures en tenant compte du fait que la visualisation interactive demande des ressources importantes. Nous présenterons dans le chapitre 4 ce que nous considérons comme une solution pour qu un EV soit réellement scalable. 3.3 Le maintien de la cohérence de l EV Un élément incontournable dans la mise en place d un EV est le maintien de la cohérence du monde. Effectivement, il est impératif qu une mise à jour d objet ou un déplacement d avatar soit répercuté sur l ensemble des terminaux de visualisation le plus rapidement possible. Les premières architectures utilisaient le multicast (cf section 2.4) pour mettre à jour l ensemble des terminaux distants. Dans SIM N ET, tous les utilisateurs disposent de la base de donnée complète et le multicast est utilisé pour maintenir la cohérence chez tous les autres participants. Tous les participants font partie du même groupe multicast. Dans ce cas, le nombre de messages échangés croît avec le nombre d utilisateurs en obligeant tous les terminaux à traiter tous les évènements qui surviennent dans l EV. Cette approche n est pas scalable car les terminaux risquent d être saturés si le nombre de participants est très important. Pour s abstraire de cette limitation, deux approches ont été proposées : Le partitionnement de l EV et le filtrage des messages. Nous les décrirons dans les sous-sections suivantes Les techniques de partitionnement La mise au point de l environnement NPSNet-IV [81] fut une avancée significative pour la création de mondes partagés par un très grand nombre d utilisateurs. Il incorpore le protocole DIS mais également une communication par IP Multicast [96]. Le protocole IP Multicast permet de définir un grand nombre de groupes de communication. Les groupes sont dynamiques : une entité peut rejoindre et quitter un nombre quelconque de groupes à la demande. En outre, on peut observer une distinction entre les entités qui sont : passives, elles reçoivent tous les messages de ce groupe mais ne peuvent pas en envoyer. actives, la réception et l émission de messages sont possibles. L idée de NPSNet-IV consiste à découper statiquement le monde virtuel en cellules hexagonales. Un groupe de communication est associé à chaque cellule. Une entité est active dans la cellule dans laquelle elle se situe et passive dans les six cellules adjacentes. La figure 3.3 présente le partitionnement en cellules hexagonales dans NPSNet-IV. Chaque cellule est un monde virtuel plus petit dans lequel le nombre d entités en interaction est réduit. En conséquence, le nombre d événements virtuels et donc le nombre de messages à traiter diminuent. Au gré de ses déplacements, une entité peut franchir la frontière séparant deux cellules adjacentes. Or, elle ne dispose pas des informations lui permettant de se joindre aux groupes associés à ses nouvelles cellules adjacentes. Deux solutions sont avancées pour résoudre ce problème :

63 Le maintien de la cohérence de l EV 61 Fig. 3.3: Partitionnement en cellules hexagonales dans NPSNet-IV [81], l entité noire émet des messages pour le groupe multicast de la cellule en gris foncé et reçoit des messages des entités situées dans les cellules grises claires. Elle ne reçoit pas de messages des autres entités. La plus simple se base sur une communication de type client-serveur. Quand une entité passe d une cellule à une autre, elle interroge un serveur qui lui offre les informations lui permettant de joindre ces groupes. La deuxième solution consiste à nommer un responsable à chaque cellule qui va disposer d informations supplémentaires à propos des cellules adjacentes à la sienne. Par défaut, le responsable est l entité la plus ancienne de la cellule. Deux centres de recherche ont, simultanément, enrichi le principe du découpage du monde virtuel et de l attribution d un groupe multipoint à chaque cellule. Le M ERL (Mitsubishi Electric Research Laboratory) a élaboré une plate-forme logicielle, nommée Spline, qui permet de développer des applications de réalité virtuelle [90, 91]. Les cellules sont caractérisées par des dimensions, un groupe multicast et éventuellement une cellule englobante vue comme un supérieur hiérarchique. Les auteurs proposent d ajuster les dimensions des cellules aux éléments du décor virtuel. Une pièce d un immeuble est une cellule contenue dans un étage qui est, également, une cellule, dont le supérieur hiérarchique est l immeuble, une autre cellule. Le Swedish Institute of Computer Science a rendu encore plus générique cette démarche avec DIV E [89]. Le monde virtuel est une base de données possédant une organisation hiérarchique correspondant au graphe de scène. Des groupes multicast sont associés à certains nœuds de l arbre. Tous les éléments dépendants de ce nœud doivent communiquer au sein de ce groupe. L organisation proposée autorise la duplication de certains sous-arbres : un groupe multicast peut être englobé par plusieurs groupes multicast indépendants. La figure 3.4 présente un exemple avec plusieurs groupes multicast dont certains sont englobés par d autres groupes multicast indépendants. Plus récemment, l Université de Nice a proposé Score, une architecture de communication basée sur un découpage dynamique du monde virtuel [97]. Des serveurs peuvent modifier les dimensions des cellules en fonction de paramètres variés tels que le nombre maximal de groupes de communication disponibles, la vélocité des entités ou encore la densité ou la répartition des entités dans le monde.

64 62 Les architectures pour environnements virtuels distribués Fig. 3.4: Dans DIV E [89], des groupes multicast sont associés à certains nœuds du graphe de scène (G 1,G 2,...,G n ). Tous les éléments dépendants de ce nœud doivent communiquer au sein de ces groupes. L organisation proposée autorise la duplication de certains sous-arbres (nœud G 4 par exemple). Un groupe multicast peut être englobé par plusieurs groupes multicast indépendants (à droite par exemple, G 4 est englobé par G 1 et G 2 ) Le filtrage des échanges de messages On distingue deux types de stratégie de filtrage des échanges de messages : l approche basée sur la perception et l approche basée sur l intérêt. Nous présenterons dans la suite ces deux approches L approche basée sur la perception L Université de Nottingham a été à l initiative d une nouvelle approche visant à réduire le flot d informations entre les entités. Leur système de réalité virtuelle, nommé Massive, a connu trois évolutions majeures. L aspect innovant de Massive-1 [98] concerne la gestion du voisinage basé sur la perception des entités [99]. Plusieurs notions issues de l observation du monde réel ont été définies. L aura d une entité est un sous-espace du monde virtuel précisant les limites de la "présence" d un objet et facilitant les interactions potentielles. Quand les auras de deux objets se chevauchent (même partiellement), le système doit faire entrer en contact ces deux objets. Cette relation leur permet de s informer des événements virtuels qu ils peuvent produire. Une aura peut avoir n importe quelle taille et n est pas forcément située autour de son entité. Le focus qui est assimilé à la zone observée par une entité. Ainsi, l attention d une entité se porte sur une région précise du monde virtuel, le focus. Le nimbus peut être considéré comme le sous-espace dans lequel une entité attire l attention sur elle. Plus une entité est située dans le nimbus d un objet virtuel, plus elle est intéressée par celui-ci. Par exemple, le nimbus d un écran de télévision est situé en face de celui-ci. Ces notions permettent de quantifier précisément l intérêt d une entité envers une autre. Il dépend de leur focus et de leur nimbus et n est pas forcément symétrique, comme l illustre la

65 Le maintien de la cohérence de l EV 63 figure 3.5. Dans la situation de gauche, l entité A oriente son focus vers B tandis que le nimbus de B contient A. Il en résulte que A est intéressé par B. Dans la situation au centre, A ne porte pas son attention sur B mais B essaye d attirer l attention de A. L entité B tente sans doute d interrompre A mais celle-ci ne l a pas encore remarquée. Enfin, dans la situation de droite, B est dans le focus de A mais le nimbus de B ne contient pas A. Peut-être que A espionne B? A B A B B A Fig. 3.5: Exemple de calcul d intérêt en utilisant les notions de focus et de nimbus [99]. L intérêt est une mesure qui permet de quantifier la motivation pour récupérer des informations concernant un certain objet. Les auteurs proposent de différencier les calculs d intérêts en fonction du média utilisé (textuel, audio, vidéo, etc.). Par exemple, dans le projet Continuum de France Telecom R&D [100], chaque participant gère des copies de son entité situées sur les terminaux des entités dont la zone de perception intersecte sa zone d influence. Les participants possèdent donc un espace de simulation peuplé de représentations locales de ses voisins. Un système de communication multicast permet aux copies d une entité d être informées des transformations survenues sur celles-ci. Le caractère le plus innovant de Massive-2 [101] est appelé "Third Party Object" [102] : certaines entités ont la capacité de modifier l intérêt entre deux autres entités. Ainsi, un objet "fenêtre" peut atténuer le niveau d intérêt sonore entre deux entités. C est également à partir de cette plate-forme que l IP Multicast est utilisé : chaque objet est le seul actif (ie. il peut émettre et recevoir des messages) dans son groupe de communication, les entités dont les auras chevauchent la sienne sont passives (ie. elles reçoivent les messages) dans ce groupe. Massive-3 [92] est la plate-forme pour environnements virtuels partagés la plus aboutie. Elle permet, entre autre, de réaliser un découpage spatial hiérarchisé tout en conservant le chevauchement d auras pour la mise en relation. Malheureusement, elle dévoile également les difficultés auxquelles restent confrontés ces systèmes. Tout d abord, ils se heurtent au faible déploiement du multicast sur Internet. Ce type de communication requiert la participation des routeurs, qui, en majorité, n ont pas adopté les différents protocoles qui ont pu être proposés par la communauté scientifique. Ensuite, ils nécessitent toujours la présence d un ou plusieurs serveurs légers pour le maintien des relations. Le découpage du monde nécessite une base de données associant chaque groupe multicast à une cellule tandis qu un serveur est responsable de la détection du chevauchement des auras. Au-delà du problème de dimensionnement que ces serveurs entraînent, il est important de noter que leur présence ne permet pas de garantir la persistance du monde et la liberté des participants. Notre choix de permettre à n importe quel terminal connecté à Internet de participer au monde virtuel nous conduit à exclure ce type d architecture.

66 64 Les architectures pour environnements virtuels distribués L approche basée sur l intérêt Le récent engouement pour les jeux en réseau a relancé les recherches autour des mondes virtuels massivement partagés. Parmi les nombreuses offres commerciales, quelques systèmes [103, 104, 105, 106] n utilisent pas de serveurs centraux. La diffusion des événements est assurée par un mécanisme de publication/abonnement. Une entité participant au monde virtuel possède des centres d intérêt. Elle souhaite être informée de tout événement relatif à cet intérêt. Un événement est publié par une entité lorsqu elle décide de le rendre public auprès d autres entités du monde virtuel. Chaque entité est amenée à publier les événements qui la concernent (déplacements, actions, etc.) et à notifier ses intérêts. Des mécanismes garantissent que tous les événements ayant rapport à un intérêt identifié par une entité sont effectivement reçus par cette entité. Dans [103], les auteurs proposent que les événements soient associés à la position de l entité émettrice dans l EV tandis que les intérêts correspondent à une zone du monde, typiquement la zone située autour de l entité. Ainsi, une entité située à la position (x = 100, y = 200) s abonne à l ensemble des événements contenant une position (x, y ) telle que 50 x 150 et 150 y 250. La figure 3.6 présente cet exemple. Fig. 3.6: Une entité située à la position (x = 100, y = 200) s abonne à l ensemble des événements contenant une position (x, y ) telle que 50 x 150 et 150 y 250 [103]. La difficulté réside dans le déploiement du mécanisme assurant la transmission des messages en rapport avec l intérêt annoncé. Ce mécanisme repose sur la collaboration des entités participantes. Chaque entité est responsable d une collection d intérêts. Elle gère les abonnements et la diffusion des événements portant sur ces intérêts. Une entité notifiant son intérêt a doit informer au moins un responsable de l intérêt a. Tous les événements sont également envoyés à ce responsable qui est chargé de transmettre cet événement à toutes les entités abonnées. La découverte d une entité responsable d un intérêt et la diffusion des événements sont facilitées par une organisation en anneau présentée dans la figure 3.7. Les systèmes Gryphon [107, 106] et Siena [105] utilisent la technique de l inondation (ie. envoi de nombreux messages qui sont transmis de proche en proche jusqu aux entités concernées) pour réaliser ces tâches. Dans de tels systèmes, il existe toujours un intermédiaire entre une entité désirant annoncer un événement et les entités intéressées par cet événement. Le passage par cet intermédiaire ralentit forcément la diffusion du message. De plus, les risques de défaillance de cet

67 Le maintien de la cohérence de l EV 65 Fig. 3.7: La notification d intérêt [103] doit être transmise au moins à l un des groupes d intérêt H a. Dans ce cas le groupe H x est mis à contribution et les entités b et c qui y sont abonnées retiennent cet intérêt. Si aucune des entités du groupe H x n avaient retenu cet intérêt le groupe H y aurait été mis à contribution. intermédiaire rendent aléatoire la capacité d une entité à diffuser un événement. Il apparaît en conclusion que la solution idéale n a pas encore été montrée. Tout d abord, la communication par groupes multicast n offre, pour l instant, pas les garanties nécessaires à un large déploiement. Ensuite, l utilisation de serveurs allégés pour mettre en relation les entités en fonction de l intérêt qu elles se portent rend le système fragile, tout en contraignant la liberté individuelle des participants La gestion des arrivées et des interactions D autres éléments importants comme la gestion des arrivées dans l EV et la gestion des collisions doivent être pris en compte. Effectivement, un utilisateur qui arrive dans l EV a rapidement besoin de connaître l état courant de l EV (position des objets, des utilisateurs connectés, etc.). Il se pose donc la question de savoir quelle entité va prendre à sa charge d informer le nouvel arrivant. Plusieurs stratégies ont été proposées : Dans NPSNet [81], l entité choisie est celle qui contient l objet le plus ancien dans sa zone d intérêt. Cette entité sera toujours celle sollicitée, et ce jusqu à ce qu elle se déconnecte. Les autres systèmes utilisent un serveur ou une base de données dédiée. Ce qui permet d éviter qu une entité soit surchargée à cause de l arrivée d autres entités. On note que ces travaux sont peu aboutis car personne ne s est encore vraiment intéressé au problème de la scalabilité. Cette question reste ouverte et dépend du type d architecture qui sera proposée. Concernant la gestion des collisions entre les entités et les éléments qui consituent l EV : soit la gestion des collisions est effectuée par un processus central [89, 93, 99]. soit chaque entité effectue ses calculs de collision [81]. Si on utilise un processus dédié (entité ou serveur dédié), il est difficile d envisager une réelle scalabilité, car sa charge augmente avec le nombre d entités qui sont connectées.

68 66 Les architectures pour environnements virtuels distribués 3.4 Quelques critères d évaluation des performances d un EV Comme l architecture de chaque EV est différente, on peut supposer que les performances qui en résultent sont elles aussi différentes. Dans cette section nous allons donner quelques clefs permettant d évaluer ces performances, à savoir : l adaptabilité des contenus de l EV. Si l on considère l aspect visualisation, l adaptabilité des contenus est la capacité de la scène constituant l EV a être rendue en tenant compte des ressources du terminal de visualisation. la scalabilité de l EV. Si l on considère l aspect réseau, la scalabilité est la capacité de passage à l échelle de l architecture réseau support de l EV. Une architecture réseau est considérée comme réellement scalable si le service peut être fourni à un nombre illimité d utilisateurs. la capacité de coopération correspond à la capacité d un EV à prendre en charge des terminaux de très faible capacité. Effectivement, certains terminaux de faible capacité doivent être pris en charge et épaulés pour qu ils puissent visualiser l EV La scalabilité La scalabilité est un problème récurrent si l on souhaite permettre à de très nombreux utilisateurs de naviguer dans des EV s complexes. Pour ce qui est des capacités de rendu des terminaux, il est nécessaire d utiliser les techniques que nous avons présentées dans la section 1.2 qui permettent d adapter la complexité des modèles qui sont rendus. Pour ce qui est du nombre d utilisateurs, on constate que cette contrainte n a pas été au cœur des travaux effectués. Le tableau 3.1 présente quelques résultats de tests effectués avec les différentes architectures que nous avons présentées. Système Prévu pour Testé avec Community Place 1000 utilisateurs plus de 400 utilisateurs MASSIVE entre 10 et 100 utilisateurs 6 utilisateurs (mentionné) NPSNet 1000 utilisateurs 100 utilisateurs (simulé) RING 1000 utilisateurs 512 utilisateurs (simulé) SPLINE 1000 utilisateurs 1000 utilisateurs (simulé) Tab. 3.1: Résultats de tests de charge effectués avec différents EV s. Ce tableau présente le nombre d utilisateurs pour lesquelles ces architectures ont été conçues et le nombre réel d utilisateurs avec lesquelles elles ont été testées [108]. On constate que le nombre d utilisateurs qui ont été testés simultanément ne dépassent pas le millier, ce qui est très peu en comparaison du nombre d utilisateurs qui peuvent être amenés à naviguer dans un EV. L utilisation d une architecture centralisée classique est un outil intéressant si l on souhaite transmettre des messages de façon ordonnée à toutes les entités. La contrepartie de l utilisation de ce type d architecture tient au fait que le serveur risque d être rapidement saturé, car il doit traiter tous les messages venant de toutes les entités et il doit aussi se charger de transmettre les mises à jours à toutes les entités. Malgré tout, quelques propositions ont été effectuées de manière à limiter l impact de l utilisation d une architecture client-serveur classique : Une première solution consiste à utiliser un serveur secondaire pour épauler le serveur

69 Conclusion 67 principal [109]. Cette solution permet à un nombre plus grand d utilisateurs de naviguer dans l EV mais le coût de mise à jour est important. En effet, à mesure que l on souhaite faire évoluer le service, il est nécessaire de mettre en place et de maintenir de plus en plus de serveurs. Une autre solution consiste à centraliser les communications autour des processus (serveur ou entité) qui hébergent les objets [90, 91]. Tous les échanges concernant un objet sont supervisés par le processus (serveur ou entités) qui héberge l objet. Cette solution est intéressante, mais elle peut poser des problèmes si un processus (serveur ou entités) héberge un grand nombre d objets car il pourrait rapidement être saturé. Dans ce cas, la gestion des messages est répartie entre différents processus (serveur ou entités), mais la scalabilité n est pas garantie. Il est aussi possible d utiliser le multicast pour se prévenir des problèmes de centralisation des messages [81, 89]. Si un message est perdu, un message de "non acquittement" est transmis de manière à pouvoir le recevoir après une retransmission. Cependant, comme on l a dit précédemment, le multicast n est pas très répandu sur le réseau Internet. Il n est donc pas envisageable d utiliser le multicast comme support de la scalabilité. Malgré les travaux que nous avons présentés dans la section 3.3, qui permettent de limiter le nombre de messages échangés en les filtrant ou en partitionnant l EV (ce qui permet de limiter la charge des serveurs), il apparaît qu aucun des EV s actuels n ait résolu le problème de la scalabilité si ce n est par la solution coûteuse qui consiste à multiplier les serveurs La capacité de coopération Parmi les architectures que nous avons présentés, quelques unes proposent des techniques adaptées aux capacités réseau et de rendu des terminaux de visualisation. Le débit et la latence des connections varient considérablement si le terminal est connecté sur Internet ou en réseau local. Certaines architectures [110] ont proposé des techniques permettant "d aider" les terminaux ayant des connections très limitées. Ainsi, l autorité centrale s occupe de filtrer les messages essentiels et de les compresser de façon à ce qu un nombre plus important d évènements puissent être pris en compte à chaque réception. Dans Spline [90, 91], les "locales" permettent de limiter la quantité de bande passante utilisée. Une compression des messages permet aussi de traiter plus d évènements en simultané. Cependant, la compression de messages, dont le coût est important, peut saturer le serveur s il doit servir beaucoup de clients avec des connections limitées. Un autre problème récurrent concerne la capacité de traitement des terminaux de visualisation. Ainsi, par exemple, certains systèmes centralisent les calculs de détection de collision [89, 93, 92], ce qui décharge les terminaux de visualisation. 3.5 Conclusion Dans ce chapitre, nous avons présenté différents EV s existants en montrant leurs différentes particularités. De nombreux travaux ont été effectués pour gérer les interactions entre les utilisateurs et les objets de façon optimale. Nous avons montré que des techniques telles que le partitionnement de l EV ou le filtrage des messages permettent de réduire considérablement les flux de données de mises à jour. Cependant, ces techniques reposent sur des architectures plus ou moins centralisées, ce qui

70 68 Les architectures pour environnements virtuels distribués engendre des difficultés de dimensionnement. Si l on souhaite fournir un service à grande échelle, il est nécessaire de rajouter des serveurs, ce qui augmente considérablement les coûts de maintenance et de mise en place de l application. D autres solutions ont été proposées, comme l utilisation du multicast qui permet de s affranchir d un serveur central. Malheureusement, comme on l a présenté, le multicast n est que très peu implémenté dans les réseaux actuels. Il n est donc pas envisageable d utiliser le multicast comme support de l échange des données de mise à jour dans un EV. La plupart des EV se sont focalisés sur l optimisation des échanges des messages de maintien de la cohérence de l EV. Comme on vient de le présenter, ces solutions sont des solutions partielles et le problème de la scalabilité reste ouvert si l on souhaite fournir un service à un très grand nombre d utilisateurs. De plus, très peu d EV s ont abordé le problème crucial de l échange des données de visualisation qui constituent pourtant la masse la plus importante des données à échanger. Quelques architectures comme RIN G ont proposé une solution de chargement progressif des données de visualisation en fonction de la zone dans lequel se trouve l observateur. Les autres EV s utilisent la plupart du temps une stratégie de réplication de la base de données de visualisation. On note que du fait des capacités de stockage limitées des terminaux de visualisation, le stockage de la base de données de visualisation peut poser des difficultés. De façon additionnelle, on note qu une stratégie de réplication peut poser des problèmes si la base de données doit être mise à jour ou si on souhaite mettre en place une stratégie de contrôle d accès. Nous pouvons donc déduire que la question de la scalabilité dans les EV s reste encore aujourd hui un problème ouvert. Cependant, nous pensons qu il existe actuellement tous les éléments nécessaires pour permettre l émergence d EV s réellement scalables aussi bien en nombre d utilisateurs qu en taille de l EV, d autant qu il existe aujourd hui un réel engouement des Internautes pour les EV s. L apparition récente de Second Life et sa popularité montre à quel point il est important de résoudre ces problèmes. Une solution que nous préconisons est l utilisation d une architecture complètement pairs à pairs dont nous présentons une étude des précédence dans le chapitre suivant. Le chapitre suivant présente les différents travaux qui ont été effectués pour échanger des contenus en pairs à pairs.

71 4. Les réseaux de pairs à pairs 4.1 Introduction Une définition des systèmes pairs à pairs a été donnée dans [111] : "Les systèmes pairs à pairs sont des systèmes distribués constitués de nœuds interconnectés. Ces systèmes s autoorganisent avec des topologies réseaux particulières de façon à partager des ressources telles que des contenus, de la bande passante, de la capacité de stockage ou des calculs. Les systèmes pairs à pairs peuvent s adapter au déni de service et se satisfaire d une population de nœuds volatiles tout en maintenant des performances et une connectivité acceptable sans l intermédiaire d une autorité ou d un serveur central". Nous avons montré dans le chapitre précédent que les différentes architectures pour EV s proposées dans la littérature ne permettent pas de résoudre les problèmes de scalabilité. Effectivement, ces architectures plus ou moins centralisées ont surtout abordé les problèmes de maintien de la cohérence dans l EV et très peu de solutions ont été proposées concernant le problème crucial de l échange des données de visualisation qui constituent pourtant la plus grande part des données à échanger. L utilisation d architectures plus ou moins centralisées ne permet pas une réelle scalabilité sauf en ajoutant des serveurs. Les architectures pairs à pairs permettent quant à elles de dépasser ces problèmes de dimensionnement et permettent de mettre en place des applications qui peuvent passer à l échelle. Le récent engouement pour les applications pairs à pairs montrent à quel point ces applications sont prometteuses. Ainsi, des applications de partage de fichiers telles que Emule [112] ou Bit Torrent [113], qui sont les plus connues, peuvent rassembler jusqu à plusieurs millions d utilisateurs simultanément [114]. Cependant, les architectures pairs à pairs ne sont pas utilisées uniquement dans les applications de partage de fichiers, et on retrouve ce type d architectures dans de très nombreux domaines tels que la collaboration, les calculs distribués et le support de services Internet. Nous présenterons une liste exhaustive de ces applications par la suite mais pour l instant nous nous intéresserons plutôt aux architectures de distribution de contenus qui répondent le mieux à notre problématique. Effectivement, nous souhaitons distribuer au mieux la base de données de visualisation de façon à mettre en place un EV réellement scalable. Dans cette partie, après avoir présenté les principes des architectures pairs à pairs et décrit quelques applications caractéristiques, nous intéresserons en particulier à deux architectures pairs à pairs qui nous semblent le plus à même de répondre à notre problématique. Une caractéristique commune à tous les EV s est la position des éléments de la scène dans un repère cartésien en trois dimensions. Les deux architectures que nous présenterons sont caractéristiques en ce sens que les différents nœuds du réseau pairs à pairs sont connectés les uns aux autres en fonction de leur position dans un espace en deux dimensions. Nous présentons dans la partie suivante les principes qui nous conduisent à choisir ce type d architecture comme support de la connectivité entre les entités de notre EV. Nous n évoquerons pas ces raisons pour l instant car elles ne sont

72 70 Les réseaux de pairs à pairs pas caractéristiques des réseaux pairs à pairs que nous présenterons dans cette partie. 4.2 Les principes généraux Une couche d abstraction pairs à pairs est caractérisée par plusieurs composants fondamentaux. Ceux-ci sont présents dans tous les types d application de pairs à pairs. Avant de les décrire, il est important de noter que chacun des nœuds du système pairs à pairs : peut être client ou serveur, peuvent communiquer directement les uns avec les autres, peut participer au maintiende l infrastructure. Les figures suivantes illustrent les différents composants fondamentaux d un réseau pairs à pairs. En premier lieu, il est souvent nécessaire d utiliser une passerelle pour connaître l adresse IP d au moins un des nœuds actuellement connectés au réseau de pairs à pairs. La passerelle peut être par exemple un serveur dédié avec une adresse IP ou une page Web sur laquelle sont inscrites les informations nécessaires. L utilisation d une passerelle permet à un nœud de récupérer l adresse IP d un nœud actuellement connecté au réseau pairs à pairs afin de s y connecter aussi. La figure 4.1 présente un exemple d interrogation d une passerelle pour récupérer l adresse IP d un nœud actuellement connecté au réseau pairs à pairs. d'un noeud du réseau P2P Requête d'un noeud du réseau P2P Système pairs à pairs Connexion au noeud du réseau P2P et ensuite connexion au réseau P2P Terminal Fig. 4.1: Exemple d interrogation d une passerelle pour connaître un nœud du réseau pairs à pairs. Une fois que le terminal connaît un des nœuds du réseau pairs à pairs, il peut s y connecter. Une fois que le nœud connait l adresse IP d un des nœuds du réseau pairs à pairs actuellement connecté, il peut, lui aussi, s y connecter. Le nœud utilise un protocole de connexion spécifique et ensuite un protocole de transport lui aussi spécifique. Ces protocoles lui permettent par exemple de contourner les firewalls mis en place sur le réseau. La figure 4.2 montre un exemple d utilisation de protocoles de connexion/transport spécifiques. L utilisation d un tunnel permet l acheminement d une ressource entre les deux terminaux. Quand un nœud est connecté à un réseau pairs à pairs, il utilise le protocole de transport pour publier le(les) service(s) (ou les ressources) qu il met en commun. Chaque nœud précise quelles ressources peuvent être partagées (fichiers, espace disque, CP U, etc.), quel(s) rôle(s) peuvent

73 Les principes généraux 71 Firewall Internet, Intranet ou LAN Firewall Terminal Ressource Système pairs à pairs Ressource Terminal Ressource Internet Tunnel Fig. 4.2: Pour se connecter à un réseau pairs à pairs et échanger des données, il est nécessaire d utiliser un protocole de connexion/transport spécifique. être joués et éventuellement quel protocole utiliser (pour accéder à une ressource par exemple). La figure 4.3 montre un exemple de publication de ressources au sein d un réseau pairs à pairs. Internet, Intranet ou LAN Terminal Système pairs à pairs Fichier Ressources partagées CPU Terminal Espace disque Fig. 4.3: La publication de services (ou de ressources) permet aux nœuds de préciser quelles ressources peuvent être partagées, quel(s) rôle(s) peut(peuvent) être joué(s) par le nœud et quel protocole utiliser. Le dernier composant essentiel concerne la recherche des ressources précédemment publiées. Il est effectivement important de mettre en place un mécanisme qui permette à chaque nœud de localiser précisément au sein du réseau pairs à pairs la ressource ou le service dont il a besoin. Le mécanisme est implémenté de façon à ce que la recherche puisse être effectuée le plus rapidement possible. La figure 4.4 présente un exemple de recherche de ressources au sein d un réseau pairs à pairs. Dans cette section, nous avons présenté les différents composants fondamentaux communs à tous les réseaux pairs à pairs. Dans chaque réseau de pairs à pairs, les composants fondamentaux

74 72 Les réseaux de pairs à pairs Terminal Terminal Demande de ressource(s) Internet, Intranet ou LAN Système pairs à pairs Fichier Ressources partagées CPU Terminal Espace disque Fig. 4.4: Exemple de recherche de ressources dans un réseau pairs à pairs. sont souvent implémentés de façon différente en fonction des services et/ou des ressources qu ils permettent de mettre à disposition. La section suivante présentera quelques uns des réseaux pairs à pairs que l on peut retrouver dans la littérature. 4.3 Quelques exemples de réseaux pairs à pairs Les réseaux pairs à pairs peuvent actuellement être classés en cinq catégories qui sont la communication et la collaboration, le calcul distribué, le support de service Internet, les bases de données et la distribution de contenus. Nous allons rapidement décrire ces différentes catégories et nous allons présenter quelques exemples de ces applications dans les points suivants. La catégorie communication et collaboration inclut les systèmes pairs à pairs dont l infrastructure facilite la communication et la collaboration directe, et souvent temps réel, entre deux ou plusieurs terminaux. On retrouve dans cette catégorie de nombreuses applications de messagerie instantanée telle que Yahoo Messenger [115], MSN Live Messenger [116], Jabber [117], etc. Une fois que deux ou plusieurs terminaux sont mis en relation, les utilisateurs peuvent directement tchatter, faire de l audio ou de la visio conférence, etc. on retrouve, dans la catégorie calcul distribué, tous les systèmes pairs à pairs qui permettent de mettre à contribution la puissance de calcul des terminaux qui y sont connectés. Certains traitements nécessitent une puissance de calcul considérable. Avec ces systèmes pairs à pairs, les traitements sont découpés en petites unités qui sont ensuite distribuées à tous les terminaux connectés. Pendant leurs périodes d inactivité (par exemple quand le terminal est en veille), les terminaux mettent leur puissance de calcul à contribution. Les terminaux exécutent les unités de traitement qu ils ont reçus et ils renvoient les résultats obtenus. Pour des raisons de coordination des différents traitements, la présence d une autorité centrale est bien sur nécessaire. Parmi ces applications on retrouve le projet Seti@Home [118] consacré à la recherche d une intelligence extraterrestre, ou le projet Genome@Home [119] qui, quant à lui, est consacré à l étude du génome humain.

75 Les réseaux pairs à pairs spatialement organisés 73 Récemment, de nombreuses applications de support de service Internet basées sur des réseaux pairs à pairs ont émergé. Parmi celles-ci on retrouve des applications permettant de faire du multicast [120, 121], des infrastructures de routage sur Internet [122] ou encore des applications de sécurité fournissant une protection contre les virus ou les "déni de service" [123, 124, 125]. De nombreux travaux ont été effectués dans le domaine des bases de données distribuées et basées sur une infrastructure pairs à pairs. En 2002, Berstein et al. [126] ont proposé un modèle de relations locales (Local Relationnal Model : LRM). P IER [127] est un moteur de recherche distribué scalable mis en place sur une infrastructure pairs à pairs qui permet d effectuer des recherches sur des milliers de terminaux. Le système Piazza [128] fournit une infrastructure permettant de mettre en place des applications de Web sémantique [129]. La distribution de contenus est actuellement la catégorie de systèmes pairs à pairs la plus répandue. Les systèmes et les infrastructures pairs à pairs de distribution de contenus sont conçus pour partager des données multimédia et d autres données entre les différents utilisateurs. Cette catégorie inclut le plus simple système de partage de fichiers jusqu aux systèmes permettant de créer une ressource de stockage distribuée avec laquelle il est possible de façon sure de publier, d organiser, d indexer, de rechercher et de télécharger des données. Parmi ces très nombreux systèmes on donne quelques exemples : Gnutella [130], Kazaa [131], Freenet [132], OceanStore [133], PAST [134], Chord [135], etc. Les réseaux de pairs à pairs sont utilisés dans de nombreuses applications qui peuvent répondre à un grand nombre de problématiques que l on retrouve dans les EV s. Dans cette thèse, nous nous intéressons particulièrement au problème crucial de l échange de données. Nous nous plaçons donc dans le contexte de la distribution de contenus présentée dans le point précédent. Dans la section suivante nous présenterons deux architectures pairs à pairs qui répondent bien à notre problématique de distribution de la base de données de visualisation dans un EV. 4.4 Les réseaux pairs à pairs spatialement organisés Parmi les différentes architectures pairs à pairs de la littérature, deux d entre elles ont particulièrement retenu notre attention. Un élément commun à tous les EV s est la position des éléments dans un espace cartésien en trois dimensions. Les architectures V AST (Voronoi-based Adaptive Scalable Transfer) [136] et Solipsis [137] que nous présenterons dans la suite sont les premières architectures pairs à pairs qui permettent de connecter des nœuds en fonction de leur position dans un EV en deux dimensions. Le code source de ces deux architectures est disponible sur Internet aux adresses que l on vient de citer VAST Le projet V AST est basé sur les travaux de recherches de Shun-Yun Hu qui a d abord mis en place l architecture V ON (Voronoi-based Overlay Network) [138]. V ON est basé sur la construction mathématique du diagramme de Voronoi [139]. Pour chacun des n points d un plan (chaque point étant appelé site), un diagramme de Voronoi est construit en partitionnant le plan en n région qui ne se chevauchent pas. Chaque région contient un seul et unique site et tous les points les plus proches de ce site par rapport aux autres sites y sont inclus aussi. La figure 4.5 présente un exemple de diagramme de Voronoi.

76 74 Les réseaux de pairs à pairs Fig. 4.5: Exemple de diagramme de Voronoi [138]. Les points correspondent aux sites et les sites sont inclus dans une région. Le diagramme de Voronoi présenté dans la figure 4.5 peut être utilisé pour trouver les k- voisins les plus proches d un site spécifique. Ainsi, il est possible de déterminer les voisins directs et les voisins englobant un site spécifique. Les voisins directs sont ceux dont la région partage une arête commune avec la région du site considéré. Les voisins englobant sont ceux dont la région intersecte la zone d intérêt du site considéré. On note que parfois des voisins directs peuvent être aussi et en même temps des voisins englobant. La figure 4.6 montre, pour un site considéré, les voisins directs et les voisins englobant. Fig. 4.6: Découverte des voisins d un site avec V ON. Le site de référence est le disque rouge, Les voisins directs sont les carrés vert et les voisins englobant sont les triangles bleus [138]. Les principes évoqués dans la figure 4.6 permettent à chaque site de déterminer ses voisins. Ainsi, l idée principale de V ON est que chaque nœud du réseau pairs à pairs construise et maintienne seul un diagramme de Voronoi basé sur les coordonnées des voisins inclus dans sa zone d intérêt. Les connections réseau se font avec les voisins inclus dans la zone d intérêt du nœud et sont uniquement basées sur des critères spaciaux. Le tableau 4.1 suivant montre de manière schématique le fonctionnement de différentes procédures essentielles telles que l ajout, la suppression et le déplacement de nœuds. A la suite de ses travaux sur V ON, Hu a proposé une méthode pour échanger des données présentes dans un EV [140]. Nous montrerons dans la suite que cette méthode ne permet pas un échange vraiment efficace de ces données entres les différents nœuds du réseau pairs à pairs.

77 Les réseaux pairs à pairs spatialement organisés 75 Procédure Description Schema Ajout Suppression Déplacement Le nouveau nœud contacte la passerelle (disque rouge) qui lui indique le nœud qui est le plus près de la position où il souhaite se connecter (carré bleu). Ensuite, le diagramme de Voronoi est mis à jour et le nouveau nœud est inséré. (trianle vert). Si un nœud souhaite se déconnecter (étoile verte), il informe ses voisins et le diagramme de Voronoi est mis à jour en conséquence. Le nœud considéré (disque rouge) se déconnecte du nœud qui est parti et se connecte à ses nouveaux voisins (triangles bleu). Si un nœud (disque rouge) souhaite se déplacer vers une nouvelle position (triangle bleu), le diagramme de Voronoi est mis à jour et les voisins qui ne sont plus dans la zone d intérêt sont déconnectés (carrés bleu). De même, le nœud se connecte aux nouveaux nœuds qu il a découvert dans sa zone d intérêt (carré vert). Tab. 4.1: Les procédures d ajout, de suppression et de déplacement dans V ON [138] Solipsis Dans Solipsis [141], les nœuds du réseau pairs à pairs sont aussi connectés les uns aux autres en fonction de leur position dans un espace en deux dimensions. Chaque nœud (ou entité e ) de Solipis est caractérisé par sa position (x e,y e ), par une zone de connaissance de rayon r e et par un groupe de nœuds (ou entités) voisin(e)s k(e). Les nœuds (ou entités) voisin(e)s k(e) sont inclus(e)s dans la zone de connaissance de l entité e. La figure 4.7 présente une entité e et sa zone de connaissance de rayon r e.