Le dossier par défaut contenant ces dossiers/fichiers est X-System/Resources/Earth nav data. Allez y jeter un coup d'œil, vous comprendrez mieux la suite ;-)
On a bien notre dossier "Earth nav data" contenant des dossiers aux noms bizarres contenant eux-même nos fichiers d'environnement. Si vous avez un dossier "Earth nav data" ayant cette allure, vous devez avoir accès aux fichiers d'environnement correspondants.
Il existe un autre endroit où vous pouvez trouver ces fichiers, c'est dans X-System/Custom Scenery. En effet, lorsque vous voulez améliorer une partie du monde (textures, objets, aéroports,...), vous modifiez une copie de ces fichiers d'environnement.
Il y a quatre moyens à ma connaissance pour récupérer ces fichiers:
Remarque : si vous possédez également le DVD de la version 8, les scènes du GloS sont dessus.
Ils contiennent les informations sur les textures utilisées (lesquelles, où et comment), sur le relief (altitude), sur les vecteurs (routes, lignes à haute tension, rivières et canaux, taxilines) ainsi que sur les objets personnels (position, orientation).
Pour mieux comprendre comment les données de ces fichiers agissent dans X-Plane, consultez cette page: Le terrain de la v7
Vous pouvez regarder à l'intérieur de ces fichiers grâce à un petit utilitaire nommé "Env2CSV" disponible gratuitement avec les XPTools. Le fichier CSV pourra être ouvert avec un éditeur de texte et vous pourrez voir les infos de la zone présentées comme ceci:
################################################### # MESH / Modelé du Terrain ################################################### # carrés de 201 x 151, du SW au NE, adjacent=est # lat,lon,elevation,landuse,custom,rotation,scale,xoffset,yoffset,joincode 48.000000,2.000000,131.000000,25,0,0,0,0,0,0 48.000000,2.006701,130.000000,30,0,0,0,0,0,0 48.000000,2.013301,131.000000,60,0,0,0,0,0,0 48.000000,2.020002,132.000000,60,0,0,0,0,0,0 ....... etc, etc, etc… ################################################### # OBJECTS ################################################### # Variable number of objects, ends with 'END' # type , lat , lon , elevation , rotation , Emplacement / nom de l’objet 2,48.890713,2.246791,262.467407, 2,48.892242,2.246063,262.467407, 2,48.891525,2.245991,262.467407, 2,48.888081,2.241260,262.467407, 8,48.892727,2.235475,115.000000,Monuments\ArcheDefense 8,48.874008,2.295191,116.000000,Monuments\ArcDeTriomphe 8,48.805332,2.119498,23.000000,Monuments\VersaillesChateau 8,48.858471,2.294240,43.000000,Monuments\TourEiffel 8,48.852795,2.350571,296.000000,Monuments\NotreDame ....... etc, etc, etc… END ################################################### # VECTORS / vecteurs ################################################### # Variable number of vector sets, each ends with END # lat, lon, is last # Roads / routes 48.928192,2.000000,0 48.924492,2.004200,0 48.723473,2.429043,0 48.722374,2.423842,0 48.720871,2.420142,0 48.717972,2.415041,0 48.714672,2.408241,1 ....... etc, etc, etc… END ################################################### # TEXTURES ################################################### # Variable number of texture file names, ends with END B1 B2 B3 B4 Bb5 Foret Untitled coinforet_champ-ouvert champ-ouvert passagechamp-ouvert_foret CentreParis1 CentreParis2 CentreParis3 Untitled Untitled Untitled Untitled Untitled Untitled ....... etc, etc, etc… END
Cette visualisation sous forme de texte vous permet de modifier un élément sans passer par World-Maker, elle permet aussi de récupérer des informations d'une autre scène (située sur la même zone que celle que vous voulez modifier) et de les ajouter à votre travail sans tout reprendre à zéro. Une fois vos modifications effectuées, un passage par Env2CSV vous re-transforme le fichier texte en fichier .env prêt à être utilisé dans X-Plane.
Ce document a été initialement écrit et mis en ligne le 27 novembre 2002 et reflète le système de scènes d'X-Plane 6.5 à X-Plane 7.x .
les fichiers .env 6.x sont des fichiers binaires. Ils peuvent être de type "little-endian" ou "big-endian", selon le programme qui les a créés, donc tout programme doit envisager d'avoir à manipuler des problèmes de compatibilité au niveau "endian".
L'agencement d'un fichier .env 6.06 est :
1) fichier d'en-tête 2) données vertex (format 6.06) 3) placements d'obstacles 4) textures custom (format 6.06)
Le format d'un fichier .env 6.10-6.50 est légèrement différent :
1) fichier d'en-tête 2) données vertex (format 6.10) 3) placements d'obstacles 4) les routes, chemins, rails et lignes à haute tension, éventuellement les taxiways et peut-être les fleuves. 5) textures custom (format 6.10)
Les renseignements ci-dessous ont été séparés comme suit : - données pour la version "6" - toutes les autres versions ultérieures
La plupart des versions depuis la "6.1" sont très semblables. Le format de fichier .env a surtout connu des changements de la version 6 à la version 6.1.
Les données qui suivent donnent les détails des caractéristiques de chaque section. Toutes les chaînes de caractères sont de type ASCII. Les séparateurs de répertoire devraient être cohérents avec leur environnement d'origine.
Le fichier .env 6.x débute par un en-tête de 5 bytes :
Champ taille type de donnée contenu signification Type "endian" du fichier 1 byte char 'a' ou 'i' Big-endian ou Little-endian Version 4 bytes long int 6,61,631 ou 650 version "endian" d'origine
L'en-tête commence par un caractère de 1 byte : 'a' minuscule ("Apple") signale le type "Big-endian", 'i' minuscule ("Intel") signale le "Little-endian". Sauf exception signalée, tous les entiers 2-bytes ou 4-bytes et toutes les valeurs décimales 4-bytes seront du type "endian" précisé dans l'en-tête.
La version identifie de quel format les sections suivantes seront, ainsi que l'agencement du fichier. Les tableaux ci-dessus indiquent quelles sections sont incluses dans quelle version de fichier.
REMARQUE : les versions précédentes de cette caractéristique étaient fausses; la version [NDT: ??] est un entier de type long int 32-bits, au format "endian" d'origine.
Chaque version d'X-Plane est compatible par ascendance avec les formes précédentes du fichier .env, jusqu'à l'original. Ce tableau indique quelle application d'X-Plane est requise pour lire une version de fichier donnée. Chaque version de World-Maker créée la version la plus récente qu'il connaisse d'un format.
Version de format de fichier 6 61 631 650 Version minimale d'X-Plane pour lire le fichier 600 610 640 650 Changements importants depuis la version précédente La taille de Land uses Ajout des Ajout des la grille ,vecteurs taxiways vecteurs de devient de routes fleuves 201x151 etc. /cours d'eau
X-Plane 7 lit les 4 versions "6" des formats .env listées ci-dessus, mais ne crée que le format de fichier 650.
La section de données vertex contient les définitions des points de grille qui forment le paysage ou le mesh de terrain, etc. en question. Chaque fichier .env 6.x est organisé selon une grille de 151 points à l'horizontale sur 201 à la verticale, ce qui donne 150x200 quadrilatères. Les vertex apparaissent dans l'ordre dans le fichier, depuis le vertex le plus bas à gauche jusqu'au vertex le plus bas à droite, puis continue sur la rangée immédiatement au-dessus, en commençant par la gauche, etc., comme indiqué sur la figure de droite.
Le vertex d'en bas à gauche correspond à la latitude et à la longitude d'après lesquelles le fichier .env est nommé. Dans l'exemple ci-dessus, il s'agirait du carré .env pour latitude +42 et longitude +71. Chaque fichier .env couvre 1 degré de latitude et de longitude, la latitude des vertex supérieurs et la longitude des vertex de droite étant des multiples pairs de degrés.
Pour les textures custom et les textures par défaut 6.06, la texture d'un quad est spécifiée par le vertex qui indique son coin inférieur gauche.; les vertex supérieurs et de droite sont ignorés. Pour les textures par défaut 6.10 (basé sur les land uses), le coin de chaque quad est texturé séparément par le land uses de ce vertex. Chaque vertex crée ainsi un patch de quad texturé de 1x1, centré autour du vertex.
Chaque vertex de version 6.06 possède la structure suivante :
Champ latitude longitude altitude données de textures Longueur 4 bytes 4 bytes 4 bytes 4 bytes Type décimal décimal décimal entier Contenu la latitude des la longitude des l'altitude des les propriétés vertex en deg.déc vertex en deg.déc vertex en de texture mètres ASL (voir ci-dessous) (au-dessus du niveau de la mer)
Les latitude, longitude et altitude sont simplement stockées en tant que coordonnées décimales. Les données de texture sont encodées une fois de plus en tant que "caractères" décimaux dont l'interprétation est la suivante:
version 6.13 uniquement: pour les textures custom, ce champ est le même. Pour le land use par défaut, ceci est un "join code"
Chaque champ de texture contient un numéro de texture entre 0 et 999. Pour les textures custom, c'est un indice de base 1 [NDT: à revoir] vers le tableau de textures custom situé à la fin du fichier. Pour les textures intégrées, c'est soit un des 16 codes de scène par défaut (pour la version 6.06), soit un code de land use (version 6.10). Le champ de texture custom contient un flag, 0 ou 1, qui sert à déterminer le type de texture en question.
X-Plane 6.06 utilisait un flag qui spécifiait le "land use" pour un vertex donné; un 1 dans ce champ indiquait que le quad situé en haut à droite du vertex était de l'eau. Un 2 indiquait que la scène dynamique devait être dessinée; cette scène dynamique était toujours des maisons, sauf dans quelques cas particuliers de textures par défaut. Étant donné que la version 6.10 utilise une grande variété de land uses (dans le champ du numéro de texture), ce champ n'est pas utilisé et doit toujours contenir 0. La version 6.10 place les scènes dynamiques selon le land use, etc.
Le champ "rotation" précise une des 4 orientations possibles pour la texture, comme indiqué dans le tableau. N'importe quelle texture custom peut être pivotée, mais les textures par défaut ne peuvent être pivotées que dans la version 6.06.
X-Plane peut étendre une texture sur plusieurs quads. Ceci est obtenu en dessinant seulement une partie de la texture sur chaque quad. Pour indiquer ce comportement, un facteur d'échelle peut être appliqué. Le facteur d'échelle est le nombre multiplicateur de la taille apparente de la texture MOINS UN; c-à-d 0=pas de changement de taille, 1=taille double, 2=taille triple, etc.
Ceci réduit donc la quantité de texture apparaissant dans un quad par 1/(taille+1). Les facteurs de décalage X et Y indiquent quelle partie de la texture doit être utilisée, du fait que chaque quad en affichera seulement une partie. Un décalage de 0 désigne le coin inférieur gauche de la texture; Un X positif indique un décalage vers la droite; Un Y positif indique un décalage vers le haut. La valeur maximale pour le décalage est la valeur d'échelle. [NDT: ?? la limite de taille, sans doute...]
Notez deux choses à propos de ce schéma qui peuvent passer inaperçues lors de l'utilisation de World-Maker :
Pour X-Plane 6.13 le code d'échelle est partagé; pour le terrain par défaut (type "land use"), ce code est maintenant un "join code". Pour les fichiers 6.10, ce code doit toujours être 0 pour le terrain non-custom (puisque le terrain non-custom ne peut pas être étiré).
Un join code est appliqué au quad dont il est le coin inférieur gauche (coin Sud-Ouest). Le join code indique si les coins de ce quad se connecteront ou pas, s'ils ont le même land use appliqué. Le join code doit être 0 si les coins ont un type de land use différents.
code 0 1 2 3 connexion du coin inférieur gauche au X-Plane décide lui-même oui non non coin supérieur droit? connexion du coin inférieur droit au X-Plane décide lui-même non oui non coin supérieur gauche? description ce code indique qu'X-Plane ceci connecte ceci connecte ceci conserve les peut décider du type une diagonale l'autre diagonale deux diagonales de jonction, et est non connectées utilisé par souci de compatibilité ascendante.
Les join codes supérieurs à 3 sont réservés et ne doivent pas être utilisés.
Dans X-Plane 6.06, les numéros de texture par défaut étaient les suivants:
numéro 0 1 2 3 texture herbe montagnes eau zone résidentielle numéro 4 5 6 7 texture zone commerciale zone industrielle champs mi-herbage_mi-montagnes numéro 8 9 10 11 texture 3/4 herbe_1/4 montagne 1/4 herbe_3/4 montagne mi-herbage_mi-eau 3/4 herbe_1/4 eau numéro 12 13 14 15 texture 1/4 herbe_3/4 eau mi herbage_mi-résidentiel 3/4 herbe_1/4 résidentiel 1/4 herbe_3/4 résidentiel
Un vertex de la version 6.10 prend la forme suivante :
Champ code de latitude/longitude altitude Code texture Longueur 4 bytes 2 bytes 4 bytes Type entier entier signé "Big endian" entier Contenu une valeur encodée de l'altitude propriétés de textures latitude et de longitude (encodée aussi) comme décrites ci-dessus
Les latitude et longitude d'un vertex dans 6.10 sont compressées selon le schéma suivant:
1) la valeur des latitude et longitude du vertex inférieur gauche du fichier .env (celui qui donne son nom au fichier .env) est soustraite des latitude et longitude des vertex. Ces latitude et longitude du coin inférieur gauche sont les latitude et longitude de référence. Les [deltas] des latitude et longitude qui en résultent se situent entre 0.0 pour les bords gauche et inférieur, et 1.0 pour les bords supérieur et droit.
2) les [deltas] des latitude et longitude sont alors chacun multipliés par 9999.0 et arrondis à l'entier pair le plus proche. La latitude est multipliée par 10000 et ensuite on en fait la somme [NDT: ?].
De cet encodage résultent 2 numérateurs supérieurs à 9999, stockés sous forme décimale qui désigne des fractions de degrés.
L'altitude est stockée en mètres ASL (au-dessus du niveau de la mer), plus 10000. Ce nombre est toujours un Big-endian; c'est la seule partie du fichier .env qui est ainsi.
Le code texture pour la version 6.10 est le même que pour la 6.06, sauf que les numéros de texture par défaut sont des "land uses", et que le champ de land use est ignoré.
La section de données d'obstacle contient une liste d'obstacles et leur placements. Cette section varie en longueur et utilise un "stop-marker" pour en indiquer la fin. Cependant, il y a une limite finie au nombre d'obstacles qui peuvent être placés dans la section. Je ne connais pas actuellement la valeur de obsDIM.
Chaque objet commence par un code de type entier. C'est un entier signé 4-bytes, dans le format "endian" du système d'origine. Une valeur de 99 indique la fin de la section de placement d'objet; aucune autre donnée concernant les obstacles ne doit suivre. Si la valeur est autre que 99, cette valeur est un code de type objet. Les champs suivants sont alors lus :
Champ latitude longitude rotation/orientation Longueur 4-bytes 4-bytes 4-bytes Type décimal décimal décimal Contenu la latitude de la longitude de l'élévation de l'obstacle par défaut l'obstacle l'obstacle en mètres(explication plus bas)ou la rotation de l'obstacle custom en degrés.
Les types d'obstacle suivant sont définis :
type obstacle: 1 2 3 4 5 6 7 8 description: tour de gratte-ciel tour radio relai de château usines inutilisé obstacle contrôle centrale d'eau avec (réservé) custom électrique cheminées
Les latitude et longitude de l'obstacle sont en degrés décimaux. Le champ rotation/orientation correspond à la hauteur de l'obstacle au dessus du niveau du sol pour les obstacles par défaut. Pour un obstacle par défaut, ceci spécifie le nombre de degrés de rotation de l'obstacle depuis son orientation naturelle.
Pour les textures custom, un nom d'obstacle de 150 caractères suit le champ d'orientation. Ce champ est complété avec des zéros et contient le nom du fichier (sans l'extension .obj), en incluant n'importe quel chemin partiel, et en utilisant l'indicateur de répertoire du système d'origine depuis le répertoire Custom Objects. Par exemple, la chaîne de caractères:
MyFunkyTrains\SteamEngine
s'étendrait jusqu'au chemin complet de fichier suivant:
C:\Program Files\X-System 6.10 Folder\Resources\Custom Objects\MyFunkyTrains\SteamEngine.obj
La section des vecteurs contient des spécifications pour les vecteurs de routes, de chemins, de lignes de chemin de fer, de lignes à haute tension, et éventuellement de taxiways. Chacun de ces types de vecteurs utilise le même format, et ils apparaissent dans l'ordre indiqué précédemment.
Chaque vecteur consiste en une série de valeurs de latitude/longitude encodées en un seul entier, à la manière dont les vertex de la version 6.10 sont encodés. Cet entier est de type "4-bytes int", au format "endian" d'origine. Deux codes particuliers doivent être soulignés:
Du fait que 99 possède une signification particulière, il existe un point de code latitude/longitude pour un point de vecteur non-terminé qui ne peut PAS être utilisé, car il est utilisé comme marqueur de fin de fichier. Pour garantir l'intégrité du fichier, lorsque vous écrivez des points de vecteur, vérifiez toujours s'il n'y a pas un encodage accidentel de 99 à partir d'un code de lat/long valide, et ajoutez ou soustrayez 1 pour empêcher la formation d'un marqueur de fin de fichier. On appellera ce type d'encodage "encodage STANDARD de vecteur" dans le tableau suivant.
Les taxiways n'apparaissent que dans les versions 6.40 et supérieures du fichier, notés par un numéro de version "631" dans l'en-tête de fichier. Les taxiways sont différents des autres vecteurs; ils sont au format suivant:
'c' si un point donné n'est pas le dernier dans un segment de taxiway, 'e' s'il est le dernier dans un segment, et 'g' pour marquer la fin des données de taxiway.
On appellera ce type d'encodage "encodage DECIMAL" dans le tableau qui suit.
Les fleuves sont inclus dans les versions 6.50 et supérieures du fichier, notés par un numéro de version "650" dans l'en-tête. Les fleuves sont encodés au même format que les routes, etc.
Le tableau suivant résume les vecteurs inclus dans un fichier .env dans leur ordre d'apparition:
Données: routes chemins rails lignes à h.tension taxiways fleuves Encodage: standard standard standard standard décimal standard Version minimale du fichier: 61 61 61 61 631 650 version minimale d'X-Plane: 610 610 610 610 640 650
La dernière partie du fichier .env est le tableau de texture custom. Chaque entrée est tout simplement une chaîne de 150 caractères, complétée à l'aide de zéros, indiquant un nom de texture (sans l'extension .bmp). Tout comme pour les chemins d'accès des obstacles, on peut indiquer un chemin partiel à partir du dossier "Custom Objects Textures".
Le tableau de texture custom se termine simplement à la fin du fichier. Les fichiers 6.06 doivent contenir des entrées vides (contenant "Untitled" plus un remplissage avec des zéros) pour toute la taille maximale du fichier. Les tableaux de texture 6.10 varient en longueur et peuvent se terminer lorsqu'aucune texture n'est disponible. Les entrées inutilisées doivent contenir une entrée "Untitled" complétée par des zéros. La taille maximale du tableau de texture a pu être de 100 textures dans de précédentes révisions d'X-Plane, mais elle est de 500 textures dans la version 6.10.
Le système de scènes d'X-Plane a subit des changements significatifs avec la sortie d'X-Plane 6.10 et les versions qui ont suivi. Le système de scènes "par défaut" a été complètement revu de manière à fournir un système de rendu beaucoup plus puissant et souple. Ce document décrit le concept du nouveau système de rendu pour les créateurs qui souhaiteront revoir et éditer des scènes.
La forme de base d'un fichier scène n'a pas changé; un fichier scène contient des données concernant un rectangle de terrain d'environ 1x1 degré. Les fichiers scènes sont toujours nommés selon les coordonnées de leur coin Sud-Ouest; par ex: le fichier -42+071 contient tous les points entre les latitudes 42-sud et 41-sud, et entre les longitudes 71-est et 72-est incluses.Le fichier scène contient un "mesh" qui décrit la forme du terrain dans ce rectangle de 1x1 degré.
Le "mesh" contient une série de vertex (sommets, coin d'arêtes; ici: intersections), ou points distincts sur la grille. Chaque vertex repose sur une grille contenant 201 points du Nord au Sud et 151 points de l'Est à l'Ouest. Chaque série de 4 points forment un "quad". Comme tous les quads sont contenus (dans la grille), il y a 200 quads du Nord au Sud et 150 quads de l'Est à l'Ouest. Les vertex sur le bord Est d'un fichier scène touchent le bord Ouest du fichier scène suivant. Mais ces vertex du bord ne doivent pas nécessairement avoir les mêmes coordonnées que leurs correspondants dans le fichier suivant.
Il est important de faire la distinction entre vertex(s) et quads. Souvent, les propriétés d'un quad sont spécifiées par le vertex Sud-Ouest du quad en question. Mais parfois, les 4 vertex d'un quad contribuent à définir ses propriétés. Par exemple, comme les vertex de droite et d'en haut (d'un fichier scène) ne sont les vertex Sud-Ouest d'aucun quad dans le fichier scène en question, certaines de leur caractéristiques sont parfois ignorées.
Chaque vertex contient les données suivantes:
On fera particulièrement attention à cette dernière information.
Il existe 2 catégories d'images qui peuvent apparaître sur du terrain dans X-Plane: les "land uses" et les "textures custom".
- Une texture custom reste telle qu'elle a toujours été : une image bitmap, réalisée par le créateur de la scène et couvrant ce quad.
- Un "land use" est une description du type de terrain ou eau dont ce vertex est proche. Ces codes sont appliqués aux textures, mais ils ont tendance à préciser des renseignements d'ordre géologiques, plutôt qu'en terme de représentation visuelle. Par exemple, vous pouvez spécifier "stony desert" (NDT: désert rocailleux) pour un point, mais c'est X-Plane qui décide de la couleur des pierres.
Les "land uses" et les "textures custom" sont rendus de manière légèrement différente. Une "texture custom" est appliquée directement sur un quad dont le vertex Sud-Ouest contient les données de cette "texture custom". Les "textures custom" sont toujours carrées, et si une "texture custom" est spécifiée pour les vertex du bord de droite ou d'en haut, elle n'apparaîtra jamais.
Les "land uses", par contre, sont rendues de manière centrée autour d'un vertex. Chaque vertex provoque l'apparition d'un "morceau" de ce "land use" autour du vertex ( d'environ la moitié de la largeur du quad ). Si les 4 vertex d'un quad ont le même "land use", les morceaux se rejoignent pour couvrir entièrement le quad. Mais là où des "land uses" différents co-existent, les morceaux auront tendance à se rejoindre près du centre du quad. Comme les "land uses" sont rendus autour des vertex, les "land uses" appliqués sur les bords d'en haut et de droite du fichier ont leur importance.
Les "land uses" utilisent des ordres de priorité; lorsque plusieurs "land uses" sont présents sur les vertex d'un seul quad, ils empièteront les uns sur les autres en fonction de leur indice de priorité. L'eau a toujours la priorité la plus faible et donc apparaît "au fond". D'autres "morceaux" leur sont alors superposés. La proportion de différents "land uses" dans une zone donnée n'a pas d'importance; l'ordre de priorité est toujours respecté.
Si de minces enchaînements d'un même "land use" se trouvent être alignés Nord-Sud ou Est-Ouest, ils formeront toujours de fines bandes par connexion. Mais si le "land use" est enchaîné sur une diagonale étroite, il peut y avoir ou non connexion (NDT: visuellement):
Comment X-Plane sait-il si une série de vertex en diagonale doit former une bande ou une séries d'îlots? La réponse est que chaque vertex spécifie un "join code" (NDT: code de jonction). Un "join code" dit à X-Plane comment lier, ou ne pas lier, des "land uses" du même type en diagonale. Le "join code" est indiqué sur le coin Sud-Ouest du quad sur lequel la diagonale va se former. Un "join code" fera dessiner un "pont" à X-Plane ou rien du tout.
Les "join codes" sont définis comme suit :
Notez que vous ne pouvez pas faire de lien dans les deux directions; par définition, un pont supplanterait l'autre.
Le "join code" "0" est particulier et demande à X-Plane d'agir selon sa propre meilleure solution. X-Plane va observer le terrain environnant et essayer de déterminer si dessiner un pont est une bonne idée ou non. Pour les anciens fichiers .env, tous les "join codes" seront de type 0, ce qui force X-Plane à générer des ponts automatiquement. Le "join code" sera aussi de type 0 pour les quads qui n'ont pas besoin de pont (parce qu'ils n'ont pas de "land use" en diagonale).
Les "join codes" sont importants car ils permettent de définir des bandes de terrain ou d'eau très étroites.
Les "land uses" sont centrés autour des vertex, alors que les "textures custom" sont situés dans les quads. Lorsque le vertex d'une "texture custom" est à côté d'un vertex de "land use", X-Plane étire le "land use" de manière à remplir l'espace vide.
X-Plane utilise deux ensembles de données d'image pour dessiner les "land uses", ainsi qu'un "map" (NDT: carte, plan). Le map est un fichier texte qui associe des fichiers bitmap à des "land uses" particuliers. On peut utiliser un fichier bitmap pour plusieurs "land uses"; normalement X-Plane est livré avec environ 3 douzaines d'ensembles de bitmaps pour environ 60 "land uses" définis. Plusieurs autres "land uses" ne sont pas encore définis, et sont réservés à un développement futur. Chaque terrain est défini par un "fill bitmap" (NDT : bitmap de remplissage) qui indique quelle image le "land use" utilisera, et des "bitmaps alpha" qui définissent comment ces bitmaps se superposent (NDT : en terme de forme).
Le "fill bitmap" contient une simple image RVB (NDT:en couleurs rouge-vert-bleu) du "land use". Quelques règles s'appliquent aux "fill bitmaps" :
Les "fill bitmaps" sont toujours traités comme des carrés. Si le "fill bitmap" est en largeur, chaque "carré" est traité comme une version séparée du bitmap, et sera utilisé pour varier la scène.
Les bitmaps alpha contiennent un masque en noir et blanc qui décrivent comment une texture donnée sera appliquée (NDT :en terme de forme) sur les autres textures. Le blanc indique que le "land use" sera dessiné, le noir qu'il ne le sera pas. Les valeurs de gris mélangent le "land use". Le "land use" doit posséder les propriétés suivantes :
Pour chaque "fill bitmap", 4 bitmaps alpha sont définis, et nommés par les extensions C1,C2,C3 et C4 (on utilisera ces suffixes pour s'y référer). Chaque masque alpha contient 4 rotations du même type de forme, indiquées ci-dessous, sauf pour le C4, qui contient seulement 2 rotations.
La raison pour laquelle 4 variations de chaque coin sont fournies est double : ceci apporte plus de variété dans la forme des côtes, et les textures de "land use" ne peuvent pas être pivotées; elles contiennent souvent des ombres qui apparaissent incohérentes lorsque certaines, mais pas toutes, sont pivotées par incréments de 90 degrés.
Chaque masque alpha joue un rôle différent dans le rendu des "land uses" :
L'exemple ci-dessous illustre comment une côte de forme complexe peut être fabriquée à partir d'une série de masques alpha.
Cette image montre comment plusieurs bitmaps sont superposés lorsque des "land uses" se rejoignent.
[image ci-dessus : on utilise les masques C2 et C3 pour créer l'assemblage des coins et des côtés]
[image ci-dessus : Bon: Deux coins ne forment pas de pont (blanc = terrain) Mauvais: Deux coins forment un pont de terrain Ce coin est probablement trop large]
X-Plane traite également en quelques étapes un fichier .env qui permet de changer ce que vous spécifiez :
Le terrain situé sous un aéroport sera changé en "land use" pour cet aéroport. Étant donné que, souvent, les données gouvernementales utilisées pour construire les scènes du monde entier ne précisaient pas les îlots artificiels sur lesquels beaucoup d'aéroports modernes sont installés, beaucoup d'aéroports reposent directement sur l'eau. X-Plane "remplit" quelques quads pour garder l'aéroport au sec. Notez que, de ce fait, une île ou une péninsule apparaîtra parfois trop large.
Sur l'image qui suit, l'aéroport de Gênes (entièrement construit à partir de remplissage) est sous l'eau, parce que l'îlot artificiel n'était pas inclus dans les données gouvernementales. Cependant, cet aéroport apparaît sur la terre ferme dans X-Plane..
Sur cette image-ci, l'aéroport de Boston Logan repose sur une péninsule. Cependant, X-Plane y ajoute un petit peu plus de terrain, comme une "assurance" contre l'inondation de l'aéroport. Le résultat est que les voies d'eau autour de l'aéroport se changent entièrement en terre ferme.
Les futures versions d'X-Plane et du GLoS scenery project tenteront de régler ce problème.
Autre chose, X-plane "aplatit" l'eau jusqu'à un certain degré pour éviter qu'elle n'apparaisse comme un creux. L'eau bleu clair sur cette image tirée de World-Maker est faite de quads où la moitié de l'eau est plus élevée que l'autre moitié. X-Plane réduira la hauteur de cette eau pour éviter que l'eau n'ait l'air d'être en diagonale. C'est fait pour conserver la hauteur des berges de la rivière ou du plan d'eau, de manière à ce que les rendus futurs des fjords soient plus précis.
Si un "join code" est zéro mais nécessaire (c-à-d qu'il y a du "land use " en diagonale), X-Plane devinera si le terrain doit former un pont en se basant sur l'eau et le terrain environnants. Ce processus de devinette du "join code" fonctionne la plupart du temps et sert de sauvegarde de compatibilité avec les scènes plus anciennes.