ContribCliquez ici pour proposer des corrections ou des compléments pour cette page.
Obj

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

Historique des versions

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 :

  • TEXTURE_NORMAL pour renseigner les cartes des normales et des spéculaires à un objet.
  • LIGHT_PARAM pour les lumières personnalisées.

CHANGEMENTS pour la 9.30 : Les fonctions suivantes deviennent disponibles avec X-Plane 9.30 :

  • ATTR_light_level et ATTR_light_level_reset
  • ATTR_draw_enable / ATTR_draw_disable
  • ATTR_solid_camera / no_solid_camera

CHANGEMENTS pour la 9.20 : Les fonctions suivantes deviennent disponibles pour X-Plane 9.20 et plus :

  • Manipulateur

CHANGEMENTS pour la 9.00 : Les fonctions suivantes deviennent disponibles pour X-Plane 9 et les versions ultérieures :

  • Images clés
  • Régions du tableau de bord
  • Surfaces solides de type "plateau"

CHANGEMENTS pour la 8.50 : Les fonctions suivantes ne sont disponibles que pour X-Plane 8.50 et plus :

  • Lumières nommées et personnalisées
  • Groupes de couches
  • Plus de contrôle d'opacité et de dureté des surfaces
  • Commandes d'animation montrer/cacher (show/hide)

Concepts d'objets

Type de fichier et compatibilité

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.

Système de coordonnées et géométrie

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.

Commandes supplémentaires d'état

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.

Tables

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.

Attributs

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.

Niveau de détail

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.

Animation

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.

Manipulation

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 :

  • Aucune manipulation. Si une section de mesh est étiquetée comme n'ayant pas de manipulation, il ne réagit pas aux clics. Les clics de souris "traversent" les triangles. Cette manipulation est la plus rapide - toutes les autres demandent des ressources au CPU.
  • Manipulations sur la texture du tableau de bord. Un clic sur le triangle provoque un clic sur le tableau de bord 2D ou 3D, dont les coordonnées de texture correspondent à la surface où le clic prend effet. Les zones cliquables ne sont pas définies sur une texture du tableau de bord inutilisée. (En pratique, cette manipulation n'est jamais disponible sur un triangle non texturé, en raison de la syntaxe des fichiers OBJ.) On le localise précisément avec les fonctions ATTR_cockpit et ATTR_cockpit_region ensemble.
  • La manipulation anime l'axe XY. Deux datarefs sont modifiés en fonction de la distance le long des axes X et Y dans l'espace de l'écran. C'est principalement fourni pour les contrôles 2D comme les volants (yokes).
  • La manipulation fait glisser l'axe. Un dataref est modifié sur la base d'un glissement le long d'un axe dans un espace d'objet arbitraire. L'axe est «verrouillé» au moment de cliquer, il change l'emplacement du glissement (en tant qu'espace d'objet) à la suite de la rotation de la tête du pilote ou d'animations qui n'affectent pas l'axe. En effet, au moment du clic, l'axe est converti de pixels 3D en 2D à l'écran et quitte cette fonction. Cela fournit une expérience de glissement plus prévisible pour les utilisateurs.
  • Manipulations de commande. En cliquant sur une section du mesh, cela entraîne une commande au moment du clic de souris.
  • Manipulations de commande d'un axe. On glisse le long de l'axe d'un espace objet arbitraire avec une des deux commandes, selon la direction du glissement.
  • Manipulations sans opération (no-op). Aucune mesure n'est prise, mais ce manipulateur "bloque" le clic, alors la souris ne marche plus. Cela rend les triangles "solides" pour les clics de souris.

X-Plane 9.30 ajoute les manipulateurs "dataref" suivants (c'est-à-dire des manipulateurs qui changent un dataref en réponse à un clic) :

  • Appuyez sur le bouton. Le dataref est sur l'appui, puis sur le relâchement du bouton.
  • Le bouton radio. Le dataref est modifié par de multiples manipulateurs.
  • Un bouton à bascule. Le dataref est modifié par un clic sur 2 valeurs différentes.
  • Delta. Le dataref est légèrement modifié par un clic ou maintenu, avec des limites sur la plage totale.
  • Wrap. Le dataref est légèrement modifié par un clic ou maintenu, et "s'enroule" quand il devient hors de portée.

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.)

Types de géométrie pour les objets

Les types de géométrie fondamentale pour OBJ8 sont les suivants :

  • Les triangles. Ils sont texturés et ont une normale définie par vertex pour l'éclairage. La face avant du triangle est celle où les sommets apparaissent en séquence dans le sens horaire.
  • Les lignes. Elles ont une couleur RVB.
  • Les lumières. Elles ont une couleur et peuvent clignoter. A partir de X-Plane 8.50, des lumières plus complexes sont également définies.

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.

Couche des mesh

Un objet a par définition quatre «couches» d'information dans lequel un triangle peut prendre part :

  • La couche dessin - l'utilisateur peut voir le triangle. Tous les triangles sont normalement dans le plan de dessin.
  • La couche physique - le triangle cause des collisions dans le moteur physique. Les auteurs ont mis un triangle dans le plan physique avec ATTR_hard, etc
  • La couche manipulation - le triangle peut être cliqué avec la souris. Les auteurs ont mis un triangle dans le plan de manipulation avec un manipulateur ou ATTR_cockpit. Seuls les triangles de l'objet cockpit peuvent être dans le plan de manipulation.
  • La couche caméra - les triangles peuvent gêner le déplacement de la caméra 3D. Les auteurs peuvent mettre un triangle dans le plan caméra pour obliger l'utilisateur à regarder en 3D. Seuls les triangles de l'objet cockpit peuvent être dans la couche caméra.

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 :

  • Un triangle manipulable peut être non dessinable, ce qui permet à un auteur de disposer des "points chauds" larges et faciles à cliquer en face du mesh d'un interrupteur qui seraient autrement difficiles à cliquer à cause de leur forme.
  • Un auteur peut faire un mesh séparé pour contraindre la camera à constater qu'il n'est pas dessiné - ce mesh distinct peut être étanche à l'eau, avec un faible nombre de triangles, et être encadré par des murs, un peu pour que la camera puisse aller dans des endroits particuliers.

L'état de l'objet

OBJ8 définit les états des objets comme suit :

  • Flat/Smooth shading = Ombrage lisse/plat (smooth = lisse par défaut). En ombrage plat, le triangle entier est dessiné avec la même luminosité. En ombrage lisse, les coins du triangle ont des niveaux d'ombrage appropriés pour leurs normales, et l'intérieur est interpolé. Notez que depuis que l'ombrage plat peut être simulé via des normales par vertex, il est généralement préférable de n'utiliser que des ombrages lisses.
  • One-sided vs. Two-sided geometry = géométrie à une vs deux faces (one-sided = une face par défaut). Avec la géométrie monoface, un triangle n'est dessiné que si la partie avant du triangle est visible à l'utilisateur. Avec les deux faces, les deux parties sont dessinées.
  • Panel vs. object texture = Texture du tableau de bord vs texture d'objet (objet par défaut). Normalement, les triangles sont texturés via la texture (et la lumière de l'Overlay) nommée dans les attributs TEXTURE et TEXTURE_LIT. Lorsque la texture du tableau de bord est allumée, le tableau de bord 2D de l'avion est utilisé comme une texture. NOTE : dans OBJ7, une commande spéciale quad_cock était utilisée pour indiquer la texture de remplacement. En OBJ8, le changement de texture est géré par son état. Le modèle d'éclairage pour le texturage du tableau de bord peut être "plat" (c'est-à-dire qu'aucun calcul d'éclairage n'est fourni) ou "réel" (c'est-à-dire que l'ensemble du système d'éclairage 3D est utilisé, ce qui correspond au reste de l'objet) ; ce qui est appelé système d'éclairage dépend de l'attribut qui est utilisé pour sélectionner le dessin de la texture du tableau de bord.
  • Depth testing = test de profondeur on/off (on par défaut). Normalement, X-Plane utilise des "tests de profondeur" pour s'assurer que les objets proches apparaissent toujours "au-dessus" des objets éloignés (dans le sens 2D). Avec cet état, vous pouvez annuler ce test. AVERTISSEMENT : annuler le test de profondeur est presque toujours une erreur, et n'est pas recommandé. [Nouveauté  9.00] : le test de profondeur est obsolète.
  • Polygon offset amount = hauteur du polygone (O par défaut). Il s'agit d'une hauteur pour dessiner votre géométrie au-dessus du terrain, avec 0 et 1, 0 étant nul et 1 le montant minimum au-dessus du terrain qui peut être représenté par OpenGL. La position de l'objet n'est pas dessinée différemment, ce décalage est seulement utilisé pour décider si votre objet apparaît "en haut" du terrain dans le sens d'un écran plat à deux dimensions.
  • Blend ON/OFF (on par défaut). Normalement, un pixel alpha dans l'objet texture qui n'est ni totalement opaque, ni totalement transparent, est dessiné translucide avec l'arrière-plan visible à travers. Mais cela peut causer des artefacts dans certaines conditions. Lorsque le mélange est désactivé, toutes les valeurs alpha au-dessus de 50% sont traitées de manière totalement opaque et toutes celles qui sont inférieures à 50%, totalement transparente. REMARQUE : même si un bitmap a des pixels uniquement opaques ou transparents, certains peuvent être rendus translucides en raison des effets d'interpolation comme quand une texture est rééchantillonnée.
  • Polygon physical properties = propriétés physiques des polygones (none par défaut). Normalement, les triangles d'un modèle OBJ8 n'interagissent pas avec le modèle physique d'X-Plane. Lorsque cet état est "on", ils le font. Faire des calculs physiques contre les triangles peut être lent pour un grand nombre de triangles, ne le faites pas pour chaque objet. REMARQUE OBJ7 : dans OBJ7, un spécial hard_quad était utilisé pour indiquer un polygone qui interagissait avec le modèle physique. Avec OBJ8, cet état est utilisé dans ce but.

[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.

  • Materials = matériaux. Vous pouvez modifier l'équilibre des contributions de couleur à partir du modèle d'éclairage pour vos surfaces. Ces paramètres sont :

- 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).

  • La relation entre ces couleurs et OpenGL : la couleur diffuse correspond aux couleurs diffuses et ambiantes d'OpenGL. La couleur émissive correspond à la couleur émissive OpenGL. Le ratio de brillance induit les trois composantes de couleur des reflets avec un exposant de 0,5. Les valeurs par défaut sont "diffuses maxi" et "pas de brillance ni émissive". Utilisez ATTR_reset pour restaurer ces propriétés d'éclairage par défaut.
  • [Nouveauté 9.20:] La manipulation actuelle.
  • [Nouveauté 9.30:] Activer/désactiver l'état des couches de dessin et de la caméra.

L'application de texture

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:

  • La texture "de jour" (albédo) pour l'objet, spécifiée via la commande TEXTURE. Cette commande est obligatoire - si le nom de la texture est vide, une texture grise est utilisée.
  • La texture "_LIT" (émission) pour l'objet, spécifiée via la commande TEXTURE_LIT. Cette commande est facultative.
  • Une carte des normales, spécifiée par TEXTURE_NORMAL. La carte des normales est facultative et ignorée, sauf si l'utilisateur a activé l'éclairage par pixel.

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.

Attributs de l'objet

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.

Caractéristiques du cockpit

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 doivent être une puissance de 2 en largeur et en hauteur.
  • Il peut y avoir jusqu'à quatre régions du cockpit.
  • Les régions du cockpit ne sont pas transparentes. Si le tableau de bord 2D est transparent, la texture de la région du cockpit de cet espace n'est pas défini.

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.

La syntaxe de l'objet

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 :

  • MacIntosh : un seul CR (13)
  • Unix : un seul LF (10)
  • DOS : un CR suivi d'un LF

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 :

  • Ligne 1: les caractères A ou I - A est recommandé pour la dernière ligne des fichiers MacIntosh et I pour celle d'Unix ou DOS.
  • Ligne 2: le numéro de version du fichier (actuellement 9.00) suivi par un espace blanc optionnel et des caractères de commentaire supplémentaire.
  • Ligne 3: le mot OBJ.

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.

Sémantiques de l'objet

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 :

  • Les LOD doivent être présentés dans l'ordre du plus proche au plus éloigné.
  • La distance éloignée d'un enregistrement doit être la proche de la suivante. Ni les chevauchements, ni les les lacunes ne sont autorisés.
  • Le premier LOD doit commencer à zéro.
  • Aucun enregistrement de LOD ne peut avoir une distance égale pour le près ou le loin.

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.

Enregistrements d'attributs

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.

Enregistrements de données

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 :

  • Si une valeur est négative, la lumière est considérée comme clignotante.
  • Si la valeur du triplet est de tout 9,9, c'est une lumière rouge pulsante.
  • Si la valeur du triplet est de tout 9,8, c'est une lumière stroboscopique.
  • Si la valeur du triplet est de tout 9,7, c'est un feu de signalisation.

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.

Enregistrements de commandes

Commandes de géométrie

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 :

  • Les lumières personnalisées sont toujours texturées. La couleur RVB est une teinte de cette texture.
  • La texture des lumières personnalisées vient de la texture de l'objet - vous devez dessiner une sorte de halo de lumière dans l'objet.

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 :

  • <r> <g> <b> <a> - la couleur de la lumière (une teinte appliquée à la texture) et le niveau alpha, ce qui rend l'intensité de la lumière. Un alpha de 0,0 signifie que la lumière ne sera pas dessinée.
  • <s> - la taille de la lumière - ce n'est pas dans une unité particulière (comme les mètres), mais un plus grand nombre produit des lumières plus brillantes.
  • <s1> <t1> <s2> <t2> - les coordonnées de texture (fractions de 0 à 1). S fait référence à des coordonnées horizontales, et T à les coordonnées verticales.

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.

Commandes d'action

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 ?

Commandes d'état

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.

Commandes d'animation

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:] <