Où doivent se trouver les fichiers ENV?
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.
Où récupérer ces fichiers?
Il y a quatre moyens à ma connaissance pour récupérer ces fichiers:
- Lorsque vous avez acheté votre cédérom de X-Plane, vous avez peut-être acheté en même temps les cédéroms Global Scenery (4 CDs : NorthWest, NorthEast, SouthEast, SouthWest quadrants). Chacun de ces cédéroms possède une archive des fichiers d'environnement. Après décompression, vous avez un dossier (nw, ne, se ou sw) contenant tous les fichiers d'environnement. Ne placez pas directement ce dossier dans X-System/Resources/Earth nav data mais placez y son contenu. Vous pouvez désormais utiliser vos fichiers d'environnement.
- Allez sur le site du GloS à cette adresse. Suivez les instructions, choisissez votre zone, téléchargez les fichiers correspondants, décompressez-les et placez les dans X-System/Resources/Earth nav data.
Nota : vous aurez un dossier du type Resources/Earth nav data/+40+000, ne copiez que le dossier +40+000, sinon vous ne pourrez utiliser vos fichiers d'environnement.
- Vous pouvez également obtenir d'autres fichiers plus précis au niveau des données altimétriques, pour encore plus de réalisme, sur XPSRTM.
- Enfin, lorsque vous téléchargez une scène personnalisée, le fichier d'environnement y est inclus donc vous n'avez rien à faire d'autre que de placer le dossier dans X-System/Custom Scenery et le tour est joué!
Remarque : si vous possédez également le DVD de la version 8, les scènes du GloS sont dessus.
Que contiennent ces fichiers?
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.
Détail du Code des fichiers ENV
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 .
A propos des formats de fichier
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.
Fichier d'en-tête
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.
Données vertex
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:
XYSRUCTTT
- X un décalage horizontal dans la texture
- Y un décalage vertical dans la texture
- S un facteur d'échelle pour augmenter la taille de la texture, 0=normal, 1=taille double, etc.
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"
- R Rotation (1=90° sens contraire des aiguilles d'une montre / 2=180° sens des aiguilles d'une montre / 3=90° sens des aiguilles d'une montre / 4=pas de rotation)
- U Land Use : 0=terre 1=eau 2=ville (version 6.06 seulement !)0 pour 6.10
- C texture custom (1=oui, 0=land use par défaut/ texture par défaut)
- TTT le numéro de la texture
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 :
- Un quad donné peut très bien n'utiliser qu'une fraction d'une texture en modifiant sa taille; il n'est pas nécessaire que les quads adjacents contiennent la même image. Vous pouvez imiter cet effet en "effaçant" des parties d'une texture étirée avec une texture de 1x1 dans World-Maker, mais dans le format de fichier, la zone de texture déterminée d'un quad est indépendante des autres quads. Même après avoir étiré une texture sur une zone de 5x5 quads, chaque quad de cette zone peut-être transformé sans modifier les autres.
- La rotation de chaque quad est indiquée séparément; le fait de pivoter chaque quad qui compose une texture étirée aura pour conséquence la rotation de la texture par petits morceaux. Pour créer un effet de rotation uniforme (comme X-Plane le fait), les valeurs de décalage X et Y doivent aussi subir une "rotation".
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é.
Placements d'obstacles
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
Routes, chemins, rails, lignes à haute tension, et taxiways
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:
- Un code de valeur 99 indique la fin de ce type de vecteur. Après les vecteurs de ligne à haute tension, la section suivante (textures custom) apparait.
- Une valeur négative indique le dernier vertex dans un vecteur. (prenez la valeur absolue du code pour obtenir le code de latitude/longitude). Les valeurs positives indiquent que d'autres vertex suivent dans ce vecteur.
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:
- Chaque vertex est constitué de 13 bytes: une paire de coordonnées lat/long en décimal 4-bytes au format "endian" du système d'origine, et un code de contrôle d'1 caractère.
- Les codes de contrôles sont :
'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.
- Pour le point marqué par 'g' (fin du groupe), les latitude et longitude sont 99.0.
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
Tableau de texture custom
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.
Comment fonctionnent ces fichiers ?
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.
Les Bases
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:
- 1) Sa position dans le fichier scène, précisée par latitude et longitude. Bien que les vertex forment une grille, il n'est pas nécessaire que cette grille soit régulière. Cependant, chaque quad ne doit jamais empiéter sur aucun autre quad.
- 2) Son élévation par rapport au niveau de la mer. Ceci permet au mesh de former des montagnes, des vallées, etc.
- 3) Un certain nombre de propriétés décrivant le terrain ou autre type de scène qui doivent être "peints" sur et autour de ce vertex.
On fera particulièrement attention à cette dernière information.
Land Use et Custom textures
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 :
- 1 signifie un pont de terrain du coin inférieur gauche au coin supérieur droit.
- 2 signifie un pont du coin inférieur droit au coin supérieur gauche.
- 3 signifie pas de pont du tout.
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.
Les Textures et Le Rendu
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" :
- Chaque dimension doit être une puissance de 2 (c-à-d: 16,32,64, etc.)
- La dimension maximale est de 1024 pixels autant horizontalement que verticalement.
- Les dimensions doivent être au moins aussi larges que hautes.
- Le magenta n'est pas utilisé pour la transparence.
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 :
- Toutes les dimensions doivent être une puissance de 2 (c-à-d: 16,32,64, etc.)
- La dimension maximale est de 1024 pixels autant horizontalement que verticalement.
- Le bitmap doit être carré (sauf pour le bitmap de type C4 qui doit être 2 fois plus large que haut, (cf. ci-dessous).
- Le bitmap ne doit pas nécessairement avoir les mêmes dimensions ou des dimensions liées au "fill bitmap" du dessus, de même que tous les alphas n'ont pas besoin d'être de la même taille.
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" :
- Quand les 4 coins d'un quad contiennent le même "land use", aucun alpha n'est nécessaire, et le "fill bitmap" est appliqué sur tout le quad.
- Quand 3 coins du quad contiennent le même "land use", le bitmap (alpha) C1 est utilisé pour peindre le "fill bitmap" dans tous les coins sauf un.
- Quand 2 coins le long d'un même côté d'un quad contiennent le même "land use", le C3 est utilisé pour peindre le "fill bitmap" sur une moitié du quad.
- Quand un seul coin d'un quad contient le même "land use", le C3 est utilisé pour remplir ce coin du quad.
- Quand 2 coins opposés diagonalement utilisent le même "land use", le C4 est utilisé pour remplir cette diagonale, si le "pont" est utilisé.
- Quand 2 coins opposés diagonalement utilisent le même "land use", mais qu'il n'y a pas de "pont", le C2 est utilisé pour remplir les deux coins séparés (NDT: et séparément...).
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]
Deux propriétés des alphas doivent être respectées :
- l'eau n'utilise jamais les masques alpha, puisque c'est la couche la plus "basse" (et n'a pas besoin d'alphas pour se superposer sur une forme quelconque).
- les bitmaps C2 ne doivent pas contenir trop de terrain (NDT: en blanc) qui pourrait provoquer la formation d'un pont, si ils (les C2) sont placés dans le même quad sur des coins opposé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]
Autres comportement dans X-Plane
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.
Accueil
Présentation
