spacer.png, 0 kB

Identification



Copyright © 2018 GRATISIM, promotion du graticiel pour Flight Simulator. Tous droits réservés.
Joomla! est un logiciel libre sous licence GNU/GPL.
Nous avons 68 invités en ligne

spacer.png, 0 kB
spacer.png, 0 kB
Accueil Documentations Technologie de traitement de l'environnement
Technologie de traitement de l'environnement Imprimer Envoyer
Index de l'article
Technologie de traitement de l'environnement
2. Les conditions
3. Traitement des données géographiques
5. Tracé de la scène
6. Maillage géométrique de l`environnement
7. Synthèse de l`imagerie aérienne
7.1. Construction du modèle de classe
7.2. Application des textures de landclass
7.3. Restitution linéaire des données vectorielles
7.4. Construction du modèle d'éclairage
8. Parlons Threads, Fibers, et architectures Multi-core
9. Remerciements
10. Références et bibliographie
Toutes les pages
Par Adam Szofran
Traduit de l'anglais par Christian Gandon,  helipad.fr - mai 2006
demande d'autorisation de publier en cours.


Copyright Microsoft ACES Game Studio
One Microsoft Way, Redmond, WA  98052

Cliquer  pour télécharger l'article (en anglais, 8.3 MB;  .DOC)
Cliquer  pour télécharger la présentation PowerPoint (en anglais, 30.1  MB)
Cliquer  ici pour voir une vidéo (spaceshot2.wmv; 2.4 MB)


1. Introduction
Vers la fin 2006, ACES game studio de Microsoft publiera la dixième version de la longue lignée des produits Flight Simulator. La technologie de mise en oeuvre de Flight Simulator a considérablement évoluée au cours des 23 années de vie de ce produit, et continuera d'évoluer, mais le but est toujours resté identique : permettre aux clients de vivre de la façon la plus réaliste au monde leur rêve aéronautique.


A l'évidence, une part énorme du monde de Flight Simulator est constitué par la Terre elle-même et l'ensemble de ses constituants, incluant montagnes, rivières, forêts, villes, routes et autres éléments visibles depuis le cockpit d'un avion virtuel. Cet article explique quelques une des techniques que Microsoft utilise pour représenter la Terre dans le monde virtuel de Flight Simulator

Image

 Figure 1: Vue de l'environnement Flight Simulator (en médaillon  1982 [1]) et maintenant (2006)


2. Les conditions


La communauté Flight Simulator est constituée essentiellement d'hommes âgés  de 28 à 34 ans, mais se compose également d'une audience grandissante  d'enthousiastes de l'aviation, hommes et femmes, jeunes ou anciens. Cette  nouvelle catégorie ne mettra pas à jour son ordinateur de façon aussi  systématique que le simmeur typique. Flight Simulator doit donc s'adapter à une  gamme étendue de systèmes.

Le but du moteur d'environnement de Flight Simulator est de permettre la  visualisation la plus fidèle possible de la Terre depuis n'importe quel point au  sol, en vol ou en orbite, à n'importe quelle heure du jour ou de la nuit et à  toutes les saisons. Le moteur doit également alimenter des vues multiples et  simultanées afin de les partager dans plusieurs fenêtres. En outre, le moteur  doit permettre aux utilisateurs de visualiser d'autres scènes supplémentaires  téléchargeables (adds-on).

Cependant, Flight Simulator doit exécuter bien d'autres tâches que le rendu  du terrain, et ce moteur ne peut se permettre de monopoliser les ressources  processeur du micro-ordinateur. Les ressources doivent être réparties avec les  autres aspects du jeu comme la simulation de l'avion lui-même, l'intelligence  artificielle incluant le trafic et la navigation, la gestion des sessions multi  joueurs, la modélisation graphique de l'avion, des bâtiments au sol ainsi que  tous les autres artifices.


3. Traitement des données géographiques


Afin de modéliser la Terre de façon aussi réaliste que possible, le moteur  d'environnement de Flight Simulator utilise une quantité considérable de données  géographiques issues du monde réel, a la fois vectorielles (chiffrées par des  coordonnées) et matricielles (ou "raster" : représentation numérique d'une image  par une matrice de points appartenant à une palette de couleurs). Par exemple,  les lignes médianes des routes, voies de chemin de fer, lignes haute tension,  fleuves ou côtes littorales sont exprimés par des vecteurs, ainsi que les  contours délimitant les terrains de golf et les zones aéroportuaires. Les  données "raster" représentent les quadrillages utilisés pour la représentation  du relief, les éléments photo réalistes aériens, la représentation suivant une  classification des éléments de paysage et aquatiques ainsi que les données des  saisons.

Les sources brutes de données elles-mêmes dépassent en volume le téraoctets  (1000 Go). Avant qu'elles ne puissent être utilisées par Flight Simulator, elles  doivent être combinées, isolées, et compressées dans un format compatible avec  la taille du média supportant la distribution du produit, et exploitables par le  moteur d'environnement. Afin d'éviter une submersion par la quantité de données,  il est très important d'avoir recours à un bon système de traitement des  informations géographiques (GIS : Geographic Information System). Nous utilisons  ArcGIS édité par la société ESRI [8]  qui fournit d'excellentes fonctionnalités  natives, mais autorise aussi la manipulation rationnelle des données via des  interfaces de programmation personnalisées (API).

Bien que de bons outils soient en mesure d'automatiser la plupart des  traitements nécessaires, il reste cependant un certain nombre de cas épineux  devant être édités manuellement. Par exemple, les données vectorielles d'une  rivière et les données "raster" du relief peuvent ne pas être totalement  appairées lorsqu'elles proviennent de sources diverses ou d'échelle différente.  Si l'écart visuel est trop important, comme c'est le cas lorsqu'une rivière  grimpe le long de la montagne au lieu de suivre la vallée, un système GIS  totalement éditable est indispensable afin de "détourner" certains  points.

Afin de rendre possible l'inscription de toutes les données sur un média  destiné à la distribution du produit, nous employons des techniques de  compression de données variées, avec ou sans perte de précision ou qualité afin  d'obtenir le meilleur résultat en fonction des données de départ. Une méthode  que nous utilisons intensivement depuis peu est le "Progressive Transform Codec"  (PTC), une technologie propriétaire sans perte développée par Microsoft Research  [10]. PTC traite particulièrement bien les données incluant à la fois l'imagerie  aérienne et les données de relief car il peut traiter les entiers de type  multi  canal et les nombres à virgule flottante avec une étendue variable de digit par  canal. Il peut aussi atteindre un taux de compression élevé sans perte de  qualité objective. A l'instar de JPEG2000 ou du procédé "wavelet compression",  la qualité est ajustable. De plus, le code généré par PTC est plus compact que  celui du JPEG2000 et s'exécute plus rapidement.
{mospagebreak title=4. Division de la surface de la Terre}

4. Division de la surface de la Terre


Afin d'aider à organiser et gérer les données d'environnement au  moment de les exécuter, nous divisons la surface du globe en cellules organisées  en arbres quadrants. Il existe plusieurs philosophies pour atteindre le meilleur  résultat. L'un des moyens le plus simple est de diviser le globe suivant les  tracés géographiques latitude/longitude. Toutefois, et en raison de la  convergence des longitudes vers les pôles, l'échelle des cellules varie avec la  latitude. Les divisions polyhédrales du globe peuvent réduire cette variation  d'échelle, au prix d'une complexité accrue [2, 3, 4].

 

Image

    

Image

 Figure 2: Divisions géographiques et polyhédrales [6] du  globe

Le défaut le plus important de la division polyhédrale de notre point de vue  est qu'il est tout simplement trop difficile pour les producteurs de contenu de  créer des dalles de textures devant s'intégrer le plus souvent dans des cellules  de forme triangulaire ou parallélépipédique. La méthode de division  géographique, en dépit des problèmes de convergence aux pôles gagne en  simplicité et est d'un abord plus familier. D'ailleurs, et même si Flight  Simulator permet des vols transpolaires, la plupart de l'action virtuelle se  déroule aux latitudes moyennes, là où se concentre la majorité de la population  mondiale.

Afin de minimiser la distorsion d'échelle là où la majorité de nos clients  vivent et volent, nous avons conçu notre arbre quadrant de telle sorte que le  ratio nord-sud est-ouest soit proche de 1:1 à +/- 45 degrés de latitude. Ceci a  été fait en réalisant six cellules racine, trois au nord de l'équateur et trois  au sud. Chaque cellule couvre 90 degrés de latitude et 120 degrés de longitude

Image

 

Figure 3: Niveau 1 du système global de l'arbre quadrant de  Flight Simulator

A chaque cellule de l'arbre quadrant est assigné un identifiant unique  composé de son niveau de profondeur dans l'arbre, sa distance sud exprimée en  nombre de cellules par rapport au Pôle Nord et sa distance est par rapport au  180ème méridien. Avec ce schéma, seules des opérations sur des entiers simples  sont nécessaire pour trouver l'identifiant de n'importe quelle feuille. Nous  utilisons l'identifiant cellule comme clé de recherche pour en extraire les  données depuis le disque et les mettre en cache dans des tables rapidement  accessibles au moment de l'exécution (hash). Des liens explicites entre cellules  sont seulement utilisés lorsque c'est nécessaire pour la rapidité d'exécution  mais dans les autres cas, nous gagnons en stockage et en maintenance en  utilisant les identifiants de cellules comme liens implicites. Ce type de  construction d'arbre quadrant est souvent appelé arbre quadrant linéaire  [13].


5. Tracé de scène


Le tracé de scène est conçu pour refléter avec le plus de fidélité possible  l'environnement mais sans devoir pour autant charger plus de données que  nécessaire. En fait, nous souhaitons seulement utiliser les données comportant  le plus haut niveau de détail (LOD : Level Of Detail) tout près du point de vue  et  utiliser progressivement moins de détails lorsque l'oeil pointe vers  l'horizon. Les petites cellules (dernières feuilles de l'arbre, les plus  "profondes") contiennent les données du plus haut niveau de détail ; nous  voulons donc les exploiter pour l'environnement proche. Les cellules de taille  plus importante (près du tronc, moins "profondes") contiennent les données  appauvries en détail, et nous voulons donc qu'elles ne soient visibles que pour  les distances plus grandes. Pour arriver à cela, nous chargeons en mémoire les  cellules de tous les niveaux dans le tracé de scène mais utilisons un procédé  géométrique permettant de diminuer le rayon géographique lorsque la profondeur  des cellules augmente. Comme le rayon décroît à peu près à la même vitesse que  la taille des cellules, le nombre de cellules chargé pour chaque niveau du tracé  de scène reste relativement constant à tous les niveaux.

Image

 

Figure 4 : Contours des cellules de l'arbre quadrant lors du  tracé de scène en superposition avec l'environnement

Idéalement, le rayon du tracé de scène pour chaque niveau de l'arbre quadrant  devrait être déterminé par la résolution de l'écran, les plus hautes résolutions  réclamant un rayon plus grand, mais nous laissons le choix à l'utilisateur qui  pourra ainsi trouver le meilleur réglage qualité/performance de son PC. En  pratique nous permettons une sélection du rayon compris entre 2,5 et 4,5  cellules, qui semble un bon compromis, tentant de garder en mémoire le nombre de  cellules le plus petit possible tout en conservant la fluidité lors du  chargement de nouveau contenu lors du déplacement.
Un tracé de scène  indépendant pour chacun des points de vue est utilisé, mais les données sont  communes.


6. Maillage géométrique de l'environnement


Les techniques d'avant-garde en matière de maillage triangulaire  d'environnement et d'algorithmes de calcul du niveau de détail sont destinés à  exploiter les capacités des périphériques 3D en terme de calculs de  transformation géométrique et d'éclairage [9]. Cependant, comme Flight Simulator  doit pouvoir tourner à la fois sur des configurations anciennes et récentes,  nous exécutons nos calculs de maillage triangulaire sur une base technique  introduite par Lindstrom [5], Pajarola [7], Duchaineau [11] et d'autres, faisant  collectivement référence ici à la triangulation restreinte d'arbres quadrants  (Restricted Quad tree Triangulation : RQT). La RQT génère un maillage sans  couture dont la complexité dépend surtout de l'inégalité du terrain et est  réglable par un simple filtre d'espace écran (erreur métrique) réglable par  l'utilisateur et permettant l'adaptation au PC et aux préférences de chacun.

Image

 

Figure 5 : Section d'environnement maillée triangulaire avec  l'algorithme RQT

L'algorithme RQT tel qu'il est publié est en réalité prévu pour une Terre  "plate" où le point de référence d'élévation est le niveau de la mer, considéré  comme un plan infini. Comme Flight Simulator modélise le rotondité de la Terre,  nous avons dû modifier l'algorithme en conséquence. Le problème majeur est que  le RQT non modifié tend à éliminer la presque totalité des sommets de polygones  constituant les zones sans relief comme les océans, qu'il interprète comme  totalement plats. La solution consiste à augmenter l'erreur métrique pour chaque  point du maillage en nous basant sur la hauteur de courbure de la Terre  au-dessus de la ligne reliant les points voisins opposés. Le résultat est un  accroissement de l'erreur métrique approximativement proportionnelle à la  distance de ses voisins. Plus grande est l'erreur métrique, moins un point sera  éliminé du maillage triangulaire. Cet artifice permet de préserver la rotondité  de la Terre dans les grandes étendues plates.

Afin d'éviter la monopolisation des ressources processeur, le moteur  d'environnement ne recalcule pas la maille lors de chaque image affichée. En  fait, la maille est calculée et triangulée par incréments et le résultat est  ajouté au tracé de scène lorsqu'il devient disponible, utilisant un procédé à  double mémoire tampon.

Une fois le maillage triangulaire effectué, les sommets des mailles doivent  être transformés afin de tenir compte de la rotondité de la Terre. Flight  Simulator utilise le modèle ellipsoïdal défini par le World Geodesic System 1984  ou WGS 84  [12]. WGS 84 utilise un système de coordonnées rectangulaires  géocentrique avec le centre de masse la Terre comme  origine. Les axes X, Y et Z sont représentés Figure 6. Chacun d'eux a pour  origine le centre de masse de la Terre. L'axe X traverse l'équateur au niveau du  premier méridien. L'axe Y intercepte l'équateur à 90 degrés de longitude Est.  L'axe Z traverse le Pôle Nord.

La longitude, ?, est la mesure de l'angle dans le plan X-Y depuis l'axe X  vers l'axe Y. La latitude géodétique, f, est constituée de l'angle formé par le  plan X-Y et le normal de référence ellipsoïde à ce point. L'altitude, h, est la  hauteur en mètres au-dessus de la surface ellipsoïde, que nous utilisons comme  notre référence du niveau de la mer.

Image

 

Figure 6: Le système de coordonnées WGS 84 [12]

 

La conversion depuis les latitude, longitude et altitude au-dessus du niveau  de la mer en coordonnées cartésiennes est relativement simple et directe à  l'aide de l'équation 4-14 des spécifications WGS 84 :

Image

Où :

Image

 

a = 6378137.0 mètres (Rayon de la Terre à l'Equateur)
b = 6356752.3142 mètres  (Rayon de la Terre aux Pôles)
e = 8.1819190842622 x 10-2 (ellipsoïde  excentrique)

Les équations doivent être évaluées en utilisant le mode 64 bits virgule  flottante afin de prévenir une perte de précision. Les sept digits significatifs  des nombres représentés sur 32 bits ne sont pas suffisants pour représenter un  point avec une incertitude de moins d'un mètre. Etant donné que Direct 3D (dans  notre cas) utilise des flottants 32 bits pour transporter les données de rendu  d'images, les coordonnées finales doivent être converties en offsets 32 bits  sous peine d'une erreur de plusieurs centaines de mètres (voir Figure 7). Le  process serait simplifié si chaque cellule intégrait sa propre origine locale et  une table de translation de type "world-to-camera", mais des erreurs de positionnement seraient alors visibles entre les  cellules en raison de l'imprécision due au calcul en virgule flottante. Par  conséquent, toutes les cellules doivent avoir une origine locale  identique.
 

Image

 Figure 7: Diagramme montrant WGS 84, l'origine locale et les  axes camera.

 

Comme le point de vue se déplace, l'origine locale doit être périodiquement  mise à jour afin de la conserver dans un périmètre de quelques kilomètres du  point de vue. D'un autre côté, une perte de précision a comme résultat de faire  bouger l'environnement lorsque le point de vue se déplace, intéressant mais  indésirable cependant. Lorsque nous mettons à jour l'origine locale, tous les  vertex de chaque cellule de l'arbre doivent être recalculés en fonction de la  nouvelle origine. Comme cela prend le temps de plusieurs images affichées, les  nouvelles données sont stockées dans une seconde mémoire tampon et ne sont  activées que lorsque l'ensemble est recalculé afin d'éviter des sauts d'image  visibles.

 Image

 


7. Synthèse de l'imagerie aérienne


Un jour, Flight Simulator pourrait charger en temps réel la totalité des  images d'environnement depuis un serveur central comme celui de Microsoft Visual  Earth (http://ve.msn.com/).

argaiv1852

Mais ce jour  n'est pas encore arrivé pour des raisons variées [20]. En premier lieu, Flight  Simulator n'impose pas une connexion permanente à l'Internet, nous ne pouvons  donc pas utiliser ce type de solution. Deuxièmement, les photos aériennes  brutes, même celles en haute résolution, on un aspect fade surprenant lorsqu'on  les applique aux données d'environnement. Les problèmes rencontrés sont dus à  des irrégularités du contraste et des couleurs perceptibles entre les dalles  adjacentes, de problèmes de perspective et d'effet parallaxe générés par les  bâtiments de grande taille, l'obstruction partielle par les nuages pour  certaines vues, les ombres, la perte des vues saisonnières et une couverture  loin d'être complète. Les ressources nécessaires à la résolution de ces  problèmes à une échelle mondiale sont actuellement hors de portée.


Notre solution aux problèmes soulevés ci-dessus est de synthétiser une  imagerie aérienne "au vol", depuis une collection de dalles d'images en haute  résolution et représentant la plupart des types de paysages (landclass). La  détermination du choix de telle dalle représentant tel type de paysage pour une  étendue donnée est faite par acquisition numérique d'un carte du monde en  classifiant les paysage et les vues aquatiques pour l'ensemble des saisons. Afin  de tenir compte des variations de la végétation et des types d'agriculture tout  autour du globe, nous avons subdivisé le monde en 23 régions distinctes, chacune  d'elle contenant ses propres textures représentant le type de paysage. Les  routes, voies de chemin de fer et pièces d'eau y sont inclus à partir de bases  de données réelles. Cette approche permet une couverture de l'environnement avec  un aspect photo réaliste, pour un coût ridicule et balayant la plupart des  problèmes liés à l'imagerie aérienne réelle.


L'un des inconvénients le la synthèse au vol des textures est que cela peut  prendre une part significative de ressources processeur, si l'on souhaite  obtenir un rendu de bonne qualité. Ce problème s'estompe quelque peu : une fois  l'image finalisée à la proximité du point de vue, la synthèse de nouvelles  textures est seulement nécessaire lorsque le point de vue bouge ou que des  changements significatifs (saisonniers, par exemple), se produisent. De plus,  nous synthétisons uniquement les textures de LOD le plus élevé au moment de  l'exécution, d'une résolution plus élevée que 300 mètres par pixel. Les autres  textures (de LOD inférieur) sont assez légères pour que nous puissions  simplement les synthétiser par un traitement préliminaire, les compresser et les  inscrire sur le média de distribution afin qu'elles soient chargées comme des  images aériennes.


L'algorithme de synthèse étant complexe, nous l'exécutons dans le code  programme plutôt que d'utiliser les capacité matérielles de la carte graphique.  Bien entendu, cela nécessite l'utilisation d'un code de synthèse d'image 2D  rapide et de haute qualité. Nous avons arrêté notre choix sur l'application  développée par Maxim Shemanarev, Anti-Grain Geometry (AGG) [14] car elle est  rapide, libre de droits et son code source est disponible, nous permettant de  l'adapter complètement à nos besoins.


La base de l'algorithme de synthèse est composé des étapes suivantes, pour  chaque cellule lors du tracé de scène :

1. Construction du modèle de classe  de la cellule

    a. Atténuation ou masquage des différentes classes  présentes dans la cellule

    b. Détermination de la pente de terrain pour  moduler le landclass

    c. Application des données vectorielles  d'environnement au landclass

2. Application de chaque classe de texture en  utilisant le modèle de classe (1.) comme matrice

3. Rendu linéaire des  données vectorielles

4. Construction du modèle d'éclairage.

Les figures  illustrant les étapes de traitement de la synthèse sont toutes créées pour la  zone délimitée en rose de la Figure 9.


 Image

 


7.1. Construction du modèle de classe


La première étape consiste à construire le modèle de classe, une recherche en  2 dimensions dans la table des textures de landclass étant utilisée pour chaque  pixel de la texture finale. Nous utilisons le modèle de classe comme une jeu de  coloriage par cases chiffrées pour aboutir à la texture finale.

La liste initiale des textures est assemblée en échantillonnant la classe  d'image (type de paysage et saison) chevauchant la cellule. Les données de  classe de paysage et la saison sont tracées à une résolution d'approximativement  1 Km de façon à ce que les échantillonnages coïncident exactement avec les coins  des cellules de l'arbre quadrant. Une recherche dans une table est faite afin de  trouver les textures de classe de paysage et de saison correspondant à une dalle  de texture. Dans le cas de classes multiples dans une même cellule, nous  utilisons un système de masque à 1 bit pour faire la transition d'une classe à  une autre.

 Image

Figure 10 : Le modèle de classe après masquage entre les différents landclass à chaque coin.

Au-dessus cette texture composite, nous ajoutons tout élément aquatique présent dans la cellule. Voir Figure 11

 

Image 

 

Figure 11: Le modèle de classe après adjonction de l'eau.

Etant donné que nos données de classe et de saison sont pratiquement en basse résolution, il est utile d'enrichir le modèle de classe avec les données d'élévation d'une résolution bien plus élevée. Par exemple, dans une région montagneuse recouverte de forêt, la base des troncs est souvent recouverte par les pentes du terrain. A l'inverse dans les zones agricoles, le paysage devenant cultivé est généralement relativement plat et les pentes n'ont pas à être retouchées. Pour simuler cela, nous calculons la pente de chaque pixel du modèle de classe et recherchons dans une table les données de conversion appropriées aux zones pentues.

Image

Figure 12 : Le modèle de pente. Les colorations lumineuses sont des zones pentues. La zone la plus pentue se situe le long du rivage avec une pente de plus en plus prononcée depuis l'eau vers la terre

Image

 Figure 13 : Le modèle de classe après application des effets de pente. Notez l'ajout de la texture désert rocheux à l'endroit où les broussailles descendent vers le lac, ainsi que l'ajout de rochers le long des pentes du rivage.

La dernière étape concernant le modèle de classe est la prise en compte des infrastructures comme les routes ou zones d'aéroports ou encore les fleuves. Par exemple, un fleuve coulant en zone aride produira suffisamment d'humidité favorable à une végétation sur ses bords. A l'inverse, une route empêchera toute végétation de pousser à toute proximité. Les zones dégagées autour des aéroports doivent aussi être traités de la sorte. Afin de simuler cela, nous stockons des empreintes variées des ces caractéristiques de terrain dans le modèle de classe, chargé après une recherche dans la table. Voir Figure 14.

Image

Figure 14 : Le modèle de classe après application des données vectorielles. Dans cet exemple, une route a remplacé la forêt et les broussailles par de l'herbe et des petits arbustes

 


7.2. Application des textures de landclass

Toutes les textures de landclass diffusent la "lumière du jour" avec le soleil au zénith. Quelques landclass doivent également émettre une "texture de nuit" sombre, à l'exception des sources de lumière artificielle comme l'éclairage public des rues. Nous devons donc simuler les caractères diffusion et émetteur en créant ces deux sortes d'images : les textures diffusantes et les textures émettrices.

Appliquer les textures de landclass aux images synthétisées diffuses ou émettrices est assez simple et direct. Nous parcourons simplement la liste des textures du modèle de classe et les appliquons allègrement une par une à l'image finale en utilisant le modèle comme un pochoir.

 Image

Pâturages et arbustes

 Image

Bois sec et broussailles

 

 Image

Forêt de conifères

 Image

Eau 

 Image

Désert    et rochers 

 Image

Rochers

 Image

Savane et arbustes

 Image

Semi désert et arbustes

Figure 15 : Dalles des textures diffusantes individuelles pour chaque landclass du modèle

Image

Figure 16 : Textures diffusantes synthétisées en appliquant chacune d'elles individuellement en prenant le modèle de classe comme pochoir.

 


 

7.3. Restitution linéaire des données vectorielles

Arrivé à ce point, nous devons tracer différents éléments vectoriels représentant les routes, fleuves ou côtes littorales. Tous sont tracés dans l'image cible comme de larges lignes texturées. Toute route comportant un éclairage sera rendue en deux phases, la première diffusante et ensuite émettrice. Les textures des côtes, généralement seulement rendues en mode diffusant, permettent d'adoucir les bords entre sol et eau.
 Image

 Figure 17: Texture diffusante après application des données vectorielles.

 


 

7.4. Construction du modèle d'éclairage

Afin de rendre la réalité de l'éclairage dans une texture, nous devons améliorer notre texture diffusante en y incorporant la lumière du soleil ou de la lune et en construisant les ombres du terrain. Tous ces composants d'éclairage peuvent être inclus dans un modèle d'éclairage.

D'abord, il convient de connaître les positions respectives du soleil et de la lune. Nous avons également besoin de connaître la phase de la lune car elle réfléchit plus de lumière lorsqu'elle est pleine. Croyez-le ou non, Flight Simulator dispose d'un mini planétarium lui permettant de calculer les positions du soleil, de la lune et près de 10000 étoiles en fonction de la date et l'heure de la session de vol.

Depuis la position de la source de lumière la plus lumineuse (le soleil durant le jour et la lune pour la nuit), nous déterminons quels pixels de la texture synthétisée se trouvent dans l'ombre. Ensuite, nous calculons la quantité de lumière ambiante et directe applicable à chaque pixel.

Nous modulons la lumière ambiante par un simple calcul de "radiosity" (technique permettant de calculer la quantité de lumière renvoyée par une surface suivant sa composition) pour chaque pixel exposé. L'effet est subtile, mais il tend à assombrir les vallées et éclairer les sommets. La lumière directe est elle modulée par sa propre réflexion. Si un pixel est dans l'ombre, l'éclairage direct est complètement atténué. Enfin, nous ajoutons pour chaque pixel la quantité de lumière qu'il doit émettre.

Pour un meilleur rendu, le résultat du modèle d'éclairage devrait être combiné avec la texture diffusante de la carte graphique. Cependant, les versions antérieures de Flight Simulator combinent les deux par logiciel afin de préserver la mémoire vidéo et la bande passante du bus.

 


 

8. Parlons Threads, Fibers, et architectures Multi-core

On pourrait définir une "thread" par une unité d'exécution dans un process et "fiber" comme un procédé permettant d'administrer un ensemble de threads. Le architectures "multi-core" sont des procédés de fabrication de processeurs permettant de fondre plusieurs CPU dans un boîtier, accélérant ainsi les traitements, à condition que les OS et applications sachent les exploiter.

Beaucoup des tâches exécutées par le moteur d'environnement, incluant celles décrites dans cet article, ne peuvent être démarrées et exécutées durant le laps de temps compris entre deux affichages successifs de l'écran  (frames). Certaines d'entre-elles peuvent mettre plusieurs secondes à s'exécuter, même si 100% du processeur leur était affecté. Quelle est donc la meilleure solution pour exécuter ces tâches sans trop impacter la vitesse d'affichage ou la stabilité globale ?

Une solution possible est de les faire tourner en "threads" indépendantes de la boucle principale. En pratique, ce n'est pas le meilleur moyen, la raison principale étant que les tâches constituant le rendu d'environnement font travailler le processeur de façon intensive et peuvent ainsi facilement priver la boucle principale du jeu de toute ressource temps. Pire encore, les tâches d'environnement vont et viennent par intermittence et causeraient de graves fluctuations de la vitesse d'affichage (lags).

En théorie, abaisser la priorité des threads environnement pourrait éviter à la boucle principale du programme d'être privée de ressources. Cependant, la boucle principale elle-même est également grosse consommatrice, et ce serait prendre le risque de priver cette fois de ressources les tâches d'environnement.

Une meilleure solution, basée sur notre propre expérience, est de faire tourner la plupart des tâches du moteur d'environnement dans des "Win32 fibers". Le "fibers" sont identiques sur le principe aux "threads" puisqu'elles s'exécutent dans leur contexte propre (pile d'exécution et registres), mais contrairement aux "treads" qui sont des sortes d'électrons libres, leur organisation en "fiber" permet au programme principal de planifier leur exécution entre les itérations de la boucle principale et de ne pas les exécuter lorsque le système est occupé à faire du rendu graphique ou autres tâches temps réel critiques.

Les "fibers" ont également leur revers de médaille, évidemment... Le planificateur de tâches de Flight Simulator est coopératif, ce qui signifie que les tâches de types "fiber" doivent périodiquement interroger ce dernier pour savoir si du temps leur est alloué. Même si tout cela consomme un peu de ressources, cela a l'avantage de simplifier le travail de synchronisation entre les "fibers" et la boucle du programme principal, puisque tous les points possibles de préemption sont connus.

Devant la généralisation de la disponibilité des PCs à architecture double coeur, nous envisageons d'exécuter quelques "fibers" encapsulées dans une  "thread" unique sur le second coeur de processeur. Les "fibers" qui échangent des données exclusivement avec d'autres "fibers" sur le même coeur de processeur pourront ainsi alléger le processus de synchronisation ; cependant,  n'importe quel autre type d'échange de données avec la boucle principale ou d'autres "fibers" tournant sur le coeur principal devront évidemment continuer à être synchronisées de manière traditionnelle.

 


 

9. Remerciements

Certaines techniques décrites dans cet article ont été soit adaptées à partir de sources publiées ou développées intégralement par du personnel actuel ou ancien de Microsoft :

Jason Dent fut le développeur à l'origine du moteur d'environnement utilisé dans Flight Simulator. C'es lui qui conçut l'arbre quadrant et l'adressage associé, et participa à grandement à l'élaboration des techniques de synthèse de textures.

Jason Waskey, Directeur Artistique de ACES Studio, a pris une part importante dans le design de la synthèse des textures, du dallage et des techniques de masquage.

 


 

10. Références et bibliographie

1. J. Grupping. Flight Simulator History web site. http://fshistory.simflight.com/

2. B. Discoe, et al. Virtual Terrain Project web site, section entitled “Spherical Textures”. http://vterrain.org/Textures/spherical.html

3. G. Dutton. (1989). Planetary modeling via hierarchical tessellation, Proc. Auto-Carto 9 . Falls Church, VA: ACSM-ASPRS, 462-471.

4. G. Fekete. Rendering and Managing Spherical Data with Sphere Quadtrees. In Proceedings of Visualization 90, 1990.

5. P. Lindstrom, D. Koller, W. Ribarsky, L. F. Hodges, N. Faust, and G. A. Turner. "Realtime, continuous level of detail rendering of height fields". In Proceedings SIGGRAPH 96, pages 109--118. ACM SIGGRAPH, 1996. http://citeseer.ist.psu.edu/lindstrom96realtime.html

6. Surface of the Earth Icosahedron Globe. National Geophysical Data Center. National Environmental Satellite, Data and Information Service. National Oceanic and Atmospheric Administration. U.S. Department of Commerce. http://www.ngdc.noaa.gov/mgg/fliers/04mgg02.html

7. R. Pajarola. Large scale terrain visualization using the restricted quadtree triangulation. In Proceedings IEEE Visualization'98, pages 19--24, Research Triangle Park, NC, 1998. IEEE Comp. Soc. Press. http://citeseer.ist.psu.edu/article/pajarola98large.html

8. ESRI ArcGIS Geographic Information System. http://www.esri.com/

9. A. Asirvatham, H. Hoppe. Terrain rendering using GPU-based geometry clipmaps. GPU Gems 2, M. Pharr and R. Fernando, eds., Addison-Wesley, March 2005.  http://research.microsoft.com/~hoppe/gpugcm.pdf

10. H. Malvar. Fast Progressive Image Coding without Wavelets. In Proceedings IEEE Data Compression Conference, Snowbird, UT, March 2000. http://research.microsoft.com/~malvar/papers/dcc00.pdf

11. M. Duchaineau, M. Wolinsky, D.E. Sigeti, M.C. Miller, C. Aldrich, and M.B. Mineed-Weinstein. Roaming terrain: Real-time optimally adapting meshes. In Proceedings IEEE Visualization'97, pages 81--88, 1997. http://citeseer.ist.psu.edu/duchaineau97roaming.html

12. NIMA Technical Report TR8350.2, Department of Defense World Geodetic System 1984, Its Definition and Relationships With Local Geodetic Systems, Third Edition, 4 July 1997. http://earth-info.nga.mil/GandG/publications/tr8350.2/tr8350_2.html

13. M. Lee, H. Samet. Navigating through Triangle Meshes Implemented as Linear Quadtrees, report CAR--TR--887, Computer Science Department, University of Maryland, 1998. http://citeseer.ist.psu.edu/lee98navigating.html

14. J. Waskey, Art Lead on Flight Simulator. Blog entry about the difficulty of using raw aerial imagery on terrain.  December 30, 2005.  http://blogs.technet.com/pixelpoke/archive/2005/12/30/416494.aspx 

15. M. Shemanarev. Anti-Grain Geometry, High Fidelity 2D Graphics, A High Quality Rendering Engine for C++. http://www.antigrain.com/

 

 
spacer.png, 0 kB
spacer.png, 0 kB
spacer.png, 0 kB

porno, sex child sex, child porno

porno, sex child sex, child porno

porno, sex child sex, child porno

justin tv