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.2 specification, du site de référence LDraw.org, et des pages liées. En cas de divergence de vue, ou de problème de traduction, seule cette source fait foi.
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 de l'ensemble des 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 cette insertion.
Nota : Les versions précédentes du format de fichier LDraw.org ne spécifiaient pas
d'encodage de texte pour les fichiers LDraw. Les programmes n'utilisant pas UTF-8 ont été largement déployés.
Il est recommandé aux analyseurs de confirmer qu'un fichier est valide en UTF-8 et, sinon
dans le cas contraire de tenter :
- Soit d'ouvrir le fichier en utilisant la page de code Microsoft Windows la plus appropriée
pour la langue courante.
- Soit d'ouvrir le fichier en utilisant la page de code Windows 1253.
Ces recommandations de secours sont encouragées pour toutes les plates-formes logicielles,
car elles suivent le comportement de l'écrasante majorité des éditeurs LDraw non Unicode.
LDMakeList permet de vérifier l'existence de caractère Non UFT-8
dans les fichiers de la bibliothèque.
Warning! File LS22.dat contains non-UTF-8 characters!
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>, ce qui ne veut pas dire que le fichier doit se terminer par une ligne vide suivi de <CR><LF>.
Nota : Ces 2 caractères, correspondants aux codes hexa 0D et 0A, n'apparaissent pas lorsqu'on édite un fichier sous Windows. Il peut être utile d'utiliser un éditeur qui les visualisent facilement comme Notepad2, de Florian Balmer ( http://www.flos-freeware.ch ) en allant dans le menu "View / Show Line Endings", et passe en mode standard avec le menu "File / Line Endings / Windows (CR+LF)".
La langue utilisée pour la désignation des pièces, les commentaires, mots-clefs, etc, est l'Anglais, ou plutôt l'Anglais Australien en hommage au créateur du système LDraw, James Jessiman (1971-1997).
Il existe quelques différences entre l'Anglais et l'Australien :
| Français de France |
Anglais Britanique |
Anglais Australien |
|---|---|---|
| Couleur | Color | Colour |
| Gris | Gray | Grey |
Pour plus d'informations sur le langage Australien voir :
LEXILOGOS : Dictionnaire anglais d'Australie,
Wikipédia : Anglais australien.
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 adresses 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 (21.3) sont pris en compte sur "Parts Tracker" avec la nécessité d'utiliser une nouvelle version de mklist.exe pour générer la liste des pièces de votre bibliothèque (voir : Commande "Fichier / Scanner Pièces" de MLCad prohibée).
Nota : Depuis 08-2014, les noms à 25 caractères sont pris en compte pour les primitives.
Pour éviter toute confusion avec la grammaire anglaise, la virgule (,) n'est pas autorisé.
Les caractères majuscules et minuscules sont permis dans les noms de fichiers, car ces noms sont insensibles à la casse (A et a sont considérés comme le même caractère par les programmes).
Actuellement toutes les pièces officielles sont publiées avec des noms entièrement en majuscules.
Nota : Nous verrons avec la méta-commande Nom du fichier (Name:), comment on nomme les fichiers en fonction de leur utilisation.
Il y a 3 extensions utilisées pour LDraw :
.DAT : Les fichiers de pièces (briques LEGO), portent toujours l'extension DAT. Ces fichiers peuvent être des pièces complètes, des parties de pièces, des primitives (parties élémentaires répétitives), et des primitives de haute résolution. Les fichiers de la bibliothèque de pièces LDraw.org (LDraw Parts Library) n'utilisent que cette extension.
.LDR : Aujourd'hui, les fichiers des modèles simples LDraw (assemblages de pièces LEGO virtuelles), portent l'extension LDR (par défaut). Mais, à l'origine, l'extension des ces fichiers modèles était DAT, puis cette extension est devenue LDR, pour éviter des ambigüités. C'est pour cette raison qu'il existe encore des modèles ayant l'extension DAT.
.MPD : Les fichiers des modèles multiples contiennent plusieurs modèles, et portent généralement l'extension MPD, mais pour rester compatible avec l'historique l'extension .LDR n'est pas interdit, et tous les programmes peuvent (doivent) utiliser les deux extensions.
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és 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 aux 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èrent 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 à déclarer une action à des programmes compatibles avec le format LDraw.
Il y a actuellement beaucoup de méta-commandes officielles,
et également des méta-commandes officieuses plus ou moins spécifiques à des
programmes particuliers.
La possibilité d'avoir des méta-commandes est une façon d'étendre les spécifications
du format LDraw, et d'y inclure des instructions comme "STEP" (étape de construction)
ou "BFC" (définition du sens des faces), etc..., à l'intérieur du fichier.
Méta-donnée : Au lieu d'être une commande, il peut s'agir de méta-donnée, comme le nom de l'auteur, ou ajouter des mots-clefs de recherche, de catégorie de pièce, d'aide sur l'utilisation de la pièce, etc..., à l'intérieur du fichier.
Format de la ligne :
0 !<commande> <paramètres additionnels>
Ou :
0 <commande> <paramètres additionnels>
Nota : la seconde forme n'est plus à utiliser pour toutes les nouvelles méta-commandes.
! : Est utilisé pour identifier positivement qu'il s'agit d'une méta-commande.
Nota : Quelques méta-commandes officielles n'ont pas ce caractère "!", pour conserver la compatibilité
avec l'existant. Cependant, toutes les nouvelles méta-commandes officielles doivent utiliser ce caractère,
et il est recommandé que toutes les officieuses fassent de même.
<commande> : Nom de la méta-commande ou méta-donnée. Ce nom peut être en majuscules et/ou en minuscules (insensible à la casse).
<paramètres additionnels> : Paramètres additionnels de la méta-commande. Elle peut comporter plusieurs paramètres. Si la méta-commande ne demande aucun paramètre, alors il ne faut pas lui en fournir.
Nous verrons plus loin une description des diverses méta-commandes officielles, et les méta-commandes spécifiques à des programmes tiers.
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-dossiers 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 uniquement
pour les bords de pièces. Quand elle est utilisée de cette manière, elle
Elle doit prendre la couleur 24.
La ligne de type 2 peut pouvait également être utilisée pour représenter de fins détails dans
les motifs, comme sur les "Torso" de Minifig. Dans ce cas, toutes les couleurs peuvent
pouvaient être utilisées. Voir le chapitre Couleurs plus bas. Nota :
Actuellement cette pratique est désuète et ne doit plus être utilisée à cause des problèmes de rendu
que cela occasionne. Les fins détails doivent être créés avec des triangles et quadrilatères.
Dans tous les cas, il faut se rappeler que certains programmes de rendu n'affichent pas les lignes de type 2 ou 5, ou les affichent seulement en cochant un paramètre.
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.
Lorsqu’aucun ordre spécifique de déclaration des points n'est donné, ils peuvent être déclarés dans le sens horaire (CW) ou antihoraire (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 vue 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 couleurs à 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ée 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'en-tête du fichier forme la liste des commandes commençant le fichier avant les lignes permettant de créer les entités graphiques de la pièce ou du modèle (lignes types 1 à 5). Cet en-tête ne peut contenir que des lignes type 0, ou des lignes vides servant de séparateurs.
L'en-tête des fichiers de pièces doit au minimum permettre de décrire la pièce, identifier cette pièce par un numéro, donner le nom du créateur de ce fichier.
Il doit ensuite donner son statut vis-à-vis de l'organisation LDraw.org, si cette pièce est officielle ou non, et si elle peut être redistribuée.
Toutes ces informations sont (ou sont devenus) obligatoires.
D'autres informations peuvent être ajoutées, de façon optionnelle, pour permettre d'informer l'utilisateur du fichier de son historique (!HISTORY), de certaines caractéristiques sur son utilisation (!HELP), de donner sa catégorie (!CATEGORY), ou des mots-clefs permettant une recherche (!KEYWORDS), ou d'informer les programmes de visualisation sur le mode de construction (!CMDLINE), (BFC CERTIFY).
Aucune autre méta-commande n'est permise dans l'en-tête du fichier.
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 en-têtes et noms de fichiers des modèles. C'est pour avoir des modèles homogènes, et facilement indexable par un script, et une base de données. Vous trouverez ici, un aperçu de ce standard pour les noms de fichiers et les en-têtes.
L'en-tête du fichier doit être concis, et en même temps, donner toutes les informations nécessaires sur le modèle ou le sous-modèle. Voici l'en-tête officiel des fichiers actuels :
En-tête de modèle principal :
0 7140 X-Wing Fighter
0 Name: main.ldr
0 Author: Tim Courtney
0 LDraw.org Official Model Repository
0 http://www.ldraw.org/repository/official/
En-tête d'un sous-modèle :
0 7140 X-Wing Fighter, Main Fuselage
0 Name: m-2a.ldr
0 Author: Tim Courtney
0 LDraw.org Official Model Repository
0 http://www.ldraw.org/repository/official/
En-tête d'un Minifig :
0 7140 X-Wing Fighter, Luke Skywalker Mini-figure
0 Name: mf-1.ldr
0 Author: Tim Courtney
0 LDraw.org Official Model Repository
0 http://www.ldraw.org/repository/official/
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 ensemble OMR est inclus dans un fichier MPD. Ce fichier MPD peut être extrait pour créer un autre sous-dossier pour l'ensemble particulier (voir le diagramme ci-dessous). A l'intérieur, il y a les différents fichiers qui composent l'ensemble.
Le sous-dossier de l'ensemble utilise pour son nom, le numéro de l'ensemble, 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 l'ensemble complet. Tout cela doit aller dans le sous-dossier \sets du dossier \models.
Quatre chiffres pour le numéro de l'ensemble
|
| Modifieur optionnel pour l'année
| |
| | Deux chiffres pour l'année où l'ensemble a été réalisé.
| | |
models/sets/XXXXZ-YY/
Dans le sous-dossier de l'ensemble, les noms de fichiers suivants représentent les différents aspects de l'ensemble 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 ensembles, cette année là, qui portent ce numéro d'ensemble. Cela se rencontre habituellement dans les packs d'ensembles, de la fin des années 80, et le début des années 90, mais cela arrive aussi pour d'autres ensembles. Par exemple, le pack d'ensembles 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 ensemble différent, qui est publié avec ce numéro d'ensemble 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 ensemble du pack, ou le premier ensemble publié, avec ce numéro prendra A comme modifieur, et le second B, etc...
Ce système d'en-tête et d'appellation des noms de fichiers a été mis en place par le "LDraw.org Official Model Repository" (modèles officiels répertoriés) (OMR) pour une redistribution des ensembles officiels aux utilisateurs de LDraw. Chaque auteur individuel, de ces modèles officiels, utilisé dans l'OMR, est crédité pour le modèle dans l'en-tête, et sur le site internet LDraw.org. L'OMR ne veut pas dire, enlever ses droits à l'auteur individuel, ou à l'auteur du site, mais cherche uniquement à distribuer les modèles Lego aux utilisateurs de LDraw gratuitement.
Le Répertoire des Modèles Officiels (Official Model Repository ou OMR en anglais) est une base de données de fichiers au format LDraw qui décrit des modèles publiés ou vendus par LEGO®.
Cet OMR se trouve actuellement sur : Welcome to the LDraw Model Repository et le forum de LDraw.org : Official Models.
Pour avoir une cohérence entre les modèles et aider à l'indexage par logiciel, un standard pour les en-têtes de fichiers, noms, et hiérarchie dans l’OMR est exigé. Ce document esquissera les exigences supplémentaires (en plus de ceux présentés dans les spécifications du format de fichier LDraw actuel) pour un modèle devant être inclus dans l’OMR.
Voir les spécifications officielles : Official Model Repository (OMR) Specification (en Anglais).
Tous les fichiers dans le modèle doivent être conformes au format de fichier LDraw actuel.
Chaque modèle dans l’OMR consistera en plusieurs sous-fichiers qui sont emballés dans un seul
fichier MPD. Pour les ensembles qui incluent des instructions pour de multiples modèles chaque modèle
aura son propre fichier MPD. Chaque fichier MPD pour l'ensemble sera nommé dans la manière suivante :
<Numéro de l'ensemble> - <Nom de l'ensemble> [- <Nom du Sous-modèle>]
Où :
<Numéro de l'ensemble> : Le numéro assigné sur la boite de l'ensemble.
<Nom de l'ensemble> : Le nom de l'ensemble imprimé sur la boite, en anglais.
<Nom du Sous-Modèle> : Facultatif dans la plupart des cas.
Cela est exigé pour les modèles alternatifs qui sont détaillés dans
les instructions de montage (par exemple dans le thème Creator).
Dans ce cas la nomination est laissée à l'arbitraire de l'auteur,
mais devrait être descriptif du modèle contenu dans le fichier MPD.
Pour les ensembles qui se composent de multiples modèles qui font partie intégrante de l'ensemble complet, tous les sous-modèles seront contenus dans un seul fichier MPD.
Exemple :
L'ensemble Creator 4896 - Roaring Roadsters décrit 3 modèles dans ses instructions :
Ensemble 4896 - Roaring Roadsters - Roadster.mpd
Ensemble 4896 - Roaring Roadsters - Dragster.mpd
Ensemble 4896 - Roaring Roadsters - SUV.mpd
Le fichier MPD se conformera à la spécification des fichiers MPD.
Chaque nom de fichier aura la structure :
<Numéro de l'ensemble> [- <Index facultatif>] - <Nom individuel>
Où :
<Numéro de l'ensemble> est le numéro assigné sur la boite de l'ensemble.
<Index facultatif> est un nombre séquentiel, en commençant par 1, ajouté s'il y a plus d'un ensemble qui pourrait être assigné au
Les pièces officieuses (Unofficial parts) sont autorisées. Le nom de fichier de la pièce officieuse est soumis aux règles de la nomination ci-dessus (par exemple 33056.dat seraient renommé comme <Nom de fichier MPD> - 33956.dat). Il est fortement conseillé que toutes les pièces qui ont été créées spécifiquement pour un fichier OMR soient soumises au LDraw.org Parts Tracker (suivi des pièces de LDraw.org). Si une pièce est non disponible officiellement ou sur le LDraw.org Parts Tracker, une substitution appropriée peut être faite. Si la pièce non disponible est une pièce à motif avec une version sans motif disponible, utilisez la version sans motif. Un commentaire devrait être inséré pour indiquer qu'une substitution a été faite ou, si aucune substitution n'est appropriée qu'une pièce a été omise. Indiquez l’étape et le numéro de la page des instructions si possible.
Exemple :
0 // The next piece should have the Star Wars Hatch pattern per step X on page Y or
0 // Bionicle piece X should go here per step Y on page Z
Traduction :
0 // La pièce suivante devrait avoir le motif de Panneau Star Wars à l’étape X sur la page Y ou
0 // La pièce Bionicle X devrait aller ici à l’étape Y sur la page Z
En-tête Standard :
0 FILE <Nom de fichier>.ldr
0 <sous-fichier individuel>
0 Name: <Nom de fichier>.ldr
0 Author: <Nom Auteur> [Pseudo]
0 !LDRAW_ORG Model -OR- 0 !LDRAW_ORG Unofficial_Model
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !THEME Theme name
0 !KEYWORDS words, more words, ...,
0 !KEYWORDS words in second row, ..., final words
0 !HISTORY YYYY-MM-DD [Username] Free text description of change. This can wrap to a
0 !HISTORY YYYY-MM-DD [Username] second row with the same date if necessary. However authors should lean toward writing longer
0 !HISTORY YYYY-MM-DD [Username] single !HISTORY lines(and not feel constrained to the historic 80-character limit on line length).
Où :
<Nom de fichier> : Le nom du fichier suivant les règles spécifiées dans le chapitre
Structure du fichier MPD.
<sous-fichier individuel> : Le nom du sous-fichier individuel qui utilise les règles
dans le chapitre Structure du fichier MPD.
<Nom Auteur> : Le nom de l'auteur. Le nom réel complet (prénom et nom) est exigé par
le "LDraw.org Contributor's Agreement" (Accord du Contributaire LDraw.org ).
[Pseudo]: Le pseudo LDraw.org de l'auteur.
Exemple :
0 FILE 4896 - Roadster Main.ldr
0 Roadster Main
0 Name: 4896 - Roadster Main.ldr
0 Author: Joe Smith [jsmith]
0 !LDRAW_ORG Unofficial_Model
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 !THEME Creator
0 !KEYWORDS car, convertible
0 !HISTORY 2011-08-01 [jsmith] Initial creation
Toutes les méta-commandes sont permises dans le fichier modèle mais pas spécifiquement exigées excepté celles spécifiées pour l'en-tête. Si incluses, toutes les méta-commandes utilisées devraient permettre toute instruction générée pour être au plus près des instructions officielles que possible.
Les modèles avec des parties entièrement symétriques (ailes droite et gauche d’un avion par exemple) peuvent souvent être modélisés beaucoup plus facilement en modélisant un des côtés symétriques et en l’incluant alors dans le modèle deux fois, dont un symétrisé par rapport à l’axe de symétrie. Malheureusement, cette symétrisation produit une liste de pièces incorrecte, et également un logo LEGO en miroir sur les tenons, quand on fait un rendu réaliste avec certains logiciels. Donc l’utilisation des symétries est fortement découragée.
Cette traduction est basée sur le document officiel en anglais ratifié le 21 octobre 2011.
Par défaut dans les fichiers officiels les étapes sont séparées par :
0 STEP
1 ...
1 ...
J'utilise dans mes fichiers une variante permettant de suivre la numérotation des manuels officiels :
0 STEP
0 WRITE Etape 1
1 ...
1 ...
0 STEP
0 WRITE Etape 278 à 286
1 ...
1 ...
0 STEP
0 WRITE Fin
Cette variante me convient très bien, mais je comprends que l'utilisation du français peut poser des problèmes aux non francophiles.
Je n'utilise pas, mais pourrait être une aide pour suivre la distribution des sachets :
0 STEP
0 WRITE Sachet 1
0 WRITE Etape 1
1 ...
Variantes :
0 STEP
0 WRITE Sachet Sans Numéro
0 WRITE Etape 18
1 ...
0 STEP
0 WRITE Hors Sachet
0 WRITE Etape 123
1 ...
Si je suis d'accord qu'une standardisation du nom pour la gestion des modèles officiels soit une bonne chose, les contraintes sur le format interne, qui devraient être laissées à l'appréciation des créateurs, limite les soumissions à l'OMR.
Personnellement je n'utilise pas la règle officielle, mais des règles personnelles
qui me correspondent mieux.
Voir également :
Créer un modèle avec MLCad : Découpage en sous-modèles.
Conséquence regrettable : Je ne soumets pas mes nombreux fichiers de modèles sur LDraw.org. Ils restent confidentiels sur mon ordinateur local (environ 880 modèles en 02-2023).
Ces méta-commandes servent à renseigner l'en-tê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 (en anglais, ou plutôt australien-anglais)
pour nommer votre pièce ou modèle.
Si la première ligne du fichier a pour type "0", le reste de cette ligne est considéré comme le titre
du fichier (en tout cas pour les fichiers de pièces). Cela fait ignorer
toute méta-commande pouvant se trouver sur cette ligne.
Nota : Dans les fichiers de projets MPD, cette ligne n'est pas la première du fichier, mais la première ligne apparaissant derrière chaque ligne "0 FILE ...".
Le "Texte de Titre" est limité à 64 caractères.
Tous les mots doivent avoir leur première lettre en majuscule, sauf les
articles, prépositions, conjonctions, et forme du verbe être (to be).
Exemple :
0 Wheel 17 x 75 Motorcycle with Holes in Rim
Certains mots sont considérés inutiles dans la description, comme new (nouveau) et old (ancien), car cela n'est pas toujours une aide sur la chronologie d'apparition des pièces.
Si la pièce est assez bonne pour un usage publique, mais a quelques déficiences qui ont besoin d'être corrigées, le texte "(Needs Work)" (nécessite travail), sans mettre les guillemets, doit être ajouté à la fin de la description.
Nota : Certaines anciennes pièces portent les mots en minuscules : (needs work).
Nota : Le nom descriptif complet incluant "(Needs Work)" est limité à 64 caractères, en conséquence, cela diminue la partie de la description utilisable à 51 caractères. Si le nom descriptif comporte "(Needs Work)", un commentaire doit être ajouté au fichier, immédiatement après l'en-tête officiel, 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.
Nota : Depuis 2012 les autocollants ne comportent plus le mot "Pattern",
car ils sont tous à motif, et cela laisse plus de place pour la description.
Ces pièces contiennent des erreurs ou des techniques de création de motifs qui ne sont plus utilisées aujourd'hui. Elles ne doivent plus être utilisées normalement, mais sont gardées pour des raisons de compatibilité avec l'existant.
Pour les mettre en fin de liste, elles ont aussi "_" en premier caractère.
A l'origine l'ajout de ce premier caractère a été fait pour déplacer les pièces concernées à la fin du fichier listant ces pièces parts.lst.
Il y a 6 cas de figure :
Lorsque qu'une pièce réelle composite (normalement non démontable) est constitué de plusieurs pièces moulées ou fabriquées séparément, et assemblées par clipage, vissage, collage, emboutissage, etc..., il est malgré tout fait un fichier de pièce par pièce élémentaire, et tous ces fichiers portent comme premier caractère de titre le caractère "~". Les fichiers vont dans le dossier PARTS.
Exemple : 3829.dat ~Car Steering Wheel Stand, est le support de volant utilisé dans la pièce complète comportant le volant (3829c01.dat).
Par contre pour les pièces assemblées, dont les éléments sont mobiles les uns par rapport aux autres, il est souhaitable que la pièce assemblée, comme les parties mobiles ne comportent pas de "~". Cela permet à l'utilisateur d'utiliser la pièce assemblée dans une certaine configuration, ou les éléments mobiles dans les autres cas. Nota : Si une partie mobile est elle-même composée d'éléments assemblés fixes les uns par rapport aux autres ces sous-éléments comporteront un "~".
Nota : Ces fichiers peuvent perdre leur caractère "~" si la pièce unitaire vient à être utilisée en dehors de l'assemblage d'origine. Exemple la pièce 3680 (Turnable 2 x 2 Plate Base) utilisée indépendamment de la pièce 3679 (Turnable 2 x 2 Plate Top) sur l'ensemble 10189 (Taj Mahal).
Nota : De même pour les parties de pièces mis dans des sous-fichiers du
dossier PARTS\S, leur nom commence également par ~.
Les parties de pièces mis dans des sous-fichiers du
dossier PARTS\S, ne doivent PAS utiliser le caractère "~".
Cette forme de titre sert lorsqu'un fichier change de numéro. Voir le chapitre précédent pour les différents cas de figure.
Il est uniquement utilisé par le l'administrateur LDraw en utilisant le pseudo spécial de [PTadmin].
Voir la page spéciale Contributor Agreement (CA) en anglais.Format ancien des fichiers "~Moved to" :
0 ~Moved to {nouveau_numéro}
0 WRITE Part {ancien_numéro} moved to {nouveau_numéro}
0 BFC CERTIFY CCW
1 16 0 0 0 1 0 0 0 1 0 0 0 1 {nouveau_numéro}.dat
où : {nouveau_numéro} et {ancien_numéro} sont des numéros de pièces LDraw.
Ce n'est plus conforme au nouveau standard agrée. C'est pourquoi il a été changé par le format suivant.
Nouveau format des fichiers "~Moved to" :
0 ~Moved to {nouveau_numéro}
0 Name: {ancien_numéro}.dat
0 Author: [PTadmin]
0 !LDRAW_ORG {Part, Subpart, etc as appropriate} UPDATE YYYY-RR
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CCW
0 !HISTORY {date} [PTAdmin] {any necessary comment(s)}
0 // {part_description}
1 16 0 0 0 1 0 0 0 1 0 0 0 1 {nouveau_numéro}.dat
0
Exemple :
0 ~Moved to 3842a
0 Name: 193a.dat
0 Author: [PTadmin]
0 !LDRAW_ORG Part UPDATE 2006-01
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CCW
0
0 !HISTORY 2006-12-31 [PTadmin] Official update 2006-01
0 // Minifig Helmet Classic with Thin Chin Guard
1 16 0 0 0 1 0 0 0 1 0 0 0 1 3842a.dat
0
Ce nouveau format est cependant une source de problèmes possibles, avec certains programmes, qui utilisent la ligne "WRITE" supprimée, pour mettre à jour les pièces.
Le nouveau format a été défini sans la collaboration des administrateurs de pièces (Parts Tracker Administrators), et nécessite leur agrément.
La page Internet, de l'interface de soumission des pièces (PT GUI) de LDraw.org, incorpore un test, de tel façon que les auteurs de pièces ne peuvent soumettre un fichier "~Moved to". Si la nouvelle version est acceptée, il faudra également tester l'ancienne, comme la nouvelle version, pour le cas ou un auteur changerait le titre pour autre chose que "~Moved to".
Avec ce titre, le fichier ne doit pas comporter de méta-commande !CATEGORY.
A l'origine l'ajout de ce premier caractère a été fait pour déplacer les pièces concernées à la fin du fichier listant ces pièces parts.lst.
Les pièces récentes Lego officielles, portent un numéro plus long, correspondant à une codification incorporant la forme (moule), la couleur, et le motif éventuel. C'est ce numéro qui est donné à la fin des manuels d'instructions officiels.
Pour distinguer les fichiers utilisant cette numérotation, le titre doit commencer par "_".
De même, ces pièces utilisent comme type : "Part Physical_Colour", "Shortcut Physical_Colour", "Unofficial_Shortcut Physical_Colour" (voir au chapitre sur la méta-commande "!LDRAW_ORG").
Exemple : la pièce 4234927.dat porte pour titre : _Wing 4 x 4 with 2 x 2 Cutout Yellow. Cela correspond à la pièce de base et son numéro de moule 43719, mais affecté de la couleur jaune (14 LDraw).
Les parties de pièces mis dans des sous-fichiers du dossier PARTS\S, ne doivent PAS utiliser le caractère "_".
Apparu en 2013, sert à différencier les pièces ayant 2 numéros de moule (Pièces Alias). Il s'agit la plupart du temps des moules utilisés pour les pièces transparentes dont les tolérances de fabrication sont différentes. La raison est l'utilisation de plastiques dont le retrait n'est pas identique au refroidissement.
Ces pièces utilisent comme type : "Part Alias" (voir au chapitre sur la méta-commande "!LDRAW_ORG").
Les pièces dont le titre comporte des dimensions en nombre de tenons,
comporte 2 caractères par dimension, et chaque dimension est séparé par le
caractère "x". Les nombres inférieurs à 10 sont notifiés par un espace supplémentaire
suivi d'un chiffre de 1 à 9, en plus des espaces séparateurs. Exemples :
Brick 2 x 8
Brick 2 x 10
Brick 2 x 6 x 2 Weight
Il y a donc 2 espaces entre le mot "Brick" et le premier "2". Il ne doit pas y avoir 1 seul espace comme :
Brick 2 x 8
Brick 2 x 10
Brick 2 x 6 x 2 Weight
Cela permet d'avoir les pièces dans l'ordre croissant des dimensions dans la liste des pièces des programmes.
Premier paramètre : Largeur de la jante (en mm),
séparateur "x". Second paramètre : Diamètre de la jante (en mm). Paramètres supplémentaires : Qualifieurs
du type de jante. Exemples :
Wheel Rim 8 x 8 Notched Hole
Wheel Rim 20 x 30 with 6 Spokes and External Ribs
La définition LDraw essaye de s'approcher de la définition ISO des pneus réels, et de celle des pneus LEGO qui ont cette information gravée sur leur flanc.
Premier paramètre : Largeur du pneu (W en mm, de flanc à flanc (largeur maximum et non la largeur de la bande de roulement),
séparateur "/". Second paramètre : Profil (% H/W : pourcentage de la hauteur du flanc sur la largeur du pneu),
séparateur "x". Troisième paramètre : Diamètre de la jante recevant le pneu (D en mm et non le diamètre du pneu à l'état libre). Paramètres supplémentaires : Qualifieurs
du type de pneu. Exemples :
Tyre 14/ 54 x 15 VR
Tyre 38/ 76 x 56
Nota : Tous les pneus LDraw ne respectent pas cette définition (surtout les anciens).
Cette méta-commande indique et reprend le nom effectif du fichier lui-même. Il sert à l'identification des différents fichiers DAT de la bibliothèque de pièces LDraw. C'est un nom alphanumérique.
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 ensembles 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...
puis en 2013 de mettre en premier caractère de leur Nom le signe =.
Les pièces à motif (pattern), c'est-à-dire les pièces comportant un motif imprimé, portent le numéro du moule de la pièce simple, plus une extension "pnn" par motif différent.
Format de la ligne :
0 Name: <numéro>pnn.dat
Où : <numéro> est le numéro du moule (pièce sans motif), p l'indication d'une pièce à motif (pattern), nn est un nombre à 2 chiffres, ou une association de chiffre et lettre donnant un numéro d'ordre avec catégorisation de gamme (comme les Torso). A 10 il faut passer aux lettres : p01, ..., p09, p0a, p0b, ....
Exemple : 3009p04.dat Brick 1 x 6 with Blue "HOTEL" Pattern.
Pour obtenir le numéro ou code du motif, il suffit de le demander par Courriel à : Steve Bliss and Chris Dee, ou de poster une message sur le forum lugnet.cad.dev.
Normalement le premier caractère du code aide à identifier le thème ou la ligne de produits dans lequel apparaît le motif. Ce n'est pas une règle absolue, car de nombreuses pièces à motifs sont utilisées dans plusieurs thèmes, et l'approche de la codification a évolué dans le temps. En conséquence, il y a des exceptions.
| Catégorie | Utilisation |
|---|---|
| 0x | Général/Divers et Ville (Town) |
| 1x,2x | Ville (Town), incluant Paradisa |
| 3x | Pirates (Pirates), Soldats (Soldiers), Iliens (Islanders) |
| 4x | Médiéval (Castle) |
| 5x,6x | Espace (Space) |
| 7x,8x | Ville moderne (Modern Town) |
| 9x | Libre et Espace (Space) |
| Ax | Action (Adventurers, Aquazone, Alpha Team, Rock Raiders) |
| Bx | Super héros, dont Batman |
| Cx | Panneaux de contrôle (Control Panels, dials, gauges, keyboards, readouts, etc) |
| Cxy | Motif de Minifig des séries collectionnables (pour torse, bras, hanche, jambe). Format spécifique pour le torse par exemple : 973pc[série : 1-9,a-f][séquence : 1-9,a-f].dat (a pour 11, ..., f pour 16). série = 0 pour les Minifigs des séries collectionnables fournis en "Accessory packs", lorsqu'elles diffèrent. Exemple : 973pcbe = 15ème torse (e) de la série 11 (b) |
| Dx | Studios |
| Dxy | Motif de Minifig des séries collectionnables non numérotées (pour torse, bras, hanche, jambe). Format spécifique pour le torse par exemple : 973pdxy.dat, avec x=1 et y=1-9 pour la série "Team GB", x=2 et y=1-9,a-g pour la série "Simpsons", x=3 pour et y=1-9,a-g pour la série "The LEGO Movie". Exemple : 973pd21 = 1er torse (1) de la série "Simpsons" (2) |
| Ex | Libre |
| Fx | Fabuland et Scala |
| Gx | Sport (Soccer, Basketball) |
| Hx | Harry Potter |
| Jx | Indiana Jones |
| Kx | Cars (Disney Pixar) |
| Mx | Monde du milieu (Lord of the Rings (Le seigneur des anneaux), Elves (Elfes)) |
| Nx | Ninja, Ninjago |
| Qx | Pharaoh's Quest |
| Rx,Sx | Star Wars |
| Tx | Motifs généraux textuels (lettres et nombres) et marques (Logos de sociétés, etc) |
| Ux - Vx | Libre |
| Wx | Western |
| Xx - Zx | Libre |
Caractères à éviter : Il faut éviter les lettres I, L, et O, dans les codes de motif car elles sont facilement confondus avec les chiffres 1 et 0. La lettre P est à éviter car c'est la lettre utilisée pour définir les pièces à motif, et une pièce portant un nom comme 3001ppp.dat semblerait bizarre.
Exceptions : Les conventions ci-dessus ne sont pas appliquées aux pièces ayant comme motif les lettres de l'alphabet et les chiffres. Dans ce cas, il est pratique d'incorporer la lettre ou le chiffre représenté dans le nom du fichier, et donc les lettre I, L, O, et P, sont permis. Par exemple les pièces 6309 (Duplo Tile 2 x 2) et 3005 (Brick 1 x 1), possèdent comme variantes à motif les caractères alphanumériques (0-9, a-z) et utilisent le code Tx, ou x est remplacé par la lettre ou le chiffre correspondant. Tous les caractères accentués, ou caractères composés, ou symboles, peuvent utiliser le code Ux. Dans des cas exceptionnels, comme la pièces 3005, qui possède le même motif en plusieurs couleurs, un autre jeu de code peut-être utilisé, comme Vx, ou Wx.
Motifs communs : Quelques motifs apparaissent sur de nombreuses pièces différentes. Un exemple est le logo "Classic Space", qui est utilisé dans 8 fichiers de pièces de la bibliothèque LDraw. Pour rendre plus facile le suivi de ces pièces, ayant un motif commun, un code spécifique peut-être assigné. Ensuite, toutes les pièces avec ce motif doivent utiliser ce code dans leur numéro de pièce. Naturellement, cela n'est pas toujours possible, car le motif peut apparaître parfois sur la même pièce de différentes façons, et le code peut-être déjà utilisé pour une certaine pièce.
Nombres futurs : Lorsque des personnes soumettent des pièces à motif
dans des thèmes qui n'ont pas encore été modélisés dans la bibliothèque,
Nous (PT), allouerons des codes à ces motifs et thèmes. Ce serait une aide,
si les auteurs pouvaient cataloguer les différents motifs du thème.
Cela aiderait à 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 à double injection sont moulées en une seule fois avec 2 couleurs différentes ou 2 matériaux différents : par exemple la pièce 61406p01 avec la base en ABS rigide et l'extrémité pointue, pouvant être dangereuse, en plastique souple.
Leur numérotation est identique aux pièces à motif.
Format de la ligne :
0 Name: <numéro>pnn.dat
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érotation 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 indissociables, 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érentes moulées ensembles, et fournies avec leur support de moulage. Elles ont par conséquent le même numéro de moule. Pour les distinguer on leur ajoute une lettre derrière le numéro.
Format de la ligne :
0 Name: <numéro>x.dat
Où : <numéro> est le numéro du moule, et x une lettre de l'alphabet : a, b, c, ..., donnant le premier, second, troisième, ..., élément de la grappe.
Exemple : 6246d.dat : Minifig Tool Box Wrench, appartenant à la grappe de pièces 6246 :
Nota : Les pièces en grappe peuvent parfois être fournies sans le support de moulage, mais possèdent un seul numéro codifié ou "Item" (Numéro commercial).
Exemple : Les 9 pièces item 6038211, correspondant au moule 11402, sont
fournies sans grappe dans un sachet :
Les pièces à variantes, sont des pièces normalement identiques, mais dont le moule à évolué au cours du temps. Elles gardent le même numéro de moule, et pour les distinguer on leur ajoute une lettre derrière le numéro.
Nota : l'ordre des lettres est l'ordre d'apparition des variantes sur le site LDraw.org, et non l'ordre chronologique de création réelle, qui n'est pas toujours connu.
Format de la ligne :
0 Name: <numéro>x.dat
Où : <numéro> est le numéro du moule, et x une lettre de l'alphabet : a, b, c, ..., donnant la première, second, troisième, ..., forme de la pièce.
Exemple : 4085a.dat, 4085b.dat, 4085c.dat, Plate 1x1 with Clip Vertical Type 1, 2, et 3.
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érencier 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 ensemble, 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. Ex :
Pour la planche 72047/4112924 de 1998, le nom
de base est 72047.dat, s'il n'y a qu'un seul motif sur la planche,
même s'il est reproduit plusieurs fois.
S'il y a plusieurs motifs, ils prennent les noms successifs
de 72047a.dat, 72047b.dat, 72047c.dat, ...
Changement en 7-2011 : Un autocollant porte comme nom le second
numéro imprimé sur la planche. Ex :
Pour la planche 72047/4112924 de 1998, le nom
de base est 4112924.dat, s'il n'y a qu'un seul motif sur la planche,
même s'il est reproduit plusieurs fois.
S'il y a plusieurs motifs, ils prennent les noms successifs
de 4112924a.dat, 4112924b.dat,
4112924c.dat, ...
Les autocollants sont imprimés sur une planche "plane",
mais sont parfois utilisés et collés sur des pièces non planes.
Dans ce cas il peut exister la version plane de base, et
une ou plusieurs versions "en forme". Ces versions portent l'extension
c01, c02, ...
Dans la pratique pour respecter une longueur de nom
ne dépassant pas 8 caractères c01 devient c1, etc... Ex :.
L'autocollant en forme 56711gc1.dat
Si la planche ne comporte pas de numéro connu, un numéro d'ordre lui est attribué par un administrateur de LDraw.org. Ex : s1.dat, s2.dat, ..., s25.dat.
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).
Une première série s'est appliquée avant 2/2010 avec des noms du type xnnnn, c'est-à-dire de la lettre x suivi d'un nombre à 3 ou 4 chiffres.
Une nouvelle série est apparue en 2/2010 avec des noms du type unnnn, c'est-à-dire de la lettre u suivi d'un nombre à 2, 3 ou 4 chiffres.
Un découpage de cette série s'applique :
Nota : Si ces pièces ont des variantes, motifs, etc, elles prennent les extensions correspondantes.
Il s'agit des pièces en tissu (canvas), en caoutchouc souple (Technic Tread), et aussi les autocollants en forme (Sticker Formed) ....
Dans ce cas il peut exister une version sans contrainte ou dépliée de base, et une ou plusieurs versions "en forme". Ces versions portent l'extension c01, c02, ...
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'en-tête de base du fichier (Il s'agit des premières lignes du fichier, avec le titre du modèle, et les lignes Name: (Nom) et Author: (Auteur)). Le premier format (!LDRAW_ORG) est le standard actuel pour les fichiers officiels de la bibliothèque de pièces. Les anciens fichiers conservent les autres formats.
Format actuel de la ligne :
0 !LDRAW_ORG <type> [qualifier(s)] [update-tag]
Formats anciens de la ligne :
0 LDRAW_ORG <type> update-tag
ou : 0 Official LCAD <type> update-tag
ou : 0 Unofficial <type>
ou : 0 Un-official <type>
mais on peut aussi rencontrer : "LDRAW", "LDRAWORG", "OFFICIAL", "UNOFFICIAL", "UN-OFFICIAL".
Les chaines de caractères valides pour le champ <type> est :
On peut aussi trouver : Configuration, Unofficial_Model.
Le champ optionnel qualifier(s) est utilisé pour les pièces officielles, et donne son état, comme : ORIGINAL (Original), UPDATE (Mis à jour).
Le champ optionnel update-tag est utilisé pour les pièces officielles "UPDATE" (Mis à jour), et donne l'année et le rang de la mise à jour au format AAAA-RR, comme : 1998-02 (1998 2ème mise-à-jour).
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.
Format de la ligne :
0 !LICENSE Not redistributable : see NonCAreadme.txt
ou : 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
ou : 0 !LICENSE Licensed under CC BY 4.0 : see CAreadme.txt
ou : 0 !LICENSE Licensed under CC BY 2.0 and CC BY 4.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).
Depuis le 23-02-2022, la base de données des pièces LDraw passe progressivement sous CCAL version 4.0.
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). Aujourd'hui, cette méta-commande n'a plus qu'une seule utilisation, définir la couleur que la pièce a dans des circonstances normales. Toutes les pièces qui ont été produites uniquement dans une seule couleur devraient recevoir cette méta-commande.
Format de la ligne :
0 !CMDLINE LDraw run-time command(s)
Utilisation actuelle :
0 !CMDLINE -ccolor
Avec l'option -c pour définir la couleur et color le code d'une couleur définie dans LDConfig.ldr (sans espace entre les deux).
Exemple :
0 !CMDLINE -c14
Dans cet exemple la pièce est définie et affichée en jaune.
Cette méta-commande permet de noter l'historique des modifications et officialisation de la pièce.
Format de la ligne :
0 !HISTORY YYYY-MM-DD [UserName] Free text description of change. This can wrap to a
0 !HISTORY YYYY-MM-DD [UserName] second row with the same date if necessary. However authors should lean toward writing longer
0 !HISTORY YYYY-MM-DD [UserName] single !HISTORY lines(and not feel constrained to the historic 80-character limit on line length)
0 !HISTORY 2008-07-01 [PTadmin] Official Update 2008-01
0 !HISTORY YYYY-MM-DD {RealName} Free text description of change
YYYY-MM-DD : est la date de la modification ou officialisation en année, mois, jour. Exemple : 2004-08-25 pour le 25 août 2004.
YYYY-RR : Pour les officialisations, dans le corps de l'historique, apparait une date donnée par l'année de mise à jour du fichier de pièce LDraw (YYYY), et la version dans l'année (RR).
[UserName] : Les parenthèses carrées sont incluses pour indiquer le nom d'utilisateur LDraw. [PTadmin] est l'un des administrateurs de LDraw.org.
{RealName} : Ce type de parenthèses sont incluses pour indiquer le nom réel du rédacteur de la modification (peu employé).
Lorsque le fichier de pièce a été créé à partir d'un fichier existant en dehors du système LDraw, il faut définir cette source.
Exemple en provenance de l'équipe de développement LEGO Universe (projet aujourd'hui arrêté) :
0 !HISTORY 2010-02-09 {LEGO Universe Team} Original part shape
0 !HISTORY 2010-02-21 [Philo] File preparation for LDraw Parts Tracker
Exemple en provenance de l'équipe de développement LEGO Technic :
0 !HISTORY 2012-09-12 {LEGO Technic Team} Original part shape
0 !HISTORY 2012-10-11 [Philo] Complete rebuild for LDraw Parts Tracker
Exemple en provenance de l'équipe de développement LEGO Mindstorms :
0 !HISTORY 2012-05-20 {LEGO MINDSTORMS Team} Original part shape
0 !HISTORY 2012-06-28 [Philo] Complete rebuild for LDraw Parts Tracker
Exemple en capture de données du programme LDD :
0 !HISTORY 2013-03-08 {LEGO Digital Designer} Original part shape
0 !HISTORY 2013-03-08 [angmarec] File preparation for LDraw Parts Tracker
Exemple en conversion de données du programme LEGO/Unity :
0 !HISTORY 2020-12-12 {LEGO/Unity Microgame} Original part shape
0 !HISTORY 2020-12-12 [Philo] File preparation for LDraw Parts Tracker
Exemple en conversion de données de l'application Instructions de montage LEGO :
0 !HISTORY 2022-06-28 {LEGO Instructions App} Original part shape
0 !HISTORY 2022-06-28 [Philo] File preparation for LDraw Parts Tracker
Les méta-commandes !CATEGORY et !KEYWORDS sont là pour donner des
informations pour organiser et chercher dans la bibliothèque LDraw.
Avant que les méta-commandes !CATEGORY et !KEYWORDS soient définis,
la seule façon d'organiser la bibliothèque de pièces, était d'utiliser
le nom descriptif (descriptive name), et le numéro de la pièce (part number).
Cela est précieux, mais le nom et le numéro ne donne pas assez d'informations,
pour cataloguer la bibliothèque d'un grand nombre de pièces.
Ces méta-commandes sont utilisées dans les fichiers de pièces
uniquement. Elles ne doivent pas apparaître dans les modèles,
primitives, ou parties de pièces (subparts).
La différence entre les deux méta-commandes est :
La position de ces méta-commandes, dans l'en-tête du fichier, est formalisée 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 :
Nota :
- Pour Helper, seules les pièces avec le type de pièce "Helper" peuvent utiliser cette catégorie.
- Pour Moved, seul "Moved to" peut utiliser cette catégorie.
- Pour Obsolete, seul les pièces obsolètes peuvent utiliser cette catégorie.
De nouvelles catégories ne peuvent être ajoutées que par le "LDraw Standard Committee".
Le 9 août 2012, et avec la sortie des pièces officielles 2012-02 sont apparus de nouvelles catégories pour les équipements de Minifig :
Si un fichier de pièce ne contient pas de commande de catégorie, la catégorie prend en compte le premier mot du titre du fichier (file title).
Cette méta-commande est indispensable si le premier mot du nom descriptif de la pièce n'est pas dans la liste des catégories officielles données ci-dessus.
Source : LDraw.org CATEGORY and KEYWORDS Language Extension.
Nota : En conséquence des points précédents, la plupart des pièces ne doivent pas comporter de méta-commande !CATEGORY, car elles ont par défaut leur nom de catégorie comme premier mot de leur nom descriptif.
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 virgule 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 (ensemble) où apparait seulement cette pièce, et les thèmes de jeux ou la !CATEGORY. D'autres mots-clefs habituels sont les catégories des pièces similaires. Comme la méta-commande !CATEGORY, cette commande est utilisée exclusivement dans les fichiers de pièces.
Exemple :
0 Tile 1 x 2 with Playing Cards Pattern 0 Name: 3069bpw1.dat ... 0 !CATEGORY Tile 0 !KEYWORDS western, wild west, spaghetti western, horse opera, cowboy, desperado, bandit, cardsharper, swindler 0 !KEYWORDS casino, pocker, bridge, blackjack, twenty-one, baccarat, chemin de fer 0 !KEYWORDS stud, stud poker, strip poker, straight poker, penny ante, penny ante poker, high-low, draw, draw poker 0 !KEYWORDS pair, straight, flush, full house, straight flush, royal flush, eight-card stud 0 !KEYWORDS Set 377
Nota : Un moyen d'avoir une liste des mots-clefs d'une pièce est de rechercher cette pièce sur le site de Peeron. Les "Keywords" se trouvent juste sous le titre (s'il y en a).
Nota : Un autre moyen indiqué par Steffen et complété par Philo dans le suivi PT de la pièce 87079p01.dat : Lorsqu'il y a un motif symbolique (caractère asiatique, égyptien, symbole ethnique, ...), il suffit de faire une image séparée de chaque motif et de la soumettre sur le site de recherche d'image Google, en téléchargeant son image avec le petit bouton en forme d'appareil photo. S'il y a plusieurs caractères à rechercher une image de l'ensemble fera une recherche sur le sens du mot et non de la lettre seule.
Cette méta-commande est spécifique aux fichiers de modèles officiels. Reste pour l'instant (début 2012) expérimental, en particulier sur le découpage et la liste des thèmes.
Format de la ligne :
0 !THEME nom_du_thème
Le nom_du_thème peut (pourrait) être limité à 1 et 2 niveaux, ou bien 1 à 3 niveaux.
Exemples sur 1 niveau :
Creator
Universal Building Set
Exemples sur 2 niveaux :
Adventurers / Desert
Adventurers / Dino Island
Adventurers / Jungle
Exemples sur 3 niveaux :
Town / City / Police
Town / Classic Town / Police
Town / World City / Police
Voir la liste des thèmes sur le Wiki : http://wiki.ldraw.org/index.php?title=LDraw_Themes.
Pour les pièces soumises à LDraw.org il y a des restrictions sur les méta-commandes employées.
L'en-tête des fichiers de pièces doit être conforme au Official Library Header Specification (en Anglais).
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 appuyiez 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.
En pratique, ne semble plus utilisé aujourd'hui.
Pour les pièces soumises à 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 conformes à ces directives. Ces pièces (y compris celles se trouvant dans le "Part Tracker", pièces en cours d'officialisation) ne doivent pas être éditées dans le seul but de les rendre conforme. Cependant, si la pièce est modifiée pour n'importe quelle autre raison, les lignes non conformes doivent être mises à jour.
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 mises 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 ou sous-modèles dans un même fichier LDraw.
Un fichier MPD se compose de blocs de code LDraw séparés par des instructions 0 FILE ou 0! DATA. Chaque bloc est considéré comme un fichier distinct et peut être référencé par les autres selon les besoins.
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 principalement 3 méta-commandes. Seule la première est communément utilisée. La seconde !DATA est spécifique aux images incorporées et NOFILE est optionnel.
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.
Il y a des règles pour définir les noms des sous-modèles. Voir : En-têtes normalisées des modèles officiels.
Permet d'insérer les données d'une image dans le fichier MPD.
Les blocs commençant par l'instruction 0! DATA contiennent des données binaires codées à l'aide d'une multitude de lignes 0 !:. Chacune de ces lignes contient un bloc de données encodées en base64 qu'un analyseur doit combiner avant le décodage. Aucune autre instruction LDraw ne peut être utilisée dans un bloc !DATA.
Format de la première ligne :
0 !DATA image.png
Format des lignes suivantes :
0 !: chaine_de_caractères_base64
La chaine de caractères est un bloc de données codées en base64 (A-Za-z0-9+/) d'une longueur maximale de 80 caractères. Chaque ligne sauf la dernière doit utiliser la même longueur et être un multiple de 4 caractères. Remplir la dernière ligne de caractères "=" pour compléter son dernier groupe de 4 est facultatif.
Voir exemple : Incorporation de l'image dans un fichier MPD.
Indique la fin d'un sous-modèle.
Format de la ligne :
0 NOFILE
Il n'y a pas d'option ou paramètre.
La fin de chaque texte de code individuel, ou juste à la fin du dernier, peut être marquée 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.
Lorsqu'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 rendues. 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 antihoraire, lorsque le polygone est vu de face.
Sens horaire (les sommets sont numérotés de 0 à 3) :
0 -> 1 ^ | | v 3 <- 2
Sens antihoraire :
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 forment 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 les 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, antihoraire, 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 faces, 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 en-tête.
Si un fichier n'a pas de méta-commande 0 BFC avant la première méta-commande opérationnelle, alors il est considéré comme si il y avait une méta-commande 0 BFC NOCERTIFY, et le processus BFC est désactivé pour ce fichier.
NOCERTIFY
Cette option spécifie que ce fichier n'est pas compatible avec les spécifications BFC. Les polygones ne sont pas définis logiquement par des points dans le même sens, et/ou corrects, et/ou les références aux sous-fichiers ne sont pas inversés correctement. Si l'option NOCERTIFY est utilisée, 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 établies. 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é à 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 changements 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.
Dans la pratique l'instruction NOCLIP est utilisée pour les pièces transparentes à motif. Voir : Créer pièce : Pièce transparente à motif.
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 antihoraire.
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ée pour le fichier, l'état local du sens est mis par défaut à antihoraire, 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'en-tête) et/ou les exigences des administrateurs de cette bibliothèque, sans affecter la validité des spécifications du choix de la face arrière (BFC).
La bibliothèque de pièces LDraw inclue toutes les pièces, primitives, et parties de pièces distribuées avec LDraw ou avec les mises à jour de pièces de LDraw.org.
Les nouvelles pièces ne sont pas exigées compliantes avec cette extension du langage LDraw. Il sera seulement exigé d'avoir une méta-commande 0 BFC, indiquant si elle est compliante ou non compliante.
Les nouvelles primitives sont exigées compliantes pour être acceptées dans les mises à jour.
Il est désirable que tous les fichiers utilisent le même sens. Lorsque c'est possible, les fichiers doivent utiliser le sens antihoraire. 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 telles façons que les polygones aient leur face avant à l'extérieur, ou vers le haut. Des exceptions sont permises pour les polygones qui modélisent les parties internes ou inférieures.
Comme indiqué plus haut, tous les fichiers compliants BFC de la bibliothèque de pièces LDraw doivent avoir une ligne explicite contenant 0 BFC CERTIFY dans leur en-tête.
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ée.
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 antihoraire).
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 fichiers 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ée, 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
La texturation, c'est-à-dire la projection d'une image 2D (texture) sur des objets LDraw 3D est pour l'instant à l'état de projet avancé. Actuellement, LDView en v4.2 Beta 1 (04-2012) permet de visualiser les textures, Bricksmith v2.6 (30-10-2012) supporte les textures planes, et également LeoCAD v0.79 (13-12-2012), LDCad les textures tous types.
Source principale : Language Extension for Texture Mapping, Révision 1.0 du 4 octobre 2012.
Format général
0 !TEXMAP (START | NEXT) <method> <parameters> <pngfile> [GLOSSMAP pngfile] 0 !: <geometry1> ... <geometry2> ... 0 !TEXMAP FALLBACK <geometry3> ... 0 !TEXMAP END
Description
0 !TEXMAP est la méta-commande principale de déclaration de texture.
0 !: est utilisé pour spécifier la géométrie mappée qui sera ignorée par les programmes de visualisation qui ne supportent pas la méta-commande !TEXMAP. Elle ne peut être incorporée à cette dernière. La méta-commande actuelle est le deux-points, et a été choisie pour être bref, facile à lire dans les fichiers, et sans rentrer en conflit avec d'autres méta-commandes ou programmes existants.
La commande START indique que la texture donnée devra être utilisé. Si une autre texture est en cours d'utilisation, elle est mise dans une pile pour la retrouver lorsque la commande END est fournie. Cette texture reste active jusqu'à l'apparition de la commande END, ou lorsque qu'on arrive à la fin du fichier qui contient le START. La texture reste active lorsque le processus traite un sous-fichier, à moins qu'elle ne soit écrasée dans ce sous-fichier.
La commande FALLBACK est un séparateur de section. Dans une application supportant le texturage toutes les lignes de géométrie qui suivent un !: servant de commentaire (geometry1) ou les lignes de géométrie LDraw standards (geometry2), entre START et FALLBACK sont utilisées comme géométrie, et ont la texture appliquée. Toutes les lignes de géométrie entre FALLBACK et END (geometry3) sont ignorées. Dans une application qui ne supporte pas le texturage, il n'y a rien à faire de spécial car toutes les géométries non commentées (geometry2 et geometry3), sont générées normalement, tandis que celles commentées (geometry1) sont ignorées. Nota : L'auteur d'une pièce LDraw devra être très prudent pour ne pas introduire involontairement une ligne de géométrie non commentée entre les sections START et FALLBACK.
En général, la section entre START et FALLBACK contient seulement de la géométrie commentée suivant un marqueur 0 !:, et la section entre FALLBACK et END est de la géométrie non commentée.
Nota : Il faut être prudent et réfléchir à l'approche lorsque l'on veut introduire de la géométrie non commentée avant FALLBACK (geometry2). Cette fonction est présente pour pouvoir utiliser une géométrie identique en mode texturé et non texturé. C'est un cas rare, et normalement cela sera peu employé.
La commande END cesse l'utilisation de la texture en cours, et restaure la précédente texture comme texture en cours. Cela veut dire qu'une commande START imbriquée formera une pile de textures, et qu'une commande END dépilera les textures. Si une commande END apparait dans un sous-fichier cela fait cesser l'utilisation de la texture spécifiée dans le fichier appelant, puis cette texture sera restaurée pour l'utiliser lorsque le sous-fichier sera fini d'être traité.
La commande NEXT est un raccourci pour qu'une texture ne fonctionne que sur la ligne de types 1, 2, 3, 4 ou 5 suivante. C'est un usage équivalent à utiliser une commande START, puis une seule ligne de géométrie, avant une commande END, sans possibilité de commande FALLBACK. La première ligne non vide qui suit cette commande NEXT ne doit pas être une ligne commençant par 0. Si cela est, la commande NEXT elle-même pourra être ignorée, et un message d'erreur pourra être généré, si l'environnement est prévu pour générer des messages vers l'utilisateur.
L'indicateur method spécifie la méthode de projection à utiliser pour la texture. Chaque méthode de projection a son propre ensemble de paramètres, et l'analyse des paramètres dépend de la méthode.
Il y a 3 méthodes de projection utilisables : PLANAR (plane), CYLINDRICAL (cylindrique) et SPHERICAL (sphérique), Ces méthodes et leurs paramètres sont décrits plus bas.
Le premier fichier au format PNG pngfile représente la texture à appliquer. Elle peut être en noir et blanc ou en couleurs, et si un canal Alpha existe, il devrait être appliqué convenablement (permettre à la couleur de la pièce de se voir à travers). Le second fichier PNG optionnel derrière GLOSSMAP est utilisé comme texture d'apparence. Il devrait être une image à un seul canal, où la valeur indique la spécularité qui s'ajoute à la texture de la pièce. Les valeurs RVB sont actuellement ignorées, mais réservées, dans ce second fichier, et le canal Alpha détermine le degré de réflexion de la texture donnée.
Les noms des fichiers pngfile qui contiennent des espaces doivent être entourés de doubles-guillemets ("). En outre une recherche du fichier sera tenté en ajoutant "textures/" comme préfixe en premier, puis la recherche se fera dans les dossiers standards LDraw. Si aucun fichier n'est trouvé, la recherche sera répétée sans le préfixe "textures/". Les noms de fichiers qui contiennent eux-mêmes des doubles-guillemets doivent avoir un caractère anti-slash (\) devant chaque. Le caractère \ lui-même doit être doublé (\\) pour être utilisé comme séparateur de sous-dossier, mais il est recommandé d'utiliser le caractère slash (/) dans ce cas. Nota : Dans les fichiers LDraw, \ et / sont interchangeables comme séparateurs du chemin d'un dossier.
Cette nouvelle possibilité (05-2020) utilise les méta-commandes 0 !DATA et 0 !: comme suite. Le but est d'obtenir un seul fichier à transmettre pour un modèle donné, en dehors de la bibliothèque de pièces officielle.
Source principale : MPD Language Extension, Révision 2 du 26 mai 2020.
Format général (exemple)
0 FILE main.ldr 1 7 0 0 0 1 0 0 0 1 0 0 0 1 819.dat 1 4 80 -8 70 1 0 0 0 1 0 0 0 1 house.ldr 1 4 -70 -8 20 0 0 -1 0 1 0 1 0 0 house.ldr 1 4 50 -8 -20 0 0 -1 0 1 0 1 0 0 house.ldr 1 4 0 -8 -30 1 0 0 0 1 0 0 0 1 house.ldr 1 4 -20 -8 70 1 0 0 0 1 0 0 0 1 house.ldr 0 FILE house.ldr 1 16 0 0 0 1 0 0 0 1 0 0 0 1 3023.dat 1 16 0 -24 0 1 0 0 0 1 0 0 0 1 3065.dat 1 16 0 -48 0 1 0 0 0 1 0 0 0 1 3065.dat 1 16 0 -72 0 0 0 -1 0 1 0 1 0 0 3044b.dat 1 4 0 -22 -10 1 0 0 0 0 -1 0 1 0 sticker.ldr 0 FILE sticker.ldr 0 UNOFFICIAL PART 0 BFC CERTIFY CCW 1 16 0 -0.25 0 20 0 0 0 0.25 0 0 0 30 box5.dat 0 !TEXMAP START PLANAR -20 -0.25 30 20 -0.25 30 -20 -0.25 -30 sticker.png 4 16 -20 -0.25 30 -20 -0.25 -30 20 -0.25 -30 20 -0.25 30 0 !TEXMAP END 0 !DATA sticker.png 0 !: iVBORw0KGgoAAAANSUhEUgAAAFAAAAB4CAIAAADqjOKhAAAAAXNSR0IArs4c6QAAAARnQU1BAACx 0 !: jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAEUSURBVHhe7du9DcIwFABhk5WgQLSsQM0UjMEU 0 !: 1BQsQIsoYAt6NkAYxQV/JQ7WvfuKkFTR6UmOFJzR9bJLkXTlNwyD6QymM5ju5Tl8m67KGUt3XJcz 0 !: J/yY8HZ/6C8BFvNZPoaesMF0BtMZTGcwncF0BtMZTGcwncF0BtMZTGcwnf8t0bmLh85gOoPpDKYz 0 !: mM5gOoPpDKYzmM5gunDBf3tN+/zqNKt367cbOeGUTstxf1nJZHPOx68T/u3XB5/7/zMXLTqD6Qym 0 !: M5jOYDqD6QymM5jOYDqD6QymM5jOYDqD6QymM5jOYLpwwW3t8ajBXTxtTHgwLlp0BtMZTGcwncF0 0 !: BtMZTNfKZzyDiT3hCFy06IIFp3QH/CBMh66aBy4AAAAASUVORK5CYII=
L'exemple sous LDCad v1.7 (Non publié en 05-2020) :
La méthode PLANAR
Les paramètres pour PLANAR sont :x1 y1 z1 x2 y2 z2 x3 y3 z3
Ces trois points représentent 3 coins de la texture en coordonnées 3D. Ils forment un plan sur lequel les objets peuvent être projetés et représentent également l'étendue de la texture.
De plus, par les points 1 et 3 passe un plan P1 perpendiculaire au plan de la texture, où le point 1 est sur le plan et la normale à ce plan va du point 1 au point 2. De façon similaire, par les points 1 et 2 passe un plan P2 perpendiculaire aux deux plans précédents. Ce plan contient également point 1 mais sa normale va du point 1 au point 3.
Maintenant, pour faire correspondre les coordonnées 3D aux coordonnées de la texture, U est donné par la distance entre un point et le plan P1 divisé par la longueur du vecteur du point 1 au point 2. V est donné par la distance entre un point et le plan P2 divisé par la longueur du vecteur du point 1 au point 3. Ensuite U et V sont normalisés pour être entre 0 et 1. Cela peut maintenant faire correspondre les pixels de la texture à la zone à texturer.
Nota : Une projection plane ne veut pas dire que l'objet recevant la texture doit être plan. Il peut être de forme courbe ou bosselé... mais pas trop !
La méthode CYLINDRICAL
Les paramètres pour CYLINDRICAL sont :x1 y1 z1 x2 y2 z2 x3 y3 z3 a
Le premier point représente le centre de la base du cylindre. Le second représente le centre du haut du cylindre. Le troisième représente un emplacement sur le bord externe de la base où le centre bas de la texture toucherait. L'angle a indique la portion du cylindre couvert par la texture, et donc l'étendue peut aller de -a/2 à a/2 en mesure relative à la ligne radiale allant du point 1 au point 3.
Maintenant, pour faire correspondre les coordonnées 3D aux coordonnées de la texture, U est donné par l'angle entre le vecteur formé par les points 1 et 3 et le vecteur formé par le point 1 et un point 3D qui a été projeté sur le plan occupé par la base du cylindre. Cet angle est ensuite divisé par le paramètre "a" pour le normaliser entre 0 et 1. V est donné par la distance d'un point au plan occupé par la base du cylindre et divisé par la longueur du vecteur formé par les points 1 et 2.
La méthode SPHERICAL
Les paramètres pour SPHERICAL sont :x1 y1 z1 x2 y2 z2 x3 y3 z3 a b
Le premier point représente le centre de la sphère. Le second représente un point sur la sphère ou le centre de la texture va toucher. Le troisième est utilisé pour former un plan P1 perpendiculaire à la texture et la coupant en deux horizontalement. Un plan additionnel P2 peut être calculé en utilisant les points 1 et 2 et en générant un troisième point sur la normale à P1. P2 sera perpendiculaire à la fois à P1 et à la texture et coupe la texture en deux verticalement. Les deux angles a et b indiquent la portion de la sphère couverte par la texture, et donc l'étendue peut aller de -a/2 à a/2 et de -b/2 à b/2 en mesure relative au vecteur allant du point 1 au point 2 et respectivement sur les plans P1 et P2.
Maintenant, pour faire correspondre les coordonnées 3D aux coordonnées de la texture, U est donné par l'angle entre le vecteur formé par les points 1 et 2 et le vecteur formé par le point 1 et un point 3D qui a été projeté sur le plan P1. Cet angle est ensuite divisé par le paramètre "a" pour le normaliser entre 0 et 1. V est donné par l'angle entre le vecteur formé par les points 1 et 2 et le vecteur formé par le point 1 et un point 3D qui a été projeté sur le plan P2. Cet angle est ensuite divisé par le paramètre "b" pour le normaliser entre 0 et 1.
Nota : Au 10-2012 la discussion n'est pas terminée sur la définition de la méta-commande TEXMAP, et peut donc changer.
Une proposition a été faite pour incorporer l'image dans le fichier pièce et ne plus avoir de fichier externe. Cette proposition reste pour l'instant à l'état de projet.
Format proposé
0 !DATA START 0 !: <data1> 0 !: <data2> ... 0 !: <datan> 0 !DATA END
Voir origine : Proposal: New !DATA meta-command for embedded textures (en Anglais).
Exemples de texturations avec LDPartEditor.
Exemple sous LDView de la pièce 19204p01 montrant la projection plane
d'une image comportant un dégradé de couleur (à gauche) avec le résultat sur la pièce bosselée.
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.
Depuis 06-2019, le numéro LDraw dépasse la valeur 511 et atteint des valeurs supérieures à 10000 (voir
les couleurs caoutchouc. Cette haute valeur peut poser des problèmes avec certains programmes comme MLCad
qui est limité à 511.
Voici une table des 16 couleurs de base (codes 0 à 15) :
| N° LDraw |
N° LEGO |
Couleur | Nom Français |
Nom Anglais |
RGB | Observation |
|---|---|---|---|---|---|---|
| 0 | 26 | Noir | Black | #1B2A34 | ||
| 1 | 23 | Bleu | Blue (Bright Blue) | #1E5AA8 | ||
| 2 | 28 | Vert | Green (Dark Green) | #00852B | ||
| 3 | 107 | Turquoise Foncé (Sarcelle) | Dark Turquoise (Bright Bluish Green, Teal) | #069D9F | ||
| 4 | 21 | Rouge | Red (Bright Red) | #B40000 | ||
| 5 | 22 221 |
Rose Foncé | Dark Pink (Medium Reddish Violet, Bright Purple) | #D3359D | ||
| 6 | 25 | Marron | Brown (Earth Orange) | #543324 | Remplacé par couleur 70 (Brun Rougeâtre) vers 2004. | |
| 7 | 2 | Gris Clair | Light Grey (Grey) | #8A928D | Remplacé par couleur 71 (Gris Bleuté Clair) vers 2004. | |
| 8 | 27 | Gris Foncé | Dark Grey | #545955 | Remplacé par couleur 72 (Gris Bleuté Foncé) vers 2004. | |
| 9 | 45 | Bleu Clair | Light Blue | #97CBD9 | ||
| 10 | 37 | Vert Clair | Bright Green | #58AB41 | ||
| 11 | 116 | Turquoise | Light Turquoise (Medium Bluish Green) | #00AAA4 | ||
| 12 | 101 | Saumon | Salmon (Medium Red) | #F06D61 | ||
| 13 | 9 | Rose | Pink (Light Reddish Violet) | #F6A9BB | ||
| 14 | 24 | Jaune | Yellow (Bright Yellow) | #FAC80A | ||
| 15 | 1 | Blanc | White | #F4F4F4 |
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 ici 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 était gris et maintenant jaune clair.
| N° LDraw |
N° LEGO |
Couleur (par défaut) |
Nom Français |
Nom Anglais |
RGB |
|---|---|---|---|---|---|
| 16 | - | Couleur principale, ou courante | Main color | #FFFF80 |
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). Lorsqu'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 #B40000 EDGE #333333
| La couleur rouge : | #B40000 | , 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 appelait é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és 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 ou solides sont aujourd'hui définies dans le fichier ldconfig.ldr. Depuis 05-2020 les couleurs de base (0 à 15) font partie intégrante des couleurs unies.
Voici une table des couleurs unies :
| N° LDraw |
N° LEGO |
Couleur | Nom Français |
Nom Anglais |
RGB | Observation |
|---|---|---|---|---|---|---|
| 17 | 6 | Vert Clair | Light Green | #ADD9A8 | ||
| 18 | 3 | Jaune Clair | Light Yellow | #FFD67F | ||
| 19 | 5 | Beige (Jaune Brique) | Tan (Brick Yellow) | #B0A06F | ||
| 20 | 39 | Violet Clair | Light Violet (Light Bluish Violet) | #AFBED6 | ||
| 22 | 104 | Violet | Purple (Bright Violet) | #671F81 | ||
| 23 | 196 | Violet Bleuté Foncé | Dark Blue Violet (Dark Royal Blue) | #0E3E9A | ||
| 25 | 106 | Orange (Orange Lumineux) | Orange (Bright Orange) | #D67923 | ||
| 26 | 124 | Magenta (Violet Rougeâtre Lumineux) | Magenta (Bright Reddish Violet) | #901F76 | ||
| 27 | 119 | Citron vert (Vert Jaunâtre Lumineux) | Lime (Bright Yellowish Green) | #A5CA18 | ||
| 28 | 138 | Beige Foncé (Sable) | Dark Tan (Sand Yellow) | #897D62 | ||
| 29 | 222 | Rose Lumineux | Bright Pink (Light Purple) | #FF9ECD | ||
| 30 | 324 | Lavande Moyen | Medium Lavender | #A06EB9 | ||
| 31 | 325 | Lavande | Lavender | #CDA4DE | ||
| 68 | 36 | Orange Très Clair | Very Light Orange (Light Yellowish Orange) | #FDC383 | ||
| 69 | 198 | Lila Rougeâtre Clair | Bright Reddish Lilac | #8A12A8 | ||
| 70 | 192 | Brun Rougeâtre | Reddish Brown | #5F3109 | Remplace couleur 6 (Marron) depuis 2004. | |
| 71 | 194 | Gris Bleuté Clair | Light Bluish Gray (Medium Stone Grey) | #969696 | Remplace couleur 7 (Gris Clair) depuis 2004. | |
| 72 | 199 | Gris Bleuté Foncé | Dark Bluish Gray (Dark Stone Grey) | #646464 | Remplace couleur 8 (Gris Foncé) depuis 2004. | |
| 73 | 102 | Bleu Moyen | Medium Blue | #7396C8 | ||
| 74 | 29 | Vert Moyen | Medium Green | #7FC475 | ||
| 77 | 223 | Rose Clair | Light Pink | #FECCCF | ||
| 78 | 283 | Nougat Clair (Chair Clair) | Light Nougat | #FFC995 | ||
| 84 | 312 | Nougat Moyen | Medium Nougat | #AA7D55 | ||
| 85 | 268 | Lila Moyen | Medium Lilac (Dark Purple) | #441A91 | ||
| 86 | 217 | Brun Moyen | Medium Brown (Brown) | #7B5D41 | ||
| 89 | 195 | Bleu Violet | Blue Violet (Medium Royal Blue) | #1C58A7 | ||
| 92 | 18 | Nougat (Chair) | Nougat | #BB805A | ||
| 100 | 100 | Saumon Clair | Light Salmon (Light Red) | #F9B7A5 | ||
| 110 | 110 | Violet | Violet (Bright Bluish Violet) | #26469A | ||
| 112 | 112 | Violet Moyen | Medium Violet (Medium Bluish Violet) | #4861AC | ||
| 115 | 115 | Citron Vert Moyen | Medium Lime (Medium Yellowish Green) | #B7D425 | ||
| 118 | 118 | Vert d'Eau | Aqua (Light Bluish Green) | #9CD6CC | ||
| 120 | 120 | Citron Vert Clair | Light Lime (Light Yellowish Green) | #DEEA92 | ||
| 125 | 125 | Orange Clair | Light Orange | #F9A777 | ||
| 128 | 128 | Nougat Foncé | Dark Nougat | #AD6140 | ||
| 151 | 208 | Gris Bleuté Très Clair | Very Light Bluish Gray (Light Stone Gey) | #C8C8C8 | ||
| 191 | 191 | Orange Clair Lumineux | Bright Light Orange (Flame Yellowish Orange) | #FCAC00 | ||
| 212 | 212 | Bleu Clair Lumineux | Bright Light Blue (Light Royal Blue) | #9DC3F7 | ||
| 216 | 216 | Rouille | Rust | #872B17 | ||
| 218 | 218 | Lila Rougeâtre | Reddish Lilac | #8E5597 | ||
| 219 | 219 | Lila | Lilac | #564E9D | ||
| 226 | 226 | Jaune Clair Lumineux | Bright Light Yellow (Cool Yellow) | #FFEC6C | ||
| 232 | 232 | Bleu Ciel | Sky Blue (Dove Blue) | #77C9D8 | ||
| 272 | 140 | Bleu Foncé | Dark Blue (Earth Blue) | #19325A | ||
| 288 | 141 | Vert Foncé | Dark Green (Earth Green) | #00451A | ||
| 295 | 295 | Rose Flamant | Flamingo Pink | #FF94C2 | ||
| 308 | 308 | Brun Foncé | Dark Brown | #352100 | ||
| 313 | 11 | Bleu Maersk | Maersk Blue (Pastel Blue) | #ABD9FF | ||
| 320 | 154 | Rouge Foncé | Dark Red (New Dark Red) | #720012 | ||
| 321 | 321 | Azur Foncé | Dark Azure (Dark Azur) | #469BC3 | ||
| 322 | 322 | Azur Moyen | Medium Azure (Medium Azur) | #68C3E2 | ||
| 323 | 323 | Eau Claire | Light Aqua (Aqua) | #D3F2EA | ||
| 326 | 326 | Vert Jaunâtre | Yellowish Green (Spring Yellowish Green) | #E2F99A | ||
| 330 | 330 | Vert Olive | Olive Green | #77774E | ||
| 335 | 153 | Rouge Sable | Sand Red | #88605E | ||
| 351 | 16 | Rose Foncé Moyen | Medium Dark Pink (Pink) | #F785B1 | ||
| 353 | 353 | Corail | Coral (Vibrant Coral) | #FF6D77 | ||
| 366 | 12 | Orange Terre | Earth Orange (Light Orange Brown) | #D86D2C | ||
| 368 | 368 | Jaune vif | Vibrant Yellow | #EDFF21 | ||
| 370 | 370 | Brun Moyen | Medium Brown | #755945 | ||
| 373 | 136 | Violet Sable | Sand Purple (Sand Violet) | #75657D | ||
| 378 | 151 | Vert Sable | Sand Green | #708E7C | ||
| 379 | 135 | Bleu Sable | Sand Blue | #70819A | ||
| 450 | 4 | Brun Fabuland | Fabuland Brown (Brick Red) | #D27744 | ||
| 462 | 105 | Orange Moyen | Medium Orange (Bright Yellowish Orange) | #F58624 | ||
| 484 | 38 | Orange Foncé | Dark Orange | #91501C | ||
| 503 | 103 | Gris Très Clair | Very Light Grey (Light Grey) | #BCB4A5 | ||
| 507 | 12 | Brun Orange Clair | Light Orange Brown | #FA9C1C | ||
| 508 | 13 | Rouge Fabuland | Fabuland Red (Red Orange) | #FF8014 | ||
| 509 | 19 | Orange Fabuland | Fabuland Orange (Light Brown) | #CF8A47 | ||
| 510 | 14 | Vert Fabuland | Fabuland Pastel Green (Pastel Green) | #78FC78 | ||
| - | Jaune Fluorescent | Fluorescent Yellow | #FAE600 |
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 |
|---|---|---|---|---|---|
| 33 | 43 | Transparent Bleu Foncé | Trans Dark Blue (Transparent Blue) | #0020A0 | |
| 34 | 48 | Transparent Vert | Trans Green (Transparent Green) | #237841 | |
| 35 | 311 | Transparent Vert Lumineux | Trans Bright Green (Transparent Bright Green) | #56E646 | |
| 36 | 41 | Transparent Rouge | Trans Red (Transparent Red) | #C91A09 | |
| 37 | 113 | Transparent Rose Foncé | Trans Dark Pink (Transparent Medium Reddish Violet) | #DF6695 | |
| 38 | 47 | Transparent Orange Néon | Trans Neon Orange (Transparent Fluorescent Reddish Orange) | #FF800D | |
| 39 | 229 | Transparent Bleu Très Clair | Trans Very Light Blue (Transparent Light Bluish Green) | #C1DFF0 | |
| 40 | 111 | Transparent Noir | Trans Black (Transparent Brown) | #635F52 | |
| 41 | 143 | Transparent Bleu Moyen | Trans Medium Blue (Transparent Fluorescent Blue) | #559AB7 | |
| 42 | 49 | Transparent Vert Néon | Trans Neon Green (Transparent Fluorescent Green) | #C0FF00 | |
| 43 | 42 | Transparent Bleu Clair | Trans Light Blue (Transparent Light Blue) | #AEE9EF | |
| 44 | 236 | Transparent Lila Clair | Trans Bright Reddish Lilac (Transparent Bright Reddish Lilac) | #96709F | |
| 45 | 230 | Transparent Rose | Trans Pink (Transparent Bright Pink) | #FC97AC | |
| 46 | 44 | Transparent Jaune | Trans Yellow (Transparent Yellow) | #F5CD2F | |
| 47 | 40 | Transparent | Trans Clear (Transparent) | #FCFCFC | |
| 52 | 126 | Transparent Violet | Trans Purple (Transparent Bright Bluish Violet) | #A5A5CB | |
| 54 | 157 | Transparent Jaune Néon | Trans Neon Yellow (Transparent Fluorescent Yellow) | #DAB000 | |
| 57 | 182 | Transparent Orange | Trans Orange (Trans Bright Orange) | #F08F1C | |
| 227 | 227 | Transparent Vert Clair Lumineux | Transparent Bright Yellowish Green | #86B22E | |
| 231 | 231 | Transparent Orange Clair Lumineux | Tans Bright Light Orange (Transparent Flame Yellowish Orange) | #FCB76D | |
| 234 | 234 | Transparent Jaune Feu | Trans Fire Yellow (Transparent Fire Yellow) | #FBE890 | |
| 284 | 284 | Transparent Lila Rougeâtre | Trans Reddish Lilac (Transparent Reddish Lilac) | #C281A5 | |
| 285 | 285 | Transparent Vert Clair | Trans Light Green (Transparent Light Green) | #7DC291 | |
| 293 | 293 | Transparent Bleu Violet Clair | Trans Light Blue Violet (Transparent Light Royal Blue) | #6BABE4 |
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 (Transparent Medium Reddish-Violet w. Glitter 2%) | #DF6695 | ||
| 117 | 117 | Transparent à Inclusion | Glitter Trans Clear (Transparent Glitter) | #EEEEEE | ||
| 129 | 129 | Violet Transparent à Inclusion | Glitter Trans Purple (Transparent Bright Bluish Violet w. Glitter 2%) | #640061 | ||
| 302 | 302 | Bleu Clair Transparent à Inclusion | Glitter Trans Light Blue (Transparent Light Blue with Glitter 2%) | #AEE9EF | ||
| 339 | 339 | Vert Néon Transparent à Inclusion | Glitter Trans Neon Green (Transparent Fluorescent Green with Glitter 2%) | #C0FF00 | ||
| 341 | 341 | Orange Transparent à Inclusion | Glitter Trans Orange (Transparent Bright Orange with Glitter 2%) | #F08F1C | ||
| 360 | 360 | Opale Transparent à Inclusion | Opal Trans Clear (Transparent Clear Opal) | #FCFCFC | ||
| 362 | 362 | Opale Bleue Transparent à Inclusion | Opal Trans Light Blue (Transparent Blue Opal) | #AEE9EF | ||
| 363 | 363 | Opale Brun Transparent à Inclusion | Opal Trans Black (Transparent Brown Opal) | #635F52 | ||
| 364 | 364 | Opale Rose Foncé Transparent à Inclusion | Opal Trans Dark Pink (Transparent Medium Reddish Violet Opal) | #DF6695 | ||
| 365 | 365 | Opale Violet Transparent à Inclusion | Opal Trans Purple (Transparent Violet Opal) | #671F81 | ||
| 367 | 367 | Opale Vert Transparent à Inclusion | Opal Trans Green (Transparent Green Opal) | #237841 | ||
| 10351 | 351 | Vert Clair Transparent à Inclusion | Glitter Trans Bright Green (Transparent Bright Green with Glitter 2%) | #56E646 | ||
| 10366 | 366 | Opale Bleu Foncé Transparent à Inclusion | Opal Trans Dark Blue (Transparent Blue Opal) | #0020A0 |
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 336 |
Métal Argent | Metallic Silver (Cool Silver Drum Lacq, Silver Ink) | #767676 | Pour les pièces à motif ou peinture argentée, autocollant argenté. | |
| 200 | Métal Vert | Metallic Green (Lemon Metallic) | #6A7944 | Voir couleur nacrée (Pearl) | ||
| 82 | 299 335 |
Métal Doré | Metallic Gold (Warm Gold Drum Lacq, Gold Ink) | #DBAC34 | Pour les pièces à motif ou peinture dorée, autocollant doré. | |
| 149 | Métal Noir | Metallic Black | #0A1327 | Voir couleur nacrée (Pearl) | ||
| 87 | 337 336 |
Métal Gris Foncé | Metallic Dark Grey (Titanium) | #3E3C39 | ||
| 184 | Métal Rouge Clair | Metallic Bright Red | #D60026 | Voir couleur nacrée (Pearl) | ||
| 186 | Métal Vert Foncé | Metallic Dark Green | #008E3C | Voir couleur nacrée (Pearl) | ||
| 300 | 300 334 |
Métal Cuivré | Metallic Copper (Copper Drum Lacq, Copper Ink) | #C27F53 | ||
| 10045 | - | Métal Bleu Clair | Metallic Light Blue | #97CBD9 |
Couleurs existantes dans le fichier de configuration ldconfig.ldr :
| N° LDraw |
N° LEGO |
Couleur | Nom Français |
Nom Anglais |
RGB | Observation |
|---|---|---|---|---|---|---|
| 60 | Chrome Cuivre Antique (Vert-de-gris) | Chrome Antique Brass (Metallic Earth Orange) | #645A4C | |||
| 61 | Chrome Bleu | Chrome Blue (Metallic Bright Blue) | #6C96BF | |||
| 62 | Chrome Vert | Chrome Green (Metallic Dark Green) | #3CB371 | |||
| 63 | - | Chrome Rose | Chrome Pink | #AA4D8E | ||
| 64 | - | Chrome Noir | Chrome Black | #1B2A34 | ||
| 334 | 310 | Chrome Or (Doré) | Chrome Gold (Metalized Gold) | #DFC176 | Utilisé pour pièce à revêtement doré | |
| 383 | 309 | Chrome Argent (Argenté) | Chrome Silver (Metalized Silver) | #CECECE | Utilisé pour pièce à revêtement chromé. |
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 | #FFFF80 | Voir : ci-dessus | |
| 24 | - | Couleur de Bord | Edge Color | #7F7F7F | Voir : ci-dessus | |
| 32 | 109 | Noir Transparent de Cellule Infrarouge | Trans Black IR Lens (Black IR) | #000000 | ||
| 493 | - | Aimant | Magnet | #656761 | Utilisé pour les aimants. | |
| 494 | - | Contact Electrique Métal Blanc | Electric Contact Alloy | #D0D0D0 | Utilisé pour contact électrique (tenons). Utilisé pour pièce réellement métallique, dont l'acier. | |
| 495 | - | Contact Electrique Cuivré | Electric Contact Copper | #AE7A59 | Utilisé pour contact électrique cuivré (tenons). | |
| 10047 | - | Autocollant Transparent | Trans Sticker | #FFFFFF | Utilisé pour le fond des autocollants transparents. |
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 |
|---|---|---|---|---|---|---|
| 81 | 200 | Vert Nacré | Lemon Metallic (Metallic Green) | #6A7944 | ||
| 83 | 149 | Noir Nacré | Metallic Black | #0A1327 | ||
| 134 | 139 | Cuivre | Copper | #764D3B | ||
| 135 | 296 131 315 |
Gris Nacré Clair | Pearl Light Grey ( |
#A0A0A0 | ||
| 137 | 145 | Bleu Métallique | Metal Blue (Sand Blue Metallic) | #5B7590 | ||
| 142 | 127 | Or Nacré Clair | Pearl Light Gold (Gold) | #DEAC66 | ||
| 148 | 148 | Gris Nacré Foncé | Pearl Dark Grey (Metallic Dark Grey) | #484D48 | ||
| 150 | 150 | Gris Nacré Très Clair | Pearl Very Light Grey (Metallic Light Grey) | #989B99 | ||
| 178 | 147 | Or Foncé Mat | Flat Dark Gold (Metallic Sand Yellow) | #83724F | ||
| 179 | 179 |
Argent Mat (Argent Terne) | Flat Silver (Silver Flip-Flop) | #898788 | Pour motif imprimé sur les pièces. | |
| 183 | 183 | Blanc Nacré | Pearl White (Metallic White) | #F6F2DF | ||
| 184 | 184 | Rouge Clair Nacré | Metallic Bright Red | #D60026 | ||
| 185 | 185 | Bleu Clair Nacré | Metallic Bright Blue | #0059A3 | ||
| 186 | 186 | Vert Foncé Nacré | Metallic Dark Green | #008E3C | ||
| 189 | 189 | Or Rougeâtre | Reddish Gold | #AC8247 | ||
| 297 | 297 | Or Nacré | Pearl Gold (Warm Gold) | #AA7F2E |
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 |
|---|---|---|---|---|---|---|
| 132 | - | Noir Argenté | Speckle Black Silver | #000000 | ||
| 133 | 132 | Noir Doré | Speckle Black Gold (Black Glitter) | #000000 | ||
| 75 | - | Noir Cuivré | Speckle Black Copper | #000000 | ||
| 76 | - | Gris Bleuté Foncé Argenté | Speckle Dark Bluish Grey Silver | #635F61 |
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) | #EEEEEE | ||
| 21 | 294 | Vert Phosphorescent | Glow In Dark Opaque (Phosphorescent Green) | #E0FFB0 | Opaque | |
| 294 | 50 | Blanc Phosphorescent | Glow In Dark Trans (Phosphorescent White) | #BDC6AD | Transparent | |
| 329 | 329 | Blanc Phosphorescent | Glow In Dark White (White Glow) | #F5F3D7 | Opaque |
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 | #FAC80A | ||
| 256 | - | Caoutchouc Noir | Rubber Black | #1B2A34 | ||
| 273 | - | Caoutchouc Bleu | Rubber Blue | #1E5AA8 | ||
| 324 | - | Caoutchouc Rouge | Rubber Red | #B40000 | ||
| 350 | - | Caoutchouc Orange | Rubber Orange | #D67923 | ||
| 375 | - | Caoutchouc Gris Clair | Rubber Light Grey | #8A928D | ||
| 406 | - | Caoutchouc Bleu Foncé | Rubber Dark Blue | #19325A | ||
| 449 | - | Caoutchouc Violet | Rubber Purple | #671F81 | ||
| 490 | - | Caoutchouc Citron Vert | Rubber Lime | #A5CA18 | ||
| 496 | - | Caoutchouc Gris Bleuté Clair | Rubber Light Bluish Grey | #969696 | ||
| 504 | - | Caoutchouc Argent Mat | Rubber Flat Silver | #898788 | ||
| 511 | - | Caoutchouc Blanc | Rubber White | #F4F4F4 | ||
| 10002 | - | Caoutchouc Vert | Rubber Green | #00852B | ||
| 10010 | - | Caoutchouc Vert Clair | Rubber Bright Green | #58AB41 | ||
| 10026 | - | Caoutchouc Magenta | Rubber Magenta | #901F76 | ||
| 10030 | - | Caoutchouc Lavande Moyen | Rubber Medium Lavender | #A06EB9 | ||
| 10031 | - | Caoutchouc Lavande | Rubber Lavender | #CDA4DE | ||
| 10070 | - | Caoutchouc Brun Rougeâtre | Rubber Reddish Brown | #5F3109 | ||
| 10073 | - | Caoutchouc Bleu Moyen | Rubber Medium Blue | #7396C8 | ||
| 10226 | - | Caoutchouc Jaune Clair Lumineux | Rubber Bright Light Yellow | #FFEC6C | ||
| 10308 | - | Caoutchouc Brun Foncé | Rubber Dark Brown | #352100 | ||
| 10320 | - | Caoutchouc Rouge Foncé | Rubber Dark Red | #720012 | ||
| 10321 | - | Caoutchouc Azur Foncé | Rubber Dark Azure | #469BC3 | ||
| 10322 | - | Caoutchouc Azur Moyen | Rubber Medium Azure | #68C3E2 | ||
| 10323 | - | Caoutchouc Eau Claire | Rubber Light Aqua | #D3F2EA | ||
| 10378 | - | Caoutchouc Vert Sable | Rubber Sand Green | #708E7C | ||
| 10484 | - | Caoutchouc Orange Foncé | Rubber Dark Orange | #91501C |
Il existe également des couleurs transparentes prévues pour les pièces en caoutchouc ou en matière synthétique souple (tuyaux, pneus, etc...), leur donnant un aspect transparent et mat. Voir plus bas leur définition avec la méta-commande !COLOUR et les options ALPHA 128 et RUBBER.
Couleurs existantes dans le fichier de configuration ldconfig.ldr :
| N° LDraw |
N° LEGO |
Couleur | Nom Français |
Nom Anglais |
RGB | Observation |
|---|---|---|---|---|---|---|
| 66 | - | Caoutchouc Transparent Jaune | Rubber Trans Yellow | #F5CD2F | ||
| 67 | - | Caoutchouc Transparent | Rubber Trans Clear | #FCFCFC | ||
| 10035 | - | Caoutchouc Transparent Vert Clair | Rubber Trans Bright Green | #56E646 | ||
| 10036 | - | Caoutchouc Transparent Rouge | Rubber Trans Red | #C91A09 | ||
| 10043 | - | Caoutchouc Transparent Bleu Lumineux | Rubber Trans Light Blue | #AEE9EF |
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 à :
https://www.ldraw.org/library/official/LDConfig.ldr et
https://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. Seulement utilisé dans les pièces à motif.
Format de la couleur :
0x2RRVVBB
Nota : Les valeurs hexadécimales utilisent les chiffres 0 à 9 et les lettres A à F qui doivent être en majuscules.
Exemple : 0x2A18B5C
Dans cet exemple la couleur beige sombre particulière est définie par ses 3 valeurs hexadécimales.
De nombreux programmes d'imagerie permettent à partir d'une photo
ou d'un scan d'obtenir les valeurs à utiliser en cliquant avec
l'outil "Pipette" :
Voir comme exemples les pièces 3960ps3.dat, 47753p01.dat, 47759p01.dat.
Il existe d'autres modes de codage qui ont été utilisés sans avoir été officialisés, mais qui semblent supportés par LDView.
Format de la couleur :
0x2RRGGBB: Couleur directe RGB opaque (officiel)
0x3RRGGBB: Couleur directe RGB transparente
0x4RGBRGB: Couleur directe RGB opaque tramée (défini par 2 couleurs 12-bit RGBRGB)
0x5RGBxxx: Couleur directe RGB transparente tramée (xxx est ignoré et traité comme complètement transparent)
0x6xxxRGB: Couleur directe RGB transparente tramée (xxx est ignoré et traité comme complètement transparent)
0x7xxxxxx: Couleur directe invisible
Cette méta-commande spécifie les propriétés de codage d'une couleur LDraw unique.
Cette commande peut apparaître n'importe où dans un fichier LDR, mais cela est
surement meilleur de la mettre dans l'en-tête.
Dans les éléments officiels de LDraw.org, !COLOUR apparaît dans le fichier de configuration ldconfig.ldr, pour définir l'ensemble de couleurs standards LDraw. Elle ne doit pas apparaître dans les fichiers de pièces et primitives officielles.
Il est recommandé que les définitions de couleur soient 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é :
Certaines gammes de ensembles utilisent des gammes de couleurs personalisées.
| 30 Lavande Moyen |
31 Lavande |
326 Vert Olive |
321 Azur Foncé |
Azur Moyen |
323 Eau Claire |
Les tableaux ci-dessous sont approximatifs et sujets à modification.
| 0 Mx Noir Mx Black |
0x0227867E Mx Vert d'Eau Mx Aqua Green |
47 Mx Transparent Mx Clear |
7 Mx Gris Clair Mx Light Grey |
0x027C9051 Mx Vert Olive Mx Olive Green |
0x02F47B30 Mx Orange Mx Orange |
0x0268AECE Mx Bleu Pastel Mx Pastel Blue |
0x02B52C20 Mx Rouge Mx Red |
15 Mx Blanc Mx White |
| 398 Mx Ocre Jaune Mx Ocre Yellow |
430 Mx Citron Vert Mx Lemon |
263 Mx Gris Ardoise Mx Tile Gray |
264 Mx Charbon de bois Mx Charcoal Gray |
510 Mx Jaune Clair Mx Light Yellow (Buff) |
418 Mx Vert Pastel Mx Pastel Green |
305 Mx Bleu Sarcelle Mx Teal Blue |
351 Mx Rose Mx Pink |
0x02365AB4 Bleu Gris ? Mx Grey Blue ? |
Nota : Ces couleurs ne sont pas toutes disponibles actuellement (04-2013) dans le fichier LDConfig.ldr, en conséquence tous les programmes ne visualisent pas ces couleurs. Utilisez LDView pour visualiser vos assemblages Modulex.
Le code des couleurs de la seconde partie du tableau a pour origine une recherche de Tore Eriksson (voir message du Forum LDraw.org : Re: Modulex parts library).
Voir : Créer modèle : Couleur des pièces Modulex.
En 2004 est apparu un changement dans la gamme des couleurs standards :
| Avant 2004 : | ||
| 6 Marron |
7 Gris Clair |
8 Gris Foncé |
| Après 2004 : | ||
| 70 Brun Rougeâtre |
71 Gris Bleuté Clair |
72 Gris Bleuté Foncé |
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 reconnues 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 programme 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 tourne de 90° dans le sens des aiguilles d'une montre, sur l'axe Y, alors vous pourrez voir le modèle sur chacune des quatre faces.
Syntaxe de cette commande :
0 ROTSTEP <x-angle> <y-angle> <z-angle> ADD
x-angle, y-angle et z-angle sont les angles de rotation individuels pour les différents axes en degrés (de -360 à 360).
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é de 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é 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ées
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. Voir sur ma page : LSynth : Format général des commandes, ma liste plus complète avec quelques exemples sur l'usage de ces méta-commandes.
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
Nota : Cette liste est ancienne (v2.x de LPub), et n'est plus à jour. Certaines méta-commandes ont changées et beaucoup ont été ajoutées. Voir sur mes pages : Liste des méta-commandes reconnues par LPub, Liste des méta-commandes reconnues par LPub3D et Liste des méta-commandes reconnues par LPub3D (la plus récente), une liste plus complète avec quelques explications sur l'usage de ces méta-commandes.
LdLite est un visualiseur 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 #
Nota : La gestion des groupes de SR 3D Builder rentre en conflit avec l'utilisation des groupes dans MLCad. Il faut dans ce cas mettre en commentaire les lignes comportant des déclarations de groupe.
Courroie :
0 BELT # PartFile1.DAT x1 y1 z1 PartFile1.DAT x2 y2 z2
Tuyaux souples (exemple) :
0 SPLINE 0 7 3 0.5 4 -1
0 -15 0 0 -1 0 0
0 15 0 -123 1 0 0
0 ENDSPLINE
1 7 0 0 0 1 0 0 0 1 0 0 0 1 3749.DAT
1 7 0 0 0 1 0 0 0 1 0 0 0 1 0.70554.DAT
Nota : La dernière ligne a un format non compatible avec le format LDraw et génèrera un message d'erreur.
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ée, 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 des variantes de modèle dans un fichier LDraw pour alléger visuellement les très gros modèles.
0 !LDSWITCH DEFINE SWITCH xxxx Do
0 !LDSWITCH DEFINE xxxx Undo
0 !LDSWITCH SWITCH xxxx
0 !LDSWITCH SWITCH xxxx Do
0 !LDSWITCH CASE Do
0 !LDSWITCH CASE Undo
0 !LDSWITCH END
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
LDCad est un éditeur de modèle. Il sauvegarde au format LDraw, et utilise sa propre syntaxe pour les pièces souples, ou pour d'autres informations :
0 !LDCAD MARKER
0 !LDCAD GROUP_DEF
0 !LDCAD GROUP_NXT
0 !LDCAD GROUP_OBJ
0 !LDCAD SCRIPT
0 !LDCAD CONTENT
0 !LDCAD GENERATED
0 !LDCAD PATH_POINT
0 !LDCAD PATH_CAP
0 !LDCAD PATH_ANCHOR
0 !LDCAD PATH_SKIN
0 !LDCAD PATH_LENGTH
0 !LDCAD SPRING_POINT
0 !LDCAD SPRING_CAP
0 !LDCAD SPRING_ANCHOR
0 !LDCAD SPRING_SECTION
0 !LDCAD SNAP_CLEAR
0 !LDCAD SNAP_INCL
0 !LDCAD SNAP_CYL
0 !LDCAD SNAP_CLP
0 !LDCAD SNAP_FGR
0 !LDCAD SNAP_GEN
0 !LDCAD SNAP_SPH
Voir : Méta-commandes LDCad pour une information plus complète.
LDView est un visualiseur de pièce ou modèle LDraw. Il utilise des méta-commandes spécifiques, pour ne pas calculer les dimensions de la vue avec certaines pièces (en premier les circuits de trains lorsqu'on veut se focaliser sur le train lui-même) :
0 !LDVIEW BBOX_IGNORE NEXT
0 !LDVIEW BBOX_IGNORE BEGIN
0 !LDVIEW BBOX_IGNORE END
Avec NEXT la prochaine ligne de géométrie est ignorée dans le calcul. Avec BEGIN toutes les lignes sont ignorées jusqu'à la ligne comportant END.
LDForge est un éditeur et visualiseur de fichier LDraw. Il a quelques commandes spécifiques.
Définition d'un point ou sommet :
0 !LDFORGE VERTEX <couleur> <X> <Y> <Z>
Définition d'une image de fond :
0 !LDFORGE OVERLAY <fichier> <Vue (0=top, 1=...)> <Xorigine> <Yorigine> <Xdimension> <Ydimension>
Définition de primitive circulaire (exemple) :
Nota : Ces éléments ont été supprimés avec la version v0.2 du 10 juillet 2013.
0 !LDFORGE RADIAL CIRCLE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
0 !LDFORGE RADIAL CYLINDER <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
0 !LDFORGE RADIAL DISC <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
0 !LDFORGE RADIAL DISCNEGATIVE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
0 !LDFORGE RADIAL RING <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
0 !LDFORGE RADIAL CONE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
0 !LDFORGE RADIAL CIRCLE <couleur> <Nb segments> <Résolution (16 ou 48)> <X> <Y> <Z> <Matrice (6 valeurs)>
Bricksmith est un modeleur utilisant le format LDraw. Les commandes spécifiques qui suivent sont utilisées dans un fichier related.ldr pour associer des pièces parents avec d'autres pièces liées (jante avec pneu par exemple).
Précédent la liste de pièces parent similaires :
0 !PARENT
Précédent la liste de pièces enfant similaires :
0 !CHILD nom
Nota : Il peut y avoir plusieurs listes enfant pour un même parent : Left Pane (volet gauche), Right Pane (volet droit), pour une fenêtre.
LDPartEditor est un éditeur de pièce LDraw. Il a quelques commandes spécifiques.
Définition de tache :
0 !LPE TODO <tache>
Définition de point :
0 !LPE VERTEX <x> <y> <z>
Définition de construction CSG :
0 !LPE CSG_EPSILON <Tolérance supérieure à 0 (1E-6 par défaut)>
0 !LPE CSG_QUALITY <Qualité circulaire entre 1 et 48 (16 par défaut)>
0 !LPE CSG_CUBOIDE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
0 !LPE CSG_ELLIPSOIDE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
0 !LPE CSG_QUAD <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
0 !LPE CSG_CYLINDER <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
0 !LPE CSG_CONE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
0 !LPE CSG_CIRCLE <nom_unique> <couleur> <x> <y> <z> <Matrice (6 valeurs)>
0 !LPE CSG_UNION <nom_source1> <nom_source2> <nom_cible>
0 !LPE CSG_DIFFERENCE <nom_source1> <nom_source2> <nom_cible>
0 !LPE CSG_INTERSECTION <nom_source1> <nom_source2> <nom_cible>
0 !LPE CSG_COMPILE <nom_source>
Définition d'image de fond :
0 !LPE PNG <x> <y> <z> <Rx> <Ry> <Rz> <Sx> <Sy> <Sz> <chemin+nom_fichier>
LeoCAD est un éditeur de modèle. Il sauvegardait à un format spécifique binaire, mais maintenant il sauvegarde au format LDraw, et utilise sa propre syntaxe pour les objets spécifiques, et pour d'autres informations :
0 !LEOCAD MODEL AUTHOR
0 !LEOCAD MODEL BACKGROUND
0 !LEOCAD MODEL DESCRIPTION
0 !LEOCAD MODEL CURRENT_STEP2
0 !LEOCAD GROUP BEGIN
0 !LEOCAD GROUP END
0 !LEOCAD PIECE POSITION_KEY
0 !LEOCAD CAMERA FOV
0 !LEOCAD CAMERA POSITION
0 !LEOCAD CAMERA TARGET_POSITION
0 !LEOCAD CAMERA UP_VECTOR
0 !LEOCAD CAMERA NAME
0 !LEOCAD SYNTH BEGIN
0 !LEOCAD SYNTH CONTROL_POINT
0 !LEOCAD SYNTH END
Voir : Méta-commandes LeoCAD pour une information plus complète.
CastleGenerator est un générateur de châteaux-forts. Il utilise ses propres méta-commandes dans les fichiers servant de modules pour créer de façon pseudo-aléatoire ces châteaux.
0 REPCOLOR 14 "A_PrimaryBuildColor" ALL
0 RNDCOLOR 81 "1,73" ALL
0 RNDCOLOR 10 "*ColorSets" (key) ALL
0 REPLACE "Throne_Table" ONE
0 REPLACE_ID 3009.dat "92950.dat" ALL
0 REPLACE_BRICK 60808.dat "4x6_Wall_Table" ALL
0 X_WIDTH 1
0 Y_HEIGHT 3
0 Z_LENGTH 3
0 SCMD_TABLE
0 SCMD_KEY OctBattlement
0 SCUBE
0 LAYOUT Spawn8x8Tower.txt
Définition de texture générée par Part Designer et utilisée par Studio (image .png).
0 PE_TEX_PATH -1
0 PE_TEX_INFO iVBORw0......
Nota : Ces méta-commandes sont incompatibles avec les autres programmes LDraw.
Autres méta-commandes générées par Part Designer dans les fichiers .part.
0 ModelType: Part
0 ModelType: Body
0 ModelType: Texture
0 BL_Item_No test5
0 MIN_SIZE 20.00000 8.00000 20.00000
0 PE_SCALE 2.0000 1.0000 2.0000
0 PE_CONN 2 0 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 -20.000000 0.000000 20.000000 2 2 0:1,0:2,0:1,0:2,10:4,0:2,0:1,0:2,0:1
Définitions de mise en page de ce programme de génération de manuel d'instructions.
0 !LDINSP INSTR [parametre] ... pour instruction générale
0 !LDINSP INSTRSC [parametre] ... pour portée (scope) sur une pièce particulière
0 !LDINSP INSTRDIR [parametre] ... pour la liste des pièces (PLI)
0 !LDINSP INSTRCMD [parametre] ... pour l'inventaire des pièces (BOM)
La localisation est la possibilité de traduire le nom des pièces dans le système LDraw, en particulier, pour ceux qui lisent ces lignes, en Français.
Nota : Pour le français tout n'a pas encore été traduit, en particulier les descriptions de pièces, et les mots-clefs, en raison du travail laborieux que cela nécessite.
Le programme de gestion des traductions s'appelle LDTranslator.
Source de ce chapitre : Localisation Guideline (en Anglais).
Les fichiers de traduction sont encodés avec le format UTF-8.
Chaque ligne se termine par les caractères <CR><LF>. Voir Restrictions sur le format des fichiers de pièces.
Les fichiers de traduction sont :
Le dossier de sauvegarde est :
En-tête des fichiers de traduction :
0 LDraw.org Configuration File 0 Name: colours.txt 0 Author: LDraw.org 0 !LDRAW_ORG Configuration UPDATE 2009-09-05 0 !TRANSLATION COLOURS de-DE 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
Corps des fichiers de traduction :
"<langage neutre>" = "<langage traduit>" ...
Il n'est pas obligatoire d'avoir une traduction pour chaque entrée, car il est parfois difficile de traduire certains mots-clefs ou désignation de pièces, et cela minimise la taille des fichiers.
Les applications doivent utiliser les traductions uniquement pour afficher une sentence à l'utilisateur et jamais pour décider une action basée sur cette traduction.
0 LDraw.org Configuration File 0 Name: colours.txt 0 Author: LDraw.org 0 !LDRAW_ORG Configuration UPDATE 2009-09-05 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt 0 !TRANSLATION COLOURS fr "Black" = "Noir" "Blue" = "Bleu" "Green" = "Vert" "Dark_Turquoise" = "Turquoise_foncé" "Red" = "Rouge" "Dark_Pink" = "Rose_foncé"
0 LDraw.org Configuration File 0 Name: parts.txt 0 Author: LDraw.org 0 !LDRAW_ORG Configuration UPDATE 2009-09-05 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt 0 !TRANSLATION PARTS de-DE "Animal Bat Wing 9 x 9 with Axle" = "Tier Fledermaus Flügel 9 x 9 mit Achse" "Animal Bird" = "Tier Vogel" "Animal Bird with Parrot Pattern" = "Tier Vogel mit Papagei Dekor" "Animal Cat Crouching" = "Tier Katze kauernd" "~Technic Pneumatic Cylinder with 2 Inlets Medium Slide" = "~Technik Pneumatik Zylinder mit 2 Einlässen Mittel Gleiter" "~Moved to 75974" = "~Verschoben nach 75974" "_Brick 2 x 2 White" = "_Stein 2 x 2 Weiss" "Brick 1 x 1 with Blue \"0\" Pattern" = "Stein 1 x 1 mit Blau \"0\" Dekor"
Nota : Les caractères spéciaux '~' (tilde) et '_' (souligné) en début de sentence, doivent être également présents dans la traduction.
0 LDraw.org Configuration File 0 Name: categories.txt 0 Author: J.C. Tchang [tchang] 0 !LDRAW_ORG Configuration UPDATE 2009-09-05 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt 0 !TRANSLATION CATEGORIES fr "Animal" = "Animal" "Antenna" = "Antenne" "Arch" = "Arche"
0 LDraw.org Configuration File 0 Name: keywords.txt 0 Author: LDraw.org 0 !LDRAW_ORG Configuration UPDATE YYYY-MM-DD 0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt 0 !TRANSLATION KEYWORDS fr "cone" = "" "Colored Globe" = "Globe coloré" "Coffee" = "Café"
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 trois 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 pour série 8000 sert à limiter
le nombre de dossiers sous \model_off, et \v1 la version du fichier (il
peut y en avoir plusieurs si j'ai récupéré un modèle disponible sur Internet,
ou si j'ai repris le modèle en faisant évoluer ma technique de construction.
J'utilise une autre arborescence pour les modèles de ma création (MOC= Ma propre création)
du style :
c:\lego\model_moc\categorie\sous_categorie\model\v1\model.mpd.
L'identification des différents fichiers DAT de la bibliothèque de pièces LDraw se fait en fonction du format de leur nom de fichier, et le caractère initial de la description de la pièce. Dans le tableau qui suit, dans la colonne "Nom", "n" indique un chiffre, et "x" une lettre. Le nombre de caractère indiqué peut être en pratique variable.
| Type de fichier | Titre (Description) |
Nom (Numéro) |
Sous-dossier de LDraw |
|---|---|---|---|
| Primitive | nnnn.dat, xxxx.dat, ... | \P | |
| Primitive de tenon, résolution standard | studnnn.dat | \P | |
| Primitive de tenon, résolution basse | Termine par : (Fast-Draw) | stu2nnn.dat | \P\8 |
| Primitive de groupe de tenons | stugnnn.dat | \P | |
| Primitive circulaire de haute résolution | 48\nnnn.dat, 48\xxxx.dat, ... | \P\48 | |
| Partie de pièce | s\nnnnsnn.dat | \PARTS\S | |
| Partie de motif de pièce | s\nnnnpsn.dat | \PARTS\S | |
| Partie de pièce souple | nnnnk01.dat, nnnnk02.dat, ... |
\PARTS | |
| Pièce simple | nnnn.dat | \PARTS | |
| Pièce imparfaite, mais admissible en officielle | Termine par : (Needs Work) | nnnn.dat | \PARTS |
| Pièce simple à numéro inconnu (avant 2/2010) | xnnnn.dat | \PARTS | |
| Pièce simple à numéro inconnu (depuis 2/2010) | unnnn.dat | \PARTS | |
| Pièce Alias (1 pièce, 2 numéros de moule) | Débute par : = | nnnn.dat | \PARTS |
| Texture, motif de pièce ou autocollant (Image PNG) | nnnn.png | \PARTS\TEXTURES (LDView, LDCad)\TEXTURES (LD Part Editor) | |
| Autocollant à 1 seul motif | Débute par : Sticker, et ne contient pas Pattern | nnnnnnn.dat 00nnnn.dat (SKU court) |
\PARTS |
| Autocollant à plusieurs motifs | Débute par : Sticker, et ne contient pas Pattern | nnnnnnna.dat, nnnnnnnb.dat, ... 00nnnna.dat, 00nnnnb.dat, ... (SKU court) nnnnnnna1.dat, nnnnnnna2.dat (2=sym si plus de 26 autocollants) |
\PARTS |
| Autocollant "en forme" du support | Débute par : Sticker, Contient : (Formed), et ne contient pas Pattern | nnnnnnnacnn.dat, nnnnnnnbcnn.dat, ... 00nnnnacnn.dat, 00nnnnbcnn.dat, ... (SKU court) |
\PARTS |
| Autocollant à numéro inconnu | Débute par : Sticker, et ne contient pas Pattern | snn.dat | \PARTS |
| Pièce à motif | Termine par : Pattern | nnnnpnn.dat | \PARTS |
| Pièce à double injection (2 couleurs ou 2 matériaux différents) | nnnnpnn.dat | \PARTS | |
| Pièce souple monobloc "en forme" | Contient : (Formed) | nnnncnn.dat | \PARTS |
| Pièce "en position" | Contient : (Open), (Open Flat), (Neutral Position), ... | nnnn-fn.dat | \PARTS |
| Pièce composite assemblée | Contient : (Shortcut) | nnnncnn.dat | \PARTS |
| Pièce composite assemblée "en position" | Contient : (Contracted), (Retracted), ... | nnnncnn-fn.dat | \PARTS |
| Pièce simple avec autocollant(s) | Contient : (Shortcut) | nnnndnn.dat | \PARTS |
| Pièce composite avec autocollant(s) | Contient : (Shortcut) | nnnncnndnn.dat | \PARTS |
| Elément de pièce composite | Débute par : ~ | nnnn.dat | \PARTS |
| Pièces moulées en grappe | nnnna.dat, nnnnb.dat, ... | \PARTS | |
| Pièce à variante (évolution) | nnnna.dat, nnnnb.dat, ... | \PARTS | |
| Pièce renommée (pour ancien numéro) | Débute par : ~Moved to | nnnn.dat | \PARTS |
| Pièce simple avec numéro codifié | Débute par : _ | nnnnnnn.dat | \PARTS |
| Pièce tierce (non Lego) BBB, Brickstuff, BuWizz, Hubelino, LifeLite, MinuteBot, Vengit S-Brick. |
Débute par : | | tnnnn.dat | \PARTS |
| Pièce tierce assemblée | Débute par : | | tnnnncnn.dat | \PARTS |
| Elément de pièce tierce composite | Débute par : ~| | tnnnn.dat | \PARTS |
| Partie de pièce tierce | Débute par : ~| | tnnnnsnn.dat | \PARTS\S |
| Sous-modèle | xxxx.ldr | \MODELS ou ... | |
| Modèle simple | xxxx.ldr | \MODELS ou ... | |
| Modèle multiple | xxxx.mpd (xxxx.ldr accepté) | \MODELS ou ... | |
| Modèle multiple principal A et alternatif B (ex: 8297A, 8297B) | xxxxA, xxxxB.mpd | \MODELS ou ... | |
| Modèle multiple composé avec plusieurs ensembles (ex: 8865+8700 ou 42010+42011) | xxxx+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.