6.1 Impl ´ementation
Nous avons impl´ement´e deux syst`emes ind´ependants, l’un pour le pr´ecalcul et l’autre pour le rendu interac-tif. Le pr´ecalcul utilise autant que faire se peut le mat´eriel graphique, en particulier pour les Projections et pour la convolution. Les Cartes de Profondeur sont lues depuis la m´emoire graphique, et les tests d’occultations sont effectu´ees en logiciel. Cette op´eration pourrait ˆetre optimis´ee en utilisant les nouvelles cartes graphiques qui permettent des test de profondeur efficaces [Sgi99]. Les PVS calcul´es sont stock´es sur disque.
Notre impl´ementation du rendu interactif est bas´ee sur la biblioth`eque SGI Performer[RH94]. Performer offre un puissant graphe de sc`ene et l’´elimination des objets hors du cˆone de vue (view-frustum culling), ce qui fournit une base honnˆete de comparaison.
6.2 R ´esultats
Projections ´etendues sur un seul plan de projection
Les sc`enes de test que nous avons utilis´ees pour la m´ethode `a un seul plan de projection sont les suivantes : le mod`ele du quartier de Montmartre, contenant 150 000 polygone ; (b) ce mod`ele r´epliqu´e 4 fois avec en plus 2 000 voitures en mouvement de 1 000 polygones chacune (2,6 millions de polygones au total).
Nous avons utilis´e la Projection des bloqueurs avec la carte de stencil et les Projections am´elior´ees pour les objets. Toutes les Projections sont calcul´ees `a la r´esolution 256x256. Nous n’avons pas observ´e d’artefact, mais une comparaison avec des Cartes de Profondeur de plus grande r´esolution est souhaitable.
Le pr´ecalcul pour une seule instance du quartier a pris environ 1 heure sur une Onyx 2 Infinite Reality avec un processeur R10k `a 196Mhz. Pour le quartier r´epliqu´e 4 fois avec les voitures, il a fallu 4 heures, pour 3479 cellules finales, soit 4,1 secondes par cellule. Dans cette derni`ere sc`ene, le stockage du PVS requiert 25Mo, pour un mod`ele de 60Mo (sans compter les voitures). Environ 95% de la g´eom´etrie est d´eclar´ee invisible en moyenne.
Nous avons effectu´es nos tests de rendu interactif sur deux configurations mat´erielles. La premi`ere est une station de travail Silicon Graphics O2R5000, et la seconde une station haut de gamme Onyx 2 Infinite Reality 2xR10k. Une acc´el´eration d’environ 5 `a 6 fois a ´et´e observ´ee. Cela peut sembler faible apr`es avoir ´elimin´e 95% de la g´eom´etrie, mais Performer effectue une puissante ´elimination de la g´eom´etrie hors du cˆone de vue [GBW90], et environ 80% de la sc`ene est ´elimin´ee. La figure 5.15 montre des r´esultats de notre m´ethode.
Nous avons impl´ement´e l’algorithme de Cohen-Or et al. [COFHZ98, COZ98] afin d’effectuer une com-paraison informelle (cf. figure 5.16). Pour le mod`ele de ville, cet algorithme d´eclare 4 fois plus d’objets po-tentiellement visibles que le n ˆotre en moyenne, pour un temps de calcul 150 fois plus ´elev´e. Une version plus optimis´ee diminuerait sans aucun doute ce co ˆut, mais les 4,1 secondes par cellule de notre algorithme semblent difficiles `a battre en utilisant du lancer de rayon sur d’aussi gros mod`eles.
Balayage d’occultation
Nous avons effectu´e des test pr´eliminaires pour le balayage d’occultation, en utilisant un mod`ele de forˆet contenant 1 200 arbres de 1 000 feuilles triangulaires chacun. La Projection des feuilles sur le plan de projection est calcul´ee avec l’algorithme de Projection pour bloqueurs convexes `a l’aide de la carte de stencil. La taille
(a) (b)
(c) (d)
FIG. 5.15:R´esultats de notre m´ethode. (a) Sc`ene vue depuis la position de l’observateur. (b) Sc`ene en vue d’oiseau sans ´elimination ; la sc`ene contient 600 000 polygones pour les bˆatiments et 2 000 voitures de 1 000 polygones chacune. (c) Mˆeme vue avec ´elimination d’occultation. (d) Les boˆıtes en jaune repr´esentent les
´el´ements de la hi´erarchie d’objets qui sont ´elimin´es.
du noyau de convolution est fix´ee `a 5 pixels et nous utilisons 15 plans pour le balayage. Le balayage d’occul-tation prend environ 12 secondes par cellule, et ´elimine 75% des arbres. La figure 5.17 montre le balayage, et l’agr´egation des feuilles dans la Carte d’Occultation.
7 Discussion
7.1 R ´esum ´e
Nous avons pr´esent´e des op´erateurs de projection ´etendue qui autorisent des tests prudents d’occultation par rapport `a une cellule de vue volumique. La projection ´etendue d’un bloqueur est l’intersection de ses vues, tandis que pour un objet, il s’agit de l’union des vues. Nous avons ´egalement d´efini une profondeur ´etendue qui permet la d´efinition de cartes de profondeur ´etendue qui sont la g´en´eralisation du z-buffer pour des cellules volumiques.
Nos op´erateurs permettent des tests d’occultation prudents et peuvent prendre en compte la fusion de blo-queurs, c’est-`a-dire l’occultation due `a la conjonction de plusieurs bloqueurs. Nous avons d´ecrit des
impl´emen-FIG. 5.16:Comparaison entre l’algorithme de Cohen-Or et al. [COFHZ98, COZ98] et les projections ´etendues.
Nous repr´esentons les bˆatiments que leur algorithme d´eclare potentiellement visibles alors qu’ils sont ´elimin´es par notre m´ethode. La cellule se trouve en bas `a gauche.
FIG. 5.17:Balayage d’occultation. (a) Mod`ele de forˆet. (b)-(d) trois positions du plan de balayage. Les boˆıtes en jaunes indiquent les arbres ´elimin´es.
tations efficaces pour ces op´erateurs, ainsi qu’une am´elioration pour le cas des bloqueurs convexes ou planaires.
Nous avons d´efini un op´erateur de reprojection qui reprojette les projections ´etendues calcul´ees pour un plan initial sur un nouveau plan de projection. Nous l’avons ´etendu en un balayage d’occultation qui consiste
`a balayer la sc`ene par une s´erie de plans parall`eles quittant la cellule. Les occultations caus´ees par de petits objets sont agr´eg´ees sur les plans lors du balayage.
Nous avons pr´esent´e une impl´ementation efficace qui b´en´eficie tant que faire se peut des acc´el´erations mat´erielles. Notre pr´ecalcul subdivise de mani`ere adaptative l’espace de l’observateur en cellules pour les-quelles des ensembles d’objets potentiellement visibles sont calcul´es. Nous obtenons un facteur d’acc´el´eration de 5 `a 6 par rapport `a un programme haut de gamme de rendu interactif, ce qui rend possible une balade dans un mod`ele de 2,6 millions de polygones. Des r´esultats pr´eliminaires ont ´egalement ´et´e pr´esent´es qui montrent que notre balayage d’occultation permet de calculer, par rapport `a une cellule volumique, les occultations dues aux feuilles des arbres dans une forˆet.
7.2 Discussion
Pour commencer, il est important de souligner que notre m´ethode ne peut identifier qu’un sous-ensemble des objets qui peuvent ˆetre ´elimin´es par une m´ethode qui effectue des calculs d’occultation par rapport `a un point de vue unique, comme le z-buffer hi´erarchique [GKM93] ou les cartes hi´erarchiques d’occultation [ZMHH97, Zha98b]. Ces m´ethodes pr´esentent ´egalement l’avantage de traiter les bloqueurs en mouvement et de ne n´ecessiter aucun pr´ecalcul et aucun stockage de PVS.
Cependant, notre m´ethode ne n´ecessite quasiment aucun surcoˆut lors de l’affichage, alors que le syst`eme de rendu de sc`enes complexes d´evelopp´e `a l’Universit´e de Caroline du Nord [ACW+99] utilise jusqu’`a deux processeurs uniquement pour les calculs d’´elimination d’occultation. De plus, pour certaines applications – les jeux, le rendu `a travers le r´eseau, le tourisme virtuel, etc. – le pr´ecalcul n’est pas un v´eritable handicap, il peut ˆetre effectu´e une fois pour toute par le cr´eateur de l’application. Les PVS que nous calculons permettent un pr´e-chargement pr´edictif qui est crucial pour transmettre des sc`enes `a travers le r´eseau ou pour l’affichage de sc`enes qui ne peuvent ˆetre charg´ees enti`erement en m´emoire principale.
Par oppositions aux calculs exacts de visibilit´e (tels que ceux pr´esent´es dans les trois chapitres pr´ec´edents), les op´erateurs de projection ´etendue peuvent ´echouer `a identifier certaines occultations dues `a la conjonction de plusieurs bloqueurs. Comme nous l’avons vu `a la section 5.2, la fusion des bloqueurs d´epend du choix du plan de projection.
Les projections ´etendues r´eduisent un probl`eme de visibilit´e qui est 4D `a une repr´esentation 2D sur un plan de projection. L’information de visibilit´e port´ee par l’ensemble des rayons qui passent par un point du plan de projection et la cellule est approxim´ee de mani`ere prudente par une seule valeur (binaire pour les Cartes d’Occultation, r´eelle pour les Cartes de Profondeur). Cela revient `a projeter l’information de visibilit´e `a l’int´erieur du volume de tangence de la cellule sur une 2-vari´et´e.
L’approximation entraˆın´ee par la discr´etisation sur le plan de projection est une question primordiale. Nous pensons que notre approche est moins sensible aux artefacts dus `a une faible r´esolution que par exemple le z-buffer hi´erarchique, pour lequel une plus faible r´esolution entraˆınerait des probl`emes le long des sil-houettes des objets. Dans ce cas, la carte de profondeur utilis´ee correspond directement `a la vue calcul´ee, tandis que dans notre cas nous utilisons des Projections prudentes. Notre estimation de la Projection des objets est compl`etement prudente, elle sur-estime l´eg`erement le rectangle englobant de la v´eritable Projection (`a cause de l’arrondi sur les entiers). De plus, la Projection d’un bloqueur est une sous-estimation de la vue depuis n’im-porte quel point de la cellule, ce qui r´eduit les risques de d´etecter de fausses occultations `a cause de l’erreur de discr´etisation. Cependant, la r´esolution de nos Cartes de Profondeur est faible (256256) et de plus amples analyses devraient ˆetre men´ees.
Il existe des configurations dans lesquelles mˆeme un algorithme parfait d’´elimination d’occultation
(c’est-`a-dire un algorithme exact d’´elimination des parties cach´ees) ne peut ´eliminer suffisamment de g´eom´etrie pour parvenir `a un rendu en temps r´eel. Par exemple, si l’observateur se trouve au sommet d’une colline ou sur le toit d’un bˆatiment, la ville enti`ere peut ˆetre visible. D’autres techniques doivent alors ˆetre utilis´ees avec notre
´elimination d’occultation, comme nous en discutons dans la section suivante.
7.3 Travaux futurs
Projection ´etendue de bloqueurs concaves
La m´ethode de tranchage que nous avons pr´esent´ee pour traiter les bloqueurs concaves n’est pas totale-ment satisfaisante. Elle est restreinte aux objets vari´et´es qui ont effectivetotale-ment une intersection avec le plan de projection. Nous proposons ici des techniques pour traiter certaines classes de bloqueurs.
Les sp´ecificit´es des sc`enes architecturales ont ´et´e exploit´ees pour les calculs de visibilit´e (e.g. [ARB90, Tel92b, TS91]). Des pi`eces diff´erentes ne sont visibles qu’`a travers une s´equence de “hublot” (portals) comme les portes ou les fenˆetres. Les hublots convexes sont en fait les compl´ementaires de bloqueurs convexes. Leur Projection peut ˆetre calcul´ee en consid´erant le compl´ementaire de l’union des vues depuis les sommets (fi-gure 5.18(a)).
Des m´ethodes sp´ecifiques peuvent ˆetre impl´ement´ees pour certaines classes de bloqueurs convexes, ce qui s’av´erera utile dans le paragraphe suivant. Prenons l’exemple d’une sph`ere. Si l’on place une sph`ere englobante autour de la cellule, la Projection de la sph`ere est une ellipse qu’il est facile de calculer.
cell
portal
projection plane occluder
occluder projection
V cell
occluder projection plane
(a) (b)
FIG. 5.18:(a) La projection ´etendue d’un mur contenant un “hublot” est l’intersection de ses vues. Elle peut ˆetre calcul´ee en prenant le compl´ementaire de l’union des vues du hublot. (b) Projection ´etendue d’un bloqueur concave en utilisant une union de bloqueurs convexes (des sph`eres ici).
Nous proposons d’utiliser des convexes (par exemple une union de sph`eres, e.g. [RF95], comme approxima-tion des bloqueurs concaves (figure 5.18(b)). Le chevauchement de ces convexes est crucial, puisque la fusion de bloqueurs permet alors une estimation efficace de la Projection du concave. Cette m´ethode devrait permettre de s’affranchir du probl`emes des interstices qui apparaissent lorsque chaque triangle d’un maillage connexe est projet´e.
Nous pr´esentons une derni`ere m´ethode pour r´egler les probl`emes de connexit´e de la projection d’un maillage poly´edrique concave. Il s’agit de simplement projeter le maillage depuis le centre de la cellule, avant d’effectuer un “r´etr´ecissement”. Cette id´ee est illustr´ee figure 5.19. Les arˆetes de la silhouette sont translat´ees vers le centre de l’objet. Le calcul du vecteur de translation est similaire au calcul du noyau de convolution utilis´e pour la reprojection. A priori, les triangles au centre de la projection du maillage n’auront pas besoin d’ˆetre translat´es.
Cependant, si un triangle silhouette est trop petit (comme c’est le cas du triangle T2), la translation de leur arˆete doit ˆetre propag´ee aux triangles adjacents.
Rendu temps-r ´eel
Notre m´ethode diminue de mani`ere drastique le temps de rendu, mais elle ne permet pas pour autant de garantir une fr´equence d’affichage donn´ee. Nous proposons ici de l’utiliser au sein des cadres de rendu temps-r´eel offerts par les travaux ant´erieurs. Ils sont tous fond´es sur la notion de niveaux de d´etail (LOD) [Cla76] : une repr´esentation simplifi´ee est utilis´ee pour les objets distants.
La biblioth`eque Performer [RH94] utilise une m´ethode simple de r´egulation de l’affichage. Une valeur globale de stress est utilis´ee pour mettre `a l’´echelle un crit`ere de s´election des niveaux de d´etail bas´e sur la distance. Une fr´equence d’affichage cible est choisie, et si le rendu de la sc`ene prend plus qu’une valeur donn´ee, disons 95% du temps d´evolu `a chaque image, la valeur de stress est augment´ee, des niveaux de d´etail plus grossiers sont utilis´es, et la fr´equence d’affichage est r´egul´ee.
Notre pr´ecalcul peut ˆetre utilis´e pour pr´evoir les soudaines augmentations du nombre de primitives, puisque nous connaissons le nombre d’objets potentiellement visibles depuis la cellule courante et ses voisines. Nous pouvons pr´edire les variations et nous y adapter de mani`ere plus fluide.
Pour obtenir un rendu temps r´eel, Funkhouser et al. [FS93] r´esolvent un probl`eme du sac `a dos (knapsack problem) pour chaque image : un budget de polygones doit ˆetre optimalement d´epens´e, en choisissant le niveau de d´etail appropri´e pour chaque objet. Maciel et Shirley [MS95] ont ´etendu cette approche aux hi´erarchies de niveaux de d´etail. Funkhouser et al. [FS93] ont montr´e qu’un pr´ecalcul de visibilit´e permet de concentrer