J.C. Tchang
| 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.0 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.
Les fichiers LDraw sont de simples fichiers texte (sans mise en page).
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.
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.
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>.
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".
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.
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 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).
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.
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 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 à modèles multiples contiennent plusieurs modèles, et portent l'extension MPD.
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). |
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.
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.
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.
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.
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.
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 :
Une méta-commande sert a déclarer à des programmes compatibles avec le format LDraw,
de faire quelque chose. 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.
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).
Format de la ligne :
1 <couleur> x y z a b c d e f g h i <fichier>
où :
| a d g 0 | | a b c x | | b e h 0 | | d e f y | | c f i 0 | | g h i z | | x y z 1 | | 0 0 0 1 |Ces deux formes sont équivalentes, mais notez l'emplacement de la position de la transformation (x, y, et z) par rapport aux autres termes.
u' = a*u + b*v + c*w + x v' = d*u + e*v + f*w + y w' = g*u + h*v + i*w + z
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.
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.
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.
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
Cette commande dessine une ligne entre deux points.
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
pour les bords de pièces. Quand elle est utilisée de cette manière, elle doit prendre la couleur
24.
La ligne de type 2 peut é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 être utilisées.
Voir le chapitre Couleurs plus bas.
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.
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.
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.
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.
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.
Voici quelques considérations sur la façon de créer des quadrilatères pour qu'ils soient valides.
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.
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.
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.
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é.
Les lignes conditionnelles sont des lignes qui ne sont dessinées que si elles sont utiles à la bonne visualisation des parties cylindriques.
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.
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/ |
\ | | /
\ | | /
\|___________|/
|
|
1___________2
/ \
/ \
6/ \3
|\ /|
| \ / |
| \5___________4/ |
\ /
\ /
\_____________/
|
|
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.
Il y a un certain nombre de restrictions sur le chevauchement des entités graphiques pour avoir un bon rendu.
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.
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).
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.
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.
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. |
L'entê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 entête ne peut contenir que des lignes type 0, ou des lignes vides servant de séparateurs.
L'entê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'entête du fichier.
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>
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
Le "Official Model Repository" (OMR) a développé des standards pour les entê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 entêtes.
L'entê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'entête officielle des fichiers actuels :
Entê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/
Entê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/
Entê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/
Voici les termes utilisés dans le dossier, avec leur sens contextuel.
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).
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
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'entê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'entê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.
Ces méta-commandes servent à renseigner l'entête du fichier.
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à.
Format de la ligne :
0 texte de titre
Où le "texte de titre" est ce que vous voulez pour nommer votre 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.
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.
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 : 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'entête officielle, décrivant le travail restant à faire, pour finir la pièce.
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), ...
Les pièces comportant un motif imprimé, utilisent le mot "Pattern" (Motif) à la fin de leur titre.
Cette forme de titre sert lorsqu'un fichier change de numéro.
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.
En dehors du cas précédent avec "~Moved to", il y a d'autres cas ou le titre de la pièce doit commencer par "~".
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).
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 "~".
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 "~".
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 "_".
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. Exemple :
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.
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.
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.
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...
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 ou 3 chiffres, ou une association de lettres et de chiffres donnant un numéro d'ordre ou une catégorisation de gamme (comme les Torso).
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.
| Catégorie | Utilisation |
|---|---|
| 0x | Général/Divers et Ville |
| 1x,2x | Ville, incluant Paradisa |
| 3x | Pirates, Soldiers, Islanders |
| 4x | Castle |
| 5x,6x | Space |
| 7x,8x | Modern Town |
| 9x | Libre |
| Ax | Adventurers |
| Bx | Libre |
| Cx | Control Panels, dials, gauges, keyboards, readouts, etc. |
| Dx | Studios |
| Ex | Libre |
| Fx | Fabuland et Scala |
| Gx | Libre |
| Hx | Harry Potter |
| Jx - Mx | Libre (I et L ne doivent pas être utilisés, voir la note plus loin). |
| Nx | Ninja |
| Qx | Libre (O et P ne doivent pas être utilisés, voir la note plus loin). |
| 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.
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.
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.
Les pièces en grappe, sont des pièces différents moulées ensembles, et fournis avec le support de moulage. Elles ont par conséquent le même numéro de moule. Pour les distinguer on leur ajoute une lette 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 :
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 lette 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.
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.
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.
Un autocollant porte comme nom le premier numéro imprimé
sur la planche imprimée. 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 imprimée. 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 LDraw.org. Ex : s1.dat, s2.dat, ..., s25.dat.
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).
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]
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'entê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>
Les chaines de caractères valides pour le champ <type> est :
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.
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).
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
Cette méta-commande permet d'envoyer une commande aux programmes LDraw et LEdit (programmes d'origine).
Format de la ligne :
0 !CMDLINE LDraw run-time command(s)
Exemple :
0 !CMDLINE -C14
Dans cet exemple la pièce est affichée en jaune.
Cette méta-commande permet de noter l'historique des modifications et officialisation de la pièce.
Format de la ligne :
0 !HISTORY 2008-07-01 [PTadmin] Official Update 2008-01
0 !HISTORY YYYY-MM-DD {RealName} Free text description of change
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)
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. Toujours valide ?
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'entête du fichier, est formalisé dans le "LDraw.org Official Library Header Specifications".
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".
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.
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
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).
Pour les pièces soumise à LDraw.org il y a des restrictions sur les méta-commandes employées.
L'entête des fichiers de pièces doit être conforme au Official Library Header Specification (en Anglais).
Ces méta-commandes se trouvent généralement dans le corps des fichiers de pièces.
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.
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.
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.
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.
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.
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) de devraient 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.
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.
Ces méta-commandes permettent de gérer plusieurs modèles dans un même fichier LDraw.
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.
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.
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.
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
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.
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.
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 entê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.
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'entê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 entête.
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.
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
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é.
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.
Voici une table des 16 couleur de base (codes 0 à 15) :
| N° LDraw |
N° 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).
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.
| N° LDraw |
N° LEGO |
Couleur (par défaut) |
Nom Français |
Nom Anglais |
RGB |
|---|---|---|---|---|---|
| 16 | - | Couleur principale, ou courante | Main color | #7F7F7F |
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 |
| N° LDraw |
N° LEGO |
Couleur (par défaut) |
Nom Français |
Nom Anglais |
RGB |
|---|---|---|---|---|---|
| 24 | - | Couleur de bord | Edge color | #7F7F7F |
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.
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.
Les couleurs unies sont aujourd'hui définies dans le fichier ldconfig.ldr.
Voici une table des couleurs unies :
| N° LDraw |
N° 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 | ||
| 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 | ||
| 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 | ||
| 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 | ||
| 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 | ||
| 323 | 323 | Eau Claire | Light Aqua (Aqua) | #ADC3C0 | ||
| 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 |
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.
Aujourd'hui elles sont définies dans le fichier ldconfig.ldr.
Voici une table des couleurs transparentes unies :
| N° LDraw |
N° 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 | 227 | Transparent Vert Lumineux | Trans Bright Green (Transparent Bright Yellowish Green) | #D9E4A7 | |
| 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 |
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 :
| N° LDraw |
N° 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 |
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.
Voici une table des couleurs métalliques :
| N° LDraw |
N° LEGO |
Couleur | Nom Français |
Nom Anglais |
RGB | Observation |
|---|---|---|---|---|---|---|
| 80 | 298 | Métal Argent | Metallic Silver (Cool Silver Drum Lacq) | #A5A9B4 | Pour pièces en plastique argenté. | |
| 81 | - | Métal Vert | Metallic Green | #899B5F | ||
| 82 | 299 | Métal Or | Metallic Gold (Warm Gold Drum Lacq) | #DBAC34 | ||
| 83 | - | Métal Noir | Metallic Black | #1A2831 | ||
| 87 | - | Métal Gris Foncé | Metallic Dark Grey | #6D6E5C |
Couleurs existantes dans le fichier de configuration ldconfig.ldr :
| N° LDraw |
N° LEGO |
Couleur | Nom Français |
Nom Anglais |
RGB | Observation |
|---|---|---|---|---|---|---|
| 334 | - | Chrome Or (Doré) | Chrome Gold | #BBA53D | ||
| 383 | - | Chrome Argent (Argenté) | Chrome Silver | #E0E0E0 | Utilisé pour pièce réellement métallique, dont l'acier. | |
| 60 | - | Chrome Cuivre Antique (Vert-de-gris) | Chrome Antique Brass | #645A4C | ||
| 64 | - | Chrome Noir | Chrome Black | #1B2A34 | ||
| 61 | - | Chrome Bleu | Chrome Blue | #6C96BF | ||
| 62 | - | Chrome Vert | Chrome Green | #3CB371 | ||
| 63 | - | Chrome Rose | Chrome Pink | #AA4D8E |
Couleurs existantes dans le fichier de configuration ldconfig.ldr :
| N° LDraw |
N° 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 | - | Noir Transparent de Cellule Infra-Rouge | Trans Black IR Lens | #000000 | ||
| 494 | - | Contact Electrique Métal Blanc | Electric Contact Alloy | #D0D0D0 | Utilisé pour contact électrique (tenons). | |
| 495 | - | Contact Electrique Cuivré | Electric Contact Copper | #AE7A59 | Utilisé pour contact électrique (tenons). |
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 :
| N° LDraw |
N° 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 | 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 |
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 :
| N° LDraw |
N° LEGO |
Couleur | Nom Français |
Nom Anglais |
RGB | Observation |
|---|---|---|---|---|---|---|
| 75 | - | Noir Cuivré | Speckle Black Copper | #000000 | ||
| 76 | - | Gris Bleuté Foncé Argenté | Speckle Dark Bluish Grey Silver | #635F61 | ||
| 132 | - | Noir Argenté | Speckle Black Silver | #000000 | ||
| 133 | 132 | Noir Doré | Speckle Black Gold (Black Glitter) | #000000 |
Couleurs existantes dans le fichier de configuration ldconfig.ldr :
| N° LDraw |
N° 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 |
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 :
| N° LDraw |
N° 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 | ||
| 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 |
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 |
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.
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.
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'entê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.
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.
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.
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.
Il existe actuellement 2 noms de matériaux officiels (name) :
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 :
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é :
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.
Ces méta-commandes ont été ajoutées pour le programmes MLCad, et peuvent être ignorées par d'autres programmes.
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 :
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).
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 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).
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).
Cette commande retourne à l'angle de vue par défaut des vue individuelles.
Syntaxe de cette commande :
0 ROTSTEP END
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
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>
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>
Où <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.
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.
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>
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) !
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.
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>
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.
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.
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.
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.
La méta-commande suivante est réservée pour une future définition d'axe de rotation :
0 ROTATION AXLE
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.
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.
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.
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.
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.
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.
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.
0 CLEAR
0 STEP
0 ROTSTEP
0 BUFEXCHG
0 GHOST
0 GROUP
0 SYNTH
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
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
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
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
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
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
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
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
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>
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 #
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.
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
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.
LDRaw Switch est un projet de créer des alternatives de pièce ou de variante de modèle dans un fichier LDraw.
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
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
Voici l'emplacement où doivent se trouver par défaut les différents fichiers LDraw.
Les différents fichiers de la bibliothèque de pièces LDraw sont placés dans deux
dossiers et deux sous-dossiers, à partir du dossier d'installation de LDraw :
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 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.
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 |
| 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 | |
| Pièce simple | 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) | Actuellement aucune distinction | nnnn.dat | \PARTS |
| Autocollant à 1 seul motif | Débute par : Sticker | nnnnnnn.dat | \PARTS |
| Autocollant à plusieurs motifs | Débute par : Sticker | nnnnnnna.dat, nnnnnnnb.dat, ... | \PARTS |
| Autocollant "en forme" du support | Débute par : Sticker, Contient : (Formed) | nnnnnnnacnn.dat, nnnnnnnbcnn.dat, ... | \PARTS |
| Autocollant à numéro inconnu | Débute par : Sticker | snn.dat | \PARTS |
| Pièce à motif | Termine par : Pattern | nnnnpnn.dat | \PARTS |
| Pièce composite assemblée | Contient : (Shortcut) | nnnncnn.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 ... |
Principales pages ayant servi pour créer cette page en français, provenant du site de référence LDraw.org :
Traduction et adaptation : J.C. Tchang.