Format des fichiers LDraw

Mise à jour de la page : 29 décembre 2016.
    Set 700/1 de 1950
J.C. Tchang
 

Décrire les pièces et modèles LEGO® dans un environnement virtuel a été une perspective provocatrice à l'origine. En 1995, James Jessiman a développé un tel système avec son programme LDraw et son format de fichier spécifique. Depuis lors, ce format de fichier LDraw a grandi, pour devenir le format utilisé par la plupart des programmes de création de modèles LEGO® sur ordinateur.

Le but de ce document est de compiler et consolider les spécifications du format du fichier, à partir du format original de James, avec les additions faites depuis.

Cette page en français donne une vue d'ensemble des spécifications des fichiers LDraw. Sa structure est faite pour avoir une vue la plus complète possible de chaque commande ou particularité, dans une approche logique (au moins la mienne).

Elle a pour principale base la traduction de la page en anglais : LDraw File Format 1.0.2 specification, du site de référence LDraw.org, et des pages liées. En cas de divergence de vue, ou de problème de traduction, seule cette source fait foi.

 

Navigation rapide

 

Format des fichiers LDraw

Les fichiers LDraw sont de simples fichiers texte (sans mise en page).

 

Encodage des fichiers LDraw

Un codage des caractères spécifique (UTF-8, ISO-LATIN1, US-ASCII7, etc.) n'est pas défini, et les auteurs de logiciels sont libres d'utiliser le codage approprié à la plateforme de destination.

Depuis le 30-04-2011, l'encodage est défini par le standard.

Les fichiers LDraw doivent être crées en UTF-8 du set de caractères Unicode. L'insertion de BOM (Byte Order Mark) ne doit pas apparaître dans les fichiers. Les programmes de l'environnement LDraw peuvent choisir de rejeter les fichiers contenant cet insertion.

Nota : Avant cette date, des programmes n'utilisant pas UTF-8 ont été largement déployés. Une analyse est recommandée pour confirmer qu'un fichier est valide, et sinon tenter soit :
- Ouvrir le fichier en utilisant la page de code Windows la plus appropriée en langage courant.
- Ouvrir le fichier en utilisant la page de code Windows 1253.

LDMakeList permet de vérifier l'existence de caractère Non UFT-8 dans les fichiers de la bibliothèque.
Warning! File LS22.dat contains non-UTF-8 characters!

 

Format général des fichiers LDraw

Chaque ligne comporte une commande unique. A peu d'exceptions près, chaque ligne est indépendante des autres lignes. Les exceptions sont les méta-commandes BFC (sens des faces) qui modifient le comportement de la, ou les lignes suivantes.

Il n'y a pas de restriction sur la longueur des lignes. Il peut également exister des lignes vides, pour en faciliter la lecture (par un être humain).

Les caractères "espace" ou "tabulation" servent de séparateur entre chaque commande, et les paramètres de ces commandes.

Les diverses commandes sont identifiées par le premier caractère de la ligne qui est un chiffre. Ce chiffre est appelé le type de ligne (line type). La fonction et le format du reste de la ligne dépend du type de ligne.

 

Restrictions sur le format des fichiers de pièces et primitives

Les fichiers de la bibliothèque de pièces LDraw.org doivent utiliser la terminaison des lignes au standard DOS/Windows. C'est-à-dire <CR><LF> (carriage return/line feed) à chaque fin de ligne.

Ils doivent donc exister à la fin de la dernière ligne du fichier. En d'autres termes, le fichier doit se terminer par <CR><LF>, ce qui ne veut pas dire que le fichier doit se terminer par une ligne vide suivi de <CR><LF>.

Nota : Ces 2 caractères, correspondants aux codes hexa 0D et 0A, n'apparaissent pas lorsqu'on édite un fichier sous Windows. Il peut être utile d'utiliser un éditeur qui les visualisent facilement comme Notepad2, de Florian Balmer ( http://www.flos-freeware.ch ) en allant dans le menu "View / Show Line Endings", et passe en mode standard avec le menu "File / Line Endings / Windows (CR+LF)".

 

Langue utilisée dans les fichiers

La langue utilisée pour la désignation des pièces, les commentaires, mots-clefs, etc, est l'Anglais, ou plutôt l'Anglais Australien en hommage au créateur du système LDraw, James Jessiman (1971-1997).

Il existe quelques différences entre l'Anglais et l'Australien :

Français
de France
Anglais
Britanique
Anglais
Australien
Couleur Color Colour
Gris Gray Grey

Pour plus d'informations sur le langage Australien voir :
LEXILOGOS : Dictionnaire anglais d'Australie,
Wikipédia : Anglais australien.

 

Nom des fichiers

 

Généralités sur le nom des fichiers

Le nom des fichiers n'est plus nécessairement restreint au format 8.3 DOS, comme par le passé. Par contre, les noms ne doivent pas dépasser 255 caractères, en incluant l'extension.

Pour des raisons de portabilité inter-plateformes et inter-systèmes d'exploitations, l'utilisation des caractères "espace" (spc) et "tabulation" (tab) est fortement déconseillé dans les noms de fichiers.

D'autres caractères spécifiques, comme &, #, |, et ?, doivent être évités, car ils peuvent également poser des problèmes dans les adresse URL des fichiers.

Il est à noter que les fichiers à noms longs, et les caractères non DOS permis, ne pourront pas toujours être utilisés avec les anciens programmes, qui ne supportent pas entièrement cette spécification.

 

Restrictions sur le nom des fichiers de pièces et primitives

Pour les fichiers de la bibliothèque de pièces LDraw.org, depuis mai 2008, les noms sont restreints à 25 caractères, y compris l'extension (.DAT), soit dans la pratique 21 caractères pour le nom lui-même, et doivent uniquement utiliser les caractères a-z, A-Z, 0-9, _, et -.

Nota : Le nom de fichiers sur "Parts Tracker" est toujours limité au format 8.3 DOS. Le fichier Parts.lst listant le contenu de la bibliothèque, et utilisé par les modeleurs, pourrait accepter 9 caractères pour le nom, mais pas plus.

Nota : Depuis 2010, les noms à 25 caractères (21.3) sont pris en compte sur "Parts Tracker" avec la nécessité d'utiliser une nouvelle version de mklist.exe pour générer la liste des pièces de votre bibliothèque (voir : Commande "Fichier / Scanner Pièces" de MLCad prohibée).

Nota : Depuis 08-2014, les noms à 25 caractères sont pris en compte pour les primitives.

Pour éviter toute confusion avec la grammaire anglaise, la virgule (,) n'est pas autorisé.

Les caractères majuscules et minuscules sont permis dans les noms de fichiers, car ces noms sont insensibles à la casse (A et a sont considérés comme le même caractère par les programmes).

Actuellement toutes les pièces officielles sont publiées avec des noms entièrement en majuscules.

Nota : Nous verrons avec la méta-commande Nom du fichier (Name:), comment on nomme les fichiers en fonction de leur utilisation.

 

Extension des fichiers

Il y a 3 extensions utilisées pour LDraw :

.DAT : Les fichiers de pièces (briques LEGO), portent toujours l'extension DAT. Ces fichiers peuvent être des pièces complètes, des parties de pièces, des primitives (parties élémentaires répétitives), et des primitives de haute résolution. Les fichiers de la bibliothèque de pièces LDraw.org (LDraw Parts Library) n'utilisent que cette extension.

.LDR : Aujourd'hui, les fichiers des modèles simples LDraw (assemblages de pièces LEGO virtuelles), portent l'extension LDR (par défaut). Mais, à l'origine, l'extension des ces fichiers modèles était DAT, puis cette extension est devenue LDR, pour éviter des ambigüités. C'est pour cette raison qu'il existe encore des modèles ayant l'extension DAT.

.MPD : Les fichiers des modèles multiples contiennent plusieurs modèles, et portent généralement l'extension MPD, mais pour rester compatible avec l'historique l'extension .LDR n'est pas interdit, et tous les programmes peuvent (doivent) utiliser les deux extensions.

 

Système de coordonnées

LDraw utilise comme système de coordonnées un trièdre orthogonal direct.

Une particularité de ce trièdre est d'utiliser la direction "Y négatif" pour donner le sens "vers le haut". Une conséquence est d'avoir le plan horizontal dans le plan "XZ", ce qui n'est pas habituel pour les spécialistes de la CAO (Conception Assistée par Ordinateur).

 

Unités LDraw

Les pièces LDraw sont mesures en unités LDraw ("LDraw Units" ou "LDU") :

1 largeur/longueur de brique 1x1 = 20 LDU
1 hauteur de brique = 24 LDU
1 hauteur de plate (1/3 de brique) = 8 LDU
1 diamètre de tenon (Stud) = 12 LDU
1 hauteur de tenon = 4 LDU

Par rapport au monde réel, et par approximation :
  1 LDU = 1/64 pouce, pour les Anglo-saxons (soit 0.39687 mm)
  1 LDU = 0.4 mm, pour le reste du monde.

Nota : Cette approximation, par rapport au monde réel, reste une approximation. Alors qu'elle peut être utilisée pour déterminer l'équivalent LDraw d'une partie physique d'une pièce réelle (par exemple, la courbe d'une surface), les points caractéristiques de cette partie de pièce doivent être vérifiées en mettant la pièce en référence par rapport à d'autres pièces réelles. Par exemple, il est possible de construire un carcan de briques et de plates pour entourer la pièce à modéliser, et de déterminer ces points caractéristiques.
Lorsque vous utilisez cette approximation dans un motif (dessin sur une brique), cela ne doit être fait que pour de petits détails. Les grandes zones de motif doivent être mesurées en multiples de dimensions de plates ou briques.

 

Précision et format des valeurs

 

Précision

En général, dans la bibliothèque LDraw, 3 chiffres après la décimale sont suffisants pour les pièces, les parties de pièces, et les primitives qui n'ont pas besoin d'être mis à l'échelle (agrandis), par exemple les tenons (studs), connecteurs (peg), clips (clips), extrémités d'articulations (hinge ends) etc...

Il faut 4 chiffres après la décimale pour les primitives en haute résolution, et les primitives devant être mis à l'échelle, comme par exemple les portions de cylindres (cylinder sections), cuboïdes (boxes), rectangles (rectangles), disques (discs), bords (edges), etc... Ceci permet à de telles primitives d'accepter un facteur d'échelle de 10, en conservant une précision de 3 chiffres.

Le page de référence consacrée au primitives indique les familles de celles qui ne sont pas supposées être mise à l'échelle.

 

Format

Les zéros superflus après la virgule doivent être enlevés. C'est-à-dire mettre 1.5 au lieu de 1.500.

Le zéro en tête des nombres supérieur ou égal à 1 doivent être enlevés. C'est-à-dire mettre 1.5 et non 01.5.

Le zéro en tête des nombres inférieurs à 1 sont optionnels. C'est-à-dire mettre 0.5 ou .5 sont tous les deux valides.

 

Types de ligne de commande

Chaque ligne du fichier est une commande unique. Le premier caractère (hors espace) de chaque ligne définit le type de commande. Les caractères valides sont les chiffres allant de 0 à 5, dont voici la signification :

Si le caractère, définissant le type de ligne, n'a pas la bonne valeur, alors la ligne est ignorée.

Les méta-commandes ont besoin d'un mot-clé supplémentaire. Ces mots-clés doivent être encapsulés, et vous devez savoir que si la méta-commande ne demande pas d'autres informations, vous ne devez pas lui en donner des supplémentaires.

 

Type de ligne 0 : Commentaire ou Méta-commande

Le type de ligne 0 est le type de ligne "fourre tout" dans lequel on met tout ce qui n'est pas des commandes de création d'entités graphiques. La première utilisation sert à commenter le fichier, et la seconde sert à informer les programmes de modélisation ou de rendu de modifier leur comportement pour tenir compte d'un ordre particulier. Pour cela il est possible d'utiliser de nombreuses commandes ou méta-commandes spécifiques, officielles ou non, générales ou spécifiques à un programme. Les programmes qui ne reconnaissent pas ces commandes ou méta-commandes les considères comme des commentaires.

 

Commentaire

Contient une information pour commenter votre fichier modèle.

Format de la ligne :

        0 // <texte du commentaire>
Ou :
        0 <texte du commentaire>

Où le <texte du commentaire> est ce que vous voulez pour commenter votre pièce ou modèle.
S'il s'agit de la première ligne du fichier, alors elle a une autre fonction : Le commentaire devient le titre du modèle. Voir ci-dessous.

Nota : la seconde forme est aujourd'hui désapprouvée. Il est préférable d'utiliser la première forme. Le séparateur // indique clairement que cette ligne est un commentaire, en autorisant les analyseurs syntaxiques des programmes à ne pas poursuivre plus loin leur analyse.

 

Méta-commande et Méta-donnée

Méta-commande : Une méta-commande sert à déclarer une action à des programmes compatibles avec le format LDraw. Il y a actuellement beaucoup de méta-commandes officielles, et également des méta-commandes officieuses plus ou moins spécifiques à des programmes particuliers.
La possibilité d'avoir des méta-commandes est une façon d'étendre les spécifications du format LDraw, et d'y inclure des instructions comme "STEP" (étape de construction) ou "BFC" (définition du sens des faces), etc..., à l'intérieur du fichier.

Méta-donnée : Au lieu d'être une commande, il peut s'agir de méta-donnée, comme le nom de l'auteur, ou ajouter des mots-clefs de recherche, de catégorie de pièce, d'aide sur l'utilisation de la pièce, etc..., à l'intérieur du fichier.

Format de la ligne :

        0 !<commande> <paramètres additionnels>
Ou :
        0 <commande> <paramètres additionnels>

Nota : la seconde forme n'est plus à utiliser pour toutes les nouvelles méta-commandes.

! : Est utilisé pour identifier positivement qu'il s'agit d'une méta-commande.
Nota : Quelques méta-commandes officielles n'ont pas ce caractère "!", pour conserver la compatibilité avec l'existant. Cependant, toutes les nouvelles méta-commandes officielles doivent utiliser ce caractère, et il est recommandé que toutes les officieuses fassent de même.

<commande> : Nom de la méta-commande ou méta-donnée. Ce nom peut être en majuscules et/ou en minuscules (insensible à la casse).

<paramètres additionnels> : Paramètres additionnels de la méta-commande. Elle peut comporter plusieurs paramètres. Si la méta-commande ne demande aucun paramètre, alors il ne faut pas lui en fournir.

Nous verrons plus loin une description des diverses méta-commandes officielles, et les méta-commandes spécifiques à des programmes tiers.

 

Type de ligne 1 : Insertion de sous-fichier

Cette commande insert un sous-fichier dans le fichier LDraw en cours. Ce sous-fichier au format LDraw peut suivant le cas être une primitive, une partie de pièce, une pièce complète, ou un assemblage de pièces (modèle ou sous-modèle).

Commande d'insertion de sous-fichier

Format de la ligne :

        1 <couleur> x y z a b c d e f g h i <fichier>

où :

Les lignes de type 1 ne devraient jamais utiliser la couleur 24, qui sert de couleur complémentaire. En effet, une couleur et sa couleur complémentaire ne sont pas symétriques, et ne vont donc pas par pair. En conséquence, utiliser la couleur 24 peut donner des résultats inattendus ou indéterminés.

Les fichiers peuvent se trouver dans les sous-dossier LDRAW\PARTS, LDRAW\P, LDRAW\MODELS, le dossier courant, un chemin relatif à un de ces dossiers, ou un chemin absolu avec le nom du disque, pouvant être spécifié. Les parties de pièces sont typiquement sauvegardés dans le sous-dossier LDRAW\PARTS\S et doivent être référencés en relatif, par exemple comme s\subpart.dat, et les primitives de haute résolution (hires), sont sauvegardés dans le sous-dossier LDRAW\P\48 et doivent être référencés en relatif, par exemple comme 48\hires.dat.

Il n'y a aucune limite de spécifié sur le nombre de niveaux d'appels de sous-fichiers (un sous-fichier pouvant appeler un autre sous-fichier, lui même appelant un sous-fichier, etc.), mais certains programmes compatibles avec le format LDraw doivent probablement avec une limite pratique imposée.

 

Position

Format de la ligne :

        1 couleur x y z a b c d e f g h i part.dat 

Les champs x, y et z sont les coordonnées de position de la pièce.
Le plan XZ représente le sol. La hauteur est défini par l'axe Y négatif, et donc les Y positifs vont vers le bas... ce qui n'est pas habituel en CAO.

 

Orientation

La commande d'insertion de pièce a quelques aspects spécifiques, qui requièrent une attention spéciale. Ce chapitre aura plus de sens, si vous êtes familiarisé avec les matrices mathématiques en modélisation graphique.

Format de la ligne :

        1 couleur x y z a b c d e f g h i part.dat 

Les champs :

Les champs :

Si l'élément est un cylindre :

Les valeurs d'inclinaisons peuvent être positives ou négatives, suivant le sens de rotation voulu.

Les champs a à i sont les paramètres d'inclinaison, de symétrie, et d'échelle, qui peuvent être utilisés par les matrices 3D de transformation "standards". Les champs x, y et z font également partis de la matrice :

    | a d g 0 |
    | b e h 0 |
    | c f i 0 |
    | x y z 1 |

de manière que chaque point (x, y ,z) se transforme en (x', y', z') suivant :

    x' = a*x + b*y + c*z + x
    y' = d*x + e*y + f*z + y
    z' = g*x + h*y + i*z + z

ou, sous forme de matrice mathématique :

                                    | a d g 0 |
    | X' Y' Z' 1 | = | X Y Z 1 | x  | b e h 0 |
                                    | c f i 0 |
                                    | x y z 1 |

Nota : Pour les pièces soumises à LDraw.org, la matrice spécifiée pour les sous-fichiers (ligne de type 1), ne doit pas être dégénérée, et ne doit pas contenir des lignes ou colonnes entièrement à zéro.

 

Pièce

Les pièces peuvent se trouver, dans les sous-dossiers p\, parts\, ou models\ (du dossier de ldraw\).
James (l'auteur de LDraw) a défini les dossiers pour que p\ contienne les éléments utilisés de nombreuses fois dans d'autres éléments (comme stud.dat). Le dossier parts\ contient les pièces complètes, prêtes à être utilisées pour la construction de modèles.

Elles peuvent également être dans le même dossier que le modèle qui l'appelle.

Les pièces peuvent, également, se trouver dans le sous-dossier models\, qui contient (par défaut) les modèles construits.

Les fichiers de pièce peuvent avoir également des commandes d'insertion de pièces. Il ne semble pas y avoir de limite spécifique, au nombre de niveaux de ces commandes, de fichier en fichier.

Les fichiers de pièces, qui se trouvent sur le site de LDraw, se partagent en deux catégories : Les officielles qui ont été validées, et les non officielles (Unofficial parts), qui n'ont pas encore été approuvées.
D'autres pièces, dites "utilisateur", peuvent se trouver sur d'autres sites

 

Type de ligne 2 : Insertion de ligne

Cette commande dessine une ligne entre deux points.

Commande d'insertion de ligne

Format de la ligne :

        2 <couleur> x1 y1 z1 x2 y2 z2 

où :

La ligne de type 2, comme également celle de type 5, est utilisée principalement uniquement pour les bords de pièces. Quand elle est utilisée de cette manière, elle Elle doit prendre la couleur 24.

La ligne de type 2 peut pouvait également être utilisée pour représenter de fins détails dans les motifs, comme sur les "Torso" de Minifig. Dans ce cas, toutes les couleurs peuvent pouvaient être utilisées. Voir le chapitre Couleurs plus bas. Nota : Actuellement cette pratique est désuète et ne doit plus être utilisée à cause des problèmes de rendu que cela occasionne. Les fins détails doivent être créés avec des triangles et quadrilatères.

Dans tous les cas, il faut se rappeler que certains programmes de rendu n'affichent pas les lignes de type 2 ou 5, ou les affichent seulement en cochant un paramètre.

 

Type de ligne 3 : Insertion de triangle

Cette commande dessine un triangle rempli (une facette), entre trois points.

En réalité il serait préférable d'utiliser le terme de facette triangulaire, car ce ne sont pas les bords qui sont dessinés mais l'intérieur du triangle.

 

Commande d'insertion de triangle

Format de la ligne :

        3 <couleur> x1 y1 z1 x2 y2 z2 x3 y3 z3 

où :

Pour la définition de <couleur> voir le chapitre Couleurs plus bas.

Voir également les commentaires sur les polygones à la fin du chapitre concernant les lignes de type 4.

 

Type de ligne 4 : Insertion de quadrilatère

Cette commande dessine un quadrilatère rempli (une facette), entre quatre points.

Comme pour le triangle il serait préférable d'utiliser le terme de facette quadrangulaire, car ce ne sont pas les bords qui sont dessinés mais l'intérieur du quadrilatère.

 

Commande d'insertion d'un quadrilatère

Format de la ligne :

        4 <couleur> x1 y1 z1 x2 y2 z2 x3 y3 z3 x4 y4 z4 

où :

Pour la définition de <couleur> voir le chapitre Couleurs plus bas.

 

Considérations sur les quadrilatères et polygones

Voici quelques considérations sur la façon de créer des quadrilatères pour qu'ils soient valides.

 

Sens de déclaration des points

Lorsque aucun ordre spécifique de déclaration des points n'est donné, ils peuvent être déclarés dans le sens horaire (CW) ou anti-horaire (CCW) sans inconvénient (voir le chapitre BFC). Le "bon" exemple est d'utiliser l'ordre des points 1, 2, 3, 4, ou bien, dans l'autre sens 1, 4, 3, 2, avec un résultat encore bon.

 

Quadrilatères non valides

Par contre, comme "mauvais" exemple, il vaut mieux éviter de construire un quadrilatère où les lignes se croisent, et forme ce qu'on appelle une facette en "nœud papillon" ou "sablier" :

Il suffit de changer l'ordre des points.

De même évitez de construire un quadrilatère concave :

Le remplacer par 2 triangles.

Il faut également éviter de créer un quadrilatère avec 3 points alignés :

Le remplacer par 1 triangle.

Il faut également éviter de créer un quadrilatère avec 2 points confondus :

Le remplacer par 1 triangle.

Nota : On appelle ces deux derniers cas des surfaces "dégénérées", car les programmes de rendu, pour afficher ce type de surface sont incapables de calculer la normale au point 4.

 

Couleur des quadrilatères

Il est fortement recommandé de ne pas utiliser la couleur 24 (la couleur complémentaire prévue pour les bords) avec les polygones. Le rendu d'un polygone en couleur 24 dans le fichier principal, est dépendant de son implémentation dans le programme de rendu, et il peut donc ne pas y avoir de rendu du tout. Bien que l'utilisation de la couleur 24 dans un sous-fichier, permette un rendu configurable, cela ne permet pas d'assurer des résultats attendus dans toutes les situations, avec tous les programmes de rendu.

 

Planéité des quadrilatères

Les quadrilatères doivent être plans, c'est-à-dire que les 4 points qui les définissent sont dans un même plan dans l'espace, pour ne pas former des quadrilatères tordus ou vrillés.

Les triangles n'ont pas ce type de problème, car pour définir un plan dans l'espace il suffit de 3 points, et en conséquence, un triangle dans l'espace est toujours plan.

Cela signifie également que si le quadrilatère plan est coupé en deux triangles, les deux triangles seront coplanaires l'un avec l'autre. Il y a toujours deux façons de couper un quadrilatère en deux triangles, et les deux résultats doivent donner des triangles coplanaires.

Les triangles sont considérés comme coplanaires, par LDraw.org, si l'angle entre les deux normales à leurs surfaces est plus petit ou égal à 3 degrés. Mais, il est fortement recommandé de descendre cette limite à 1 degré, spécialement pour les grands quadrilatères, où la "torsion" peut être vu sur la pièce grossie avec un zoom normal.

Un quadrilatère NON plan doit être remplacé par 2 triangles jointifs, avec une ligne conditionnelle à leur jonction.

Nota : les pièces déjà dans la bibliothèque ou déjà certifiés, ne doivent pas être resoumises uniquement pour fixer un problème de dépassement de la limite de coplanarité.

 

Type de ligne 5 : Insertion de ligne conditionnelle

Les lignes conditionnelles sont des lignes qui ne sont dessinées que si elles sont utiles à la bonne visualisation des parties cylindriques.

 

Commande d'insertion de ligne conditionnelle

Dessine une ligne entre les deux premiers points, si la projection des deux points de contrôle sur l'écran sont du même coté d'une ligne imaginaire passant par la projection des deux premiers points sur l'écran.

Format de la ligne :

        5 <couleur> x1 y1 z1 x2 y2 z2 x3 y3 z3 x4 y4 z4 

où :

Pour la définition de "couleur" voir le chapitre Couleurs plus bas.

 

Commentaire sur les lignes conditionnelles

Explication sur les lignes conditionnelle :
Voici un exemple utilisant une commande de ligne conditionnelle. Elle tente de représenter un tenon cylindrique (stud), en l'assimilant, de façon approximative, à un prisme hexagonal, qui ressemble au schéma ci-dessous :

             1___________2
            /             \
           /               \
         6/                 \3
         |\                 /|
         | \               / |
         |  \5___________4/  |
          \  |           |  /
           \ |           | /
            \|___________|/
  • La ligne verticale sous 1 ne doit pas être dessinée car 6 et 2 ne sont pas du même coté de cette ligne.
  • La ligne verticale sous 2 ne doit pas être dessinée car 1 et 3 ne sont pas du même coté de cette ligne.
  • La ligne verticale sous 3 doit être dessinée car 2 et 4 sont du même coté.
  • La ligne verticale sous 4 ne doit pas être dessinée car 3 et 5 ne sont pas du même coté de cette ligne.
  • La ligne verticale sous 5 ne doit pas être dessinée car 4 et 6 ne sont pas du même coté de cette ligne.
  • La ligne verticale sous 6 doit être dessinée car 5 et 1 sont du même coté.
             1___________2
            /             \
           /               \
         6/                 \3
         |\                 /|
         | \               / |
         |  \5___________4/  |
          \                 /
           \               /
            \_____________/
  • Le résultat est représenté par le dessin ci-contre.

Autre façon de présenter les lignes conditionnelle :

Soit une commande d'insertion de ligne conditionnelle BE avec ses points de contrôle AC :
5 24 Bx By Bz Ex Ey Ez Ax Ay Az Cx Cy Cz

A et C sont du même coté de la ligne en pointillé vert passant par BE, donc BE est dessinée.

Soit une autre commande d'insertion de ligne conditionnelle CF avec ses points de contrôle BD :
5 24 Cx Cy Cz Fx Fy Fz Bx By Bz Dx Dy Dz

B et D ne sont pas du même côté de la ligne en pointillé rouge passant par CF, donc CF n'est pas dessinée.

Ces lignes servent à montrer les bords de profil des surfaces courbes. C'est l'objet de ce type de ligne.
Comme on peut le voir dans l'exemple, les points de contrôle peuvent être, ou sont habituellement choisis parmi les points existants de l'objet.
Comme ces points de contrôle ne sont jamais visualisés, ils peuvent être positionnés n'importe où, tant qu'ils gardent la même propriété de contrôle, c'est-à-dire tant qu'ils restent dans le même plan que chaque point de contrôle fait et les 2 premiers points.

Voir sur ma page de création de pièces une troisième façon d'appréhender les lignes conditionnelles :
Lignes conditionnelles.

Voir également les commentaires sur les couleur à la fin du chapitre sur les lignes de type 2.

 

Chevauchement des entités graphiques

Il y a un certain nombre de restrictions sur le chevauchement des entités graphiques pour avoir un bon rendu.

 

Entités graphiques dupliquées

Pour qu'une pièce soit acceptée par LDraw.org, il ne doit y avoir d'entités graphiques (lignes type 1 à 5) de dupliquées dans le fichier. C'est-à-dire :

Appeler 2 fois un sous-fichier (ligne de type 1), avec la même position et orientation n'est pas autorisé.

Des lignes (ligne de type 2) et lignes conditionnelles (ligne de type 5) identiques ne sont pas autorisés. Mais, lors du test de soumission d'un fichier sur le PT, l'ordre des points finaux ne sont pas considérés pour tester les lignes identiques. De même les points de contrôle des lignes conditionnelles ne sont pas testés.

Des triangles (ligne de type 3) et quadrilatères (ligne de type 4) identiques ne sont pas autorisés. Mais, lors du test de soumission d'un fichier sur le PT, l'ordre des points de définition ne sont pas considérés pour tester les polygones identiques.

 

Chevauchement de lignes

Pour qu'une pièce soit acceptée par LDraw.org, il ne doit y avoir d'entités graphiques (lignes type 1 à 5) qui se chevauchent dans le fichier. C'est-à-dire :

Une ligne (ligne de type 2) ne doit pas recouvrir, partiellement ou entièrement une autre ligne (ligne de type 2).

Une ligne conditionnelle (ligne de type 5) ne doit pas recouvrir, partiellement ou entièrement une autre ligne conditionnelle (ligne de type 5).

Une partie (mais pas entière) d'une ligne conditionnelle (ligne de type 5) peut recouvrir entièrement (mais pas partiellement), une autre ligne (ligne de type 2).

Considérons 4 points A-B-C-D alignés :

Les lignes (lignes de type 2 et 5) peuvent croiser n'importe quelle autre ligne (lignes de type 2 et 5).

 

Recouvrement de polygones

Tous les efforts doit être donné pour supprimer le chevauchement des polygones (lignes de type 3 et 4) coplanaires. Lorsque ce chevauchement est inévitable, il doit être amené au minimum absolu.

Les polygones (triangles et quadrilatères) coplanaires peuvent se chevaucher seulement s'ils sont de la même couleur. Mais, ce chevauchement est à éviter car il affecte la qualité de rendu pour les pièces transparentes.

 

Intersection de polygones

Tous les efforts doit être donné pour supprimer l'intersection des polygones (lignes de type 3 et 4) non coplanaires. Lorsque ce croisement est inévitable, il doit être amené au minimum absolu.

Les polygones non coplanaires peuvent se croiser (passer l'une à travers l'autre). Mais également, cela est à éviter pour la qualité de rendu des pièces transparentes.

Nota : lorsque des primitives (ligne de type 1) chevauchent ou coupent d'autres primitives, ou polygones (lignes de type 3 et 4), si cela est petit, c'est considéré comme acceptable. La raison, est de ne pas obliger les auteurs de pièces à décomposer (inline) les primitives. Cependant, il peut y avoir quelques cas où il est meilleur ou mieux indiqué d'utiliser une primitive 3-8cyli avec un quadrilatère plutôt qu'une primitive 1-2cyli. Une décision au cas par cas est laissé aux vérificateurs de pièces, lors du processus d'acceptation.

 

Jonction de polygones

Autant que possible, les polygones doivent partager des sommets communs :

Dans cet exemple les polygones ABCD et EGF, ont les lignes AB et EF colinéaires, mais si les points A et E sont communs, les points B et F sont distincts, et l'approximation en nombre entier des pixels graphiques entre les lignes AB et EF, de longueur différente, se fait différemment, et cause des trous qui sont visibles dans la pièce, surtout avec un grand zoom. C'est la cause principale du phénomène des "bords dégradés" lorsque la pièce tourne.
Dans la pratique, il suffit de décomposer le polygone le plus grand en 2 polygones pour n'avoir que des sommets communs aux bords communs. Ici le polygone ABCD a été décomposé en un quadrilatère AFCD et un triangle FBC.

 

Méta-commandes officielles

L'en-tête du fichier forme la liste des commandes commençant le fichier avant les lignes permettant de créer les entités graphiques de la pièce ou du modèle (lignes types 1 à 5). Cet en-tête ne peut contenir que des lignes type 0, ou des lignes vides servant de séparateurs.

 

En-têtes normalisées des fichiers de pièces

L'en-tête des fichiers de pièces doit au minimum permettre de décrire la pièce, identifier cette pièce par un numéro, donner le nom du créateur de ce fichier.

Il doit ensuite donner son statut vis-à-vis de l'organisation LDraw.org, si cette pièce est officielle ou non, et si elle peut être redistribuée.

Toutes ces informations sont (ou sont devenus) obligatoires.

D'autres informations peuvent être ajoutées, de façon optionnelle, pour permettre d'informer l'utilisateur du fichier de son historique (!HISTORY), de certaines caractéristiques sur son utilisation (!HELP), de donner sa catégorie (!CATEGORY), ou des mots-clefs permettant une recherche (!KEYWORDS), ou d'informer les programmes de visualisation sur le mode de construction (!CMDLINE), (BFC CERTIFY).

Aucune autre méta-commande n'est permise dans l'en-tête du fichier.

Exemple de syntaxe

     0 PartDescription
     0 Name: Filename.dat
     0 Author: RealName [UserName]
     0 !LDRAW_ORG Part|Subpart|Primitive|48_Primitive|Shortcut UPDATE YYYY-RR
     0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt 

ou :

     0 !LICENSE Not redistributable : see NonCAreadme.txt

     0 !HELP Optional free text description of file usage
     0 !HELP Second row after user's line break to simulate paragraph

     0 BFC ( CERTIFY ( CCW | CW ) | NOCERTIFY )

     0 !CATEGORY Category name
     0 !KEYWORDS words, more words, ...,
     0 !KEYWORDS words in second row, ..., final words

     0 !CMDLINE LDraw run-time command(s)

     0 !HISTORY YYYY-MM-DD [UserName] Free text description of change. This can wrap to a
     0 !HISTORY YYYY-MM-DD [UserName] second row with the same date if necessary. However authors should lean toward writing longer
     0 !HISTORY YYYY-MM-DD [UserName] single !HISTORY lines(and not feel constrained to the historic 80-character limit on line length)

ou

     0 !HISTORY YYYY-MM-DD {RealName} Free text description of change

     0 // Comments

     1 <colour> x y z a b c d e f g h i <file>

Autres Exemples

     0 Animal Scorpion
     0 Name: 30169.dat
     0 Author: Chris Dee [cwdee]
     0 !LDRAW_ORG Part UPDATE 2006-01
     0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

     0 !HELP Obviously there is no need for additional
     0 !HELP information in this part. But it will give
     0 !HELP you an idea of a primitive formatting.
     0 !HELP 0 !HELP We should limit the length of
     0 !HELP a line to 50 characters for the sake of readability.

     0 BFC CERTIFY CW

     0 !CATEGORY Animal
     0 !KEYWORDS Sting, Poison, Adventurers, Egypt
     0 !KEYWORDS Zodiac

     0 !CMDLINE –c1

     0 !HISTORY 2000-08-?? {Axel Poque} fixes to resolve L3P error messages
     0 !HISTORY 2000-08-?? {Manfred Moolhuysen} fixes to resolve L3P error messages,
     0 !HISTORY 2000-08-?? {Manfred Moolhuysen} fixed gap where body meets head
     0 !HISTORY 2002-04-25 [PTadmin] Official update 2002-02
     0 !HISTORY 2004-05-18 [guyvivan] Made BFC compliant
     0 !HISTORY 2004-05-18 [guyvivan] Used more primitives
     0 !HISTORY 2006-??-?? [PTadmin] Official update 2006-01

     0 // Tail 1 16 1 0 23 1 0 0 0 1 0 0 0 1 4-4cyli.dat

ou :

     0 Boat Base 8 x 10
     0 Name: 2622.dat
     0 Author: Chris Alano
     0 !LDRAW_ORG Part UPDATE 2000-02
     0 !LICENSE Not redistributable : see NonCAreadme.txt

     0 BFC NOCERTIFY

     0 !KEYWORDS Pirates, Caribbean, Ship

 

En-têtes normalisées des modèles officiels

Le "Official Model Repository" (OMR) a développé des standards pour les en-têtes et noms de fichiers des modèles. C'est pour avoir des modèles homogènes, et facilement indexables par un script, et une base de donnée. Vous trouverez ici, un aperçu de ce standard pour les noms de fichiers et les en-têtes.

 

Ancienne définition des modèles officiels

Nota : Ce chapitre est obsolète, et n'est gardé que pour le côté historique. Voir le chapitre suivant pour les définitions actuelles (2011).

En-tête

L'en-tête du fichier doit être concis, et en même temps, donner toutes les informations nécessaires sur le modèle ou le sous-modèle. Voici l'en-tête officielle des fichiers actuels :

En-tête de modèle principal :

        0 7140 X-Wing Fighter
        0 Name: main.ldr
        0 Author: Tim Courtney
        0 LDraw.org Official Model Repository
        0 http://www.ldraw.org/repository/official/

En-tête d'un sous-modèle :

        0 7140 X-Wing Fighter, Main Fuselage
        0 Name: m-2a.ldr
        0 Author: Tim Courtney
        0 LDraw.org Official Model Repository
        0 http://www.ldraw.org/repository/official/

En-tête d'un Minifig :

        0 7140 X-Wing Fighter, Luke Skywalker Mini-figure
        0 Name: mf-1.ldr
        0 Author: Tim Courtney
        0 LDraw.org Official Model Repository
        0 http://www.ldraw.org/repository/official/

Termes

Voici les termes utilisés dans le dossier, avec leur sens contextuel.

Nom de fichier et Stockage

Les noms de fichiers pour les modèles officiels répertoriés, (Official Model Repository ou OMR) sont limités au format 8.3 des noms de fichiers compatibles MS-DOS (c'est-à-dire 8 caractères pour le nom, et 3 pour l'extension). Chaque set OMR est inclus dans un fichier MPD. Ce fichier MPD peut être extrait pour créer un autre sous-dossier pour le set particulier (voir le diagramme ci-dessous). A l'intérieur, il y a les différents fichiers qui composent le set.

Le sous-dossier du set utilise pour son nom, le numéro du set, plus un modifieur optionnel, et l'année sur deux chiffres. Cela est fait en plaçant ces instructions de nom de dossier dans le fichier MPD, qui contient le set complet. Tout cela doit aller dans le sous-dossier \sets du dossier \models.


              Quatre chiffres pour le numéro du set
              |
              | Modifieur optionnel pour l'année
              | |
              | |  Deux chiffres pour l'année où le set a été réalisé.
              | |  |
models/sets/XXXXZ-YY/

Dans le sous-dossier du set, les noms de fichiers suivants représentent les différents aspects du set ou du modèle.

   main.ldr  - Instructions principales, incluant tous les modèles qui peuvent
               être construits en même temps. Pour les modèles simples, c'est
               juste l'affichage des modèles m1.ldr à m(x).ldr.
   m-1.ldr   - Premier modèle du manuel d'instruction.
   m-1a.ldr  - Premier sous-modèle du premier modèle.
   m-1aa.ldr - Premier composant du premier sous-modèle du premier modèle.
   m-1ab.ldr - Second composant du premier sous-modèle du premier modèle.
   m-2.ldr   - Second model modèle du manuel d'instruction.
   alt.ldr   - Fichier d'affichage du modèle alternatif du manuel d'instruction (si existe).
   a-1.ldr   - Premier modèle alternatif du manuel d'instructions.
   a-1a.ldr  - Premier sous-modèle du premier modèle alternatif.

Pour utiliser plus de niveaux de sous-modèles, il suffit d'ajouter une lettre à la fin du nom, jusqu'à atteindre la limite de 8 caractères que doit porter le nom (sans l'extension).

Sous-modèle de Minifig

Les sous-modèles de Minifig, doivent être nommés dans leur ordre d'apparition dans le manuel d'instructions.

   mf-1.ldr  - (7140) Luke Skywalker minifig
   mf-2.ldr  - (7140) Biggs Darklighter minifig
   mf-3.ldr  - (7140) Mechanic minifig

Modifieur optionnel pour l'année

Le modifieur optionnel pour l'année, s'utilise lorsqu'il y a plusieurs sets, cette année là, qui portent ce numéro de set. Cela se rencontre habituellement dans les packs de sets, de la fin des années 80, et le début des années 90, mais cela arrive aussi pour d'autres sets. Par exemple, le pack de sets 1974 :

                         Modifieur optionnel pour l'année
                         |
C:\LDRAW\MODELS\SETS\1974A-90\MAIN.ldr Flyercracker U.S.A.
C:\LDRAW\MODELS\SETS\1974B-90\MAIN.ldr Smuggler's Hayride
C:\LDRAW\MODELS\SETS\1974C-90\MAIN.ldr Star Quest

Chaque modèle ou set différent, qui est publié avec ce numéro de set spécifique, dans cette année là, a besoin d'un modifieur pour son dossier. Les fichiers dans le dossier, cependant, suivent le système de numérotation standard. Typiquement, le premier set du pack, ou le premier set publié, avec ce numéro prendra A comme modifieur, et le second B, etc...

Ce système d'en-tête et d'appellation des noms de fichiers a été mis en place par le "LDraw.org Official Model Repository" (modèles officiels répertoriés) (OMR) pour une redistribution des sets officiels aux utilisateurs de LDraw. Chaque auteur individuel, de ces modèles officiels, utilisé dans l'OMR, est crédité pour le modèle dans l'en-tête, et sur le site internet LDraw.org. L'OMR ne veut pas dire, enlever ses droits à l'auteur individuel, ou à l'auteur du site, mais cherche uniquement à distribuer les modèles Lego aux utilisateurs de LDraw gratuitement.

 

Nouvelle définition des modèles officiels

Le but

Le Répertoire des Modèles Officiels (Official Model Repository ou OMR en anglais) est une base de données de fichiers au format LDraw qui décrit des modèles publiés ou vendus par LEGO®.

Cet OMR se trouve actuellement sur le forum de LDraw.org : Official Models.

Pour avoir une cohérence entre les modèles et aider à l'indexage par logiciel, un standard pour les en-têtes de fichiers, noms, et hiérarchie dans l’OMR est exigé. Ce document esquissera les exigences supplémentaires (en plus de ceux présentés dans les spécifications du format de fichier LDraw actuel) pour un modèle devant être inclus dans l’OMR.

Les requis de base

Tous les fichiers dans le modèle doivent être conformes au format de fichier LDraw actuel.

La base du nommage des fichiers

Chaque modèle dans l’OMR consistera en plusieurs sous-fichiers qui sont emballés dans un seul fichier MPD. Pour les Sets qui incluent des instructions pour de multiples modèles chaque modèle aura son propre fichier MPD. Chaque fichier MPD pour le set sera nommé dans la manière suivante:

	<Numéro du Set> - <Nom du Set> [- <Nom du Sous-Modèle>]

Où :

	<Numéro du Set> : Le numéro assigné sur la boite du Set. 
	<Nom du Set> : Le nom du Set imprimé sur la boite, en anglais.  
	<Nom du Sous-Modèle> : Facultatif dans la plupart des cas.
		Cela est exigé pour les modèles alternatifs qui sont détaillés dans
		les instructions de montage (par exemple dans le thème Creator).
		Dans ce cas la nomination est laissée à l'arbitraire de l'auteur,
		mais devrait être descriptif du modèle contenu dans le fichier MPD.  

Pour les Sets qui se composent de multiples modèles qui font partie intégrante du Set complet, tout les sous-modèles seront contenus dans un seule fichier MPD.

Exemple :

	Le Set Creator 4896 - Roaring Roadsters décrit 3 modèles dans ses instructions :
	Set 4896 - Roaring Roadsters - Roadster.mpd
	Set 4896 - Roaring Roadsters - Dragster.mpd
	Set 4896 - Roaring Roadsters - SUV.mpd  

Structure du fichier MPD

Le fichier MPD se conformera à la spécification des fichiers MPD. Chaque nom de fichier aura la structure :

	<Numéro du Set> [- <Index facultatif>] - <Nom individuel>  

Où :

	<Numéro du Set> est le numéro assigné sur la boite du Set.  
	<Index facultatif> est un nombre séquentiel, en commençant par 1, ajouté s'il y a plus d’un Set qui pourrait être assigné au < Numéro du Set >.  
	<Nom individuel> laissé à la discrétion de l'auteur avec les conseils suivants :  
		- Un schéma de nomination logique est très désiré. 
		- Chaque modèle individuel dans l'ensemble (par exemple un véhicule ou un minifig)
		  aura son propre sous-fichier séparé à l'intérieur du fichier MPD.
		- Le nom du Minifig devrait avoir le nom du personnage représenté, s’il est connu.  

Les pièces officieuses (Unofficial parts) sont autorisées. Le nom de fichier de la pièce officieuse est soumis aux règles de la nomination ci-dessus (par exemple 33056.dat seraient renommé comme <Nom de fichier MPD> - 33956.dat). Il est fortement conseillé que toutes les pièces qui ont été créées spécifiquement pour un fichier OMR soient soumises au LDraw.org Parts Tracker (suivi des pièces de LDraw.org). Si une pièce est non disponible officiellement ou sur le LDraw.org Parts Tracker, une substitution appropriée peut être faite. Si la pièce non disponible est une pièce à motif avec une version sans motif disponible, utilisez la version sans motif. Un commentaire devrait être inséré pour indiquer qu'une substitution a été faite ou, si aucune substitution n'est appropriée qu'une pièce a été omise. Indiquez l’étape et le numéro de la page des instructions si possible.

Exemple :

	0 // The next piece should have the Star Wars Hatch pattern per step X on page Y or
	0 // Bionicle piece X should go here per step Y on page Z

Traduction :

	0 // La pièce suivante devrait avoir le motif de Panneau Star Wars à l’étape X sur la page Y ou
	0 // La pièce Bionicle X devrait aller ici à l’étape Y sur la page Z

En-tête de fichier

Chaque modèle individuel dans le fichier MPD qui ne représente pas une pièce officieuse doit avoir le format d'en-tête standard suivant.

En-tête Standard :

	0 FILE <Nom de fichier>.ldr
	0 <sous-fichier individuel>
	0 Name: <Nom de fichier>.ldr
	0 Author: <Nom Auteur> [Pseudo]
	0 !LDRAW_ORG Model -OR- 0 !LDRAW_ORG Unofficial_Model
	0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
	0 !THEME Theme name
	0 !KEYWORDS words, more words, ...,
	0 !KEYWORDS words in second row, ..., final words
	0 !HISTORY YYYY-MM-DD [Username] Free text description of change. This can wrap to a
	0 !HISTORY YYYY-MM-DD [Username] second row with the same date if necessary. However authors should lean toward writing longer
	0 !HISTORY YYYY-MM-DD [Username] single !HISTORY lines(and not feel constrained to the historic 80-character limit on line length).

Où :

	<Nom de fichier> : Le nom du fichier suivant les règles spécifiées dans le chapitre
		Structure du fichier MPD.
	<sous-fichier individuel> : Le nom du sous-fichier individuel qui utilise les règles
		dans le chapitre Structure du fichier MPD.
	<Nom Auteur> : Le nom de l'auteur. Le nom réel complet (prénom et nom) est exigé par
		le "LDraw.org Contributor's Agreement" (Accord du Contributaire LDraw.org ).
	[Pseudo]: Le pseudo LDraw.org de l'auteur.

Les méta-commandes facultatives sont !THEME, !KEYWORDS, et !HISTORY.

Exemple :

	0 FILE 4896 - Roadster Main.ldr
	0 Roadster Main
	0 Name: 4896 - Roadster Main.ldr
	0 Author: Joe Smith [jsmith]
	0 !LDRAW_ORG Unofficial_Model
	0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
	0 !THEME Creator
	0 !KEYWORDS car, convertible
	0 !HISTORY 2011-08-01 [jsmith] Initial creation

Chaque sous-modèle individuel dans le fichier MPD qui représente une pièce officieuse doit utiliser le format de l'en-tête standard des pièces officieuses sur LDraw.org PT. Sa ligne 0 FILE reflétera la version modifiée MPD du nom de la pièce, mais le reste de l'en-tête reflétera le nom original.

Méta-commandes

Toutes les méta-commandes sont permises dans le fichier modèle mais pas spécifiquement exigées excepté celles spécifiées pour l'en-tête. Si incluses, toutes les méta-commandes utilisées devraient permettre toute instruction générée pour être au plus près des instructions officielles que possible.

Géométrie symétrique

Les modèles avec des parties entièrement symétriques (ailes droite et gauche d’un avion par exemple) peuvent souvent être modélisés beaucoup plus facilement en modélisant un des côtés symétriques et en l’incluant alors dans le modèle deux fois, dont un symétrisé par rapport à l’axe de symétrie. Malheureusement, cette symétrisation produit une liste de pièces incorrecte, et également un logo LEGO en miroir sur les tenons, quand on fait un rendu réaliste avec certains logiciels. Donc l’utilisation des symétries est fortement découragée.

Cette traduction est basée sur le document officiel en anglais ratifié le 21 octobre 2011.

 

Considérations personnelles sur les définitions des modèles officiels

Sur les noms du fichier MPD

Sur les noms des sous-fichiers LDR

Set à modèles alternatifs

Pièces non officielles

Ma conclusion : Si je suis d'accord qu'une standardisation du nom pour la gestion des modèles officiels soit une bonne chose, les contraintes sur le format interne, qui devraient être laissées à l'appréciation des créateurs, limite les soumissions à l'OMR.

 

Méta-commandes officielles de l'en-tête du fichier

Ces méta-commandes servent à renseigner l'en-tête du fichier.

 

Titre du fichier (descriptif)

Cette méta-commande contient le nom descriptif de la pièce ou du modèle. Elle se trouve sur la première ligne du fichier, et uniquement sur celle-là.

Titre standard

Format de la ligne :

        0 Texte de Titre

Où le "Texte de Titre" est ce que vous voulez (en anglais, ou plutôt australien-anglais) pour nommer votre pièce ou modèle.
Si la première ligne du fichier a pour type "0", le reste de cette ligne est considéré comme le titre du fichier (en tout cas pour les fichiers de pièces). Cela fait ignorer toute méta-commande pouvant se trouver sur cette ligne.

Nota : Dans les fichiers de projets MPD, cette ligne n'est pas la première du fichier, mais la première ligne apparaissant derrière chaque ligne "0 FILE ...".

Le "Texte de Titre" est limité à 64 caractères.

Tous les mots doivent avoir leur première lettre en majuscule, sauf les articles, prépositions, conjonctions, et forme du verbe être (to be).
Exemple :

        0 Wheel 17 x 75 Motorcycle with Holes in Rim

Certains mots sont considérés inutiles dans la description, comme new (nouveau) et old (ancien), car cela n'est pas toujours une aide sur la chronologie d'apparition des pièces.

Titre avec "(Needs Work)"

Si la pièce est assez bonne pour un usage publique, mais a quelques déficiences qui ont besoin d'être corrigées, le texte "(Needs Work)" (nécessite travail), sans mettre les guillemets, doit être ajouté à la fin de la description.

Nota : Certaines anciennes pièces portent les most en minuscules : (needs work).

Nota : Le nom descriptif complet incluant "(Needs Work)" est limité à 64 caractères, en conséquence, cela diminue la partie de la description utilisable à 51 caractères. Si le nom descriptif comporte "(Needs Work)", un commentaire doit être ajouté au fichier, immédiatement après l'en-tête officielle, décrivant le travail restant à faire, pour finir la pièce.

Titre avec "(Shortcut)"

Les pièces issues d'un assemblage de pièces élémentaires comportent à la fin le mot Shortcut entre parenthèses (Signifie : Raccourci).

Nota : Certains anciens fichiers peuvent avoir d'autres dénominations, comme : (Complete), (Complete Figure Shortcut), (Complete Assembly Shortcut), ...

Titre avec "Pattern"

Les pièces comportant un motif imprimé, utilisent le mot "Pattern" (Motif) à la fin de leur titre.
Nota : Depuis 2012 les autocollants ne comportent plus le mot "Pattern", car ils sont tous à motif, et cela laisse plus de place pour la description.

Titre avec "Obsolete"

Ces pièces contiennent des erreurs ou des techniques de création de motifs qui ne sont plus utilisées aujourd'hui. Elles ne doivent plus être utilisées normalement, mais sont gardées pour des raisons de compatibilité avec l'existant.

Pour les mettre en fin de liste, elles ont aussi "_" en premier caractère.

Titre commençant par "~"

A l'origine l'ajout de ce premier caractère a été fait pour déplacer les pièces concernées à la fin du fichier listant ces pièces parts.lst.

Il y a 6 cas de figure :

Complément sur les pièces unitaires d'un assemblage

Lorsque qu'une pièce réelle composite (normalement non démontable) est constitué de plusieurs pièces moulées ou fabriquées séparément, et assemblées par clipage, vissage, collage, emboutissage, etc..., il est malgré tout fait un fichier de pièce par pièce élémentaire, et tous ces fichiers portent comme premier caractère de titre le caractère "~". Les fichiers vont dans le dossier PARTS.

Exemple : 3829.dat ~Car Steering Wheel Stand, est le support de volant utilisé dans la pièce complète comportant le volant (3829c01.dat).

Par contre pour les pièces assemblées, dont les éléments sont mobiles les uns par rapport aux autres, il est souhaitable que la pièce assemblée, comme les parties mobiles ne comportent pas de "~". Cela permet à l'utilisateur d'utiliser la pièce assemblée dans une certaine configuration, ou les éléments mobiles dans les autres cas. Nota : Si une partie mobile est elle-même composée d'éléments assemblés fixes les uns par rapport aux autres ces sous-éléments comporteront un "~".

Nota : Ces fichiers peuvent perdre leur caractère "~" si la pièce unitaire vient à être utilisée en dehors de l'assemblage d'origine. Exemple la pièce 3680 (Turnable 2 x 2 Plate Base) utilisée indépendamment de la pièce 3679 (Turnable 2 x 2 Plate Top) sur le Set 10189 (Taj Mahal).

Nota : De même pour les parties de pièces mis dans des sous-fichiers du dossier PARTS\S, leur nom commence également par ~.
Les parties de pièces mis dans des sous-fichiers du dossier PARTS\S, ne doivent PAS utiliser le caractère "~".

Titre avec "~Moved to"

Cette forme de titre sert lorsqu'un fichier change de numéro. Voir le chapitre précédent pour les différents cas de figure.

Il est uniquement utilisé par le l'administrateur LDraw en utilisant le pseudo spécial de [PTadmin].

Voir la page spéciale Contributor Agreement (CA) en anglais.

Format ancien des fichiers "~Moved to" :

        0 ~Moved to {nouveau_numéro}
        0 WRITE Part {ancien_numéro} moved to {nouveau_numéro}
        0 BFC CERTIFY CCW
        1 16 0 0 0 1 0 0 0 1 0 0 0 1 {nouveau_numéro}.dat

où : {nouveau_numéro} et {ancien_numéro} sont des numéros de pièces LDraw.

Ce n'est plus conforme au nouveau standard agrée. C'est pourquoi il a été changé par le format suivant.

Nouveau format des fichiers "~Moved to" :

        0 ~Moved to {nouveau_numéro}
        0 Name: {ancien_numéro}.dat
        0 Author: [PTadmin]
        0 !LDRAW_ORG {Part, Subpart, etc as appropriate} UPDATE YYYY-RR
        0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

        0 BFC CERTIFY CCW

        0 !HISTORY {date} [PTAdmin] {any necessary comment(s)}

        0 // {part_description}
        1 16 0 0 0 1 0 0 0 1 0 0 0 1 {nouveau_numéro}.dat
        0

Exemple :

        0 ~Moved to 3842a
        0 Name: 193a.dat
        0 Author: [PTadmin]
        0 !LDRAW_ORG Part UPDATE 2006-01
        0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

        0 BFC CERTIFY CCW
        0
        0 !HISTORY 2006-12-31 [PTadmin] Official update 2006-01

        0 // Minifig Helmet Classic with Thin Chin Guard
        1 16 0 0 0 1 0 0 0 1 0 0 0 1 3842a.dat
        0

Ce nouveau format est cependant une source de problèmes possibles, avec certains programmes, qui utilisent la ligne "WRITE" supprimée, pour mettre à jour les pièces.

Le nouveau format a été défini sans la collaboration des administrateurs de pièces (Parts Tracker Administrators), et nécessite leur agrément.

La page Internet, de l'interface de soumission des pièces (PT GUI) de LDraw.org, incorpore un test, de tel façon que les auteurs de pièces ne peuvent soumettre un fichier "~Moved to". Si la nouvelle version est acceptée, il faudra également tester l'ancienne, comme la nouvelle version, pour le cas ou un auteur changerait le titre pour autre chose que "~Moved to".

Avec ce titre, le fichier ne doit pas comporter de méta-commande !CATEGORY.

Titre commençant par "_"

A l'origine l'ajout de ce premier caractère a été fait pour déplacer les pièces concernées à la fin du fichier listant ces pièces parts.lst.

Les pièces récentes Lego officielles, portent un numéro plus long, correspondant à une codification incorporant la forme (moule), la couleur, et le motif éventuel. C'est ce numéro qui est donné à la fin des manuels d'instructions officiels.

Pour distinguer les fichiers utilisant cette numérotation, le titre doit commencer par "_".

De même, ces pièces utilisent comme type : "Part Physical_Colour", "Shortcut Physical_Colour", "Unofficial_Shortcut Physical_Colour" (voir au chapitre sur la méta-commande "!LDRAW_ORG").

Exemple : la pièce 4234927.dat porte pour titre : _Wing 4 x 4 with 2 x 2 Cutout Yellow. Cela correspond à la pièce de base et son numéro de moule 43719, mais affecté de la couleur jaune (14 LDraw).

Les parties de pièces mis dans des sous-fichiers du dossier PARTS\S, ne doivent PAS utiliser le caractère "_".

Titre commençant par "="

Apparu en 2013, sert à différencier les pièces ayant 2 numéros de moule (Pièces Alias). Il s'agit la plupart du temps des moules utilisés pour les pièces transparentes dont les tolérances de fabrication sont différentes. La raison est l'utilisation de plastiques dont le retrait n'est pas identique au refroidissement.

Ces pièces utilisent comme type : "Part Alias" (voir au chapitre sur la méta-commande "!LDRAW_ORG").

Titre comportant des dimensions en nombre de tenons

Les pièces dont le titre comporte des dimensions en nombre de tenons, comporte 2 caractères par dimension, et chaque dimension est séparé par le caractère "x". Les nombres inférieurs à 10 sont notifiés par un espace supplémentaire suivi d'un chiffre de 1 à 9, en plus des espaces séparateurs. Exemples :

Brick  2 x  8
Brick  2 x 10
Brick  2 x  6 x  2 Weight
Il y a donc 2 espaces entre le mot "Brick" et le premier "2". Il ne doit pas y avoir 1 seul espace comme :
Brick 2 x 8
Brick 2 x 10
Brick 2 x 6 x 2 Weight

Cela permet d'avoir les pièces dans l'ordre croissant des dimensions dans la liste des pièces des programmes.

Titre comportant les dimensions des jantes de roues

Premier paramètre : Largeur de la jante (en mm), séparateur "x". Second paramètre : Diamètre de la jante (en mm). Paramètres supplémentaires : Qualifieurs du type de jante. Exemples :

Wheel Rim  8 x  8 Notched Hole
Wheel Rim 20 x 30 with 6 Spokes and External Ribs

Titre comportant les dimensions des pneus de roues

La définition LDraw essaye de s'approcher de la définition ISO des pneus réels, et de celle des pneus LEGO qui ont cette information gravée sur leur flanc.

Premier paramètre : Largeur du pneu (W en mm, de flanc à flanc (largeur maximum et non la largeur de la bande de roulement), séparateur "/". Second paramètre : Profil (% H/W : pourcentage de la hauteur du flanc sur la largeur du pneu), séparateur "x". Troisième paramètre : Diamètre de la jante recevant le pneu (D en mm et non le diamètre du pneu à l'état libre). Paramètres supplémentaires : Qualifieurs du type de pneu. Exemples :

Tyre 14/ 54 x 15 VR
Tyre 38/ 76 x 56

Nota : Tous les pneus LDraw ne respectent pas cette définition (surtout les anciens).

 

Nom du fichier (Name:)

Cette méta-commande indique et reprend le nom effectif du fichier lui-même. Il sert à l'identification des différents fichiers DAT de la bibliothèque de pièces LDraw. C'est un nom alphanumérique.

 

Nom des pièces simples

Une pièce simple est une pièce ordinaire moulée d'un seul bloc, comme la brique 2x4 3001.dat. Elle a un nom de fichier numérique. Le nom standard correspond au numéro du moule servant à fabriquer la pièce.
Si ce numéro est inconnu, alors la pièce prend le nom : xnnnn.dat, ou depuis 2010 : unnnn.dat
S'il s'agit de la codification numérique plus longue, alors le titre de la pièce commence par "_" (voir plus haut).

Format de la ligne :

        0 Name: <numéro>.dat

Où : <numéro>.dat : est le nom du fichier. Ce numéro comporte généralement de 3 à 5 chiffres.

Exemple : 3001.dat pour la brique 2x4.

Où trouver ce numéro :
   - Sur la pièce elle-même, apparaissant en bosse, avec 4 ou 5 chiffres. Nota : Il faut souvent une bonne loupe pour le voir, et ce numéro n'est pas toujours présent. Sur certaines pièces assemblées il peut exister un numéro en creux qui n'est pas à prendre en compte.
   - Dans les inventaires des Sets sur Peeron ou Bricklink, mais ce numéro n'est pas toujours valide pour les pièces qui n'en comportent pas physiquement.
   - Pour les pièces récentes apparaissant dans LDD, ce numéro est donné derrière Part#: dans la barre de statut lorsqu'on clique sur une pièce de la fenêtre graphique.
   - Evidemment pour les pièces déjà modélisées le site LDraw.org est la référence... dans la partie "Parts Tracker" pour les pièces en cours de développement, ou dans la partie "Library Updates" pour les pièces officielles mises à jour.

 

Nom des pièces Alias

Les pièces "Alias" sont des pièces qui portent plusieurs numéros de moule. C'est parfois le cas de certaines pièces qui existent en couleurs opaques et en couleurs transparentes. Pour des raisons de matières différentes les moules n'ont pas les mêmes tolérances, et donc ne portent pas le même numéro, même si visuellement les pièces ont des formes identiques.

La première pièce est défini dans un fichier habituel, et les suivantes appellent avec une ligne de type 1 la première.

Il faut mettre un commentaire du type :
0 // Alias of 6192
Cet exemple provient du fichier de pièce 30337.dat.

Autre exemple plus récent :
0 !HELP Part 94638 is the counterpart of 87552. Visually, the two parts seem
0 !HELP identical. This file is provided to make it easier to locate part files
0 !HELP when using the numbers from other sources.
0 !HELP 87552 is used for molding opaque parts, 94638 for transparent parts.
Cet exemple provient du fichier de pièce 94638.dat.

Nota : Il n'y a pas d'indication spécifique dans la première pièce.

Nota : La méta-commande !LDRAW_ORG utilise alors comme type "Shortcut Alias" ou "Unofficial_Shortcut Alias", suivant les cas.

Nota : Actuellement, ces pièces ne se distinguent pas dans les programmes de modélisation (MLCad, SR 3D Builder, ...). Elles sont visuellement identiques, et portent la même désignation.
J'ai tenté avec la pièce 94638.dat d'apporter une solution en ajoutant "Tr" à la fin de la désignation :
Panel 1 x 2 x 2 Reinforced with Hollow Studs Tr
Après une tentative de mettre à la place "(Trans)" pour les pièces transparentes et "(Opaque)" pour les autres, la décision a été prise sur PT le 18-11-2011 de ne mettre aucun signe distinctif dans le titre... puis en 2013 de mettre en premier caractère de leur Nom le signe =.

 

Nom des pièces à motif

Les pièces à motif (pattern), c'est-à-dire les pièces comportant un motif imprimé, portent le numéro du moule de la pièce simple, plus une extension "pnn" par motif différent.

Format de la ligne :

        0 Name: <numéro>pnn.dat

Où : <numéro> est le numéro du moule (pièce sans motif), p l'indication d'une pièce à motif (pattern), nn est un nombre à 2 chiffres, ou une association de chiffre et lettre donnant un numéro d'ordre avec catégorisation de gamme (comme les Torso). A 10 il faut passer aux lettres : p01, ..., p09, p0a, p0b, ....

Exemple : 3009p04.dat Brick 1 x 6 with Blue "HOTEL" Pattern.

Pour obtenir le numéro ou code du motif, il suffit de le demander par Courriel à : Steve Bliss and Chris Dee, ou de poster une message sur le forum lugnet.cad.dev.

Normalement le premier caractère du code aide à identifier le thème ou la ligne de produits dans lequel apparaît le motif. Ce n'est pas une règle absolue, car de nombreuses pièces à motifs sont utilisées dans plusieurs thèmes, et l'approche de la codification a évolué dans le temps. En conséquence, il y a des exceptions.

Tableau général sur les catégories de pièces à motif :

Catégorie Utilisation
0x Général/Divers et Ville (Town)
1x,2x Ville (Town), incluant Paradisa
3x Pirates (Pirates), Soldats (Soldiers), Iliens (Islanders)
4x Médiéval (Castle)
5x,6x Espace (Space)
7x,8x Ville moderne (Modern Town)
9x Libre et Espace (Space)
Ax Action (Adventurers, Aquazone, Alpha Team, Rock Raiders)
Bx Super héros, dont Batman
Cx Panneaux de contrôle (Control Panels, dials, gauges, keyboards, readouts, etc)
Cxy Motif de Minifig des séries collectionnables (pour torse, bras, hanche, jambe).
Format spécifique pour le torse par exemple : 973pc[série : 1-9,a-f][séquence : 1-9,a-f].dat (a pour 11, ..., f pour 16). série = 0 pour les Minifigs des séries collectionnables fournis en "Accessory packs", lorsqu'elles diffèrent. Exemple : 973pcbe = 15ème torse (e) de la série 11 (b)
Dx Studios
Dxy Motif de Minifig des séries collectionnables non numérotées (pour torse, bras, hanche, jambe).
Format spécifique pour le torse par exemple : 973pdxy.dat, avec x=1 et y=1-9 pour la série "Team GB", x=2 et y=1-9,a-g pour la série "Simpsons", x=3 pour et y=1-9,a-g pour la série "The LEGO Movie". Exemple : 973pd21 = 1er torse (1) de la série "Simpsons" (2)
Ex Libre
Fx Fabuland et Scala
Gx Sport (Soccer, Basketball)
Hx Harry Potter
Jx Indiana Jones
Kx Cars (Disney Pixar)
Mx Monde du milieu (Lord of the Rings (Le seigneur des anneaux), Elves (Elfes))
Nx Ninja, Ninjago
Qx Pharaoh's Quest
Rx,Sx Star Wars
Tx Motifs généraux textuels (lettres et nombres) et marques (Logos de sociétés, etc)
Ux - Vx Libre
Wx Western
Xx - Zx Libre

Caractères à éviter : Il faut éviter les lettres I, L, et O, dans les codes de motif car elles sont facilement confondus avec les chiffres 1 et 0. La lettre P est à éviter car c'est la lettre utilisée pour définir les pièces à motif, et une pièce portant un nom comme 3001ppp.dat semblerait bizarre.

Exceptions : Les conventions ci-dessus ne sont pas appliquées aux pièces ayant comme motif les lettres de l'alphabet et les chiffres. Dans ce cas, il est pratique d'incorporer la lettre ou le chiffre représenté dans le nom du fichier, et donc les lettre I, L, O, et P, sont permis. Par exemple les pièces 6309 (Duplo Tile 2 x 2) et 3005 (Brick 1 x 1), possèdent comme variantes à motif les caractères alphanumériques (0-9, a-z) et utilisent le code Tx, ou x est remplacé par la lettre ou le chiffre correspondant. Tous les caractères accentués, ou caractères composés, ou symboles, peuvent utiliser le code Ux. Dans des cas exceptionnels, comme la pièces 3005, qui possède le même motif en plusieurs couleurs, un autre jeu de code peut-être utilisé, comme Vx, ou Wx.

Motifs communs : Quelques motifs apparaissent sur de nombreuses pièces différentes. Un exemple est le logo "Classic Space", qui est utilisé dans 8 fichiers de pièces de la bibliothèque LDraw. Pour rendre plus facile le suivi de ces pièces, ayant un motif commun, un code spécifique peut-être assigné. Ensuite, toutes les pièces avec ce motif doivent utiliser ce code dans leur numéro de pièce. Naturellement, cela n'est pas toujours possible, car le motif peut apparaître parfois sur la même pièce de différentes façons, et le code peut-être déjà utilisé pour une certaine pièce.

Nombres futurs : Lorsque des personnes soumettent des pièces à motif dans des thèmes qui n'ont pas encore été modélisés dans la bibliothèque, Nous (PT), allouerons des codes à ces motifs et thèmes. Ce serait une aide, si les auteurs pouvaient cataloguer les différents motifs du thème. Cela aiderai à les organiser, mais ce n'est pas indispensable.
Pour les nouveaux thèmes, nous espérons donner des codes pré-alloués aux motifs. Cela serait bon, pas uniquement pour les pièces LDraw, mais aussi pour les autres bases de données LEGO, tels que Peeron.com. (Nota : écrit en 2001)

Nota : Pour la numérotation des torses de minifig, voir la page Minifig Torso.

 

Nom des pièces à double injection

Les pièces à double injection sont moulées en une seule fois avec 2 couleurs différentes ou 2 matériaux différents : par exemple la pièce 61406p01 avec la base en ABS rigide et l'extrémité pointue, pouvant être dangereuse, en plastique souple.

Leur numérotation est identique aux pièces à motif.

Format de la ligne :

        0 Name: <numéro>pnn.dat

 

Nom des pièces composites

Les pièces composites assemblées portent le nom du moule de la pièce unitaire principale plus une extension "cnn" par configuration d'assemblage. Cette configuration peut être un assemblage avec des pièces secondaires différentes, ou ayant des motifs différents, mais peut également être avec les mêmes pièces dans une position relative différente.

Nota : Pour les pièces comportant des autocollants il y a une numérotaion spéciale. Voir plus bas.

Format de la ligne :

        0 Name: <numéro>cnn.dat

Où : <numéro> est le numéro du moule, c l'indication d'une pièce composite, nn est un nombre à 2 chiffres donnant un numéro d'ordre.

Nota : ces pièces ont le mot "(Shortcut)" dans leur titre.

Exemple : 2913c01.dat Electric Train Track 9V Power Connector, composé des pièces élémentaires 2912 et 2913.

 

Elément de pièce composite

Lorsqu'une pièce est un assemblage de plusieurs composants indisociables, elle porte un nom de pièce simple, et les éléments de cette pièce composite sont considérés comme des parties de pièces.

 

Nom des pièces en grappe

Les pièces en grappe, sont des pièces différentes moulées ensembles, et fournies avec leur support de moulage. Elles ont par conséquent le même numéro de moule. Pour les distinguer on leur ajoute une lettre derrière le numéro.

Format de la ligne :

        0 Name: <numéro>x.dat

Où : <numéro> est le numéro du moule, et x une lettre de l'alphabet : a, b, c, ..., donnant le premier, second, troisième, ..., élément de la grappe.

Exemple : 6246d.dat : Minifig Tool Box Wrench, appartenant à la grappe de pièces 6246 :

Nota : Les pièces en grappe peuvent parfois être fournies sans le support de moulage, mais possèdent un seul numéro codifié ou "Item" (Numéro commercial).

Exemple : Les 9 pièces item 6038211, correspondant au moule 11402, sont fournies sans grappe dans un sachet :

 

Nom des pièces à variantes

Les pièces à variantes, sont des pièces normalement identiques, mais dont le moule à évolué au cours du temps. Elles gardent le même numéro de moule, et pour les distinguer on leur ajoute une lettre derrière le numéro.

Nota : l'ordre des lettres est l'ordre d'apparition des variantes sur le site LDraw.org, et non l'ordre chronologique de création réelle, qui n'est pas toujours connu.

Format de la ligne :

        0 Name: <numéro>x.dat

Où : <numéro> est le numéro du moule, et x une lettre de l'alphabet : a, b, c, ..., donnant la première, second, troisième, ..., forme de la pièce.

Exemple : 4085a.dat, 4085b.dat, 4085c.dat, Plate 1x1 with Clip Vertical Type 1, 2, et 3.

 

Nom des pièces simples avec numéro codifié

Il s'agit du code ou identifiant de chaque pièce donné par LEGO (forme+couleur) pour la référencer de façon unique.

Ce code peut prendre 2 formes :
   - Numéro du moule+code couleur, pour les pièces anciennes (ex 300121 pour brique 4x2 (3001) de couleur LEGO rouge (21).
   - Numéro à 7 chiffres commençant par 4 (ex : 4106356 pour brique 2x4 de couleur vert foncé). Nota : Ce numéro peut changer dans le temps pour la même pièce et le numéro le plus grand est le plus récent (exemple pour la brique 2x4 de couleur orange foncé le numéro est 4122462 de 1997 à 2003, et 4164438 depuis 2004).

Nota : Pour différencer ces noms de pièce des noms classiques, le titre commence par "_" (voir ci-dessus).

Où trouver ce numéro :
   - A la fin des notices de montage, dans l'inventaire, depuis 2006.
   - Sur le site de vente officiel : Pick A Brick depuis 2007. Pour chaque pièce sélectionnée par son "nom de brique" ou son "Design ID" (numéro de moule) l'identifiant est donné par son "Element ID".
   - Sur le site (en anglais) du service de remplacement de pièces. A partir de l'inventaire d'un Set, l'identifiant est indiqué dans la barre d'état par le premier nombre entre les parenthèses, lorsque la souris est sur une pièce.
   - Sur le site Bricklink, aller sur la page du "Catalog" d'une pièce d'après son numéro de moule, puis de cliquer sur "View Small Images". Au bas de la nouvelle page apparaît l'identifiant dans la colonne "Code" pour chaque couleur.
   - Sur le même site la liste des identifiants connus à télécharger : Bricklink Items.

Nota : La plupart des informations données dans ce chapitre provienne de la page du site Freelug : Item ou Element ID d’une pièce, qu’est ce que c’est ? de Erik "brickerik" Amzallag.

 

Nom des parties de pièces (sous-fichiers)

Les parties de pièces, mis dans des fichiers indépendants, sont utilisés dans plusieurs pièces, ou plusieurs fois dans la même pièce. Il y a 4 raisons de créer des sous-fichiers :

Format de la ligne :

        0 Name: s\<numéro>snn.dat

Où : s\ donne le sous-dossier de sauvegarde, <numéro> est le numéro de la pièce complète, s est l'indication d'une partie de pièce, et nn est un nombre à 2 chiffres donnant un numéro d'ordre.

Ces fichiers sont dans tous les cas sauvegardés dans le sous-dossier PARTS/S du dossier d'installation de LDraw.

Exemple : s\973s01.dat

Ces parties de pièce sont référencées dans la pièce principale avec une ligne de type 1 (Insertion pièce). Exemple :

        1 couleur 0 0 0 x 0 0 0 y 0 0 0 z s\nnnnSnn.dat

Nota : Certaines pièces officielles ne respectent pas les informations précédentes. Elles gardent leurs caractéristiques par compatibilité avec l'existant :

La limite entre "partie de pièce" et "primitive" est floue. En général les primitives sont utilisées dans un plus grand nombre de pièces, et son souvent moins complexes que les parties de pièce. Mais ce n'est pas toujours le cas, comme la primitive clip1.dat, et la partie de pièce 60475s01 qui ont un air de famille.

 

Nom des autocollants (Sticker)

Un autocollant porte comme nom le premier numéro imprimé sur la planche. Ex :
Pour la planche 72047/4112924 de 1998, le nom de base est 72047.dat, s'il n'y a qu'un seul motif sur la planche, même s'il est reproduit plusieurs fois. S'il y a plusieurs motifs, ils prennent les noms successifs de 72047a.dat, 72047b.dat, 72047c.dat, ...

Changement en 7-2011 : Un autocollant porte comme nom le second numéro imprimé sur la planche. Ex :
Pour la planche 72047/4112924 de 1998, le nom de base est 4112924.dat, s'il n'y a qu'un seul motif sur la planche, même s'il est reproduit plusieurs fois. S'il y a plusieurs motifs, ils prennent les noms successifs de 4112924a.dat, 4112924b.dat, 4112924c.dat, ...

Les autocollants sont imprimés sur une planche "plane", mais sont parfois utilisés et collés sur des pièces non planes. Dans ce cas il peut exister la version plane de base, et une ou plusieurs versions "en forme". Ces versions portent l'extension c01, c02, ... Dans la pratique pour respecter une longueur de nom ne dépassant pas 8 caractères c01 devient c1, etc... Ex :
L'autocollant en forme 56711gc1.dat
.

Si la planche ne comporte pas de numéro connu, un numéro d'ordre lui est attribué par un administrateur de LDraw.org. Ex : s1.dat, s2.dat, ..., s25.dat.

 

Nom des raccourcis d'autocollants (Sticker)

Un raccourci d'autocollant consiste en une pièce (qui peut être une pièce composée) assemblée avec un ou plusieurs autocollants. Ce type de pièce est autorisé dans la bibliothèque de pièces officielles.

Format de la ligne :

        0 Name: <numéro>dnn.dat

Où : <numéro> est le numéro de la pièce de base, d est l'indication de l'ajout d'autocollant, et nn est un nombre à 2 chiffres donnant un numéro d'ordre, commençant à 01, puis 02, etc..., suivant les nouveaux raccourcis apparaissant avec la même pièce de base.

Nota : Si la pièce de base est une pièce composite, et porte donc un nom de fichier se finissant pat cnn, le nom complet doit être utilisé avec d'ajouter le dnn. Par exemple, le premier autocollant ajouté sur la pièce 30185c01.dat aura pour nom 30185c01d01.dat.

Les restrictions suivantes s'appliquent :

Nota : Il s'agit d'une variante des pièces composites, ce qui fait qu'un certain nombre de raccourcis d'autocollants portent un nom de pièce composite se terminant par cnn, et ne sont donc plus à la norme actuelle (par exemple le drapeau français 3596c13.dat).

 

Nom des pièces sans numéro connu

Une première série s'est appliquée avant 2/2010 avec des noms du type xnnnn, c'est-à-dire de la lettre x suivi d'un nombre à 3 ou 4 chiffres.

Une nouvelle série est apparue en 2/2010 avec des noms du type unnnn, c'est-à-dire de la lettre u suivi d'un nombre à 2, 3 ou 4 chiffres.

Un découpage de cette série s'applique :

Nota : Si ces pièces ont des variantes, motifs, etc, elles prennent les extensions correspondantes.

 

Nom des pièces souples monoblocs

Il s'agit des pièces en tissu (canvas), en caoutchouc souple (Technic Tread), et aussi les autocollants en forme (Sticker Formed) ....

Dans ce cas il peut exister une version sans contrainte ou dépliée de base, et une ou plusieurs versions "en forme". Ces versions portent l'extension c01, c02, ...

 

Auteur du fichier (Author:)

Format de la ligne :

        0 Author: RealName [UserName]

RealName : Nom réel de l'auteur.

UserName : Nom d'utilisateur LDraw de l'auteur (pseudo de Part Tracker). Cela est optionnel pour les auteurs de pièces qui n'ont pas de nom d'utilisateur PT.

Exemple : 0 Author: Tore Eriksson [simlego]

 

Type de fichier (!LDRAW_ORG)

Indique le type de fichier (modèle, pièce, etc...), et si c'est une pièce de la bibliothèque de pièces de LDraw.org officielle ou non.

Cette méta-commande apparaît à la dernière ligne de l'en-tête de base du fichier (Il s'agit des premières lignes du fichier, avec le titre du modèle, et les lignes Name: (Nom) et Author: (Auteur)). Le premier format (!LDRAW_ORG) est le standard actuel pour les fichiers officiels de la bibliothèque de pièces. Les anciens fichiers conservent les autres formats.

Format actuel de la ligne :

        0 !LDRAW_ORG <type> [qualifier(s)] [update-tag]

Formats anciens de la ligne :

        0 LDRAW_ORG <type> update-tag
ou :    0 Official LCAD <type> update-tag
ou :    0 Unofficial <type>
ou :    0 Un-official <type>
mais on peut aussi rencontrer :    "LDRAW", "LDRAWORG", "OFFICIAL", "UNOFFICIAL", "UN-OFFICIAL".
Les chaines de caractères valides pour le champ <type> est :

On peut aussi trouver : Configuration, Unofficial_Model.

Le champ optionnel qualifier(s) est utilisé pour les pièces officielles, et donne son état, comme : ORIGINAL (Original), UPDATE (Mis à jour)

Le champ optionnel update-tag est utilisé pour les pièces officielles "UPDATE" (Mis à jour), et donne la date de mise à jour au format AAAA-MM, comme : 1998-10 (Octobre 1998)

Quelques anciens fichiers officiels, n'incluent pas de <type> dans leur ligne définissant le type de fichier.
Les fichiers non officiels, peuvent avoir une variété de chaines de caractères.
Le format précis de cette méta-commande a changé au cours du temps. En général, ce type de ligne est considéré comme ayant une casse indifférente (majuscule ou minuscule) et d'un format libre.

 

Licence (!LICENSE)

Cette méta-commande informe si la pièce envoyé à LDraw.org est non redistribuable, suivant les conditions énoncés dans le fichier NonCAreadme.txt, ou redistribuable suivant les conditions énoncés dans le fichier CAreadme.txt.

Formats de la ligne :

        0 LICENSE Not redistributable : see NonCAreadme.txt
ou :    0 LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

Nota : le fichier CAreadme.txt est une version simplifié d'information sur les droits des pièces envoyées, et redirige vers le fichier de la licence elle-même : CAlicense.txt, le tout en anglais.
Les 3 fichiers cités sont fournis avec les mises à jour des pièces officielles, et se trouvent installés dans le dossier d'installation de LDraw (Par exemple C:/lego/ldraw).

 

Aide (!HELP)

Cette méta-commande permet d'ajouter une aide à l'utilisation de la pièce.

Format de la ligne :

	0 !HELP Optional free text description of file usage
	0 !HELP Second row after user's line break to simulate paragraph

Chaque ligne après "0 !HELP" peut contenir un texte libre de description sur l'usage du fichier. Il peut y avoir plusieurs lignes "0 !HELP", et ainsi écrire une paragraphe. Les auteurs doivent se contraindre eux-mêmes à se limiter à 50 caractères par ligne pour garder le texte lisible. Evidemment (!) ce texte doit être en anglais pour que cette information puisse être comprise par la communauté...

Voir un exemple d'aide dans la pièce 982.dat

 

Commande (!CMDLINE)

Cette méta-commande permet d'envoyer une commande aux programmes LDraw et LEdit (programmes d'origine). Aujourd'hui, cette méta-commande n'a plus qu'une seule utilisation, définir la couleur que la pièce a dans des circonstances normales. Toutes les pièces qui ont été produites uniquement dans une seule couleur devraient recevoir cette méta-commande.

Format de la ligne :

	0 !CMDLINE LDraw run-time command(s)

Utilisation actuelle :

	0 !CMDLINE -ccolor

Avec l'option -c pour définir la couleur et color le code d'une couleur définie dans LDConfig.ldr (sans espace entre les deux).

Exemple :

	0 !CMDLINE -c14

Dans cet exemple la pièce est définie et affichée en jaune.

 

Historique (!HISTORY)

Cette méta-commande permet de noter l'historique des modifications et officialisation de la pièce.

Format de la ligne :

	0 !HISTORY YYYY-MM-DD [UserName] Free text description of change. This can wrap to a
	0 !HISTORY YYYY-MM-DD [UserName] second row with the same date if necessary. However authors should lean toward writing longer
	0 !HISTORY YYYY-MM-DD [UserName] single !HISTORY lines(and not feel constrained to the historic 80-character limit on line length)
	
0 !HISTORY 2008-07-01 [PTadmin] Official Update 2008-01
0 !HISTORY YYYY-MM-DD {RealName} Free text description of change

YYYY-MM-DD : est la date de la modification ou officialisation en année, mois, jour. Exemple : 2004-08-25 pour le 25 août 2004.

YYYY-RR : Pour les officialisations, dans le corps de l'historique, apparait une date donnée par l'année de mise à jour du fichier de pièce LDraw (YYYY), et la version dans l'année (RR).

[UserName] : Les parenthèses carrées sont incluses pour indiquer le nom d'utilisateur LDraw. [PTadmin] est l'un des administrateurs de LDraw.org.

{RealName} : Ce type de parenthèses sont incluses pour indiquer le nom réel du rédacteur de la modification (peu employé).

 

Information sur la source

Lorsque le fichier de pièce a été créé à partir d'un fichier existant en dehors du système LDraw, il faut définir cette source.

Exemple en provenance de l'équipe de développement LEGO Universe (projet aujourd'hui arrêté) :

	0 !HISTORY 2010-02-09 {LEGO Universe Team} Original part shape
	0 !HISTORY 2010-02-21 [Philo] File preparation for LDraw Parts Tracker

Exemple en provenance de l'équipe de développement LEGO Technic :

	0 !HISTORY 2012-09-12 {LEGO Technic Team} Original part shape
	0 !HISTORY 2012-10-11 [Philo] Complete rebuild for LDraw Parts Tracker

Exemple en provenance de l'équipe de développement LEGO Mindstorms :

	0 !HISTORY 2012-05-20 {LEGO MINDSTORMS Team} Original part shape
	0 !HISTORY 2012-06-28 [Philo] Complete rebuild for LDraw Parts Tracker

Exemple en capture de données du programme LDD :

	0 !HISTORY 2013-03-08 {LEGO Digital Designer} Original part shape
	0 !HISTORY 2013-03-08 [angmarec] File preparation for LDraw Parts Tracker

 

Catégories (!CATEGORY)

 

Préambule

Les méta-commandes !CATEGORY et !KEYWORDS sont là pour donner des informations pour organiser et chercher dans la bibliothèque LDraw. Avant que les méta-commandes !CATEGORY et !KEYWORDS soient définis, la seule façon d'organiser la bibliothèque de pièces, était d'utiliser le nom descriptif (descriptive name), et le numéro de la pièce (part number). Cela est précieux, mais le nom et le numéro ne donne pas assez d'informations, pour cataloguer la bibliothèque d'un grand nombre de pièces. Ces méta-commandes sont utilisées dans les fichiers de pièces uniquement. Elles ne doivent pas apparaître dans les modèles, primitives, ou parties de pièces (subparts).
La différence entre les deux méta-commandes est :

La position de ces méta-commandes dans l'en-tête du fichier, est formalisé dans le "LDraw.org Official Library Header Specifications".

 

Méta-commande !CATEGORY

Format de la ligne :

        0 !CATEGORY nom_de_catégorie

Où "nom_de_catégorie" est le nom unique de la catégorie de la pièce. Un fichier ne peut aller que dans une seule catégorie. Et, le nom des catégories ne peut-être pris que dans la liste ci-dessous :

De nouvelles catégories ne peuvent être ajoutés que par le "LDraw Standard Committee".

Le 9 août 2012, et avec la sortie des pièces officielles 2012-02 sont apparus de nouvelles catégories pour les équipements de Minifig :

Si un fichier de pièce ne contient pas de commande de catégorie, la catégorie prend en compte le premier mot du titre du fichier (file title).

Cette méta-commande est indispensable si le premier mot du nom descriptif de la pièce n'est pas dans la liste des catégories officielles données ci-dessus.

Source : LDraw.org CATEGORY and KEYWORDS Language Extension.

Nota : En conséquence des points précédents, la plupart des pièces ne doivent pas comporter de méta-commande !CATEGORY, car elles ont par défaut leur nom de catégorie comme premier mot de leur nom descriptif.

 

Mots-clefs (!KEYWORDS)

Cette méta-commande complète la précédente pour aider à la recherche d'une pièce.

Format de la ligne :

        0 !KEYWORDS clef_1, clef_2, ..., clef_précédent_le_passage_à_la_ligne
        0 !KEYWORDS clef_1_ligne_2, ..., dernière_clef

Où "clef_1", "clef_..." est un mot caractérisant la pièce. La liste des mots-clefs sont séparés par une virgules et un espace, ou uniquement un espace de séparation. Plusieurs lignes peuvent être utilisées, pour obtenir une meilleure structure, ou grouper les mots-clefs en thèmes. La longueur des lignes sont limitées à 80 caractères. Dupliquer les mots ou termes à partir du nom ou du numéro de la pièce n'est pas autorisé.

La méta-commande "keywords" est essentiellement une liste de mots caractéristiques, qui vont ensuite décrire le fichier. L'auteur met tous les mots qu'il voudrait utiliser pour identifier la pièce. Spécialement les termes qui ne sont pas inclus dans le nom du fichier de la pièce (part's filename), nom descriptif (descriptive name), termes géométriques, synonymes (si le nom d'une pièce comprend le terme "rounded", un mot clef peut-être "curved"), le numéro de la boite LEGO (set) où apparait seulement cette pièce, et les thèmes de jeux ou la !CATEGORY. D'autres mots-clefs habituels sont les catégories des pièces similaires. Comme la méta-commande !CATEGORY, cette commande est utilisée exclusivement dans les fichiers de pièces.

Exemple :

0 Tile 1 x 2 with Playing Cards Pattern
0 Name: 3069bpw1.dat
...

0 !CATEGORY Tile
0 !KEYWORDS western, wild west, spaghetti western, horse opera, cowboy, desperado, bandit, cardsharper, swindler
0 !KEYWORDS casino, pocker, bridge, blackjack, twenty-one, baccarat, chemin de fer
0 !KEYWORDS stud, stud poker, strip poker, straight poker, penny ante, penny ante poker, high-low, draw, draw poker
0 !KEYWORDS pair, straight, flush, full house, straight flush, royal flush, eight-card stud
0 !KEYWORDS Set 377

Nota : Un moyen d'avoir une liste des mots-clefs d'une pièce est de rechercher cette pièce sur le site de Peeron. Les "Keywords" se trouvent juste sous le titre (s'il y en a).

Nota : Un autre moyen indiqué par Steffen et complété par Philo dans le suivi PT de la pièce 87079p01.dat : Lorsqu'il y a un motif symbolique (caractère asiatique, égyptien, symbole ethnique, ...), il suffit de faire une image séparée de chaque motif et de la soumettre sur le site de recherche d'image Google, en téléchargeant son image avec le petit bouton en forme d'appareil photo. S'il y a plusieurs caractères à rechercher une image de l'ensemble fera une recherche sur le sens du mot et non de la lettre seule.

 

Thèmes pour OMR (!THEME)

Cette méta-commande est spécifique aux fichiers de modèles officiels. Reste pour l'instant (début 2012) expérimental, en particulier sur le découpage et la liste des thèmes.

Format de la ligne :

        0 !THEME nom_du_thème

Le nom_du_thème peut (pourrait) être limité à 1 et 2 niveaux, ou bien 1 à 3 niveaux.

Exemples sur 1 niveau :
Creator
Universal Building Set

Exemples sur 2 niveaux :
Adventurers / Desert
Adventurers / Dino Island
Adventurers / Jungle

Exemples sur 3 niveaux :
Town / City / Police
Town / Classic Town / Police
Town / World City / Police

Voir la liste des thèmes sur le Wiki : http://wiki.ldraw.org/index.php?title=LDraw_Themes.

 

Restrictions sur les méta-commandes de l'en-tête des pièces

Pour les pièces soumise à LDraw.org il y a des restrictions sur les méta-commandes employées.

L'en-tête des fichiers de pièces doit être conforme au Official Library Header Specification (en Anglais).

 

Méta-commandes officielles de corps du fichier

Ces méta-commandes se trouvent généralement dans le corps des fichiers de pièces.

 

Etape de construction (STEP)

Marque la fin d'une étape de construction.

Format de la ligne :

        0 STEP

Cette commande oblige le programme LDraw original (ldraw.exe) d'arrêter jusqu'à ce que vous appuyez la touche <entrée>, et de sauvegarder dans un fichier "bitmap" l'image courante, dans le dossier ldraw\bitmap. Ces deux effets sont contrôlés par l'option -M des lignes de commande (voir ldraw.doc pour plus d'informations sur -M).

En conséquence pour le programme LDraw original, une méta-commande 0 STEP est équivalent à un 0 PAUSE, suivi d'un 0 SAVE.

Pour d'autres programmes de modélisation, cela peut être interprété différemment. MLCad par exemple, en mode aperçu, fait simplement une pause dans l'affichage des pièces composant le modèle, et attend un ordre pour afficher les suivantes.

 

Ecrire un message (WRITE/PRINT)

Affiche un message en haut de l'écran.

Format de la ligne :

        0 WRITE <texte du message>
ou :    0 PRINT <texte du message>

Où le <texte du message> est une chaine de caractères de longueur quelconque, que vous voulez voir affiché sur l'écran. Nota : Le message affiché n'est pas sauvegardé dans le fichier d'image bitmap.

Cette commande est une méta-commande du programme LDraw original (ldraw.exe). D'autres programmes peuvent l'interpréter différemment.

 

Effacer la visualisation du modèle (CLEAR)

Efface l'écran.

Format de la ligne :

        0 CLEAR

Généralement utilisé pour des modèles complexes. Permet de ne pas redessiner toutes les pièces ou primitives précédentes, vous les effacez seulement de l'affichage en utilisant cette commande. Les pièces ou primitives suivantes sont dessinées normalement.

 

Attente d'affichage (PAUSE)

Oblige le programme original LDraw a arrêter l'affichage des pièce suivantes, jusqu'à ce que vous pressiez la touche <entrée>.

Format de la ligne :

        0 PAUSE

Elle fonctionne comme la commande Step (voir plus haut), mais ne sauvegarde pas les images, et n'est pas affectée par l'option -M des lignes de commande.

 

Sauvegarde d'image (SAVE)

Oblige le programme original LDraw (ldraw.exe) à sauvegarder l'image courante dans un fichier bitmap.

Format de la ligne :

        0 SAVE

C'est également comme la commande Step, mais il n'y a pas d'arrêt, et n'est pas affectée par l'option -M des lignes de commande.

 

Restrictions sur les méta-commandes de corps de fichiers de pièces

Pour les pièces soumise à LDraw.org il y a des restrictions sur les méta-commandes employées.

Seules les méta-commandes suivantes sont permises dans le corps du fichier des pièces officielles :

Des pièces officielles ne sont pas conforme à ces directives. Ces pièces (y compris celles se trouvant dans le "Part Tracker", pièces en cours d'officialisation) ne doivent pas être éditées dans le seul but de les rendre conforme. Cependant, si la pièce est modifiée pour n'importe quelle autre raison, les lignes non conformes doivent être mises à jour.

 

Restrictions sur les méta-commandes de pièces générées

Les lignes et polygones générés par un utilitaire (comme LSynth) doivent être conformes aux spécifications. Les méta-commandes utilisées pour les générer peuvent être laissés dans le fichier de la pièce, à condition qu'elles soient correctement mis en commentaire. Il est souhaitable d'ajouter un commentaire pour marquer la fin des lignes générées.

 

Méta-commandes officielles des projets MPD

Ces méta-commandes permettent de gérer plusieurs modèles dans un même fichier LDraw.

 

Nom des fichiers d'un projet MPD

Un fichier modèle, contenant plusieurs sous-modèles (projet MPD), a besoin d'un séparateur. Chaque sous-modèle commence par une ligne "FILE", donnant le nom du sous-modèle.

Pour créer un fichier MPD il suffit d'insérer le code de chaque fichier individuel dans un fichier portant l'extension MPD. Au début de chaque texte de code individuel, insérez une ligne 0 FILE nom.ldr.
Cela sépare et nomme chaque fichier individuel.

Les fichiers MPD utilisent 2 méta-commandes. Seule la première des deux est communément utilisée. La seconde est donc optionnelle.

Nom du sous-modèle : Indique le début d'un sous-modèle, et le nomme.

Format de la ligne :

        0 FILE nom.ldr

Où "nom.ldr" est le nom du sous-modèle. L'insertion de cette ligne se fait automatiquement, lorsque un projet MPD est crée sous MLCad.
Ce nom est utilisé pour nommer les fichiers, lorsque l'on utilise la commande "Exporter les modèles" sous MLCad, ce qui crée un fichier portant l'extension LDR par modèle.

 

Fin du sous-modèle d'un projet MPD

Indique la fin d'un sous-modèle.

Format de la ligne :

        0 NOFILE

Il n'y a pas d'option ou paramètre.

La fin de chaque texte de code individuel, ou juste à la fin du dernier, peut être marqué avec une ligne 0 NOFILE. Cette méta-commande est utile uniquement si le contenu du fichier est suivi d'un contenu NON LDraw (comme les lignes de signature dans un forum de discussion).

Afin de supporter l'inclusion de fichiers LDraw dans les messageries (comme les emails, et forum de discussion), toutes les lignes avant le premier 0 FILE doivent être supprimées (en dehors des lignes de commentaires), car c'est considéré comme une erreur par quelques programmes de l'environnement LDraw.
Egalement, aucune commande LDraw ne doit apparaître entre une ligne 0 NOFILE, et la ligne 0 FILE suivante.

Lorsque un fichier MPD est utilisé pour sauvegarder un modèle comportant plusieurs sous-modèles, le premier sous-modèle inséré est traité comme le "modèle principal". Les autres sous-modèles inclus ne sont affichés que s'ils sont référencés par le modèle principal, directement ou indirectement.

Il n'y a pas toute liberté sur le choix des noms dans les fichiers MPD. Il ne faut pas utiliser de nom appartenant aux pièces ou primitives existantes. Si vous mettez un fichier nommé stud.dat dans votre fichier MPD, ne soyez pas surpris de voir votre fichier stud.dat apparaître au sommet de chaque brique individuelle, de votre modèle. Pour éviter cela toujours mettre l'extension .LDR aux noms des fichiers des sous-modèles.

 

Méta-commande officielle BFC

 

Objet des méta-commandes BFC

Ce chapitre sert à établir un standard pour le traitement du sens des faces (back face culling) dans les programmes de rendu compatibles LDraw. Ce standard inclus une extension du langage LDraw, des définitions, et les effets attendus du traitement.

Dans ce chapitre ce standard est appelé l'extension BFC.

Le standard doit permettre d'avoir des fichiers LDraw inter-compatibles. Cela veut dire que les programmes de rendu compatibles LDraw, et qui ne supportent pas cette extension BFC, doivent faire un rendu correct des fichiers au standard BFC, et les programmes de rendu qui supportent l'extension BFC doivent faire un rendu correct des fichiers non à ce standard.

Pour rendre ce standard utile et efficace, la bibliothèque de pièces LDraw doit être mise à jour pour suivre le nouveau standard. Comme il sera difficile et long de réécrire entièrement la bibliothèque en une seule mise-à-jour, le standard doit permettre d'avoir un mélange de fichiers compatibles et non compatibles BFC dans un même processus de rendu.

 

Définitions

Certifié. Un fichier LDraw est dit "certifié" s'il est conforme avec les spécifications de ce chapitre, et inclus une ligne de méta-commande 0 BFC CERTIFY avant la première ligne de commande d'entité graphique (lignes de type 1 à 5), tout en n'incluant pas une ligne 0 BFC NOCERTIFY.

Coupure. Dans ce chapitre le terme "coupure" (clipping) comme synonyme de "choix" (culling). Bien que ce soit techniquement incorrect, l'usage en est resté par compatibilité avec les définitions précédentes, et donc du standard LDraw. Dans d'autres contextes graphiques, le terme de "coupure" réfère usuellement à tailler (Trimming) une primitive géométrique pour ne pas la prolonger devant le bord d'une région donnée, tandis que "choix" se réfère à ne pas dessiner la primitive du tout.

Choix (Culling). Dans ce document le terme "choix" se réfère au processus exécutant le choix de la face en arrière. C'est, ne pas dessiner une primitive géométrique du tout présentant cette face.

Branche du fichier de référence. Il s'agit d'un ensemble de fichiers, dans en arborescence de référence. Elle démarre soit par le début du fichier d'un modèle principal, soit par le début d'un fichier de pièce. C'est la branche principale unique (le modèle principal) lequel contient beaucoup de sous-branches (les pièces) qui elles-mêmes peuvent contenir des sous-branches (par exemple un assemblage complet comme une Minifig).

Inverser. Tourner le contenu d'un sous-fichier à l'envers (intérieur à l'extérieur). Généralement utilisé sur des primitives géométriques. Lorsque le standard BFC est utilisé l'inversion peut être nécessaire, sinon les faces intérieures ne seraient jamais rendus. Comme les polygones sont unilatéraux, on peut avoir besoin de voir l'intérieur des primitives visible plutôt que l'extérieur.

Fichier LDraw. Un simple fichier au format LDraw définissant une pièce, une partie de pièce, une primitive, ou un modèle. Les pièces, parties de pièces, et primitives utilisent uniquement l'extension DAT, tandis que les modèles peuvent utiliser les extensions DAT (à éviter), LDR ou MPD. Alors que la méta-commande BFC est rarement utilisée dans les fichiers de modèles, elle peut toutefois être utilisée, et devrait être utilisée si le ficher de modèle contient des polygones.

Ligne de commande opérationnelle. Toute déclaration dans un fichier LDraw de lignes de type 1 à 5. En d'autres termes, l'appel de sous-fichier, et les déclarations de ligne, triangle, quadrilatère, et ligne Conditionnelles.

Pièce. Tout fichier LDraw qui représente une pièce réelle complète. Ces fichiers sont sauvegardés dans le dossier ldraw\parts\.

Polygone. Une surface 2D (plane dans l'espace 3D) crée par une ligne de commande LDraw de type 3 (triangle) ou 4 (quadrilatère).

Primitive. Un fichier LDraw, typiquement petit, qui modélise une forme géométrique ou un attribut standard pour construire les éléments de pièces, comme les tenons ou la forme en croix des axes. Ces fichiers sont sauvegardés dans le dossier ldraw\p\ (pour les primitives en résolution standard), et le dossier ldraw\p\48 (pour les primitives en haute résolution). Dans d'autres contextes graphiques, le terme primitive fait référence aux formes géométriques de base fournies par l'environnement d'affichage et de rendu.

Sous-fichier. Un fichier LDraw référencé par un autre fichier, par l'intermédiaire d'une ligne de commande de type 1. Ou, n'importe quel fichier qui est plus bas dans la "branche du fichier de référence" que le fichier courant.

Partie de pièce. Un fichier LDraw qui représente uniquement une partie d'un élément complet. Il n'est pas nécessaire que cela corresponde à une partie spécifique d'un élément de construction réel. Ces fichiers sont sauvegardés dans le dossier ldraw\parts\s\.

Fichier parent. Le fichier qui référence le fichier courant. Plus généralement, n'importe quel fichier qui est plus haut dans la "branche du fichier de référence" courante, que le fichier courant.

Sens (Winding). C'est l'ordre des sommets (points) qui sont spécifiés dans une ligne de commande de polygone. L'ordre peut-être horaire ou anti-horaire, lorsque le polygone est vu de face.

Sens horaire (les sommets sont numérotés de 0 à 3) :

  0 -> 1
  ^    |
  |    v
  3 <- 2

Sens anti-horaire :

  0 <- 3
  |    ^
  v    |
  1 -> 2

 

Fonctionnalités

L'extension BFC du langage permet aux fichiers LDraw de spécifier et contrôler les conditions suivantes :

Compliance. Les fichiers LDraw qui suivent l'extension BFC, doivent être marqués clairement et sans ambigüité. Il est également utile de marquer clairement les fichiers non conformes. Avoir la compliance bien indiquée simplifie la tache des programmes de rendu, et facilite la lecture des fichiers par les personnes qui les lisent.

Marquer un fichier compliant BFC affecte seulement directement ce fichier. Ensuite, pour que les sous-fichiers soient traités comme compliants, ils doivent également eux-mêmes être marqués comme compliants. En outre, à l'exception des pièces, un fichier est traité comme compliant BFC lorsqu'il est compliant, ainsi que tous ses fichiers parents. La raison de cela est que, pendant le traitement, il n'y a pas de solution pour connaître les indications d'inversion d'un sous-fichier, lorsque le fichier parent n'est pas compliant BFC. La raison pour que les fichiers de pièces soient une exception à cette règle, est qu'ils formes des solides fermés complexes, et qu'il n'y a aucune raison valide de les inverser. Supposer que les fichiers de pièces ne sont jamais inversés, permet aux processus de rendu d'appliquer le processus BFC aux pièces certifiées, même lorsque le fichier les appelant (par exemple, le modèle principal ou sous-modèles du modèle principal) n'est pas certifié.

Sens. Il doit être possible pour un fichier de spécifier le sens donné par l'ordre des sommets d'une commande de polygone dans ce fichier : horaire, anti-horaire, ou inconnu. Fixer ce sens au niveau du fichier (comme option de la méta-commande 0 BFC CERTIFY) est essentiellement une commodité pour les auteurs de pièces.

Changer le sens donné par l'ordre des sommets affecte uniquement le fichier courant. Il ne modifie pas le sens des sous-fichiers.

Il est autorisé de changer le sens des polygones dans un fichier. Dans ce cas le changement de sens affecte tous les polygones qui suivent une option CW/CCW, jusqu'à la fin du fichier, ou une autre option CW/CCW rencontrée.

Choix (Culling). Il doit être possible d'autoriser ou interdire le choix durant le processus d'un fichier. Mais même lorsque l'autorisation du choix est en cours, il n'est pas toujours possible de faire ce choix pour les polygones. Les polygones peuvent être testés et choisis uniquement lorsque les conditions suivantes s'appliquent :
  * Tous les fichiers parents (dans la branche du fichier de référence courante) sont certifiés.
  * Le fichier courant est certifié.
  * Aucun fichier parent n'a interdit le choix avant le référencement de ce sous-fichier
Si aucune de ces conditions ne sont rencontrés au moment ou le sous-fichier est rendu, le choix est possible.

Si l'état de choix est modifié, il affecte toutes les lignes qui suivent l'option CLIP/NOCLIP, jusqu'à la fin du fichier, ou une autre option CLIP/NOCLIP rencontrée. Lorsque des sous-fichiers sont référencés, ils reçoivent un drapeau indiquant l'état cumulé de choix, mais cela n'a pas de sens en mode de choix global.

Inversion. Il est parfois désirable d'inverser les surfaces d'un sous-fichier, pour retourner le contenu du sous-fichier et mettre son intérieur à l'extérieur.

Un exemple courant d'inversion est la primitive des cylindres. Les primitives des cylindres sont conçues pour avoir leur face avant vers l'extérieur. Pour modéliser un tube, une paire de primitives de cylindres est nécessaire. Le cylindre extérieur est orienté normalement, avec ses faces avant vers l'extérieur, et le cylindre intérieur mis à une échelle plus petite (pour avoir un diamètre plus petit) nécessite d'avoir ses faces avant tournés vers l'intérieur du cylindre. Cela est fait en signalant par une étiquette que le cylindre intérieur doit être inversé.

L'inversion empile les étiquettes de la branche du fichier de référence. Si le fichier courant a un rendu inversé, alors tous les sous-fichiers du fichier courant auront également un rendu inversé.

L'inversion est une opération booléenne. Inverser un fichier qui est déjà inversé donnera un fichier avec une orientation normale. Donc, si le fichier courant est inversé, et le sous-fichier a une étiquette d'inversion, alors ce sous-fichier aura un rendu de ses faces avant normales, c'est-à-dire vers l'extérieur.

En pratique, le processus de rendu peut accomplir l'inversion simplement en inversant l'ordre des sommets des polygones. Il traite les fichiers CCW comme étant CW et vice versa. Cela doit se passer conjointement avec les autres attributs.

 

Description de la méta-commande BFC

Il y a une seule méta-commande dans l'extension du langage BFC, la méta-commande 0 BFC. Elle inclue des options pour spécifier les opérations BFC à effectuer.

Format de la ligne :


	0 BFC (NOCERTIFY | CERTIFY [CW|{CCW}])
	0 BFC ((CW|CCW) | CLIP [(CW|CCW)] | NOCLIP | INVERTNEXT)

Où : (a | b) signifie soit a soit b, [] indique in terme optionnel, et {} indique une valeur par défaut.

Il découle de cette syntaxe les différentes possibilités valides suivantes pour la méta-commande BFC.


	0 BFC NOCERTIFY

	0 BFC CERTIFY     (CCW est implicite)
	0 BFC CERTIFY CW
	0 BFC CERTIFY CCW

	0 BFC CW
	0 BFC CCW

	0 BFC CLIP        (Le sens est inchangé)
	0 BFC CLIP CW
	0 BFC CLIP CCW
	0 BFC CW CLIP     (L'ordre des paramètres peut être inversé)
	0 BFC CCW CLIP

	0 BFC NOCLIP

	0 BFC INVERTNEXT

La méta-commande BFC et toutes ses options est sensible à la casse, cela veut dire qu'elle doit toujours être en majuscule.

La méta-commande BFC ignore les espaces répétitifs entre les paramètres, et accepte n'importe quel nombre d'espaces ou tabulations comme l'équivalent d'un seul espace.

Dans un fichier LDraw devant recevoir un traitement de rendu avec le sens des face, il doit y avoir une méta-commande 0 BFC avant la première ligne de méta-commande opérationnelle (graphique). Si ce n'est pas le cas, le traitement BFC est mis hors fonction pour ce fichier.

Seule une méta-commande NOCERTIFY/CERTIFY doit être présente dans un fichier, et si elle est présente, elle doit précéder toutes les autres méta-commandes BFC, et les méta-commandes opérationnelles.

Toutes les méta-commandes BFC qui agissent sur les lignes qui suivent dans le fichier ignoreront les lignes vides.

Pour un compatibilité avec l'existant, les options CLIP et CW/CCW pourront être spécifiés dans n'importe quel ordre dans la méta-commande.

 

Description des paramètres

CERTIFY

Cette option indique que le fichier LDraw est compatible avec l'extension BFC du langage LDraw. Tous les nouveaux fichiers LDraw doivent clairement être étiquetés s'il est compatible. Une façon pour accomplir cela est de placer une ligne 0 BFC CERTIFY au début du fichier, avant la première méta-commande opérationnelle.

Une autre façon d'indiquer que le fichier est compatible, est d'utiliser une méta-commande 0 BFC avec n'importe quelle option, sauf NOCERTIFY, avant la première méta-commande opérationnelle. Ceci est une alternative acceptable, mais la méthode 0 BFC CERTIFY est recommandée et préférable.

Les fichiers dans la bibliothèque de pièces LDraw.org, s'ils sont compatibles BFC, devront avoir une ligne explicite 0 BFC CERTIFY dans leur en-tête.

Si un fichier n'a pas de méta-commande 0 BFC avant la première méta-commande opérationnelle, alors il est considéré comme si il y avait une méta-commande 0 BFC NOCERTIFY, et le processus BFC est désactivé pour ce fichier.

NOCERTIFY

Cette option spécifie que ce fichier n'est pas compatible avec les spécifications BFC. Les polygones ne sont pas définis logiquement par des points dans le même sens, et/ou corrects, et/ou les références aux sous-fichiers ne sont pas inversés correctement. Si l'option NOCERTIFY est utilisé, elle doit apparaître avant la première méta-commande graphique. Toutes les autres méta-commandes BFC dans le fichier sont alors ignorées.

CLIP

Cette option fixe comme permis l'état de choix. Cela autorise le choix, si toutes les autres conditions de choix sont établis. Alors que cette option devrait s'appeler CULL (choisir), le mot CLIP (couper) a été gardé intentionnellement par compatibilité avec l'existant.

NOCLIP

Cette option fixe comme interdit l'état choix. Tout sous-fichier ou primitive référencé avec cet état n'est pas autorisé a faire le choix. Alors que cette option devrait s'appeler NOCULL (non-choix), le mot NOCLIP (non-couper) a été gardé intentionnellement par compatibilité avec l'existant.

Notes sur CLIP/NOCLIP

Il peut y avoir n'importe quel nombre de changements d'état dans un fichier, bien qu'il soit recommandé que ces changement soient minimum.

Si aucune des options CLIP ou NOCLIP ne sont spécifiés dans une méta-commande 0 BFC avant la première méta-commande opérationnelle, alors l'état est fixé à autorisé (enable), c'est-à-dire que CLIP est considéré par défaut.

CW

Cette option fixe l'ordre des sommets de polygones au sens horaire.

CCW

Cette option fixe l'ordre des sommets de polygones au sens anti-horaire.

Notes sur CW/CCW

Il peut y avoir n'importe quel nombre de changements de sens dans un fichier, bien qu'il soit recommandé que ces changement soient minimum.

Si aucune option de sens n'est spécifié pour le fichier, l'état local du sens est mis par défaut à anti-horaire, c'est-à-dire que CCW est considéré par défaut.

INVERTNEXT

Cette option inverse un sous-fichier d'une partie de pièce ou d'une primitive. Elle ne peut être utilisée qu'immédiatement avant une commande d'appel de sous-fichier (type de ligne 1). Bien que des lignes vides soient autorisées entre les deux, cela est déconseillé pour des raisons de lisibilité. Et, cette option n'affecte que la commande qui la suit. Ce sous-fichier ne peut pas être une pièce complète (cela n'aurait pas de sens).

Exemple :


	0 BFC INVERTNEXT
	1 16 0 0 0 1 0 0 0 1 0 0 0 1 somefile.dat
	1 16 0 0 0 1 0 0 0 1 0 0 0 1 another.dat

Dans cet exemple le rendu de somefile.dat sera inversé tandis que celui de another.dat ne sera pas inversé.

Pour plus d'informations, voir "Inversion" dans la partie décrivant les fonctionnalités de l'extension du langage.

 

Directives pour la bibliothèque de pièces LDraw

Ce chapitre donne quelques suggestions pour rendre effectif l'extension BFC dans les fichiers de la bibliothèque de pièces LDraw, et son impacte sur la bibliothèque actuelle. Ce chapitre peut être diversifié par d'autres spécifications (par exemple les spécifications de l'en-tête) et/ou les exigences des administrateurs de cette bibliothèque, sans affecter la validité des spécifications du choix de la face arrière (BFC).

La bibliothèque de pièces LDraw inclue toutes les pièces, primitives, et parties de pièces distribuées avec LDraw ou avec les mises à jour de pièces de LDraw.org.

Les nouvelles pièces ne sont pas exigées compliantes avec cette extension du langage LDraw. Il sera seulement exigé d'avoir une méta-commande 0 BFC, indiquant si elle est compliante ou non compliante.

Les nouvelles primitives sont exigées compliantes pour être acceptées dans les mises à jour.

Il est désirable que tous les fichiers utilisent le même sens. Lorsque c'est possible, les fichiers doivent utiliser le sens anti-horaire. Le sens actuel pour toutes les pièces est laissé à l'appréciation de leur auteur. Les primitives devraient toujours utiliser le sens CCW.

Les primitives devraient être écrites de tel façon que les polygones aient leur face avant à l'extérieur, ou vers le haut. Des exceptions sont permises pour les polygones qui modélisent les parties internes ou inférieures.

Comme indiqué plus haut, tous les fichiers compliants BFC de la bibliothèque de pièces LDraw doivent avoir une ligne explicite contenant 0 BFC CERTIFY dans leur en-tête.

 

Directives pour les moteurs de rendu

Ce chapitre donne quelques suggestions pour la création de programmes devant faire des rendus corrects. Tout programme peut passer outre ces directives s'il y a une autre façon de le faire.

Renversement de la matrice : Les moteurs de rendu auront besoin de corriger les matrices d'orientation qui par inadvertance ou délibérément renversent un sous-fichier.

Transformation normal :

1 16 0 0 0 1 0 0 0 1 0 0 0 1 somefile.dat

Transformation 'Renversée' :

1 16 0 0 0 1 0 0 0 -1 0 0 0 1 somefile.dat

Si le moteur de rendu ne détecte pas et n'ajuste pas les matrices renversées, le sens de tous les polygones du sous-fichier sera inversé, donnant un rendu du sous-fichier incorrect.

La méthode typique de déterminer qu'une matrice d'orientation est renversée, est de calculer le déterminant de la matrice. Si le déterminant est négatif, alors la matrice a été renversé.

La façon typique de faire pour renverser une matrice, est d'inverser l'ordre des sommets des polygones. C'est, si le fichier spécifie le sens comme CW (sens horaire) et la matrice d'orientation est renversée, le programme de rendu procédera comme si le sens était défini CCW (sens anti-horaire).

L'option INVERTNEXT renverse aussi le sens des polygones dans un sous-fichier de pièce ou une primitive. Si la matrice appliquée à ce sous-fichier, ou cette primitive, a elle-même été inversé, le processus INVERTNEXT est exécuté EN ADDITION AVEC l'inversion automatique. Les deux ensembles s'annulent l'un l'autre.

Sous-fichiers inversés. Généralement, il n'est pas possible de déterminer si la référence d'un sous-fichier est inversé ou normal (c'est la raison de la méta-commande 0 BFC INVERTNEXT). En particulier, le moteur de rendu ne peut PAS utiliser le déterminant de la matrice d'orientation pour déterminer si le sous-fichier devra être renversé (voir 'Renversement de la matrice' plus haut).

Nota : Les fichier de pièces ne doivent jamais être inversés, car ils représentent des solides fermés.

Fichiers non certifiés. Aucune supposition ne peut être faite sur les fichiers de modèles qui peuvent utiliser directement des primitives ou des commandes de polygones, donc les moteurs de rendu ne devraient pas traiter simplement un fichier de modèle non certifié comme s'il était certifié.

Etat du choix. Le moteur de rendu ne peut avoir par défaut un état autorisé ou interdit du choix du sens des faces au début de processus. Il est présumé que l'utilisateur donnera la possibilité de contrôler cet état.

Matrices dégénérées. Quelques matrices d'orientation ne permettent pas de calculer le déterminant. Ce calcul est central dans le processus BFC. Si une matrice d'orientation pour un sous-fichier est dégénéré, alors le choix n'est pas possible pour ce fichier.

 

Processus de rendu

Ce chapitre présente un modèle possible pour écrire le noyau de la boucle de traitement d'un programme de rendu LDraw/BFC. Un programme peut ne pas respecter ce modèle, s'il utilise une autre façon de faire un rendu valide.

Toute la logique relevant de BFC est incluse, alors que beaucoup d'autres logiques (aussi possible) sont exclues. Il ne doit pas être considéré que ce pseudo-code représente la meilleure façon d'implémenter BFC.

La fonction BFC() retourne une valeur booléenne, indiquant si un polygone doit être rendu ou choisi (culled). Comme la nature de cette routine n'impacte pas le standard BFC, la logique pour BFC() n'est pas incluse dans le pseudo-code suivant. Il y a de l'information sur le processus BFC à beaucoup d'endroits, y compris sur "lugnet.cad.dev".

Recursive Procedure RenderFile
Parameters :
  ModelFile string             // File to render
  AccumCull boolean            // global culling value yes/no
  AccumInvert boolean          // current inversion normal/inverted
  AccumTransformMatrix matrix  // current transformation
  Colour integer               // current colour

Declare
  LocalCull  boolean                        Initial TRUE
  Winding    bivalue(CCW, CW)               Initial CCW
  Certified  trivalue(TRUE, FALSE, UNKNOWN) Initial UNKNOWN
  InvertNext boolean                        Initial FALSE
  Command    DATCommandLine // Structure containing parameters from
                            // a single operational command-line.

OpenFile(ModelFile)

Do Until EOF(ModelFile)
   Get Next Command
   If Command.Colour = 16 Then
      Command.Colour = Colour
   ElseIf Command.Colour = 24 Then
      Command.Colour = EdgeColour(Colour)
   End If

   Case Command.LineType
      BFC
        If Certified is UNKNOWN and no Option in Command is NOCERTIFY Then
           Certified = TRUE
        End If

        Do for each Option in Command
           Case Option
              CERTIFY
                 Assert Certified != FALSE
                    // Triggers error if file has been NOCERTIFY'ed
                 Certified = TRUE
              NOCERTIFY
                 Assert Certified != TRUE
                    // Triggers error if file has been CERTIFY'ed
                 Certified = FALSE
              CLIP:   LocalCull = TRUE
              NOCLIP: LocalCull = FALSE
              CCW
                 If AccumInvert Then
                    Winding = CW
                 Else
                    Winding = CCW
              CW
                 If AccumInvert Then
                    Winding = CCW
                 Else
                    Winding = CW
              INVERTNEXT
                 InvertNext = TRUE
           End Case
        End Do
      SUBFILE
         If Certified is UNKNOWN Then
            Certified = FALSE
         Case Certified
            TRUE
               RenderFile Command.Subfile,
                    (AccumCull and LocalCull),
                    (AccumInvert xor InvertNext),
                    Command.TransformMatrix * AccumTransformMatrix,
                    Command.Colour
            FALSE, UNKNOWN
               RenderFile Command.Subfile,
                    FALSE,
                    (AccumInvert xor InvertNext),
                    Command.TransformMatrix * AccumTransformMatrix,
                    Command.Colour
      LINE, CONDITIONAL_LINE
         If Certified is UNKNOWN Then
            Certified = FALSE
         Deal with primitive command
      TRIANGLE, QUAD
         If Certified is UNKNOWN Then
            Certified = FALSE
         End If
         If AccumCull and LocalCull And (Certified is TRUE) Then
            If BFC(Command, AccumTransformMatrix, Winding) Then
               Render Command
            Else
               Don't render Command
         Else
            Render Command

 

Méta-commande de Texturation (!TEXMAP)

La texturation, c'est-à-dire la projection d'une image 2D (texture) sur des objets LDraw 3D est pour l'instant à l'état de projet avancé. Actuellement, LDView en v4.2 Beta 1 (04-2012) permet de visualiser les textures, Bricksmith v2.6 (30-10-2012) supporte les textures planes, et également LeoCAD v0.79 (13-12-2012), LDCad les textures tous types.

Source principale : Language Extension for Texture Mapping, Révision 1.0 du 4 octobre 2012.

Format général

	0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile> [GLOSSMAP pngfile]
	0 !: <geometry1>
	...
	<geometry2>
	...
	0 !TEXMAP FALLBACK
	<geometry3>
	...
	0 !TEXMAP END

Description

0 !TEXMAP est la méta-commande principale de déclaration de texture.

0 !: est utilisé pour spécifier la géométrie mappée qui sera ignorée par les programmes de visualisation qui ne supportent pas la méta-commande !TEXMAP. Elle ne peut être incorporée à cette dernière. La méta-commande actuelle est le deux-points, et a été choisie pour être bref, facile à lire dans les fichiers, et sans rentrer en conflit avec d'autres méta-commandes ou programmes existants.

La commande START indique que la texture donnée devra être utilisé. Si une autre texture est en cours d'utilisation, elle est mise dans une pile pour la retrouver lorsque la commande END est fournie. Cette texture reste active jusqu'à l'apparition de la commande END, ou lorsque qu'on arrive à la fin du fichier qui contient le START. La texture reste active lorsque le processus traite un sous-fichier, à moins qu'elle ne soit écrasée dans ce sous-fichier.

La commande FALLBACK est un séparateur de section. Dans une application supportant le texturage toutes les lignes de géométrie qui suivent un !: servant de commentaire (geometry1) ou les lignes de géométrie LDraw standards (geometry2), entre START et FALLBACK sont utilisées comme géométrie, et ont la texture appliquée. Toutes les lignes de géométrie entre FALLBACK et END (geometry3) sont ignorées. Dans une application qui ne supporte pas le texturage, il n'y a rien à faire de spécial car toutes les géométries non commentées (geometry2 et geometry3), sont générées normalement, tandis que celles commentées (geometry1) sont ignorées. Nota : L'auteur d'une pièce LDraw devra être très prudent pour ne pas introduire involontairement une ligne de géométrie non commentée entre les sections START et FALLBACK.

En général, la section entre START et FALLBACK contient seulement de la géométrie commentée suivant un marqueur 0 !:, et la section entre FALLBACK et END est de la géométrie non commentée.

Nota : Il faut être prudent et réfléchir à l'approche lorsque l'on veut introduire de la géométrie non commentée avant FALLBACK (geometry2). Cette fonction est présente pour pouvoir utiliser une géométrie identique en mode texturé et non texturé. C'est un cas rare, et normalement cela sera peu employé.

La commande END cesse l'utilisation de la texture en cours, et restaure la précédente texture comme texture en cours. Cela veut dire qu'une commande START imbriquée formera une pile de textures, et qu'une commande END dépilera les textures. Si une commande END apparait dans un sous-fichier cela fait cesser l'utilisation de la texture spécifiée dans le fichier appelant, puis cette texture sera restaurée pour l'utiliser lorsque le sous-fichier sera fini d'être traité.

La commande NEXT est un raccourci pour qu'une texture ne fonctionne que sur la ligne de type 1, 2, 3, 4 ou 5 suivante. C'est un usage équivalent à utiliser une commande START, puis une seule ligne de géométrie, avant une commande END, sans possibilité de commande FALLBACK. La première ligne non vide qui suit cette commande NEXT ne doit pas être une ligne commençant par 0. Si cela est, la commande NEXT elle-même pourra être ignorée, et un message d'erreur pourra être généré, si l'environnement est prévu pour générer des messages vers l'utilisateur.

L'indicateur method spécifie la méthode de projection à utiliser pour la texture. Chaque méthode de projection a son propre ensemble de paramètres, et l'analyse des paramètres dépend de la méthode.

Il y a 3 méthodes de projection utilisables : PLANAR (plane), CYLINDRICAL (cylindrique) et SPHERICAL (sphérique), Ces méthodes et leurs paramètres sont décrits plus bas.

Le premier fichier au format PNG pngfile représente la texture à appliquer. Elle peut être en noir et blanc ou en couleurs, et si un canal Alpha existe, il devrait être appliqué convenablement (permettre à la couleur de la pièce de se voir à travers). Le second fichier PNG optionnel derrière GLOSSMAP est utilisé comme texture d'apparence. Il devrait être une image à un seul canal, où la valeur indique la spécularité qui s'ajoute à la texture de la pièce. Les valeurs RVB sont actuellement ignorées, mais réservées, dans ce second fichier, et le canal Alpha détermine le degré de reflexion de la texture donnée.

Les noms des fichiers pngfile qui contiennent des espaces doivent être entourés de doubles-guillemets ("). En outre une recherche du fichier sera tenté en ajoutant "textures/" comme préfixe en premier, puis la recherche se fera dans les dossiers standards LDraw. Si aucun fichier n'est trouvé, la recherche sera répétée sans le préfixe "textures/". Les noms de fichiers qui contiennent eux-mêmes des doubles-guillemets doivent avoir un caractère anti-slash (\) devant chaque. Le caractère \ lui-même doit être doublé (\\) pour être utilisé comme séparateur de sous-dossier, mais il est recommandé d'utiliser le caractère slash (/) dans ce cas. Nota : Dans les fichiers LDraw, \ et / sont interchangeables comme séparateurs du chemin d'un dossier.

La méthode PLANAR

Les paramètres pour PLANAR sont :
	x1 y1 z1 x2 y2 z2 x3 y3 z3

Ces trois points représentent 3 coins de la texture en coordonnées 3D. Ils forment un plan sur lequel les objets peuvent être projetés et représentent également l'étendue de la texture.

De plus, par les points 1 et 3 passe un plan P1 perpendiculaire au plan de la texture, où le point 1 est sur le plan et la normale à ce plan va du point 1 au point 2. De façon similaire, par les points 1 et 2 passe un plan P2 perpendiculaire aux deux plans précédents. Ce plan contient également point 1 mais sa normale va du point 1 au point 3.

Maintenant, pour faire correspondre les coordonnées 3D aux coordonnées de la texture, U est donné par la distance entre un point et le plan P1 divisé par la longueur du vecteur du point 1 au point 2. V est donné par la distance entre un point et le plan P2 divisé par la longueur du vecteur du point 1 au point 3. Ensuite U et V sont normalisés pour être entre 0 et 1. Cela peut maintenant faire correspondre les pixels de la texture à la zone à texturer.

La méthode CYLINDRICAL

Les paramètres pour CYLINDRICAL sont :
	x1 y1 z1 x2 y2 z2 x3 y3 z3 a

Le premier point représente le centre de la base du cylindre. Le second représente le centre du haut du cylindre. Le troisième représente un emplacement sur le bord externe de la base où le centre bas de la texture toucherait. L'angle a indique la portion du cylindre couvert par la texture, et donc l'étendue peut aller de -a/2 à a/2 en mesure relative à la ligne radiale allant du point 1 au point 3.

Maintenant, pour faire correspondre les coordonnées 3D aux coordonnées de la texture, U est donné par l'angle entre le vecteur formé par les points 1 et 3 et le vecteur formé par le point 1 et un point 3D qui a été projeté sur le plan occupé par la base du cylindre. Cet angle est ensuite divisé par le paramètre "a" pour le normaliser entre 0 et 1. V est donné par la distance d'un point au plan occupé par la base du cylindre et divisé par la longueur du vecteur formé par les points 1 et 2.

La méthode SPHERICAL

Les paramètres pour SPHERICAL sont :
	x1 y1 z1 x2 y2 z2 x3 y3 z3 a b

Le premier point représente le centre de la sphère. Le second représente un point sur la sphère ou le centre de la texture va toucher. Le troisième est utilisé pour former un plan P1 perpendiculaire à la texture et la coupant en deux horizontalement. Un plan additionnel P2 peut être calculé en utilisant les points 1 et 2 et en générant un troisième point sur la normale à P1. P2 sera perpendiculaire à la fois à P1 et à la texture et coupe la texture en deux verticalement. Les deux angles a et b indiquent la portion de la sphère couverte par la texture, et donc l'étendue peut aller de -a/2 à a/2 et de -b/2 à b/2 en mesure relative au vecteur allant du point 1 au point 2 et respectivement sur les plans P1 et P2.

Maintenant, pour faire correspondre les coordonnées 3D aux coordonnées de la texture, U est donné par l'angle entre le vecteur formé par les points 1 et 2 et le vecteur formé par le point 1 et un point 3D qui a été projeté sur le plan P1. Cet angle est ensuite divisé par le paramètre "a" pour le normaliser entre 0 et 1. V est donné par l'angle entre le vecteur formé par les points 1 et 2 et le vecteur formé par le point 1 et un point 3D qui a été projeté sur le plan P2. Cet angle est ensuite divisé par le paramètre "b" pour le normaliser entre 0 et 1.

Nota : Au 10-2012 la discussion n'est pas terminée sur la définition de la méta-commande TEXMAP, et peut donc changer.

 

Couleurs

Anciennes définitions

A l'origine du système LDraw, les couleurs étaient beaucoup plus limitées qu'aujourd'hui, et dans certains anciens programmes seules les 16 couleurs de base sont présentes (0 à 15), avec la couleur spéciale 16 pour les pièces "pas encore colorées".

Puis les choses évoluant le nombre de couleurs s'est agrandi, ajoutant des catégories et des couleurs qui vont du code 0 au code 511. Nota : Un certain nombre de codes ne sont pas affectés, et ces catégories ont évolué.

Définition actuelle

Aujourd'hui les couleurs officielles sont définies dans le fichier ldconfig.ldr. Il affecte avec la méta-commande 0 !COLOUR toutes les couleurs officielles à des numéros de code correspondant chacun à une couleur utilisée par les polygones et définie par sa valeur RGB (Red-Green-Blue ou Rouge-Vert-Bleu), ainsi que la couleur des lignes de bords en contraste avec les polygones.

Il existe également un second fichier ldcfgalt.ldr, alternatif utilisant des valeurs différentes pour chaque couleur, ou un code différent pour les lignes de bords en contraste.

Nota :

Depuis 2011, il est également possible d'affecter une couleur directe dans les fichiers de pièce à motif, dans le cas où cette couleur n'est pas disponible dans le fichier ldconfig.ldr, mais ceci doit rester exceptionnel. Voir le chapitre : Couleur directe.

 

Couleur de base (0 à 15)

Voici une table des 16 couleur de base (codes 0 à 15) :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
0 26 Noir Black #212121  
1 23 Bleu Blue (Bright Blue) #0033B2  
2 28 Vert Green (Dark Green) #008C14  
3 107 Turquoise Foncé (Sarcelle) Dark Turquoise (Bright Bluish Green, Teal) #00999F  
4 21 Rouge Red (Bright Red) #C40026  
5 22 Rose Foncé Dark Pink (Medium Reddish Violet) #DF6695  
6 25 Marron Brown (Earth Orange) #5C2000 Remplacé par couleur 70 (Brun rougeâtre) vers 2004.
7 2 Gris Clair Grey (Light Grey) #9C9999 Remplacé par couleur 71 (Gris bleuté clair) vers 2004.
8 27 Gris Foncé Dark Grey #635F52 Remplacé par couleur 72 (Gris bleuté foncé) vers 2004.
9 45 Bleu Clair Light Blue #6BABDC  
10 37 Vert Clair Bright Green #6BABDC  
11 116 Turquoise Light Turquoise (Medium Bluish Green) #33A6A7  
12 4 Saumon Salmon (Brick Red) #FF857A  
13 16 Rose Pink #F9A4C6  
14 24 Jaune Yellow (Bright Yellow) #FFDC00  
15 1 Blanc White #FFFFFF  

Nota : Aujourd'hui les couleurs de base (Core) ne sont plus séparées des couleurs unies ou mélangées et sont regroupées ensemble dans la catégorie des couleurs unies (Solid).

 

Couleur "Main" (16)

La couleur 16, appelée "main color" (couleur principale) ou "current color" (couleur courante), utilise la couleur courante, c'est-à-dire n'importe quelle couleur spécifiée dans une ligne de type 1, du fichier appelant le sous-fichier, et détermine la couleur utilisée par la ligne en cours d'exécution dans le sous-fichier portant la couleur 16.

Exemple :
1 4 0 0 0 1 0 0 0 1 0 0 0 1 part.dat
Toutes les lignes de commandes de couleur 16 dans le sous-fichier part.dat, sont affichées avec la couleur 4 (c'est-à-dire rouge).

Les pièces qui utilisent le code de couleur 16, ont n'importe laquelle des couleurs qui se trouve sur la ligne qui vient d'être affichée, ou si aucune couleur n'a été spécifiée, la valeur par défaut est gris.


LDraw

LEGO
Couleur
(par défaut)
Nom
Français
Nom
Anglais
RGB
16 - Couleur principale, ou courante Main color #7F7F7F

 

Couleur "Edge" (24)

La couleur 24 est appelée "complement colour" (couleur complémentaire), ou "edge colour" (couleur de bord). Cette couleur est généralement utilisée pour les lignes de type 2 (ligne), et type 5 (ligne conditionnelle). Lorsque un sous-fichier contenant des lignes de commandes utilisant la couleur 24 est appelé par une ligne de commande du fichier appelant, la couleur 24 est remplacée par la couleur complémentaire de la couleur courante de la ligne appelante. En général la nuance clair/sombre complémentaire. Ainsi, si la couleur courante est un bleu foncé, la couleur 24 donnera un bleu clair.

Exemple :
1 4 0 0 0 1 0 0 0 1 0 0 0 1 part.dat
Toutes les lignes de commandes de couleur 24 dans le sous-fichier part.dat, sont affichées avec la couleur complémentaire de la couleur 4 (c'est-à-dire 0 noir, ou 12 rouge clair, suivant le fichier de définition des couleurs).

La couleur complémentaire n'est ni unique, ni symétrique. En effet le complément du complément d'une couleur X, n'est pas forcément la couleur X. En particulier les couleurs 6, 7, 14, et 15 ne sont pas réversibles. Voir le fichier ldconfig.ldr (dans le dossier d'installation de LDraw) pour avoir la couleur complémentaire (paramètre EDGE) de chaque couleur définie (paramètre VALUE). Exemple :
0 !COLOUR Red CODE 4 VALUE #C40026 EDGE #333333
La couleur rouge :   #C40026   , a pour couleur complémentaire :   #333333  


LDraw

LEGO
Couleur
(par défaut)
Nom
Français
Nom
Anglais
RGB
24 - Couleur de bord Edge color #7F7F7F

 

Couleur unie

Les autres couleurs ayant un ton uniforme étaient faites précédemment par le mélange de deux couleurs de base, c'est pourquoi on les appelaient également couleurs mélangées.

Ancienne définition des couleurs mélangées

Anciennement on retrouvait dans cette catégorie, les couleurs 256 à 511 dites nuancées ou mélangées (mélange de deux couleurs). Ainsi, si vous voulez combiner les couleurs J et K, la représentation de la nuance de couleur est :

        couleur = (J * 16) + K + 256

La couleur complémentaire de J est utilisée comme la couleur complémentaire de la valeur nuancée. Egalement, vous pouvez contrôler la couleur des bords (un peu) en inversant J et K.

Modification de Janvier 2005 : Précédemment, les codes de couleur de 256 à 511 pouvaient être utilisées uniquement dans les appels de parties de pièces (reference subfiles). En conséquence, seules les commandes de type 1 pouvaient utiliser ces couleurs. Cela signifiait, que toutes les pièces ayant besoin de ces couleurs, devaient être créées dans un sous-fichier spécifique pour chaque couleur. Cette restriction était inutile. Vous êtes maintenant libre d'utiliser les couleurs 256-511 (à votre convenance) pour n'importe quel bord, polygone, ou sous-fichier.

Définition actuelle des couleurs unies

Les couleurs unies sont aujourd'hui définies dans le fichier ldconfig.ldr.

Voici une table des couleurs unies :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
17 6 Vert Clair Light Green #C2DAB8  
18 3 Jaune Clair Light Yellow #FBE696  
19 5 Jaune Brique (Beige) Brick Yellow (Tan) #E4CD9E  
20 39 Violet Bleuté Clair Light Bluish Violet #C9CAE2  
22 104 Violet Lumineux Bright Violet #81007B  
23 196 Bleu Royal Foncé Dark Royal Blue #2032B0  
25 106 Orange Lumineux (Orange) Bright Orange (Orange) #FE8A18  
26 124 Violet Rougeâtre Lumineux (Magenta) Bright Reddish Violet (Magenta) #923978  
27 119 Vert Jaunâtre Lumineux (Citron vert) Bright Yellowish Green (Lime) #BBE90B  
28 138 Beige Foncé (Sable) Dark Tan (Sand Yellow) #958A73  
29 222 Rose Lumineux Bright Pink (Light Purple) #E4ADC8  
30 324 Lavande Moyen Medium Lavender #AC78BA  
31 325 Lavande Lavender #E1D5ED  
68 36 Orange Très Clair Very Light Orange (Light Yellowish Orange) #F3CF9B  
69 198 Rouge Clair (Lila Clair) Light Purple (Bright Reddish Lilac) #CD6298  
70 192 Brun Rougeâtre Reddish Brown #CD6298 Remplace couleur 6 (Marron) depuis 2004.
71 194 Gris Bleuté Clair Light Bluish Gray (Medium Stone Grey) #A0A5A9 Remplace couleur 7 (Gris clair) depuis 2004.
72 199 Gris Bleuté Foncé Dark Bluish Gray (Dark Stone Grey) #6C6E68 Remplace couleur 8 (Gris foncé) depuis 2004.
73 102 Bleu Moyen Medium Blue #5A93DB  
74 29 Vert Moyen Medium Green #73DCA1  
77 223 Rose Clair Light Pink #FECCCF  
78 283 Chair Clair (Nougat Clair) Light Flesh (Light Nougat) #F6D7B3  
84 38 Orange Foncé Medium Dark Flesh (Dark Orange) #CC702A  
85 268 Pourpre Foncé (Lila Moyen) Dark Purple (Medium Lilac) #3F3691  
86 86 Chair Foncé Dark Flesh (Medium Nougat) #7C503A  
89 213 Bleu Violet Blue Violet (Medium Royal Blue) #4C61DB  
92 18 Chair Flesh (Nougat) #D09168  
100 100 Saumon Clair Light Salmon (Light Red) #FEBABD  
110 110 Violet Violet (Bright Bluish Violet) #4354A3  
112 112 Violet Moyen Medium Violet (Medium Bluish Violet) #6874CA  
115 115 Citron Vert Moyen Medium Lime (Medium Yellowwish Green) #C7D23C  
118 118 Vert d'Eau Aqua (Light Bluish Green) #B3D7D1  
120 120 Citron Vert Clair Light Lime (Light Yellowish Green) #D9E4A7  
125 125 Orange Clair Light Orange #F9BA61  
128 128 Nougat foncé Dark Nougat #AD6140  
151 208 Gris Bleuté Très Clair Very Light Bluish Gray (Light Stone Gey) #E6E3E0  
191 191 Orange Clair Lumineux Bright Light Orange (Flame Yellowish Orange) #F8BB3D  
212 212 Bleu Clair Lumineux Bright Light Blue (Light Royal Blue) #9FC3E9  
216 216 Rouille Rust #B31004  
218 218 Pourpre moyen Medium Purple (Reddish Lilac) #8E5597  
219 219 Violet moyen Medium Violet (Lilac) #564E9D  
226 226 Jaune Clair Lumineux Bright Light Yellow (Cool Yellow) #FFF03A  
232 232 Bleu Ciel Sky Blue (Dove Blue) #7DBFDD  
272 140 Bleu Foncé Dark Blue (Earth Blue) #0A3463  
288 141 Vert Foncé Dark Green (Earth Green) #184632  
295 295 Rose flamant Flamingo Pink #FF94C2  
308 308 Brun Foncé Dark Brown #352100  
313 11 Bleu Maersk Maersk Blue (Pastel Blue) #3592C3  
320 154 Rouge Foncé Dark Red #720E0F  
321 321 Azur Foncé Dark Azure (Dark Azur) #078BC9  
322 322 Azur Moyen Medium Azure (Medium Azur) #36AEBF  
323 323 Eau Claire Light Aqua (Aqua) #ADC3C0  
326 326 Vert Jaunâtre Yellowish Green (Spring Yellowish Green) #DFEEA5  
330 330 Vert Olive Olive Green (Yellowish Green) #9B9A5A  
335 153 Rouge Sable Sand Red #D67572  
351 22 Rose Foncé Moyen Medium Dark Pink (Medium Reddish Violet) #F785B1  
366 25 Orange Terre Earth Orange #FA9C1C  
373 136 Violet Sable Sand Purple (Sand Violet) #845E84  
378 151 Vert Sable Sand Green #A0BCAC  
379 135 Bleu Sable Sand Blue #6074A1  
450 12 Brun Fabuland Fabuland Brown (Light Orange Brown) #B67B50  
462 105 Orange Moyen Medium Orange (Bright Yellowish Orange) #FFA70B  
484 38 Orange Foncé Dark Orange #A95500  
503 103 Gris Très Clair Very Light Grey (Light Grey) #E6E3DA  

 

Couleur transparente

Ancienne définition des couleurs transparentes

Anciennement, il suffisait d'ajouter 32 au code d'une couleur de base pour avoir la nuance transparente de cette couleur. Par exemple, pour avoir un rouge transparent, il suffisait d'utiliser le code 36 (32 pour transparent + 4 pour rouge).

Nota : Il n'existe pas de couleur transparente définie pour toutes les couleurs.

Couleurs transparentes unies

Aujourd'hui elles sont définies dans le fichier ldconfig.ldr.

Voici une table des couleurs transparentes unies :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB
47 40 Transparent Trans Clear (Transparent) #FCFCFC
40 111 Transparent Noir Trans Black (Transparent Brown) #635F52
36 41 Transparent Rouge Trans Red (Transparent Red) #C91A09
38 47 Transparent Orange Néon Trans Neon Orange (Transparent Fluorescent Reddish Orange) #FF800D
57 182 Transparent Orange Trans Orange (Trans Bright Orange) #F08F1C
54 157 Transparent Jaune Néon Trans Neon Yellow (Transparent Fluorescent Yellow) #DAB000
46 44 Transparent Jaune Trans Yellow (Transparent Yellow) #F5CD2F
42 49 Transparent Vert Néon Trans Neon Green (Transparent Fluorescent Green) #C0FF00
35 311
227
Transparent Vert Lumineux Trans Bright Green (Transparent Bright Yellowish Green) #56E646
34 48 Transparent Vert Trans Green (Transparent Green) #84B68D
33 43 Transparent Bleu Foncé Trans Dark Blue (Transparent Blue) #0020A0
41 143 Transparent Bleu Moyen Trans Medium Blue (Transparent Fluorescent Blue) #559AB7
43 42 Transparent Bleu Clair Trans Light Blue (Transparent Light Blue) #AEE9EF
39 229 Transparent Bleu Très Clair Trans Very Light Blue (Transparent Light Bluish Green) #C1DFF0
44 236 Transparent Violet Clair Trans Light Purple (Transparent Bright Reddish Lilac) #96709F
52 126 Transparent Violet Trans Purple (Transparent Bright Bluish Violet) #A5A5CB
37 113 Transparent Rose Foncé Trans Dark Pink (Transparent Medium Reddish Violet) #DF6695
45 230 Transparent Rose Trans Pink (Transparent Bright Pink) #FC97AC
285 285 Transparent Vert clair Trans Light Green #7DC291
234 234 Transparent Jaune Feu Transparent Fire Yellow #FBE890
239 239 Transparent Bleu Violet Clair Trans Light Blue Violet (Transparent Light Royal Blue) #6BABE4
231 231 Transparent Orange Clair Lumineux Tans Bright Light Orange (Transparent Flame Yellowish Orange) #FCB76D

Couleurs transparentes à inclusion

Il existe aussi des couleurs transparentes comportant une autre couleur incluse dans la masse. Voir plus bas leur définition avec la méta-commande !COLOUR et l'option MATERIAL GLITTER.

Couleurs existantes dans le fichier de configuration ldconfig.ldr :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
114 114 Rose Foncé Transparent à Inclusion Glitter Trans Dark Pink (Meddium Reddish-Violet w. Glitter 2%) #DF6695  
117 117 Transparent à Inclusion Glitter Trans Clear (Transparent Glitter) #FFFFFF  
129 129 Violet Transparent à Inclusion Glitter Trans Purple (Tr. Bright Bluish Violet w. Glitter 2%) #640061  
302 302 Bleu Clair Transparent à Inclusion Glitter Trans Light Blue (Tr. Light Blue with Glitter 2%) #AEE9EF  
339 339 Vert Néon Transparent à Inclusion Glitter Trans Neon Green (Tr Fluorescent Green with Glitter 2%) #C0FF00  

 

Couleur métallique ou à éclat

Il existe plusieurs gammes de couleurs prévues pour représenter les métaux. Voir plus bas leur définition avec la méta-commande !COLOUR et l'option CHROME et METAL.

Couleur métallique

Voici une table des couleurs métalliques :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
80 315 Métal Argent Metallic Silver (Silver Metallic) #A5A9B4 Pour les pièces à motif ou peinture argentée, autocollant argenté.
81 200 Métal Vert Metallic Green (Lemon Metallic) #899B5F  
82 316 Métal Or Metallic Gold (Titanium Metallic) #DBAC34 Pour les pièces à motif ou peinture dorée, autocollant doré.
83 149 Métal Noir Metallic Black #1A2831  
87 309
336
Métal Gris Foncé Metallic Dark Grey (Metalized Silver) #6D6E5C  
300 300
334
Cuivre métallisé Metallic Copper (Copper Drum Lacq/Copper Ink) #C27F53  

Couleur chromée

Couleurs existantes dans le fichier de configuration ldconfig.ldr :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
334 299 Chrome Or Chaud (Doré) Warm Gold Drum Lacq (Chrome Gold) #BBA53D Utilisé pour pièce à revêtement doré
383 298 Chrome Argent (Argenté) Cool Silver Drum Lacq (Chrome Silver) #E0E0E0 Utilisé pour pièce à revêtement chromé.
60 187 Chrome Cuivre Antique (Vert-de-gris) Metallic Earth Orange (Chrome Antique Brass) #645A4C  
64 - Chrome Noir Chrome Black #1B2A34  
61 185 Chrome Bleu Metallic Bright Blue (Chrome Blue) #6C96BF  
62 147 Chrome Vert Metallic Dark Green (Chrome Green) #3CB371  
63 147 Chrome Rose Metallic Bright Red (Chrome Pink) #AA4D8E  

Couleur de matériau

Couleurs existantes dans le fichier de configuration ldconfig.ldr :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
16 - Couleur Principale Main Color #7F7F7F Voir : ci-dessus
24 - Couleur de Bord Edge Color #7F7F7F Voir : ci-dessus
32 109 Noir Transparent de Cellule Infra-Rouge Trans Black IR Lens #000000  
493 - Aimant Magnet #656761 Utilisé pour les aimants.
494 - Contact Electrique Métal Blanc Electric Contact Alloy #D0D0D0 Utilisé pour contact électrique (tenons).
Utilisé pour pièce réellement métallique, dont l'acier.
495 - Contact Electrique Cuivré Electric Contact Copper #AE7A59 Utilisé pour contact électrique cuivré (tenons).

Couleur nacrée

Voir plus bas leur définition avec la méta-commande !COLOUR et l'option PEARLESCENT.

Couleurs existantes dans le fichier de configuration ldconfig.ldr :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
183 183 Blanc Nacré Pearl White (Metallic White) #F2F3F2  
150 150 Gris Nacré Très Clair Pearl Very Light Grey (Metallic Light Grey) #BBBDBC  
135 179
296
131
315
Gris Nacré Clair Pearl Light Grey (Silver Flip/Flop) #9CA3A8  
179 131 Argent Mat (Argent Terne) Flat Silver (Silver) #898788 Pour motif imprimé sur les pièces.
148 148 Gris Nacré Foncé Pearl Dark Grey (Metallic Dark Grey) #575857  
137 145 Bleu Métallique Metal Blue (Sand Blue Metallic) #5677BA  
142 127 Or Nacré Clair Pearl Light Gold (Gold) #DCBE61  
297 297 Or Nacré Pearl Gold (Warm Gold) #CC9C2B  
178 178 Or Foncé Mat Flat Dark Gold (Yellow Flip/Flop) #B4883E  
134 139 Cuivre Copper #AB6038  
189 189 Or Rougeâtre Reddish Gold #AC8247  

Couleur mouchetée

Il existe des couleurs comportant une autre couleur métallique mouchetée sur sa surface. Voir plus bas leur définition avec la méta-commande !COLOUR et l'option MATERIAL SPECKLE.

Couleurs existantes dans le fichier de configuration ldconfig.ldr :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
132 - Noir Argenté Speckle Black Silver #000000  
133 132 Noir Doré Speckle Black Gold (Black Glitter) #000000  
75 - Noir Cuivré Speckle Black Copper #000000  
76 - Gris Bleuté Foncé Argenté Speckle Dark Bluish Grey Silver #635F61  

 

Couleur laiteuse ou phosphorescente

Couleurs existantes dans le fichier de configuration ldconfig.ldr :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
79 20 Blanc Laiteux Milky White (Nature) #FFFFFF  
21 294 Vert Phosphorescent Glow In Dark Opaque (Phosphorescent Green) #E0FFB0 Opaque
294 50 Blanc Phosphorescent Glow In Dark Trans (Phosphorescent White) #BDC6AD Transparent
329 329 Blanc Phosphorescent Glow In Dark White (White Glow) #F5F3D7 Opaque

 

Couleur caoutchouc

Il existe des couleurs prévues pour les pièces en caoutchouc ou en matière synthétique souple (tuyaux, pneus, etc...), leur donnant un aspect mat. Voir plus bas leur définition avec la méta-commande !COLOUR et l'option RUBBER.

Couleurs existantes dans le fichier de configuration ldconfig.ldr :


LDraw

LEGO
Couleur Nom
Français
Nom
Anglais
RGB Observation
65 - Caoutchouc Jaune Rubber Yellow #F5CD2F  
66 - Caoutchouc Transparent Jaune Rubber Trans Yellow #CAB000  
67 - Caoutchouc Transparent Rubber Trans Clear #FFFFFF  
256 - Caoutchouc Noir Rubber Black #212121  
273 - Caoutchouc Bleu Rubber Blue #0033B2  
324 - Caoutchouc Rouge Rubber Red #C40026  
350 - Caoutchouc Orange Rubber Orange #D06610  
375 - Caoutchouc Gris Clair Rubber Light Grey #C1C2C1  
406 - Caoutchouc Bleu Foncé Rubber Dark Blue #001D68  
449 - Caoutchouc Violet Rubber Purple #81007B  
490 - Caoutchouc Citron Vert Rubber Lime #D7F000  
496 - Caoutchouc Gris Bleuté Clair Rubber Light Bluish Gray #A3A2A4  
504 - Caoutchouc Argent Mat Rubber Flat Silver #898788  
511 - Caoutchouc Blanc Rubber White #FAFAFA  

 

Fichiers ldconfig.ldr et ldcfgalt.ldr

Ces fichiers de configuration des couleurs sont fournis avec les mises à jour officielles des pièces sur le site LDraw.org.

Entre deux mises à jour, ils peuvent être téléchargés à :
http://www.ldraw.org/library/official/LDConfig.ldr et
http://www.ldraw.org/library/official/LDCfgalt.ldr.

Ces fichiers doivent être mis dans le dossier d'installation de LDraw où se trouve la bibliothèque de pièces (par exemple : c:\lego\ldraw).

Exemple sous LDView avec ldconfig.ldr Exemple sous LDView avec ldcfgalt.ldr
renommé en fichier ldconfig.ldr

 

Couleur directe

Les couleurs directes sont des couleurs définies directement dans les fichiers par leurs valeurs RVB (RGB en anglais) en hexadécimal, précédé du code 0x2 pour définir le format. Seulement utilisé dans les pièces à motif.

Format de la couleur :

	0x2RRVVBB

Nota : Les valeurs hexadécimales utilisent les chiffres 0 à 9 et les lettres A à F qui doivent être en majuscules.

Exemple : 0x2A18B5C
Dans cet exemple la couleur beige sombre particulière est définie par ses 3 valeurs hexadécimales.

De nombreux programmes d'imagerie permettent à partir d'une photo ou d'un scan d'obtenir les valeurs à utiliser en cliquant avec l'outil "Pipette" :

Voir comme exemples les pièces 3960ps3.dat, 47753p01.dat, 47759p01.dat.

Couleur directe non officielle

Il existe d'autres modes de codage qui ont été utilisés sans avoir été officialisés, mais qui semblent supportés par LDView.

Format de la couleur :

	0x2RRGGBB: Couleur directe RGB opaque (officiel)
	0x3RRGGBB: Couleur directe RGB transparente
	0x4RGBRGB: Couleur directe RGB opaque tramée (défini par 2 couleurs 12-bit RGBRGB)
	0x5RGBxxx: Couleur directe RGB transparente tramée (xxx est ignoré et traité comme complètement transparent)
	0x6xxxRGB: Couleur directe RGB transparente tramée (xxx est ignoré et traité comme complètement transparent)
	0x7xxxxxx: Couleur directe invisible

 

Couleur personnalisée (!COLOUR)

Cette méta-commande spécifie les propriétés de codage d'une couleur LDraw unique.
Cette commande peut apparaître n'importe où dans un fichier LDR, mais cela est surement meilleur de la mettre dans l'en-tête.

Dans les éléments officiels de LDraw.org, !COLOUR apparaît dans le fichier de configuration ldconfig.ldr, pour définir l'ensemble de couleurs standards LDraw. Elle ne doit pas apparaître dans les fichiers de pièces et primitives officielles.

Importance

Il est recommandé que les définitions de couleur soit limitées en importance. La définition d'une couleur affecte la couleur à partir du point où elle apparaît, et va jusqu'à la fin du fichier. Les commandes précédent la définition de couleur ne sont pas affectés par cette définition. La définition de couleur disparait à la fin du fichier dans lequel elle apparaît, ce qui la rend effectivement moins importante. Les définitions de couleur restent actives dans les sous-fichiers.

Le fichier de configuration ldconfig.ldr, n'est pas affecté par ces règles d'importance, dans le sens où les définitions de ldconfig.ldr reprennent leurs effets après que le rendu soit terminé. Le programme relisant le fichier ldconfig.ldr.

Syntaxe

La commande complète doit apparaître sur une seule ligne. Elle peut être coupée dans le fichier pour plus de clarté.

Format de la ligne :

        0 !COLOUR name CODE x VALUE v EDGE e [ALPHA a] [LUMINANCE l]
           [ CHROME | PEARLESCENT | RUBBER | MATTE_METALLIC |
           METAL | MATERIAL [name <params> ...] </params> ]

Où les mots : CODE, VALUE, EDGE, ALPHA, LUMINANCE, CHROME, PEARLESCENT, RUBBER, MATTE_METALLIC, METAL et MATERIAL, sont des mots-clefs. Certaines clefs sont suivies par une valeur paramétrable. Les mots-clefs peuvent être en majuscules ou minuscules (ils sont insensibles à la casse).

Les paramètres numériques, en dehors des valeurs RGB de couleur, doivent être spécifiés en décimal.

Les valeurs RGB de couleur, doivent être spécifiées en hexadécimal, et avoir pour préfixe # ou 0x.

Les valeurs en octets, sont des entiers compris entre 0 et 255.

Les identifieurs sont des chaines de caractères. Les caractères autorisés sont les caractères alphanumériques de la table ASCII 7-bit : a-zA-Z0-9_. En plus, le premier caractère d'un identifieur doit être alphabétique (a-zA-Z). Les identifieurs ne sont pas sensibles à la casse.

Definition des Paramètres généraux :

Définition des paramètres de finition :

Uniquement un seul des paramètres suivants, peut être spécifié par couleur : CHROME, PEARLESCENT, RUBBER, MATTE_METALLIC, METAL et MATERIAL. Ils définissent tous la finition ou texture qui doit être appliqué à un objet durant son rendu. D'autres paramètres de finition pourront être définis par la suite.

 

Restrictions sur les couleurs de pièces

Il y a des restrictions sur l'usage des couleurs pour les pièces soumises à LDraw.org.

Les polygones (lignes de type 3 et 4) ne doivent pas utiliser la couleur 24.

Les lignes (lignes de type 2 et 5) ne devraient pas utiliser la couleur 16. Il y a 2 cas où l'utilisation de la couleur 16 pour les lignes est acceptable :

 

Tables de correspondance des couleurs

Il existe de nombreuses tables de correspondance des couleurs sur Internet, plus ou moins complètes, et plus ou moins à jour.

Cette correspondance est difficile à réaliser car il y a plusieurs paramètres :

Voici en empilement de briques 1x2 avec toutes les couleurs de 0 (noir en bas à gauche) à 511 (en haut) :

Gamme de couleurs sous
MLCad v3.20
Bords contrastés
Gamme de couleurs sous
LDView v4.0 Beta 1
Bords contrastés
Gamme de couleurs sous
LDView v4.0 Beta 1
Bords noirs

Voici également quelques tables ou informations complémentaires pouvant être utilisé :

 

Couleurs par gamme de Sets

Certaines gammes de Sets utilisent des gammes de couleurs personalisées.

Gamme Friends

           
30
Lavande Moyen
31
Lavande
326
Vert Olive
321
Azur Foncé
322
Azur Moyen
323
Eau Claire

Gamme Modulex

Les tableaux ci-dessous sont approximatifs et sujets à modification.

                 
0
Mx Noir
Mx Black
0x0227867E
Mx Vert d'Eau
Mx Aqua Green
47
Mx Transparent
Mx Clear
7
Mx Gris Clair
Mx Light Grey
0x027C9051
Mx Vert Olive
Mx Olive Green
0x02F47B30
Mx Orange
Mx Orange
0x0268AECE
Mx Bleu Pastel
Mx Pastel Blue
0x02B52C20
Mx Rouge
Mx Red
15
Mx Blanc
Mx White
                 
398
Mx Ocre Jaune
Mx Ocre Yellow
430
Mx Citron Vert
Mx Lemon
263
Mx Gris Ardoise
Mx Tile Gray
264
Mx Charbon de bois
Mx Charcoal Gray
510
Mx Jaune Clair
Mx Light Yellow (Buff)
418
Mx Vert Pastel
Mx Pastel Green
305
Mx Bleu Sarcelle
Mx Teal Blue
351
Mx Rose
Mx Pink
0x02365AB4
Bleu Gris ?
Mx Grey Blue ?

Nota : Ces couleurs ne sont pas toutes disponibles actuellement (04-2013) dans le fichier LDConfig.ldr, en conséquence tous les programmes ne visualisent pas ces couleurs. Utilisez LDView pour visualiser vos assemblages Modulex.

Le code des couleurs de la seconde partie du tableau a pour origine une recherche de Tore Eriksson (voir message du Forum LDraw.org : Re: Modulex parts library).

Voir : Créer modèle : Couleur des pièces Modulex.

Gamme standard avant/après 2004

En 2004 est apparu un changement dans la gamme des couleurs standards :

Avant 2004 :
     
6
Marron
7
Gris Clair
8
Gris Foncé
Après 2004 :
     
70
Brun Rougeâtre
71
Gris Bleuté Clair
72
Gris Bleuté Foncé

 

Méta-commandes spécifiques à des programmes tiers

Ces méta-commandes ne font pas partis du format standard de LDraw, mais ont été ajoutées pour d'autres programmes utilisant le format LDraw. Elles sont reconnus par certains programmes et peuvent être ignorées par d'autres programmes. Elles sont alors considérées comme des commentaires.

 

Les méta-commandes spécifiques MLCad

Ces méta-commandes ont été ajoutées pour le programmes MLCad, et peuvent être ignorées par d'autres programmes.

Méta-commandes d'étape de rotation de l'aperçu

Les commandes de rotation de l'aperçu, sont partiellement extraites de LdLite et ont été étendues, pour permettre plus de flexibilité. Généralement il s'agit d'une extension de la commande de base STEP de LDraw. Le dessin s'arrête après l'exécution de cette commande. Si vous voulez rendre visible la vue tournée, une commande de base STEP doit être utilisée immédiatement avant la commande d'étape de rotation.

Il y a quatre commandes différentes d'étape de rotation :

Etape de rotation relative (ROTSTEP REL)

Les étapes de rotation relatives sont basées sur l'angle des zones de visualisation individuelles. Le modèle est tourné de l'angle de rotation spécifié par rapport à l'angle de vue en cours.

Cela veut dire que si la vue montre le modèle en vue de face, et que l'étape de rotation va faire tourner le modèle de 90° dans le sens des aiguilles d'une montre, alors après l'exécution de la commande d'étape de rotation vous pourrez voir le modèle en vue de droite. Si l'angle de vue courante est la vue de dessus, alors après l'exécution de la commande, vous verrez encore le modèle en vue de dessus, mais tourné de 90°.

Syntaxe de cette commande :

    0 ROTSTEP <x-angle> <y-angle> <z-angle> [REL]

Le mot-clef REL est optionnel mais peut être spécifié pour plus de clarté.

x-angle, y-angle et z-angle sont les angles de rotation individuels pour les différents axes en degrés (de -360 à 360).

Etape de rotation incrémentale (ROTSTEP ADD)

Cette sorte d'étape de rotation tourne le modèle par l'angle de rotation spécifié en prenant l'angle de vue en cours en compte. La commande peut être utilisée de façon continue pour tourner le modèle d'un angle spécifique. Par exemple si cette commande est exécutée quatre fois sur la vue de face, et que le modèle tourne de 90° dans le sens des aiguilles d'une montre, sur l'axe Y, alors vous pourrez voir le modèle sur chacune des quatre faces.

Syntaxe de cette commande :

    0 ROTSTEP <x-angle> <y-angle> <z-angle> ADD

x-angle, y-angle et z-angle sont les angles de rotation individuels pour les différents axes en degrés (de -360 à 360).

Etape de rotation absolue (ROTSTEP ABS)

Le dernier type d'étape de rotation est similaire aux étapes de rotations relatives, mais il ignore l'angle de vue courante afin qu'après avoir exécuté cette commande chaque zone de vue montrera la même vue.

Syntaxe de cette commande :

    0 ROTSTEP <x-angle> <y-angle> <z-angle> ABS

x-angle, y-angle et z-angle sont les angles de rotation individuels pour les différents axes en degrés (de -360 à 360).

Fin d'étape de rotation (ROTSTEP END)

Cette commande retourne à l'angle de vue par défaut des vue individuelles.

Syntaxe de cette commande :

    0 ROTSTEP END

Calcul de la matrice de l'étape de rotation

Pour chaque étape de rotation (excepté END), la matrice de rotation est calculée par la formule suivante :

    wx, wy and wz sont les angles en radiants.
    s1 = sin(wx) s2 = sin(wy) s3 = sin(wz)
    c1 = cos(wx) c2 = cos(wy) c3 = cos(wz)

    a = c2 * c3
    b = -c2 * s3
    c = s2
    d = c1 * s3 + s1 * s2 * c3
    e = c1 * c3 - s1 * s2 * s3
    f = -s1 * c2
    g = s1 * s3 - c1 * s2 * c3
    h = s1 * c3 + c1 * s2 * s3
    i = c1 * c2

L'angle de vue résultant devant être utilisé par chaque vue individuelle est calculé da la façon suivante, ou “newmatrix” est la nouvelle matrice à utiliser par la vue, et est la matrice calculé pour la commande. La multiplication est la façon standard de multiplier les matrices.

Pour les étapes de rotation relatives la nouvelle matrice est :

    newmatrix = <view default matrix> * <rotation matrix>

Pour les étapes de rotation incrémentales la nouvelle matrice est :

    newmatrix = <current view matrix> * <rotation matrix>

Pour les étapes de rotation absolues la nouvelle matrice de vue est remplacée par la matrice de rotation :

    newmatrix = <rotation matrix>

 

Méta-commande d'image de fond (BACKGROUND)

La méta-commande d'image de fond est utilisée pour afficher une image dans le fond de la vue en mode aperçu. L'image elle-même est toujours derrière le modèle, afin que le modèle reste complètement visible.

MLCad affiche l'image après l'exécution de la commande. Une autre méta-commande "Background" remplace la commande "Background" précédente.

Format de la ligne :

    0 BACKGROUND <filename>

<filename> est le nom du fichier de l'image, avec son chemin. Il est recommandé de mettre le nom entre double guillemets ("), car ceci permet d'utiliser des espaces dans le nom, et évite donc des problèmes à l'ouverture du fichier.

 

Méta-commande d'échange de buffer (BUFEXCHG)

La méta-commande d'échange de buffer permet à l'utilisateur de créer une sorte d'animation comme instruction. Elle donne en plus une astuce pour faire des instructions de montage comme les vraies.

La méta-commande de buffer sauvegarde une image, ou rétablit cette image. L'image est prise à partir de la vue en cours, et la rétablit dans celle-ci. Par exemple, imaginez que vous voulez afficher où un moteur doit être mis dans le châssis de la voiture. Pour cela vous créez en premier une étape de construction avec le moteur visible, peut-être avec une flèche à l'endroit où le moteur doit être placé, et dans l'image suivante le moteur est mis la où il doit être. Cet effet peut être fait de la façon suivante :
En premier, vous créez le modèle complet sans le moteur. Ensuite vous sauvegardez une image de la vue en cours, puis vous mettez le moteur au-dessus du modèle. Lorsque vous passez à l'étape de construction suivante, vous retrouvez l'image précédemment sauvegardée, tout en réaffichant le moteur dans sa position finale.

Cette méta-commande est ignorée si le modèle contenant cette commande est utilisée comme sous-modèle.

Avec cette méta-commande de buffer vous pouvez sauvegarder jusqu'à vingt-six images indépendantes.

Syntaxe de cette méta-commande :

    0 BUFEXCHG <A-Z> STORE | RETRIEVE

Où :
<A-Z> est la lettre d'identification de chaque image.
STORE ... pour sauvegarder une image, ou
RETRIEVE ... pour recharger une image dans la vue.

 

Méta-commande fantôme (GHOST)

La méta-commande "fantôme" est une forme spéciale des autres commandes ou méta-commandes. Toutes les commandes et méta-commandes MLCad ou LDraw peuvent être mises dans une méta-commande fantôme. Pour cela, il suffit simplement de mettre “0 GHOST” au début de la ligne.

Quel est la raison d'être de ce type de méta-commande ?
MLCad traite le contenu de la méta-commande fantôme seulement si le modèle contenant cette méta-commande est le modèle principal. Si le modèle est un sous-modèle, ou simplement une pièce insérée dans le modèle, les lignes mises en fantôme sont simplement ignorées. C'est utile avec la méta-commande d'échange de buffer, et permet de montrer des instructions de montage détaillés d'une pièce lorsqu'elle est vue par elle-même, mais si elle est incluse comme sous-modèle ou pièce, ces étapes ne sont pas montrés. Sans cette méta-commande "fantôme" vous verriez des choses incontrôlées entre les méta-commandes d'échange de buffer puisque ces méta-commandes sont également ignorée dans les sous-modèles.
Vous pouvez trouver quelques exemples d'utilisation de cette méta-commande à l'adresse : http://www.lm-software.com/mlcad.

Syntaxe de cette méta-commande :

    0 GHOST <autre commande ldraw ou mlcad>

 

Méta-commande de groupe (GROUP)

Pour simplifier l'édition d'un modèle, MLCad permet de définir des groupes, permettant de réunir deux pièces, ou plus, dans une seule pièce virtuelle. Vous pouvez faire avec un groupe tout ce qui peut être fait avec une pièce normale, sauf les modifications de pièces seules. Pour garder l'information de groupe après avoir rechargé un modèle sauvegardé, MLCad utilise la méta-commande

Syntaxe de cette méta-commande :

    0 GROUP <n> <name>

Où :
<n> est le nombre de commandes qui appartiennent au groupe, et
<name> est le nom de ce groupe.

Les commandes appartenant au groupe sont identifiées par la méta-commande MLCAD BTG.

Vous ne pouvez pas utiliser des groupes récursifs (pas de groupe de groupe) !

 

Méta-commande de marque de groupe (MLCAD BTG)

La méta-commande de marque de groupe et utilisée lorsqu'une pièce appartient à un groupe. La ligne suivant cette méta-commande est sélectionnée pour être incluse dans le groupe identifié dans la méta-commande MLCAD BTG.

Syntaxe de cette méta-commande :

    0 MLCAD BTG <nom du groupe>
    x ...

Où :
<nom du groupe> est le nom du groupe a qui appartient la ligne qui suit la méta-commande. Cette ligne est mise dans le groupe spécifié par ce nom.

 

Méta-commande cacher (MLCAD HIDE)

Version minimum de MLCad pour utiliser cette méta-commande : 3.10.

Cette méta-commande est utilisée pour cacher temporairement des pièces durant l'édition d'un modèle. La méta-commande n'a aucun effet en mode aperçu, et sera ignoré dans ce mode.

Les pièces peuvent être cachées ou rendues visibles avec certaines options du menu ou certains boutons des barres d'outils de MLCad.

Syntaxe de cette méta-commande :

    0 MLCAD HIDE <autre commande ldraw ou mlcad>

 

Méta-commande de saut de section (MLCAD SKIP)

Cette méta-commande permet de sauter une certaine section du fichier LDraw de manière contrôlée par d'autres méta-commandes. Par conséquent deux commandes sont définies pour identifier le début et la fin de la section à sauter :

Syntaxe de cette méta-commande :

    0 MLCAD SKIP_BEGIN
    ...
    0 MLCAD SKIP_END

Tout ce qui se trouve entre les lignes de commandes SKIP, y compris les lignes SKIP elles-mêmes ne sont pas chargées en mémoire lors de la lecture du fichier.

Les méta-commandes de pseudo-pièces que nous allons voir un peu plus bas, utilisent cette méta-commande SKIP. Ces pseudo-pièces sont affichées par un processus spécial dans MLCad. Lorsque le modèle est sauvegardé, et visualisé par un programme de l'environnement LDraw non compatible avec les méta-commandes MLCad, ce sont les commandes entre les lignes SKIP qui sont utilisées.

 

Méta-commandes de point de rotation

MLCad supporte les points de rotation. Un point de rotation est un point d'origine zéro virtuel pour les rotations de primitive, pièce, ou sous-modèle. Les méta-commandes suivantes définissent ces points de rotation, et sauvegardent les paramètres du point de rotation actif du modèle.

Définition du point de rotation (ROTATION CENTER)

Syntaxe de cette méta-commande :

    0 ROTATION CENTER <x> <y> <z> <drapeau_modifiable> "<Nom>"

Où :
<x>, <y> et <z> sont les coordonnées du point de rotation dans le référentiel du modèle,
<drapeau_modifiable> est le chiffre 1 si la position du point est modifiable avec la souris, et 0 sinon,
<Nom> est un nom unique du point de rotation mis entre caractères apostrophes doubles (").

Un fichier peut contenir de multiples points de rotations. Il en existe un par défaut nommé Custom, qui peut-être renommé, et positionné par défaut à l'origine du modèle.

Dans un projet à modèles multiples, les points de rotations définis sont spécifiques à chaque sous-modèle.

Configuration du point de rotation courant (ROTATION CONFIG)

Chaque fois que MLCad sauvegarde un modèle dans un fichier, il sauvegarde également la configuration du point de rotation courant. Depuis que l'utilisateur peut définir de multiples points de rotations, et peut sélectionner un de ceux-ci, ou un des points prédéfinis, MLCad sauvegarde la sélection courante de l'utilisateur avec la méta-commande suivante :

Syntaxe de cette méta-commande :

    0 ROTATION CONFIG <Identifieur_point> <drapeau_visibilité>

Les valeurs plus petites ou égales à zéro de <Identifieur_point> font référence à des points de rotation prédéfinis :

Les valeurs supérieures à zéro de <Identifieur_point> désignent des points de rotation définis par l'utilisateur. 1 est le premier défini, 2 le second, ...
Les points de rotation eux-mêmes sont sauvegardés dans l'ordre. Cela veut dire que si l'identifieur du point de rotation (<Identifieur_point>) est 2, la seconde ligne de commande 0 ROTATION CENTER sera utilisée.

<drapeau_visibilité> mis à 0 si le point de rotation n'est pas affiché (non visible) dans les zones de visualisation, ou 1 s'il doit être affiché, lorsque qu'une pièce est sélectionnée.

Méta-commande de point de rotation réservé (ROTATION AXLE)

La méta-commande suivante est réservée pour une future définition d'axe de rotation :

    0 ROTATION AXLE

 

Méta-commande de pseudo-pièce Ressort (MLCAD SPRING)

Version minimum de MLCad pour utiliser cette méta-commande : 3.00.

Syntaxe de cette méta-commande :

    0 MLCAD SPRING <c> <pos> <rot> <H> <R> <D> <SD> <TR> <BR>

Après cette méta-commande se trouve une section SKIP, contenant les commandes LDraw standards pour visualiser la pseudo-pièce dans des programmes de l'environnement LDraw non compatibles avec les méta-commandes MLCad.

L'algorithme utilisé par MLCad pour générer le ressort est basé sur l'utilitaire "Spring2dat" de Marc Klein, qui a, avec bonté, fourni les sources pour cela.

 

Méta-commande de pseudo-pièce Tuyau Flexible (MLCAD FLEXHOSE)

Version minimum de MLCad pour utiliser cette méta-commande : 3.00.

Syntaxe de cette méta-commande :

    0 MLCAD FLEXHOSE <c> <pos> <rot> <b> <bcp> <e> <ecp> <n> <fpn> <ipn> <dl>

Nota : Les noms de fichiers ne sont pas mis entre guillemets, et ne doivent pas contenir de caractère espace.

Après cette méta-commande se trouve une section SKIP, contenant les commandes LDraw standards pour visualiser la pseudo-pièce dans des programmes de l'environnement LDraw non compatibles avec les méta-commandes MLCad.

L'algorithme utilisé par MLCad pour générer le tuyau flexible est basé sur un algorithme de Chris Daelman, qui a, avec bonté, fourni les sources pour cela.

 

Méta-commande de pseudo-pièce Courroie (MLCAD RUBBER_BELT)

Version minimum de MLCad pour utiliser cette méta-commande : 3.00.

Syntaxe de cette méta-commande :

    0 MLCAD RUBBER_BELT <c> <pos> <rot> <XD> <YD> <R1> <R2> <D> <P> <CY>

Après cette méta-commande se trouve une section SKIP, contenant les commandes LDraw standards pour visualiser la pseudo-pièce dans des programmes de l'environnement LDraw non compatibles avec les méta-commandes MLCad.

L'algorithme utilisé par MLCad pour générer la courroie est basé sur un algorithme de Philo, développé à partir de l'utilitaire "Spring2dat" de Marc Klein, qui a, avec bonté, fourni les sources pour cela.

 

Méta-commande de pseudo-pièce Flèche (MLCAD ARROW)

Version minimum de MLCad pour utiliser cette méta-commande : 3.10.

Syntaxe de cette méta-commande :

    0 MLCAD ARROW <c> <pos> <rot> <w1> <w2> <L1> <L2> <D> <R> <T> <S> <CP> <CI>

Après cette méta-commande se trouve une section SKIP, contenant les commandes LDraw standards pour visualiser la pseudo-pièce dans des programmes de l'environnement LDraw non compatibles avec les méta-commandes MLCad.

L'algorithme utilisé par MLCad pour générer les flèches est basé sur un algorithme de Willy Tschager.

 

Méta-commande de pseudo-pièce Plate (MLCAD PLATE)

Version minimum de MLCad pour utiliser cette méta-commande : 3.10.

Syntaxe de cette méta-commande :

    0 MLCAD PLATE <c> <pos> <rot> <W> <L> <H>

Après cette méta-commande se trouve une section SKIP, contenant les commandes LDraw standards pour visualiser la pseudo-pièce dans des programmes de l'environnement LDraw non compatibles avec les méta-commandes MLCad.

Nota : Il n'y a pas de paramètre "avec" ou "sans" tenons dans cette méta-commande, ce qui fait qu'une pseudo-pièce créée "sans" tenons se visualise "avec" après sauvegarde sous MLCad, et "sans" avec LDView par exemple.

L'algorithme utilisé par MLCad pour générer les plates ou briques est basé sur un algorithme de Tore Eriksson, qui a, avec bonté, fourni les sources pour cela.

 

Les méta-commandes spécifiques LSynth

Ces méta-commandes sont utilisées par le programme LSynth, qui est un générateur de pièces souples qui peut-être incorporé dans MLCad.

Liste des méta-commandes spécifiques Version 2 :

    0 SYNTH BEGIN CHAIN <c>
    0 SYNTH BEGIN ELECTRIC_CABLE <c>
    0 SYNTH BEGIN FIBER_OPTIC_CABLE <c>
    0 SYNTH BEGIN FLEX_CABLE <c>
    0 SYNTH BEGIN FLEX_SYSTEM_HOSE <c> (ex : SYNTH BEGIN FLEXIBLE_HOSE <c>)
    0 SYNTH BEGIN FLEXIBLE_AXLE <c>
    0 SYNTH BEGIN PLASTIC_TREAD <c>
    0 SYNTH BEGIN PNEUMATIC_HOSE <c>
    0 SYNTH BEGIN RIBBED_HOSE <c>
    0 SYNTH BEGIN RIGID_HOSE <c>
    0 SYNTH BEGIN RUBBER_BAND <c>
    0 SYNTH BEGIN RUBBER_TREAD <c>

Liste des méta-commandes spécifiques Version 3 :

    0 SYNTH BEGIN ELECTRIC_NXT_CABLE <c>
    0 SYNTH BEGIN ELECTRIC_POWER_FUNCTIONS_CABLE <c>
    0 SYNTH BEGIN ELECTRIC_RCX_CABLE <c>
    0 SYNTH BEGIN FIBER_OPTICS_CABLE <c>
    0 SYNTH BEGIN HOSE_FLEXIBLE <c>
    0 SYNTH BEGIN MINIFIG_CHAIN <c>
    0 SYNTH BEGIN STRING_HOSE <c>
    0 SYNTH BEGIN TECHNIC_AXLE_FLEXIBLE <c>
    0 SYNTH BEGIN TECHNIC_FLEX-SYSTEM_CABLE <c>
    0 SYNTH BEGIN TECHNIC_FLEX-SYSTEM_HOSE <c>
    0 SYNTH BEGIN TECHNIC_PNEUMATIC_HOSE <c>
    0 SYNTH BEGIN TECHNIC_RIBBED_HOSE <c>
    0 SYNTH BEGIN RUBBER_BAND <c>
    0 SYNTH BEGIN RUBBER_BELT <c>
    0 SYNTH BEGIN TECHNIC_CHAIN_LINK <c>
    0 SYNTH BEGIN TECHNIC_CHAIN_TREAD <c>
    0 SYNTH BEGIN TECHNIC_CHAIN_TREAD_38 <c>
    0 SYNTH BEGIN TECHNIC_TREAD <c>
    0 SYNTH BEGIN PLI_ELECTRIC_NXT_CABLE_20CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_NXT_CABLE_35CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_NXT_CABLE_50CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_ROT_SENSOR <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_LIGHT_SENSOR <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_CABLE_13CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_CABLE_17CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_CABLE_23CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_CABLE_40CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_CABLE_60CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_CABLE_140CM <c>
    0 SYNTH BEGIN PLI_ELECTRIC_RCX_CABLE_328CM <c>
    0 SYNTH BEGIN PLI_HOSE_FLEXIBLE_8.5L_WITHOUT_TABS <c>
    0 SYNTH BEGIN PLI_HOSE_FLEXIBLE_8.5L_WITH_TABS <c>
    0 SYNTH BEGIN PLI_MINIFIG_CHAIN_21 <c>
    0 SYNTH BEGIN PLI_TECHNIC_AXLE_FLEXIBLE_7 <c>
    0 SYNTH BEGIN PLI_TECHNIC_AXLE_FLEXIBLE_11 <c>
    0 SYNTH BEGIN PLI_TECHNIC_AXLE_FLEXIBLE_12 <c>
    0 SYNTH BEGIN PLI_TECHNIC_AXLE_FLEXIBLE_14 <c>
    0 SYNTH BEGIN PLI_TECHNIC_AXLE_FLEXIBLE_16 <c>
    0 SYNTH BEGIN PLI_TECHNIC_AXLE_FLEXIBLE_19 <c>
    0 SYNTH BEGIN PLI_TECHNIC_TREAD <c>

Liste des méta-commandes Version 2 et version 3 :

    0 SYNTH SYNTHESIZED BEGIN
    0 SYNTH SYNTHESIZED END
	
    0 SYNTH INSIDE
    0 SYNTH OUTSIDE
    0 SYNTH CROSS
    0 SYNTH SHOW
    0 SYNTH HIDE

    0 SYNTH END

Nota : La liste des méta-commandes LSynth n'est pas limitée, et peut être augmentée par les utilisateurs pour ajouter de nouvelles synthétisations particulières. Voir sur ma page : LSynth : Format général des commandes, ma liste plus complète avec quelques exemples sur l'usage de ces méta-commandes.

 

Les méta-commandes spécifiques LPub

Ces méta-commandes sont utilisées par LPub, un utilitaire de l'environnement LDraw qui permet de créer des manuels d'instructions pour des créations personnelles de modèles fait avec MLCad par exemple.

Nota : Pour respecter le standard actuel ces méta-commandes LPUB, peuvent (doivent) être changées en !LPUB.

LPub utilise un certain nombre de méta-commandes standards, MLCad, et LSynth.

Méta-commandes standards utilisées par LPub

    0 CLEAR
    0 STEP

Méta-commandes MLCad utilisées par LPub

    0 ROTSTEP
    0 BUFEXCHG
    0 GHOST
    0 GROUP

Méta-commande LSynth utilisées par LPub

    0 SYNTH

Méta-commandes spécifiques LPub de base

    0 LPUB PLI BEGIN SUB
    0 LPUB PLI BEGIN IGN
    0 PLIST END

    0 BI BEGIN GRAYED
    0 BI END
    0 LPUB GROUP REMOVE
    0 LPUB INCLUDE filename

Méta-commandes LPub Page

    0 LPUB PAGE SIZE width height
    0 LPUB PAGE PLI (YES|NO)

    0 LPUB PAGE BACKGROUND TRANS
    0 LPUB PAGE BACKGROUND color
    0 LPUB PAGE BACKGROUND [STRETCH] png_image_name

    0 LPUB PAGE BORDER SQUARE color thickness
    0 LPUB PAGE BORDER ROUND color thickness corner_radius
    0 LPUB PAGE BORDERLESS
    0 LPUB PAGE BORDER MARGINS x_margin y_margin

    0 LPUB PAGE NUMBER MARGINS x_margin y_margin
    0 LPUB PAGE INSERT pngimage_name left top

Méta-commandes LPub Assembly

    0 LPUB ASSEM MARGINS x_margin y_margin

    0 LPUB ASSEM PLACEMENT corner PAGE
    0 LPUB ASSEM PLACEMENT edge justification PAGE
    0 LPUB ASSEM PLACEMENT CENTER PAGE
    0 LPUB ASSEM PLACEMENT OFFSET x_offset y_offset

Méta-commandes LPub PLI Layout

    0 LPUB PLI PART MARGINS x y
    0 LPUB PLI MARGINS x y

    0 LPUB PLI PLACEMENT CENTER PAGE
    0 LPUB PLI PLACEMENT edge PAGE
    0 LPUB PLI PLACEMENT CENTER ASSEM INSIDE
    0 LPUB PLI PLACEMENT corner ASSEM INSIDE
    0 LPUB PLI PLACEMENT edge ASSEM INSIDE
    0 LPUB PLI PLACEMENT corner ASSEM OUTSIDE
    0 LPUB PLI PLACEMENT edge justification ASSEM OUTSIDE
    0 LPUB PLI PLACEMENT OFFSET x_offset y_offset

    0 LPUB PLI BORDER SQUARE color thickness
    0 LPUB PLI BORDER ROUND color thickness radius
    0 LPUB PLI BORDERLESS
    0 LPUB PLI BORDER MARGINS x y

    0 LPUB PLI BACKGROUND TRANS
    0 LPUB PLI BACKGROUND color
    0 LPUB PLI BACKGROUND [STRETCH] fname

    0 LPUB PLI CONSTRAIN AREA
    0 LPUB PLI CONSTRAIN SQUARE
    0 LPUB PLI CONSTRAIN WIDTH width
    0 LPUB PLI CONSTRAIN HEIGHT height
    0 LPUB PLI CONSTRAIN COLS cols

Méta-commandes LPub Callout

    0 LPUB CALLOUT MARGINS x y
    0 LPUB CALLOUT HORIZONTAL
    0 LPUB CALLOUT VERTICAL
    0 LPUB CALLOUT SEPARATOR seperator_color separator_width

    0 LPUB CALLOUT BORDER SQUARE color thickness
    0 LPUB CALLOUT BORDER ROUND color thickness radius
    0 LPUB CALLOUT BORDER MARGINS x y
    0 LPUB CALLOUT BORDERLESS

    0 LPUB CALLOUT BACKGROUND TRANS
    0 LPUB CALLOUT BACKGROUND color
    0 LPUB CALLOUT BACKGROUND [STRETCH] fname 

    0 LPUB CALLOUT BEGIN
    0 LPUB CALLOUT END
    0 LPUB CALLOUT DIVIDER

    0 LPUB CALLOUT INSTANCE_COUNT MARGINS x y
    0 LPUB CALLOUT INSTANCE_COUNT PLACEMENT corner CALLOUT preposition
    0 LPUB CALLOUT INSTANCE_COUNT PLACEMENT edge CALLOUT INSIDE
    0 LPUB CALLOUT INSTANCE_COUNT PLACEMENT horiz justification CALLOUT OUTSIDE
    0 LPUB CALLOUT INSTANCE_COUNT PLACEMENT vert justification CALLOUT OUTSIDE

    0 LPUB CALLOUT PLACEMENT CENTER PAGE
    0 LPUB CALLOUT PLACEMENT corner PAGE
    0 LPUB CALLOUT PLACEMENT edge PAGE
    0 LPUB CALLOUT PLACEMENT CENTER ASSEM INSIDE
    0 LPUB CALLOUT PLACEMENT corner ASSEM INSIDE
    0 LPUB CALLOUT PLACEMENT edge ASSEM INSIDE
    0 LPUB CALLOUT PLACEMENT corner ASSEM OUTSIDE
    0 LPUB CALLOUT PLACEMENT edge justification ASSEM OUTSIDE
    0 LPUB CALLOUT PLACEMENT OFFSET x_offset y_offset

    0 LPUB CALLOUT POINTER BASE base
    0 LPUB CALLOUT POINTER placement loc assem_x assem_y

Méta-commandes LPub Step Number

    0 LPUB STEP_NUMBER PLACEMENT CENTER PAGE
    0 LPUB STEP_NUMBER PLACEMENT corner PAGE
    0 LPUB STEP_NUMBER PLACEMENT edge PAGE
    0 LPUB STEP_NUMBER PLACEMENT CENTER ASSEM INSIDE
    0 LPUB STEP_NUMBER PLACEMENT corner ASSEM INSIDE
    0 LPUB STEP_NUMBER PLACEMENT edge ASSEM INSIDE
    0 LPUB STEP_NUMBER PLACEMENT corner PLI
    0 LPUB STEP_NUMBER PLACEMENT edge justification PLI
    0 LPUB STEP_NUMBER PLACEMENT corner ASSEM OUTSIDE
    0 LPUB STEP_NUMBER PLACEMENT edge justification ASSEM OUTSIDE

Méta-commandes LPub Multi-Step Number

    0 LPUB MULTI_STEP BEGIN
    0 LPUB RESERVE factor
    0 LPUB MULTI_STEP DIVIDER
    0 LPUB MULTI_STEP END

    0 LPUB MULTI_STEP HORIZONTAL
    0 LPUB MULTI_STEP VERTICAL
    0 LPUB MULTI_STEP SEPARATOR thickness color
    0 LPUB MULTI_STEP MARGINS x_margin y_margin

Méta-commandes LPub Bill Of Material

    0 LPUB BOM PART MARGINS x y
    0 LPUB BOM MARGINS x y
    0 LPUB BOM BEGIN IGN
    0 LPUB BOM END

    0 LPUB BOM BORDER SQUARE color thickness 
    0 LPUB BOM BORDER ROUND color thickness radius 
    0 LPUB BOM BORDERLESS
    0 LPUB BOM BORDER MARGINS x y

    0 LPUB BOM BACKGROUND TRANS
    0 LPUB BOM BACKGROUND color
    0 LPUB BOM BACKGROUND [STRETCH] fname

    0 LPUB BOM CONSTRAIN AREA
    0 LPUB BOM CONSTRAIN SQUARE
    0 LPUB BOM CONSTRAIN WIDTH width
    0 LPUB BOM CONSTRAIN HEIGHT height
    0 LPUB BOM CONSTRAIN COLS cols

    0 LPUB BOM SORT WIDTH
    0 LPUB BOM PACK SUBS

Nota : Cette liste est ancienne (v2.x de LPub), et n'est plus à jour. Certaines méta-commandes ont changées et beaucoup ont été ajoutées. Voir sur mes pages : Liste des méta-commandes reconnues par LPub et Liste des méta-commandes reconnues par LPub3D (la plus récente), une liste plus complète avec quelques explications sur l'usage de ces méta-commandes.

 

Les méta-commandes spécifiques LdLite

LdLite est un visualisateur de fichier LDraw.

    0 COLOR
    0 COLOUR
    0 TRANSLATE
    0 ROTATE
    0 SCALE
    0 TRANSFORM
    0 COLORNAME
    0 POINT
    0 MATRIX
    0 CMDLINE <line>

 

Les méta-commandes spécifiques SR 3D Builder

SR 3D Builder est un programme de création de modèles, gérant, entre autre, la cinématique des pignons. Son format de fichier (.L3B) est proche du format LDraw avec les méta-commandes particulières suivantes :

Gestion du point de vue :

    0 WORLD
    0 CENTRE
    0 LOOKAT
    0 ROTANGLE
    0 ZOOM

Gestion des groupes :

    0 GROUPLIST   
    0 GR Name #
    0 ENDGROUP
    0 GROUP  #

Nota : La gestion des groupes de SR 3D Builder rentre en conflit avec l'utilisation des groupes dans MLCad. Il faut dans ce cas mettre en commentaire les lignes comportant des déclarations de groupe.

Courroie :

    0 BELT # PartFile1.DAT x1 y1 z1 PartFile1.DAT x2 y2 z2

Tuyaux souples (exemple) :

    0 SPLINE 0 7 3 0.5 4 -1
    0 -15 0 0 -1 0 0 
    0 15 0 -123 1 0 0 
    0 ENDSPLINE
    1  7 0 0 0 1 0 0 0 1 0 0 0 1 3749.DAT
    1  7 0 0 0 1 0 0 0 1 0 0 0 1  0.70554.DAT

Nota : La dernière ligne a un format non compatible avec le format LDraw et génèrera un message d'erreur.

 

Les méta-commandes spécifiques L3P

L3P est un utilitaire permettant de rendre apte un fichier LDraw a passer dans le programme de rendu POV-Ray.

    0 L3P IFPOV
    0 L3P IFNOTPOV
    0 L3P ELSEPOV
    0 L3P ENDPOV 

 

Les méta-commandes spécifiques POV-Ray

POV-Ray est un programme de rendu réaliste d'objets 3D, et n'est pas spécifique aux modèles LDraw.

L'inclusion de méta-commandes POV-Ray encapsulées dans les pièces de la bibliothèque LDraw officielle n'est pas autorisé, principalement en raison de l'évolution de la syntaxe de ces commandes qui pourraient occasionner des erreurs dans l'avenir.

Par contre ces méta-commandes ne sont pas interdites dans le format LDraw complet, ou peuvent être mises dans des fichiers séparés non officiels.

 

Les méta-commandes spécifiques LDraw Switch

LDraw Switch est un projet de créer des alternatives de pièce ou des variantes de modèle dans un fichier LDraw pour alléger visuellement les très gros modèles.

    0 !LDSWITCH DEFINE SWITCH xxxx Do
    0 !LDSWITCH DEFINE xxxx Undo
    0 !LDSWITCH SWITCH xxxx
    0 !LDSWITCH SWITCH xxxx Do
    0 !LDSWITCH CASE Do
    0 !LDSWITCH CASE Undo
    0 !LDSWITCH END

 

Les méta-commandes spécifiques LDPattern

LDPattern est un programme de création de motif de pièce interactif. Il sauvegarde au format LDraw, et ajoute une ligne définissant l'image de référence avec son facteur d'échelle et sa position. Exemple :

    0 !LDPatternImage 50 50 -55 0 C:\LEGO\LDPattern\168145g.jpg

 

Les méta-commandes spécifiques LDCad

LDCad est un éditeur de modèle. Il sauvegarde au format LDraw, et utilise sa propre syntaxe pour les pièces souples, ou pour d'autres informations :

    0 !LDCAD MARKER

    0 !LDCAD GROUP_DEF
    0 !LDCAD GROUP_NXT
    0 !LDCAD GROUP_OBJ

    0 !LDCAD SCRIPT
    0 !LDCAD CONTENT
    0 !LDCAD GENERATED

    0 !LDCAD PATH_POINT
    0 !LDCAD PATH_CAP
    0 !LDCAD PATH_ANCHOR
    0 !LDCAD PATH_SKIN
    0 !LDCAD PATH_LENGTH

    0 !LDCAD SPRING_POINT
    0 !LDCAD SPRING_CAP
    0 !LDCAD SPRING_ANCHOR
    0 !LDCAD SPRING_SECTION

    0 !LDCAD SNAP_CLEAR
    0 !LDCAD SNAP_INCL
    0 !LDCAD SNAP_CYL
    0 !LDCAD SNAP_CLP
    0 !LDCAD SNAP_FGR
    0 !LDCAD SNAP_GEN
    0 !LDCAD SNAP_SPH

Voir : Méta-commandes LDCad pour une information plus complète.

 

Les méta-commandes spécifiques à LDView

LDView est un visualiseur de pièce ou modèle LDraw. Il utilise des méta-commandes spécifiques, pour ne pas calculer les dimensions de la vue avec certaines pièces (en premier les circuits de trains lorsqu'on veut se focaliser sur le train lui-même) :

    0 !LDVIEW BBOX_IGNORE NEXT

    0 !LDVIEW BBOX_IGNORE BEGIN
    0 !LDVIEW BBOX_IGNORE END

Avec NEXT la prochaine ligne de géométrie est ignorée dans le calcul. Avec BEGIN toutes les lignes sont ignorées jusqu'à la ligne comportant END.

 

Les méta-commandes spécifiques à LDForge

LDForge est un éditeur et visualiseur de fichier LDraw. Il a quelques commandes spécifiques.

Définition d'un point ou sommet :

    0 !LDFORGE VERTEX <couleur> <X> <Y> <Z>

Définition d'une image de fond :

    0 !LDFORGE OVERLAY <fichier> <Vue (0=top, 1=...)> <Xorigine> <Yorigine> <Xdimension> <Ydimension>

Définition de primitive circulaire (exemple) :
Nota : Ces éléments ont été supprimés avec la version v0.2 du 10 juillet 2013.

    0 !LDFORGE RADIAL CIRCLE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
    0 !LDFORGE RADIAL CYLINDER <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
    0 !LDFORGE RADIAL DISC <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
    0 !LDFORGE RADIAL DISCNEGATIVE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
    0 !LDFORGE RADIAL RING <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
    0 !LDFORGE RADIAL CONE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
    0 !LDFORGE RADIAL CIRCLE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>

 

Les méta-commandes spécifiques à Bricksmith

Bricksmith est un modeleur utilisant le format LDraw. Les commandes spécifiques qui suivent sont utilisées dans un fichier related.ldr pour associer des pièces parents avec d'autres pièces liées (jante avec pneu par exemple).

Précédent la liste de pièces parent similaires :

    0 !PARENT

Précédent la liste de pièces enfant similaires :

    0 !CHILD nom

Nota : Il peut y avoir plusieurs listes enfant pour un même parent : Left Pane (volet gauche), Right Pane (volet droit), pour une fenêtre.

 

Les méta-commandes spécifiques à LDPartEditor

LDPartEditor est un éditeur de pièce LDraw. Il a quelques commandes spécifiques.

Définition de tache :

    0 !LPE TODO <tache>

Définition de point :

    0 !LPE VERTEX <x> <y> <z>

Définition de construction CSG :

    0 !LPE CSG_EPSILON <Tolérance supérieure à 0 (1E-6 par défaut)>
    0 !LPE CSG_QUALITY <Qualité circulaire entre 1 et 48 (16 par défaut)>

    0 !LPE CSG_CUBOIDE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
    0 !LPE CSG_ELLIPSOIDE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
    0 !LPE CSG_QUAD <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
    0 !LPE CSG_CYLINDER <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
    0 !LPE CSG_CONE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
    0 !LPE CSG_CIRCLE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>

    0 !LPE CSG_UNION <nom_source1> <nom_source2> <nom_cible>
    0 !LPE CSG_DIFFERENCE <nom_source1> <nom_source2> <nom_cible>
    0 !LPE CSG_INTERSECTION <nom_source1> <nom_source2> <nom_cible>

    0 !LPE CSG_COMPILE <nom_source>

Définition d'image de fond :

    0 !LPE PNG <x> <y> <z> <Rx> <Ry> <Rz> <Sx> <Sy> <Sz> <chemin+nom_fichier>

 

Localisation (Traduction)

La localisation est la possibilité de traduire le nom des pièces dans le système LDraw, en particulier, pour ceux qui lisent ces lignes, en Français.

Nota : Pour le français tout n'a pas encore été traduit, en particulier les descriptions de pièces, et les mots-clefs, en raison du travail laborieux que cela nécessite.

Le programme de gestion des traductions s'appelle LDTranslator.

Source de ce chapitre : Localisation Guideline (en Anglais).

 

Format

Les fichiers de traduction sont encodés avec le format UTF-8.

Chaque ligne se termine par les caractères <CR><LF>. Voir Restrictions sur le format des fichiers de pièces.

 

Fichiers et Dossiers

Les fichiers de traduction sont :

Le dossier de sauvegarde est :

 

Contenu des fichiers de traduction

En-tête des fichiers de traduction :

 0 LDraw.org Configuration File
 0 Name: colours.txt
 0 Author: LDraw.org
 0 !LDRAW_ORG Configuration UPDATE 2009-09-05
 0 !TRANSLATION COLOURS de-DE
 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt

Corps des fichiers de traduction :

 "<langage neutre>" = "<langage traduit>"
 ...

 

Exemples

Il n'est pas obligatoire d'avoir une traduction pour chaque entrée, car il est parfois difficile de traduire certains mots-clefs ou désignation de pièces, et cela minimise la taille des fichiers.

Les applications doivent utiliser les traductions uniquement pour afficher une sentence à l'utilisateur et jamais pour décider une action basée sur cette traduction.

Exemple de fichier colours.txt :

0 LDraw.org Configuration File
0 Name: colours.txt
0 Author: LDraw.org
0 !LDRAW_ORG Configuration UPDATE 2009-09-05
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !TRANSLATION COLOURS fr

"Black" = "Noir"
"Blue" = "Bleu"
"Green" = "Vert"
"Dark_Turquoise" = "Turquoise_foncé"
"Red" = "Rouge"
"Dark_Pink" = "Rose_foncé"

Exemple de fichier parts.txt :

0 LDraw.org Configuration File
0 Name: parts.txt
0 Author: LDraw.org
0 !LDRAW_ORG Configuration UPDATE 2009-09-05
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !TRANSLATION PARTS de-DE

"Animal Bat Wing 9 x 9 with Axle" = "Tier Fledermaus Flügel 9 x 9 mit Achse"
"Animal Bird" = "Tier Vogel"
"Animal Bird with Parrot Pattern" = "Tier Vogel mit Papagei Dekor"
"Animal Cat Crouching" = "Tier Katze kauernd"
"~Technic Pneumatic Cylinder with 2 Inlets Medium Slide" = "~Technik Pneumatik Zylinder mit 2 Einlässen Mittel Gleiter"
"~Moved to 75974" = "~Verschoben nach 75974"
"_Brick 2 x 2 White" = "_Stein 2 x 2 Weiss"
"Brick 1 x 1 with Blue \"0\" Pattern" = "Stein 1 x 1 mit Blau \"0\" Dekor"

Nota : Les caractères spéciaux '~' (tilde) et '_' (souligné) en début de sentence, doivent être également présents dans la traduction.

Exemple de fichier categories.txt :

0 LDraw.org Configuration File
0 Name: categories.txt
0 Author: J.C. Tchang [tchang]
0 !LDRAW_ORG Configuration UPDATE 2009-09-05
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !TRANSLATION CATEGORIES fr

"Animal" = "Animal"
"Antenna" = "Antenne"
"Arch" = "Arche"

Exemple de fichier keywords.txt :

0 LDraw.org Configuration File
0 Name: keywords.txt
0 Author: LDraw.org
0 !LDRAW_ORG Configuration UPDATE YYYY-MM-DD
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !TRANSLATION KEYWORDS fr

"cone" = ""
"Colored Globe" = "Globe coloré"
"Coffee" = "Café"

 

Emplacement des fichiers

Voici l'emplacement où doivent se trouver par défaut les différents fichiers LDraw.

 

Emplacement des fichiers de primitives et de pièces

Les différents fichiers de la bibliothèque de pièces LDraw sont placés dans deux dossiers et trois sous-dossiers, à partir du dossier d'installation de LDraw :

 

Emplacement des fichiers de modèles

Emplacement des différents modèles que vous construisez.

A partir du dossier d'installation de LDraw, les fichiers sont dans :

Conseil personnel (J.C. Tchang) : J'utilise une arborescence de fichiers pour les modèles officiels, faits à partir des manuels d'instructions du style :
c:\lego\model_off\8\8865-88\v1\8865-88-alt.mpd pour sauvegarder le modèle alternatif de la boite "Auto Chassis" de 1988. Le sous-dossier \8 pour série 8000 sert à limiter le nombre de dossiers sous \model_off, et \v1 la version du fichier (il peut y en avoir plusieurs si j'ai récupéré un modèle disponible sur Internet, ou si j'ai repris le modèle en faisant évoluer ma technique de construction.

J'utilise une autre arborescence pour les modèles de ma création (MOC= Ma propre création) du style :
c:\lego\model_moc\categorie\sous_categorie\model\v1\model.mpd.

 

Tableau récapitulatif des différents fichiers LDraw

L'identification des différents fichiers DAT de la bibliothèque de pièces LDraw se fait en fonction du format de leur nom de fichier, et le caractère initial de la description de la pièce. Dans le tableau qui suit, dans la colonne "Nom", "n" indique un chiffre, et "x" une lettre. Le nombre de caractère indiqué peut être en pratique variable.

Type de fichier Titre
(Description)
Nom
(Numéro)
Sous-dossier
de LDraw
Primitive   nnnn.dat, xxxx.dat, ... \P
Primitive de tenon, résolution standard   studnnn.dat \P
Primitive de tenon, résolution basse Termine par : (Fast-Draw) stu2nnn.dat \P\8
Primitive de groupe de tenons   stugnnn.dat \P
Primitive circulaire de haute résolution   48\nnnn.dat, 48\xxxx.dat, ... \P\48
Partie de pièce   s\nnnnsnn.dat \PARTS\S
Partie de motif de pièce   s\nnnnpsn.dat \PARTS\S
Partie de pièce souple   nnnna.dat, nnnnb.dat, ... \PARTS
Pièce simple   nnnn.dat \PARTS
Pièce imparfaite, mais admissible en officielle Termine par : (Needs Work) nnnn.dat \PARTS
Pièce simple à numéro inconnu (avant 2/2010)   xnnnn.dat \PARTS
Pièce simple à numéro inconnu (depuis 2/2010)   unnnn.dat \PARTS
Pièce Alias (1 pièce, 2 numéros de moule) Débute par : = nnnn.dat \PARTS
Texture, motif de pièce ou autocollant (Image PNG)   nnnn.png \PARTS\TEXTURES
(LDView, LDCad)\TEXTURES (LD Part Editor)
Autocollant à 1 seul motif Débute par : Sticker, et ne contient pas Pattern nnnnnnn.dat
00nnnn.dat (SKU court)
\PARTS
Autocollant à plusieurs motifs Débute par : Sticker, et ne contient pas Pattern nnnnnnna.dat, nnnnnnnb.dat, ...
00nnnna.dat, 00nnnnb.dat, ... (SKU court)
\PARTS
Autocollant "en forme" du support Débute par : Sticker, Contient : (Formed), et ne contient pas Pattern nnnnnnnacnn.dat, nnnnnnnbcnn.dat, ...
00nnnnacnn.dat, 00nnnnbcnn.dat, ... (SKU court)
\PARTS
Autocollant à numéro inconnu Débute par : Sticker, et ne contient pas Pattern snn.dat \PARTS
Pièce à motif Termine par : Pattern nnnnpnn.dat \PARTS
Pièce à double injection (2 couleurs ou 2 matériaux différents)   nnnnpnn.dat \PARTS
Pièce souple monobloc "en forme" Contient : (Formed) nnnncnn.dat \PARTS
Pièce "en position" Contient : (Open), (Open Flat), (Neutral Position), ... nnnn-fn.dat \PARTS
Pièce composite assemblée Contient : (Shortcut) nnnncnn.dat \PARTS
Pièce composite assemblée "en position" Contient : (Contracted), (Retracted), ... nnnncnn-fn.dat \PARTS
Pièce simple avec autocollant(s) Contient : (Shortcut) nnnndnn.dat \PARTS
Pièce composite avec autocollant(s) Contient : (Shortcut) nnnncnndnn.dat \PARTS
Elément de pièce composite Débute par : ~ nnnn.dat \PARTS
Pièces moulées en grappe   nnnna.dat, nnnnb.dat, ... \PARTS
Pièce à variante (évolution)   nnnna.dat, nnnnb.dat, ... \PARTS
Pièce renommée (pour ancien numéro) Débute par : ~Moved to nnnn.dat \PARTS
Pièce simple avec numéro codifié Débute par : _ nnnnnnn.dat \PARTS
Sous-modèle   xxxx.ldr \MODELS ou ...
Modèle simple   xxxx.ldr \MODELS ou ...
Modèle multiple   xxxx.mpd \MODELS ou ...

 

Droits et Copyright

Sources

Principales pages ayant servi pour créer cette page en français, provenant du site de référence LDraw.org :

Cette page en Français

Traduction et adaptation : J.C. Tchang.