Ce texte fait référence au texte anglais ici.
Vous pouvez également consulter une approche moins "théorique" de ce format obj ICI.
Ceci est la spécification du format de fichier OBJ8, (c) de Laminar Research 2005, Tous Droits Réservés
16/10/16 : Mise à jour pour X-Plane 1050
31/07/12 : Mise à jour pour X-Plane 1010
14/03/12 : Mise à jour pour X-Plane 1000
03/12/09 : Ajout de la carte des normales et des paramétrages des lumières pour 9.40
16/06/09 : Ajout des nouveaux manipulateurs pour 9.30 b13
28/04/09 : Édition des ATTR_light_level
06/04/09 : Corrections de fautes
04/02/09 : Mise à jour pour X-Plane 9.30
25/09/08 : Mise à jour pour X-Plane 9.20
26/12/07 : Mise à jour pour X-Plane 9
05/04/07 : Clarification de l'utilisation des lumières personnalisées
12/07/06 : Révision pour X-Plane 8.50
16/09/05 : Écriture initial
Le format initial OBJ8 a été réalisé à partir de X-Plane 8.16. Pour X-Plane 8.50, 9.00, et 9.20, le format a été étendu
CHANGEMENTS pour la 9.40 :Les fonctions suivantes deviennent disponibles avec X-Plane 9.40 :
CHANGEMENTS pour la 9.30 : Les fonctions suivantes deviennent disponibles avec X-Plane 9.30 :
CHANGEMENTS pour la 9.20 : Les fonctions suivantes deviennent disponibles pour X-Plane 9.20 et plus :
CHANGEMENTS pour la 9.00 : Les fonctions suivantes deviennent disponibles pour X-Plane 9 et les versions ultérieures :
CHANGEMENTS pour la 8.50 : Les fonctions suivantes ne sont disponibles que pour X-Plane 8.50 et plus :
Les fichiers des objets (OBJ8) d'X-Plane 8 et 9 sont des fichiers texte qui se composent d'enregistrements (un par ligne). Chaque fichier décrit un seul modèle 3D. OBJ8 ne prétends pas être compatible avec les versions futures ; il est admis que lorsque le format sera étendu, les lecteurs écrits pour cette spécification ne seront pas en mesure d'afficher le nouveau format de fichier (qui peut contenir de nouvelles fonctionnalités).
OBJ8 est censé être rétrocompatible : on suppose que les lecteurs d'une future révision d'OBJ8 continueront à lire les fichiers OBJ8 actuels.
Les modèles OBJ8 sont spécifiés en mètres. Dans leur orientation native, l'axe Y positif est orienté vers le haut, l'axe X est positif vers l'est, et l'axe Z est positif vers le sud. (Il s'agit d'un système de coordonnées orthogonal). Le point 0,0,0 est un point sur le sol où l'objet a été placé dans X-Plane Scenery. Le fichier de scène d'X-Plane qui référence l'objet (NDT : le fichier DSF) le fait tourner dans le sens horaire autour de l'axe des Y.
Un modèle X-Plane 8 / 9 est spécifié par des commandes, qui construisent le modèle dans un certain ordre. Il existe quatre types de commandes fondamentales : Les commandes de géométrie créent la géométrie, qui sera tracée dans l'ordre où elles sont créés. Les commandes d'état affectent la façon dont la géométrie est dessinée. Les commandes d'action ont une influence sur le simulateur. Les commandes d'animation changent la forme de la géométrie en temps réel.
Cet état a une «mémoire». Par exemple, toute la géométrie est dessinée avec uniquement la face avant visible, jusqu'à ce que vous dessiniez cet état en mode "2 faces". Toute la géométrie est alors dessinée avec les deux côtés visibles, jusqu'à ce que l'état du dessin soit de nouveau réglé sur le mode "unilatéral".
Les changements d'état ont plus de conséquences que seulement spécifier comment dessiner une certaine géométrie ; ils affectent réellement les performances du dessin dans le simulateur. Celui-ci doit désactiver le "tracé en masse" pour changer d'état. Minimiser le nombre de commandes d'état améliore généralement les performances.
Parce qu'X-Plane ne réorganise pas les commandes de géométrie, c'est au créateur d'optimiser la performance en minimisant les commandes d'état dans le cadre dans les limites de la flexibilité des ordres de géométrie. De manière générale, le nombre de commandes (sans compter les différentes tables) est un bon indicateur de l'efficacité de votre objet - moins il y aura de commandes, plus ce sera efficace.
Les données de géométries (points, coordonnées de texture, normales, etc) pour un modèle OBJ8 sont stockées dans des tables, distinctes de la section des commande. Les tables de données peuvent être partagées dans n'importe quel ordre souhaité par l'auteur.
Il y a trois tables de géométries distinctes pour stocker les triangles, les lignes et les points lumineux. Il y a aussi une table d'index séparée qui fournit des index pour la géométrie ou des tables de lignes pour les lignes et les lumières. Ce deuxième niveau d'indexation permet une gamme d'index contigus en référence à un ensemble plus restreint de points communs. La commande d'un seul triangle envoie alors une série d'index contigus. Les lumières ne sont pas indexées, la commande des lumières en réfère directement à une table de points lumineux consécutifs.
Les attributs se réfèrent aux propriétés globales de l'objet entier. À l'heure actuelle, les seuls attributs sont les noms de la texture principale et des textures "lit".
Remarque concernant OBJ7 : contrairement à OBJ8, l'éclairage de nuit n'est pas chargé automatiquement par la recherche d'un fichier _LIT. Une carte doit être spécifiquement indiqué pour la lumière.
Un modèle OBJ8 contient un ou plusieurs "niveaux de détail" (LOD ou "Level of Detail"). Un niveau de détail peut être considéré comme un modèle complètement autonome et indépendant au sein de l'objet qui partage l'ensemble des données de la table et des attributs du modèle OBJ8. À tout moment, on dessine toujours un seul LOD.
Les LOD sont indiqués en mètres pour les plages (cette plage est celle du spectateur à l'objet). Cela vous permet de changer l'apparence d'un objet pour un modèle plus simple lors de la visualisation au loin.
L'état est totalement indépendant des LODs. En d'autres termes, si vous définissez un dessin recto-verso dans un LOD, le premier triangle du LOD suivant sera automatiquement d'un seul côté.
Si vous ne spécifiez pas de LODs, l'ensemble du modèle est considéré comme un LOD unique, dont la portée est calculée automatiquement par X-Plane.
Avec OBJ8, il est possible d'animer des modèles. L'animation se fait en spécifiant des transformations dans les gammes de la géométrie.
L'animation est définie par paires de début/fin de commandes d'animation. Ces commandes peuvent être imbriquées pour former une hiérarchie d'animations. Zéro ou plus de rotation et de commandes de translation peuvent être utilisées pour chaque niveau d'imbrication.
L'animation est guidée par des datarefs. Un dataref est une variable du simulateur de vol dont le nom est public. 1100 datarefs et + sont définis dans X-Plane et listées sur le site d'SDK X-Plane des plug-ins peuvent également créer des datarefs supplémentaires pour guider une animation. Des commandes d'animation permettent à une échelle de datarefs de convertir facilement les unités par défaut du simulateur à des plages utiles pour l'animation.
Pour calculer la mesure d'une translation ou de rotation, X-Plane trouve une paire de positions de référence (Key Frame), ou des paires de dataref/animation, puis choisit la paire appropriée. Les valeurs qui ne sont pas entre des paires sont extrapolées à partir la paire la plus proche.
X-Plane 8 n'utilise que deux positions de référence («départ» et «fin»). X-Plane 9 permet deux positions de référence ou plus.
Une manipulation est l'action d'un utilisateur sur un objet qui change l'état d'X-Plane. En établissant l'état de manipulation, vous définissez ce qu'un objet accomplit en cliquant dans des triangles. Les manipulations interagissent avec des animations, dans certaines conditions.
La manipulation en cours est modifiée par des commandes de manipulateur, qui sont une forme de commande d'état ; on peut associer une manipulation à n'importe quel triangle donné.
X-Plane 9.20 prend en charge les types de manipulations suivants :
X-Plane 9.30 ajoute les manipulateurs "dataref" suivants (c'est-à-dire des manipulateurs qui changent un dataref en réponse à un clic) :
Les manipulations sont affectées par les commandes d'animation qui les entourent - c'est-à-dire que, si un axe de manipulation est à l'intérieur d'une rotation, l'axe tournera sur la base de cette rotation.
Les manipulations prennent également en compte les animations sur les triangles cliqués. Cela comprend toutes les animations qui affectent ce triangle. En d'autres termes, si vous définissez une commande de manipulation et dessinez quelques triangles, puis les animez et dessinez plus de triangles, deux groupes de triangles seront inclus dans le test de clic et l'emplacement du clic déclenchera l'animation, même si elle suit le début de la manipulation. (En d'autres termes, les tests de clic de souris correspond toujours au dessin.)
Les types de géométrie fondamentale pour OBJ8 sont les suivants :
REMARQUE SUR OBJ7 : Les valeurs RVB d'OBJ8 sont toujours à une échelle 0-1, même pour les lumières et les lignes. Cela signifie que les commandes spéciales de lumières se font à 9,9, 9,8, etc au lieu de 99, 98.
Un objet a par définition quatre «couches» d'information dans lequel un triangle peut prendre part :
Un triangle peut n'être dans aucune couche, ou dans plus d'une. Les attributs sont utilisés pour contrôler quels triangles vont dans quelle couche.
Choisir dans quelle couche se trouve un triangle est statique. Les couches sont différentes pour les animations cachées ; un triangle caché par une animation cachée est caché de tout - physique, dessin, clic, et mouvements de caméra. Les couches sont prévues pour permettre aux auteurs d'utiliser différentes géométries pour les contraintes de caméra, clics, physiques et dessin.
Les lignes, lumières, et bouffées de fumée ne doivent jamais se trouver dans la manipulation physique ou les plans caméra. Par conséquent, c'est un non sens de les inclure dans une partie du fichier OBJ qui n'est pas dessinée.
Certains exemples utilisés peuvent illustrer la motivation derrière plusieurs couches :
OBJ8 définit les états des objets comme suit :
[Nouveauté 8.50] : Depuis X-Plane 8.50, vous pouvez spécifier le type de surface physique pour la géométrie. Avant 8.50, le choix était tout simplement physique ou non.
[Nouveauté 9.00] : depuis X-Plane 9.00, vous pouvez spécifier pour une surface dure d'être un "pont", autrement dit l'utilisateur peut voler au-dessus ou y atterrir. Avant 9.00, seules les surfaces physiques "solides" étaient disponibles - voler au-dessus provoquait une collision.
- Diffuse (RVB) - la luminosité de la surface due au soleil.
- Emissive (RVB) - la luminosité de la surface due au rayonnement de la lumière.
- Shininess (RVB) - la brillance des reflets spéculaires (0-1).
Le modèle d'éclairage/texturage d'X-Plane est basé sur des données différentes pour l'albédo et l'émission. Un objet X-Plane peut faire référence à trois textures:
Normalement, ces trois textures sont utilisées pour les triangles de texture. Quand ATTR_cockpit_region est utilisé, le tableau de bord remplace l'albédo et les textures émissives, et la carte des normales est désactivée.
Quand ATTR_cockpit est utilisé, le tableau de bord remplace la texture albédo, et l'éclairage 3D est désactivé.
Pour plus d'informations sur le format et l'application des cartes de normales, voir le chapitre des cartes de normales.
IMPORTANT : le niveau de brillance dans le canal alpha de la cartes des normales est modulé par la contribution de ATTR_shiny_rat, qui est 0.0 par défaut. Vous devez utiliser ATTR_shiny_rat pour voir les effets de la couche alpha dans une carte de normales.
Les objets actuellement quatre attributs : le nom de la texture, le nom de la texture éclairée, un poids si l'objet est utilisé comme une charge, et les régions du tableau de bord. Les noms de fichiers sont interprétés par rapport à l'objet fichier lui-même, et doivent comporter une extension. X-Plane recherchera les formats bitmap avec des extensions de rechange. Par exemple, si vous spécifiez TEXTURE foo.png mais que seul foo.dds est disponible, c'est foo.dds qui sera chargé. Voir les caractéristiques du cockpit, ci-dessous.
Le format OBJ est utilisé pour modéliser des objets qui font partie des avions, de l'environnement du cockpit, et une partie du système des scènes. Certaines fonctionnalités ne sont appropriées que pour le cockpit.
Les caractéristiques du cockpit sont utilisées uniquement pour des objets attachés à ceux comme le «cockpit objet» - cet objet est soumis à un traitement spécial. Les autres objets attachés à l'avion et les objets de scènes ne peuvent pas utiliser ces fonctionnalités.
Changer la texture de l'objet dans la texture du "tableau de bord" fait deux choses :
- Changer la texture utilisée pour dessiner la texture de l'OBJ (spécifiée avec la commande TEXTURE) du tableau de bord 2D. Le tableau de bord 2D est utilisé dans sa taille maximum, même si ce n'est pas une puissance de 2. (Note : les tableaux de bord 2D qui ne sont pas des puissances de 2 rendent le traitement inefficace.) Les fenêtres transparentes du tableau de bord 2D sont transparentes quand elles sont utilisées comme une texture.
- Changer la manipulation en cours, pour que les clics d'une partie de l'objet 3D du cockpit aient le même effet qu'en cliquant dans le même emplacement mappé sur le tableau de bord 2D.
[Nouveauté 9.00] : Au lieu d'utiliser le tableau de bord entier comme une texture (à l'aide d'ATTR_cockpit), un objet peut établir jusqu'à quatre "régions" de cockpit. Ces textures sont définies par un sous-rectangle dans le cockpit 2D. Les régions du cockpit utilisent différemment le cockpit comme suit :
Les régions du cockpit sont recommandées pour des raisons d'efficacité : entre l'utilisation de la transparence, du tableau de bord qui n'est pas une puissance de 2 et l'énorme quantité du tableau de bord 2D inutile pour le rendu, le tableau de bord 2D finit par utiliser beaucoup plus de VRAM et construit dynamiquement beaucoup plus de surface de texture que nécessaire. En utilisant simplement quelques régions du cockpit plus petites sur les parties clés du tableau de bord 2D , on aura un meilleur framerate.
Les fichiers OBJ8 sont des fichiers texte de type ASCII, le jeu de caractères habituels correspond à l'ensemble des fichiers imprimables ASCII 7-bit.
Les lignes sont définies par des séquences de caractères de saut de ligne, qui sont :
Tout choix de séquence de saut de ligne peut être utilisé systématiquement dans le fichier.
Un ou plusieurs onglets (8) et/ou des espaces (32) sont traités comme des espaces blancs.
Une séquence de caractères habituels qui ne contient pas de sauts de ligne peut être mentionnée comme une ligne, et une séquence de caractères habituels qui ne contient pas de sauts de ligne ou d'espace peut être considéré comme un mot.
L'identification du mot et du mot-clé est sensible à la casse. Les nombres sont représentés par un signe optionnel moins, un ou plusieurs chiffres, éventuellement suivis d'une période et un ou plusieurs chiffres. Tous les numéros dans les objets peuvent être en virgule flottante.
Le fichier objet se compose d'un en-tête de 3 lignes suivie par une série d'enregistrements, dont chacun est une ligne. Un type d'enregistrement est identifié par le premier mot de cet enregistrement. Les lignes blanches sont habituelles après l'en-tête, et les dossiers commençant par un # sont considérées comme des lignes vides, ce qui permet des commentaires.
Les lignes d'en-tête sont composées de :
Chaque enregistrement en ligne est identifié par son premier mot ; voir la liste de commande ci-dessous pour enregistrer des descriptions précises.
Les coordonnées sont spécifiées comme un triplet de nombres qui représentent les coordonnées cartésiennes XYZ en mètres.
Les normales sont spécifiées comme un triplet de fractions formant un vecteur en 3D dont la longueur est de 1. Le vecteur sera interprété dans le même espace de coordonnées de la géométrie.
Les coordonnées de texture sont spécifiées comme une paire de fractions de 0-1. Le premier représente un ratio de la gauche vers la droite de la texture, la seconde à partir du bas vers le haut.
Les couleurs sont représentées sous forme de fractions de 0 à 1 représentant au moins l'intensité de couleur. Les couleurs sont généralement des triplets RVB.
Les enregistrements se répartissent en trois catégories: attributs, données et commandes. Dans l'ordre du fichier doivent figurer tous les attributs d'abord, puis toutes les données, puis toutes les commandes. Les enregistrements d'attributs peuvent être dans n'importe quel ordre. Les types d'enregistrements des données peuvent être dans n'importe quel ordre, mais la commande d'un type d'enregistrement de données définit l'interprétation d'indexation. Les commandes sont exécutées dans l'ordre des enregistrements dans le fichier.
Un OBJ8 peut inclure on non un LOD. Un fichier qui ne possède pas de LOD peut ne pas avoir la commande ATTR_LOD. Un fichier qui possède un LOD doit avoir une commande ATTR_LOD comme premier enregistrement de commande, et doit suivre les règles de la commande LOD. Ces règles sont les suivantes :
Il n'est pas nécessaire pour un état d'objet de réinitialiser sa valeur initiale à la fin du LOD, le simulateur le prend en charge.
Les enregistrements de commande ne sont pas du tout réorganisés par le simulateur. Cela rend possible des astuces de translucidité.
Toutes les commandes d'animation doit être dans une paire ANIM_begin/ANIM_end.
Toutes les paires ANIM_begin/ANIM_end doivent être bien équilibrées dans chaque LOD.
Les commandes d'animation (ANIM__rotate et ANIM_translate) doivent se situer immédiatement après ANIM_begin. Cependant un certain nombre de commandes d'animation peuvent être utilisées juste après une seule ANIM_begin.
Les attributs POINT_COUNTS et TEXTURE sont obligatoires.
Les polygones durs ne sont pas autorisés dans tous les LOD, uniquement pour le premier.
Les caractéristiques du cockpit (texture panel/ Panel regions, manipulation, caméra de l'avion activée) peuvent être utilisées uniquement dans les objets attachés à un avion via COCKPIT_INN.obj ou COCKPIT_OUT.obj.
[Nouveauté 9.00] : Les tables des positions de référence doivent être énumérés de la plus petite à la plus grande valeur de leur dataref .
Cela n'est pas obligatoire, mais recommandé : si votre objet a plusieurs lumières et LODs, utilisez exactement les mêmes lumières dans chaque LOD. Le moteur OBJ d'X-Plane utilise un traitement spécial sur les lumières qui augmente la distance à laquelle ils sont visibles et améliore en même temps le framerate. Si les feux spécifiés dans chaque LOD sont différents, vous pouvez obtenir un dessin incorrect, ou un framerate plus bas. Le code le plus rapide consiste à laisser X-Plane mettre les mêmes lumières à chaque LOD.
TEXTURE <tex_file_name>
Définit la texture utilisée par cet objet. Laissez vide si l'objet n'a pas besoin de texture.
TEXTURE_LIT <tex_file_name>
Définit la texture de nuit utilisée. Laissez vide si vous n'avez pas besoin de texture d'éclairage.
TEXTURE_NORMAL <tex_file_name>
[Nouveauté 9.40:] Définit la texture gérant les effets normales et spéculaire (texture générant des effets de bombés et de matériaux mixtes mat / brillant).
POINT_COUNTS <tris> <lines> <lites> <indices>
Définit la taille des tables de données. Quatre nombres entiers définissent le nombre d'entrées dans chaque table.
slung_load_weight <mass weight in pounds>
Définit le poids de l'objet, pour une utilisation dans le moteur physique si l'objet est porté par un avion ou un hélicoptère.
COCKPIT_REGION <left&rt; <bottom&rt; <right&rt; <top&rt;
[Nouveauté 9.00:] Définit une région utilisée pour le cockpit - le rectangle de la région est en pixels, quand 0,0 est le coin inférieur gauche du tableau de bord 2D du cockpit. La région du cockpit peut avoir n'importe quelle position aussi longtemps que (1) sa largeur et la hauteur sont des puissances de (2) elle ne disparait pas au bord du tableau de bord 2D du cockpit. Les régions du tableau de bord sont désignées par des indices : le premier COCKPIT_REGION est le numéro 0. Il peut y avoir jusqu'à quatre régions du cockpit dans un objet.
VT <x> <y> <z> <nx> <ny> <nz> <s> <t>
Définit une entrée unique dans la table du vertex triangle. Ils sont indexés à partir de zéro sur la base d'un ordre d'enregistrement. Les huit chiffres représentent un triplet de coordonnées de localisation, un triplet normal, et une paire formant une coordonnée de texture. Cette table est uniquement utilisé pour les triangles.
Vline <x> <y> <z> <r> <g> <b>
Définit une entrée unique dans la table de vertex ligne, un triplet de coordonnées d'emplacement et un triplet de valeurs de couleur (RVB, de 0-1). Cette table est uniquement utilisée pour les primitives en ligne.
VLIGHT <x> <y> <z> <r> <g> <b>
Définit une entrée unique dans la table de vertex lumière. Encore une fois nous avons un triplet de coordonnées et triplet RVB. Les couleurs sont de 0-1 avec des règles spéciales :
AVERTISSEMENT : les valeurs spécialisées de la lumière basées sur la série 9.x ne peuvent pas être prises en charge précisément dans les specs d'OBJ futurs, et ne sont pas recommandées. Elles sont fournis pour assurer la compatibilité.
IDX <n>
IDX10 <n> <n> <n> <n> <n> <n> <n> <n> <n> <n>
Définit une ou dix entrées dans la table d'index. La table d'index est utilisée pour désigner les tables de vertex qui définissent les sommets des triangles ou des lignes. Les indices sont de base zéro, et les chiffres sont de base zéro dans les tables de vertex. En d'autres termes, un index dont la valeur est «4» peut se référer au 4ème index de la table de la ligne ou du triangle, en fonction de la commande utilisant ces index. IDX10 pack est prévu pour grouper 10 index sur une seule ligne.
TRIS <offset> <count>
Cette commande dessine <count> / 3 triangles définis par les vertex référencés par les indices commençant par «offset» dans la table d'index et qui se suivent. (En d'autres termes, les indices doivent être adjacents, mais ils peuvent se référer à des vertex non adjacents). Le <count> doit être un multiple de 3. Les vertex viennent de la table des triangles.
LINES <offset> <count>
Cette commande dessine <count> / 2 segments de droite définis par les vertex référencés par les indices commençant par «offset» dans la table d'index et qui se suivent. Les vertex sont sur la table des lignes. Le <count> doit être un multiple de 2.
LIGHTS <offset> <count>
Cette commande dessine <count> des points de lumières dont les positions sont stockées consécutivement à partir de «offset» dans la table des lumières. Contrairement aux commandes LINE et TRIS, cette commande n'utilise pas la table d'index. Cela signifie que si les triangles et lignes peuvent dessiner le même vertex plusieurs fois avec une seule commande, la commande des lumières ne peut pas répéter un vertex multiple de lumière sans plusieurs commandes de lumière.
REMARQUE : la capacité à partager des vertex efficacement est importante pour les triangles et les lignes qui peuvent être des parties de mesh, mais n'est pas utile pour l'éclairage.
LIGHT_NAMED <name> <x> <y> <z>
[Nouveauté 8.50:] Nommer une lumière lui permet d'être créée sur un modèle préexistant. Les paramètres <x> <y> <z> spécifient l'emplacement de cette lumière.
Note: la liste des feux disponibles sera publiée à l'avenir.
LIGHT_CUSTOM <x> <y> <z> <r> <g> <b> <a> <s> <s1> <t1> <s2> <t2> <dataref>
[Nouveauté 8.50:] Personnaliser une lumière permet à un objet de contenir une lumière qui a presque toutes les propriétés. Voici quelques différences entre les lumières personnalisées et les traditionnelles :
Une lumière personnalisée a neuf paramètres (en dehors de l'emplacement). Chaque fois que la lumière est dessinée, les paramètres du fichier OBJ sont gérés par un dataref, qui peut modifier ou remplacer une partie ou l'ensemble des paramètres. La façon dont le dataref interagit avec les paramètres dépend de la lumière - par exemple, certains vont tout simplement remplacer tous les paramètres, d'autres modifier un seul paramètre, et d'autres encore utiliser les paramètres comme des conseils pour leur fonctionnement. Voir les docs du plug-in dataref SDK pour plus d'informations spécifiques sur les dataref - X-Plane est livré avec plusieurs datarefs qui sont utiles pour l'éclairage personnalisé, et les auteurs de plug-in peuvent en ajouter d'autres.
Si le dataref n'est pas trouvé (ou si "NULL" est utilisé comme un nom de dataref), alors les 9 paramètres sont dessinés sans modification. De cette façon, vous pouvez complètement contrôler le dessin des lumières en la personnalisant, même sans plug-ins.
Les paramètres sont :
LIGHT_PARAM <name> <x> <y> <z> [<& params ltadditional>]
[Nouveauté 9.40:] Un lumière paramétrée est comme une lumière nommée, sauf que certains des attributs de la lumière peuvent être numériquement modifiés. <x> <y> <z> définissent la position de la lumière. Le nom choisit une lumière pré-définie. Les paramètres supplémentaires varient en nombre et en définition basés sur la lumière notamment paramétrée sélectionnée.
smoke_black <x> <y> <z> <s>
smoke_white <x> <y> <z> <s>
Ces commandes poussent l'objet à émettre périodiquement un nuage de fumée blanche ou noire à l'emplacement spécifié par <x> <y> <z> . <s> est un nombre indiquant la taille de l'intensité relative de la fumée.
TODO : Quelle est l'unité de taille du nuage de fumée ?
ATTR_LOD <near> <far>
LOD indique le début d'une nouvelle LOD, qui devrait être utilisé pour représenter l'objet lorsque le spectateur est entre <near> = proche (inclusif) et <far> = loin (exclusif), en mètres.
ATTR_ambient_rgb <r> <g> <b>
ATTR_specular_rgb <r> <g> <b>
ATTR_emission_rgb <r> <g> <b>
ATTR_shiny_rat <ratio>
Ces commandes modifient l'état matériel de géométrie basée sur le modèle d'éclairage OpenGL.
ATTR_reset
Cette commande réinitialise l'état matériel à sa valeur par défaut.
ATTR_poly_os <n>
Cette commande met le polygone de l'état offset à N, un entier non négatif.
ATTR_layer_group <name> <offset>
[Nouveauté 8.50:] X-Plane dessine les scènes par "groupes de couches" - tous les éléments du même groupe de couches sont dessinés avant tous les autres groupes, mais dans un groupe de couches, l'ordre de dessin peut être optimisé par X-Plane. Normalement, les groupes de couches sont déterminés par X-Plane en fonction du type de dessin. Les objets ont toujours eu leur propre groupe de couche.
Lorsque le ATTR_layer_group est inclus quelque part dans un objet (il ne doit être utilisé qu'une fois, même si vous avez plusieurs LODs), ce dernier est dessiné dans un groupe de couches différent. Le décalage est utilisé pour augmenter la priorité - par exemple. <groupe + 1> est dessiné après <groupe>, et <groupe - 2> est dessiné deux couches avant <objects>. Vous pouvez utiliser un décalage de -5 à + 5.
Les noms des couches valides sont:
Nom | Traduction | |
+5 | cars | voitures |
+4 | light_objects | objets éclairés |
+3 | objects | objets |
+2 | roads | routes |
+1 | airports | aéroports |
0 | markings | marquages |
-1 | runways | pistes |
-2 | taxiways | taxiways |
-3 | shoulders | bas-côtés |
-4 | beaches | plages |
-5 | terrain | tarrain |
Note: le groupe "aéroports" couvre tous les dessins de l'aéroport. Dans ce groupe, il y a des sous-groupes bas-côtés, taxiways, pistes, et marquages. Les marquages sont pour les taxilines et sont donc au-dessus de toutes les autres couches.
ATTR_cockpit
Définit la texture en cours par rapport à la texture du cockpit, et le manipulateur en cours par rapport au clic manipulateur du tableau de bord.
La texture du tableau de bord utilise un éclairage «plat» (matériaux et lumières sont ignorés, la couleur correspond au tableau de bord 2D ou 3D) quand il est invoqué en utilisant cet attribut.
ATTR_no_cockpit
ATTR_no_cockpit définit la texture en cours par rapport à la texture objet et le manipulateur en cours à rien.
ATTR_cockpit_region <region number>
[Nouveauté 9.00:] L'attribut ATTR_cockpit_region change la texture de l'objet vers une région spécifique de la texture du cockpit. Utilisez ATTR_no_cockpit quand c'est fait. La manipulation en cours est un clic sur tableau de bord.
La texture du tableau de bord utilise un éclairage «réel» (matériaux et les lumières sont utilisées, la couleur correspond à la texture d'objet) quand il est invoqué en utilisant cet attribut.
Le reste des commandes d'état affecte l'état publié ci-dessus.
ATTR_light_level <v1> <v2> <dataref>
[Nouveauté 9.30:] ATTR_light_level change la luminosité de la texture _LIT de l'objet. Le dataref est interprété comme une valeur comprise entre <v1> et <v2>. Les valeurs en dehors de l'intervalle [v1, v2] sont coupées. Cet attribut l'emporte sur la décision du simulateur sur l'éclairage de l'objet.
ATTR_light_level_reset
[Nouveauté en 9.30:] ATTR_light_level_reset réinitialise la texture _LIT de la luminosité par défaut. (Cette luminosité est généralement maximum de nuit ou nulle de jour).
Commande | Etat | Nouvelle valeur |
ATTR_hard | Polygone dur | on |
ATTR_no_hard | Polygone dur | Non-Off* |
ATTR_shade_flat | Ombre | plat |
ATTR_shade_smooth | Ombre | lisse* |
ATTR_no_depth | Vérification de profondeur | off |
ATTR_depth | Vérification de profondeur | on* |
ATTR_no-cull | Géométrie à 2 faces | 2 faces |
ATTR_cull | Géométrie à 2 faces | 1 face |
ATTR_no_blend | Mélange | off |
ATTR_blend [nouveauté 9.30] |
Mélange | on* |
ATTR_solid_camera | Plan camera | actif |
ATTR_no_solid_camera | Plan camera | inactif* |
ATTR_draw_enable | Plan dessin | actif* |
ATTR_draw_disable | Plan dessin | inactif |
* par défaut
[Nouveauté 8.50:] À partir de X-Plane 8.50 ATTR_no_blend peut prendre un ratio décimal optionnel (entre 0,0 et 1,0) qui spécifie la fréquence de coupure du canal alpha. Les niveaux alpha inférieurs à ce niveau sont rendus sous une forme totalement transparente et au-dessus de ce niveau, ils sont totalement opaques. Si cette fraction n'est pas spécifiée, no_blend utilise un ratio de coupure par défaut de 0,5.
[Nouveauté 8.50:] À partir de X-Plane 8.50, ATTR_hard peut être suivi d'un nom de surface supplémentaire. Ce nom de surface contrôle la rugosité du polygone, permettant à un objet d'imiter certaines des surfaces naturelles d'X-Plane, comme l'herbe et les rochers. Si aucun type de surface est spécifié, alors une surface lisse est utilisée.
Les noms valides de surface reconnues sont les suivants:
water (eau), concrete (béton), asphalt (asphalte), grass (herbe), dirt (terre), gravel (gravier), lakebed (lac), snow (neige), shoulder (bas-côté), blastpad (blastpad)
[Nouveauté 9.00:] À partir d'X-Plane 9, ATTR_hard_deck peut être utilisé à la place de ATTR_hard. Il définit une surface dure, mais permet à l'utilisateur de voler sous la surface.
ANIM_begin
Cette commande marque le début d'un paragraphe animation. Toutes les commandes de géométrie supplémentaires sont affectées par les commandes d'animation entre ce ANIM_begin et la commande jusqu'à ce qu'un ANIM_end soit rencontré.
ANIM_end
Définit la fin d'une section animation. La géométrie suivante n'est pas affectée par les commandes d'animation.
ANIM_rotate <x> <y> <z> <r1> <r2> <v1> <v2> <dataref>
Définit une commande de rotation. <x> <y> et <z> définissent un axe de rotation - ils doivent former un vecteur unité de longueur. r1 et r2 représentent l'angle de rotation dans le sens antihoraire lorsque le dataref est à ses valeurs minimales et maximales, en regardant vers le bas la "flèche" du vecteur. (Donc, si le vecteur est 0,1,0, alors une rotation positive est dans le sens antihoraire, vue du dessus.). v1 et v2 sont les valeurs minimales et maximales des dataref pour étalonnage. dataref est le nom de chaîne d'un dataref du simulateur.
ANIM_trans <x1> <y1> <z1> <x2> <y2> <z2> <v1> <v2> <dataref>
Définit une commande de translation. x, y, z 1 et 2 sont deux distances offset, lorsque le dataref est à ses valeurs minimales et maximales; v1 et v2 sont les min et max prévu pour le dataref et dataref est le nom de chaîne du dataref.
ANIM_hide <v1> <v2> <dataref>
[Nouveauté 8.50:] Si la valeur du dataref se situe entre les deux valeurs (inclusivement), le dessin est suspendu. Il est repris quand une commande ANIM_show redémarre le dessin, ou lorsque le groupe d'animation (défini par ANIM_begin/ANIM_end) finit.
Note : cacher une animation suspend tous les triangles/polygones, et les dessins de ligne et de lumière, mais n'arrête pas le traitement des attributs. L'état va changer, même après des commandes cachées. Ainsi, l'état de n'importe quelle partie de l'objet ne dépend pas des commandes d'animation.
ANIM_show <v1> <v2> <dataref>
[Nouveauté 8.50:] Si la valeur du dataref se situe entre les deux valeurs (inclusivement), le dessin est repris. Cela n'a aucun effet, à moins que le dessin ait déjà été suspendu.
show (montrer) et hide (cacher) ne sont pas comptés. Par exemple, si vous cachez à deux reprises et montrez une fois, le dessin est repris.
ANIM_rotate_begin <x> <y> <z> <dataref>
[Nouveauté 9.00:] Commence par une commande ANIM_rotate, mais avec une table d'image clé pour continuer. xyz est l'axe de rotation.
ANIM_rotate_key <value> <angle>
[Nouveauté 9.00:] Ajoute une position de référence à une animation de rotation. La valeur représente une valeur dataref possible - l'angle de rotation est celui qui lui correspond.
ANIM_rotate_end
[Nouveauté 9.00:] Termine une animation de rotation avec des positions de référence. Il est nécessaire après celles-ci et doit être utilisé pour équilibrer tous les ANIM_rotate_begin.
ANIM_trans_begin <dataref>
[Nouveauté 9.00:] Commence avec une commande ANIM_trans, mais avec une table de positions de référence ensuite. Le dataref est spécifié, mais les translations en cours sont traduites par des positions de référence.
ANIM_trans_key <valeur> <x> <y> <z>
[Nouveauté 9.00:] Ajoute une position de référence à une animation de translation. Pour la valeur donnée, trois distances, en x, y et z sont fournies - ce sont des distances pour translater l'objet.
ANIM_trans_end
[Nouveauté 9.00:] <