Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
This will most likely be a pain in the butt. I'm going to work on getting a basic renderer up and running first, and then plug it in to torque. the dirty part will be generating collision meshes on the fly for bricks.....

compiled from several pages on LDraw.org wrote:
MPD Commands
0 FILE <modelname> <- main model
data
0 FILE <modelname> <- sub model
data
0 NOFILE
comments, etc


http://ldraw.org/Article218.html <- IMPLEMENT THIS FIRST.
http://ldraw.org/Article342.html <- Consider supporting this for tube generation!


back face culling

0 BFC CERTIFY <- must occur before first operational command line (line type 1 - 5)
Marking a file as BFC-compliant only directly affects that file. In order for subfiles to be treated as compliant, they must also be marked as compliant. Additionally, with the exception of parts, a file is only treated as being BFC-compliant if it and all of its superfiles are compliant. The reason for this is that, while processing, there is no way to know the intended inversion state of a subfile when the file's superfile isn't BFC-compliant. The reason that part files can be excepted from this rule is that they are complex closed solids, so there is never a valid reason to invert them. Assuming part files are never inverted allows the rendering engine to apply BFC-processing on certified parts, even if the calling file(s) (for example, the main model file or sub-models of the main model) aren't certified.

Winding. It must be possible for a file to specify the winding order of the polygon commands within that file: clockwise, counterclockwise, or unknown. Allowing the winding to be set at the file level (as part of the 0 BFC CERTIFY meta-statement) is primarily a convenience for file authors.

Changing the winding setting will only affect the current file. It will not modify the winding of subfiles.

It is permitted to change the winding of polygons within a file. In this case the change of winding direction affects all polygons following the CW/CCW option, either until the end of the current file or another CW/CCW option is encountered.

Culling. It must be possible to enable and disable culling during the processing of a file. But even when culling is currently enabled, it may not be possible to actually cull the polygons. Polygons can be tested for culling only when the following conditions apply:
* All superfiles (in the current file-reference branch) are certified
* The current file is certified
* No superfile has disabled culling prior to referencing this subfile
Unless all of these conditions are met at the time a subfile is rendered, no culling is possible.

If the culling state is modified, it affects all lines following the CLIP/NOCLIP option, either until the end of the current file or another CLIP/NOCLIP option is encountered. When subfiles are referenced, they will receive a flag indicating the accumulated culling state, but there is no sense of a global culling mode.

Inversion. Sometimes, it is desireable to reverse the surfaces of a subfile; to turn the subfile 'inside out'.

One common example of inversion is the cylinder primitive. Cylinder primitives are designed so the surfaces face outward from the center. In 3D tubes, a pair of cylinder primitives are used to model the tube; one outer cylinder is oriented normally, and the inside cylinder, scaled slightly smaller, is required to face inward. This is accomplished by flagging the inner cylinder as being inverted.

Inversion accumulates down the file-reference branch. If the current file is being rendered inverted, then any subfiles of the current file are also rendered as inverted.

Inversion is a boolean operation; inverting a file that is already inverted will give the file the normal orientation. So if the current file is inverted, and a subfile is flagged as inverted, the subfile will be rendered with normal orientation, that is, right-side-out.

(As a practical matter, rendering engines can accomplish inversion simply by switching the order of winding; treat CCW files as CW and vice versa. This must happen in conjunction with the other settings.)


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



0 BFC NOCERTIFY

0 BFC CERTIFY (CCW is implied)
0 BFC CERTIFY CW
0 BFC CERTIFY CCW

0 BFC CW
0 BFC CCW

0 BFC CLIP (winding is unchanged)
0 BFC CLIP CW
0 BFC CLIP CCW

0 BFC NOCLIP

0 BFC INVERTNEXT





The BFC meta-statement and all of its options are case-sensitive, ie, they must always be in all capitals.

The BFC meta-statement shall ignore repeating whitespace, and accept any number of spaces or tabs as equivalent to a single space.

In order for a file to be processed with back face culling, there must be at least one 0 BFC meta-statement before the first operational command-line. If there is no such 0 BFC meta-statement in the file, BFC processing will be disabled for that file.

Only one NOCERTIFY/CERTIFY meta-statement may be present in a file, and if present, must preceed all other BFC meta-statements and operational command-lines.

All BFC commands that act on succeeding lines in the file shall ignore empty lines.

For backwards compatibility the CLIP and winding options may be specified in any order on the meta-statement, so the following are also valid

0 BFC CW CLIP
0 BFC CCW CLIP

Language Operations

CERTIFY

This option indicates the LDraw file is compatible with the back face culling extension. Every LDraw file must be clearly labeled if it is compliant. One way to accomplish this is to place 0 BFC CERTIFY at the beginning of the file, before the first operational command-line.

A second way to specify a file as compliant is to use any option, except for NOCERTIFY, on a 0 BFC meta-statement, before the first operational command-line. This is an acceptable alternative, but the 0 BFC CERTIFY method is recommended and prefered.

Files in the LDraw.org Parts Library, if they are BFC compliant, are required to have an explicit 0 BFC CERTIFY line in their header.

If a file has no 0 BFC meta-statement before the first operational command-line, 0 BFC NOCERTIFY is assumed and BFC processing will be disabled for the file.

NOCERTIFY

This option specifies that the file is not compliant with the BFC specification; the polygons are not wound consistently and/or correctly, and/or subfile references are not properly inverted. If the NOCERTIFY option is used, it must appear before any operational command-lines. Any other BFC meta-statements in the file will be ignored.

CLIP

This option sets the cull-state to enabled. This allows culling, if all other conditions for culling are met. (While this option should be called CULL, the CLIP form is intentionally being kept for backwards compatibility.)

NOCLIP

This option sets the cull-state to disabled. Any subpart or primitive referenced while the cull-state is disabled will not be eligible for culling. (While this option should be called NOCULL, the NOCLIP form is intentionally being kept for backwards compatibility.)

CLIP/NOCLIP Notes

There may be any number of changes to the cull-state in a file, although it is recommended that such changes be kept to a minimum.

If neither the CLIP nor NOCLIP option is specified on a 0 BFC meta-statement before the first operational command-line, then that file's cull-state is set to enabled (CLIP).

CW

This option sets polygon winding to clockwise.

CCW

This option sets polygon winding to counter-clockwise.

CW/CCW Notes

There may be any number of changes to the winding direction in a file, although it is recommended that changes to winding are kept to a minimum.

If no winding option is specified for a file, the local winding state will be defaulted to counter-clockwise (CCW).

INVERTNEXT

This option inverts a subpart or primitive. It may only be used immediately before a subfile command line [while intervening blank lines are permitted, they are discouraged for reasons of readability], and it only influences the immediately following subfile command. It should never be used before a part.

Example:

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

In this example, somefile.dat would be rendered as inverted while another.dat would not be inverted.

For further information, see "Inversion" in the Language Extension Functionality section.





Definitions

Certified. An LDraw file is certified if it complies with the specifications in this document, includes a 0 BFC CERTIFY meta-statement before the first operational command-line, and does not contain a 0 BFC NOCERTIFY meta-statement.

Clipping. In this document, the term clipping is used as a synonym for culling. While this is technically incorrect, the usage is kept for backwards compatibility with the prior draft and de-facto standards. (In other graphic contexts, clipping usually refers to trimming a geometric primitive to not extend past the edge of a given region, while culling refers to not drawing the primitive at all.)

Culling. In this document, the term culling refers to the process of performing back face culling; that is, not drawing a geometric primitive at all.

File-reference Branch. A set of files in the file-reference tree that either start from the main model file or from a part file. The file-reference tree has a single main branch (the main model) which contains many sub-branches (the parts) which themselves may contain sub-branches (for example, a complete assembly such as a minifig).

Invert. Turning a subfile inside out, usually performed on geometric primitives. When back face culling is used inversion is needed or interior surfaces will never be rendered. Because polygons are one-sided, interior primitives need to have their surfaces face inward, rather than outward.

LDraw file. A single file specifying a part, sub-part, primitive or model. Parts, sub-parts and primitives have the extension DAT, while models can use DAT, LDR or MPD. While BFC meta-statements are rarely used in model files, they still apply, and should be used if the model file contains any polygons.

Operational Command-Line. Any statement in an LDraw file with line-type 1 through 5. In other words, the Subfile, Line, Triangle, Quad, and Conditional Line statements.

Part. An LDraw file which represents a complete real-world building element. These files are stored in the ldraw\parts\ directory.

Polygon. A 2D surface created by LDraw's line-type 3 (triangle) or 4 (quadrilateral) command.

Primitive. An LDraw file, typically small, which models a geometric shape or a standard attribute of building elements, such as studs or the cross-axle shape. These files are kept in the ldraw\p\ directory (for lo-res primitives) and the ldraw\p\48 directory (for hi-res primitives). (In other graphics contexts, the term primitive refers to the basic geometric shapes provided by the rendering environment.)

Subfile. An LDraw file referenced from another file, via a line-type 1 command. Or any file which is lower in the file-reference branch than the current file.

Subpart. An LDraw file which is only a portion of a complete element. It does not necessarily correspond to a discrete portion of a real-world building element. These files are kept in the ldraw\parts\s\ directory.

Superfile. The file which referenced the current file. More generally, any file which is higher in the current file-reference branch than the current file.

Winding. This is the order vertices are specified in a polygon command. The order can be either clockwise or counter-clockwise (AKA anti-clockwise), and is based on viewing the polygon from its front side.

Clockwise winding (vertices numbered 0 through 3):

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

Counter-clockwise winding:

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

Language Extension Functionality

The BFC language extension allows LDraw files to specify and control the following conditions:

Compliance. LDraw files which follow the BFC extension must be clearly and unambiguously marked. It is also useful to allow non-compliant files to be marked as well. Having the compliancy stated plainly simplifies the task of the rendering program, and makes it easier for humans to read files.

Marking a file as BFC-compliant only directly affects that file. In order for subfiles to be treated as compliant, they must also be marked as compliant. Additionally, with the exception of parts, a file is only treated as being BFC-compliant if it and all of its superfiles are compliant. The reason for this is that, while processing, there is no way to know the intended inversion state of a subfile when the file's superfile isn't BFC-compliant. The reason that part files can be excepted from this rule is that they are complex closed solids, so there is never a valid reason to invert them. Assuming part files are never inverted allows the rendering engine to apply BFC-processing on certified parts, even if the calling file(s) (for example, the main model file or sub-models of the main model) aren't certified.

Winding. It must be possible for a file to specify the winding order of the polygon commands within that file: clockwise, counterclockwise, or unknown. Allowing the winding to be set at the file level (as part of the 0 BFC CERTIFY meta-statement) is primarily a convenience for file authors.

Changing the winding setting will only affect the current file. It will not modify the winding of subfiles.

It is permitted to change the winding of polygons within a file. In this case the change of winding direction affects all polygons following the CW/CCW option, either until the end of the current file or another CW/CCW option is encountered.

Culling. It must be possible to enable and disable culling during the processing of a file. But even when culling is currently enabled, it may not be possible to actually cull the polygons. Polygons can be tested for culling only when the following conditions apply:
* All superfiles (in the current file-reference branch) are certified
* The current file is certified
* No superfile has disabled culling prior to referencing this subfile
Unless all of these conditions are met at the time a subfile is rendered, no culling is possible.

If the culling state is modified, it affects all lines following the CLIP/NOCLIP option, either until the end of the current file or another CLIP/NOCLIP option is encountered. When subfiles are referenced, they will receive a flag indicating the accumulated culling state, but there is no sense of a global culling mode.

Inversion. Sometimes, it is desireable to reverse the surfaces of a subfile; to turn the subfile 'inside out'.

One common example of inversion is the cylinder primitive. Cylinder primitives are designed so the surfaces face outward from the center. In 3D tubes, a pair of cylinder primitives are used to model the tube; one outer cylinder is oriented normally, and the inside cylinder, scaled slightly smaller, is required to face inward. This is accomplished by flagging the inner cylinder as being inverted.

Inversion accumulates down the file-reference branch. If the current file is being rendered inverted, then any subfiles of the current file are also rendered as inverted.

Inversion is a boolean operation; inverting a file that is already inverted will give the file the normal orientation. So if the current file is inverted, and a subfile is flagged as inverted, the subfile will be rendered with normal orientation, that is, right-side-out.

(As a practical matter, rendering engines can accomplish inversion simply by switching the order of winding; treat CCW files as CW and vice versa. This must happen in conjunction with the other settings.)

Language Extensions

There is a single meta-statement in the BFC language extension, the 0 BFC statement. The statement includes options to specify BFC-related operations.

Syntax:

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

where (a | b) means either a or b, [] indicates optional items and {} indicates the default value.

This syntax results in the following permissable variations of the BFC meta-statement

0 BFC NOCERTIFY

0 BFC CERTIFY (CCW is implied)
0 BFC CERTIFY CW
0 BFC CERTIFY CCW

0 BFC CW
0 BFC CCW

0 BFC CLIP (winding is unchanged)
0 BFC CLIP CW
0 BFC CLIP CCW

0 BFC NOCLIP

0 BFC INVERTNEXT

The BFC meta-statement and all of its options are case-sensitive, ie, they must always be in all capitals.

The BFC meta-statement shall ignore repeating whitespace, and accept any number of spaces or tabs as equivalent to a single space.

In order for a file to be processed with back face culling, there must be at least one 0 BFC meta-statement before the first operational command-line. If there is no such 0 BFC meta-statement in the file, BFC processing will be disabled for that file.

Only one NOCERTIFY/CERTIFY meta-statement may be present in a file, and if present, must preceed all other BFC meta-statements and operational command-lines.

All BFC commands that act on succeeding lines in the file shall ignore empty lines.

For backwards compatibility the CLIP and winding options may be specified in any order on the meta-statement, so the following are also valid

0 BFC CW CLIP
0 BFC CCW CLIP

Language Operations

CERTIFY

This option indicates the LDraw file is compatible with the back face culling extension. Every LDraw file must be clearly labeled if it is compliant. One way to accomplish this is to place 0 BFC CERTIFY at the beginning of the file, before the first operational command-line.

A second way to specify a file as compliant is to use any option, except for NOCERTIFY, on a 0 BFC meta-statement, before the first operational command-line. This is an acceptable alternative, but the 0 BFC CERTIFY method is recommended and prefered.

Files in the LDraw.org Parts Library, if they are BFC compliant, are required to have an explicit 0 BFC CERTIFY line in their header.

If a file has no 0 BFC meta-statement before the first operational command-line, 0 BFC NOCERTIFY is assumed and BFC processing will be disabled for the file.

NOCERTIFY

This option specifies that the file is not compliant with the BFC specification; the polygons are not wound consistently and/or correctly, and/or subfile references are not properly inverted. If the NOCERTIFY option is used, it must appear before any operational command-lines. Any other BFC meta-statements in the file will be ignored.

CLIP

This option sets the cull-state to enabled. This allows culling, if all other conditions for culling are met. (While this option should be called CULL, the CLIP form is intentionally being kept for backwards compatibility.)

NOCLIP

This option sets the cull-state to disabled. Any subpart or primitive referenced while the cull-state is disabled will not be eligible for culling. (While this option should be called NOCULL, the NOCLIP form is intentionally being kept for backwards compatibility.)

CLIP/NOCLIP Notes

There may be any number of changes to the cull-state in a file, although it is recommended that such changes be kept to a minimum.

If neither the CLIP nor NOCLIP option is specified on a 0 BFC meta-statement before the first operational command-line, then that file's cull-state is set to enabled (CLIP).

CW

This option sets polygon winding to clockwise.

CCW

This option sets polygon winding to counter-clockwise.

CW/CCW Notes

There may be any number of changes to the winding direction in a file, although it is recommended that changes to winding are kept to a minimum.

If no winding option is specified for a file, the local winding state will be defaulted to counter-clockwise (CCW).

INVERTNEXT

This option inverts a subpart or primitive. It may only be used immediately before a subfile command line [while intervening blank lines are permitted, they are discouraged for reasons of readability], and it only influences the immediately following subfile command. It should never be used before a part.

Example:

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

In this example, somefile.dat would be rendered as inverted while another.dat would not be inverted.

For further information, see "Inversion" in the Language Extension Functionality section.

LDraw Parts Library Guidelines

(This section gives some suggestions for implementing BFC within the LDraw Parts Library and the impact on the current library. This section may be varied by other specifications (for example, the Parts Library Header specification) and/or the requirements of the Parts Library administrators without affecting the validity of the Back Face Culling specification.)

The LDraw Parts Library includes all parts, primitives, and subparts distributed with LDraw or in an ldraw.org parts update.

New parts will not be required to be compliant with this extension. They will however be required to carry a 0 BFC meta-statement, indicating either compliance or non-compliance.

New primitives will be required to be certified before being accepted for release.

It is desirable for all files to use the same winding. When possible, files should use counter-clockwise winding. The actual winding for any part is left to the file author. Primitives should always use CCW winding.

Primitives should generally be written so that polygons face outward, or upward. Exceptions are allowed for polygons which model inward- or downward-facing surfaces.

As noted in the language sections, all BFC compliant files in the parts library will have an explicit 0 BFC CERTIFY line in their header.

Rendering Engine Guidelines

(This section gives some suggestions for the design of programs in order to achieve correct renderings. Any program may violate these guidelines if there is another way to achieve a valid rendering.)

Matrix Reversals. Rendering engines will need to correct for orientation matrices which inadvertently or deliberately reverse a subfile.

Normal transformation:

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

'Reversed' transformation:

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

If the rendering engine does not detect and adjust for reversed matrices, the winding of all polygons in the subfile will be switched, causing the subfile to be rendered incorrectly.

The typical method of determining that an orientation matrix is reversed is to calculate the determinant of the matrix. If the determinant is negative, then the matrix has been reversed.

The typical way to adjust for matrix reversals is to switch the expected winding of the polygon vertices. That is, if the file specifies the winding as CW and the orientation matrix is reversed, the rendering program would proceed as if the winding is CCW.

The INVERTNEXT option also reverses the winding of the polygons within the subpart or primitive. If the matrix applied to the subpart or primitive has itself been reversed the INVERTNEXT processing is done IN ADDITION TO the automatic inversion - the two effectively cancelling each other out.

Inverted Subfiles. Generally, it is not possible to determine that a subfile reference is inverted or normal (which is the reason for the 0 BFC INVERTNEXT meta-statement). In particular, the rendering engine should *not* use the determinant of the orientation matrix to determine if the subfile is intended to be inverted (see 'Matrix Reversals', above).

Note: Part files are never inverted as they represent closed solids.

Uncertified Files. No assumptions can be made about models which make direct use of primitives or polygon commands, so a rendering engine should not simply treat uncertified model files as certified.

Culling State. The rendering engine can default to either allow or disable culling at the start of processing. Presumably, the user will be given the ability to control this state.

Degenerate Matrices. Some orientation matrices do not allow calculation of a determinate. This calculation is central to BFC processing. If an orientation matrix for a subfile is degenerate, then culling will not be possible for that subfile.









Rendering Processing

(This section presents a possible model for writing the core processing loop in an LDraw/BFC rendering program. Any program may violate this model if there is another way to achieve a valid rendering.)

All BFC-relevant logic is included while as much other logic (as possible) is excluded. It should not be assumed that this pseudo-code represents the most effecient way to implement BFC.

The function BFC() returns a boolean value, indicating whether a polygon should be rendered or culled. As the nature of this routine does not impact the BFC standard, the logic for BFC() is not included in the following pseudo-code. There is information about BFC processing available from many locations, including 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
End If
End Case

If Command.LineType != BFC Then
InvertNext = FALSE
ElseIf No Option in Command is INVERTNEXT Then
InvertNext = FALSE
End If
Loop
End Procedure

















Yellow-Orange

14
Yellow


Yellow-Green

2 17
Green

4
Blue-Green
1

Blue


Blue-Violet
22 26

Purple

Source:
LDraw FAQ and Suzanne Rich's Color Reference table.

Color List
Here is a list of color names along with their LDraw number and RGB value.

Black
LDraw: 0
RGB: 33 33 33
POV-Ray: <0.13, 0.13, 0.13>
Blue
LDraw: 1
RGB: 0 51 178
POV-Ray: <0.00, 0.20, 0.70>
Bright Green
LDraw: 10 (or 418)
RGB: 107 238 144
POV-Ray: <0.42, 0.93, 0.56>
Brown
LDraw: 6
RGB: 92 32 0
POV-Ray: <0.36, 0.13, 0.00>
Chrome Gold
LDraw: 334
RGB: 225 110 19
POV-Ray: <0.88, 0.43, 0.07>
Chrome Silver
LDraw: 383
RGB: 224 224 224
POV-Ray: <0.88, 0.88, 0.88>
Clear (trans white)
LDraw: 47
RGB: 255 255 255
POV-Ray: <1.00, 1.00, 1.00, 0.90>
Dark Blue
LDraw: 272
RGB: 0 29 104
POV-Ray: <0.00, 0.11, 0.41>
Dark Gray
LDraw: 8
RGB: 99 95 82
POV-Ray: <0.39, 0.37, 0.32>
Dark Green
LDraw: 288
RGB: 39 70 44
POV-Ray: <0.15, 0.27, 0.17>
Dark Orange
LDraw: 484
RGB: 179 62 0
POV-Ray: <0.70, 0.24, 0.00>
Dark Pink
LDraw: 5
RGB: 223 102 149
POV-Ray: <0.87, 0.40, 0.58>
Dark Red (first found in set 10019, Star Wars Rebel Blockade Runner)
LDraw: 320
RGB: 120 0 28
POV-Ray: <0.47, 0.00, 0.11>
Dark Stone Gray (New Dark Gray)
LDraw: 72
RGB: 99 95 97
POV-Ray: <0.39, 0.37, 0.38>
Dark Tan
LDraw: 28
RGB: 197 151 80
POV-Ray: <0.77, 0.59, 0.31>
Earth Orange
LDraw: 366
RGB: 209 131 4
POV-Ray: <0.82, 0.51, 0.02>
Electric Contact
LDraw: 494 (yellow)
RGB: 208 208 208 (chrome)
POV-Ray: <0.82, 0.82, 0.82>
Gray
LDraw: 7
RGB: 193 194 193
POV-Ray: <0.76, 0.76, 0.76>
Green
LDraw: 2
RGB: 0 140 20
POV-Ray: <0.00, 0.55, 0.08>
Light Blue
LDraw: 9
RGB: 107 171 220
POV-Ray: <0.42, 0.67, 0.86>
Light Gray (from Mosaic sets)
LDraw: 503
RGB: 230 227 218
POV-Ray: <0.90, 0.89, 0.85>
Light Green (Belville, Pastel Green)
LDraw: 17 (or 431)
RGB: 186 255 206
POV-Ray: <0.73, 1.00, 0.81>
Light Orange
LDraw: 462 (code formerly used for regular orange)
RGB: 254 159 6
POV-Ray: <1.00, 0.62, 0.02>
Light Red (Scala, Salmon)
LDraw: 12 (or 463)
RGB: 255 133 122
POV-Ray: <1.00, 0.52, 0.48>
Light Violet (Belville)
LDraw: 20
RGB: 215 196 230
POV-Ray: <0.84, 0.77, 0.90>
Light Yellow (Belville)
LDraw: 18 (or 495)
RGB: 253 232 150
POV-Ray: <0.99, 0.91, 0.59>
Lime
LDraw: 27
RGB: 215 240 0
POV-Ray: <0.84, 0.94, 0.00>
Magenta
LDraw: 26
RGB: 216 27 109
POV-Ray: <0.85, 0.11, 0.43>
Orange
LDraw: 25 (formerly 462)
RGB: 249 96 0
POV-Ray: <0.98, 0.38, 0.00>
Pearl Copper
LDraw: 134
RGB: 147 135 103
POV-Ray: <0.58, 0.53, 0.40>
Pearl Gold
LDraw: 142
RGB: 215 169 75
POV-Ray: <0.84, 0.66, 0.29>
Pearl Gray
LDraw: 135
RGB: 171 173 172
POV-Ray: <0.67, 0.68, 0.67>
Pearl Sand Blue
LDraw: 137
RGB: 106 122 150
POV-Ray: <0.42, 0.48, 0.59>
Phosphor White (Glow in the Dark)
LDraw: 21
RGB: 224 255 176
POV-Ray: <0.88, 1.00, 0.69>
Pink
LDraw: 13
RGB: 249 164 198
POV-Ray: <0.98, 0.64, 0.78>
Red
LDraw: 4
RGB: 196 0 38
POV-Ray: <0.77, 0.00, 0.15>
Reddish Brown
LDraw: 70
RGB: 105 64 39
POV-Ray: <0.41, 0.25, 0.15>
Rubber Black
LDraw: 256
RGB: 33 33 33
POV-Ray: <0.13, 0.13, 0.13>
Rubber Blue
LDraw: 273
RGB: 0 51 178
POV-Ray: <0.00, 0.20, 0.70>
Rubber Gray
LDraw: 375
RGB: 193 194 193
POV-Ray: <0.76, 0.76, 0.76>
Rubber Red
LDraw: 324
RGB: 196 0 38
POV-Ray: <0.77, 0.00, 0.15>
Rubber White
LDraw: 511
RGB: 255 255 255
POV-Ray: <1.00, 1.00, 1.00>
Sand Blue
LDraw: 379
RGB: 106 122 150
POV-Ray: <0.42, 0.48, 0.59>
Sand Green
LDraw: 378
RGB: 160 188 172
POV-Ray: <0.63, 0.74, 0.67>
Sand Red
LDraw: 335
RGB: 191 135 130
POV-Ray: <0.75, 0.53, 0.51>
Sand Violet
LDraw: 373
RGB: 132 94 132
POV-Ray: <0.52, 0.37, 0.52>
Stone Gray (New Gray)
LDraw: 71
RGB: 163 162 164
POV-Ray: <0.64, 0.64, 0.64>
Tan
LDraw: 19 (or 382)
RGB: 232 207 161
POV-Ray: <0.91, 0.81, 0.63>
Teal
LDraw: 3
RGB: 0 153 159
POV-Ray: <0.00, 0.60, 0.62>
Trans Blue (or trans dark blue)
LDraw: 33
RGB: 0 32 160
POV-Ray: <0.00, 0.13, 0.63, 0.90>
Trans Flu Lime (Trans Neon Green, Trans Yellow-Green)
LDraw: 42
RGB: 192 255 0
POV-Ray: <0.75, 1.00, 0.00, 0.90>
Trans Flu Orange
LDraw: 57
RGB: 249 96 0
POV-Ray: <0.98, 0.38, 0.00, 0.80>
Trans Gray (Smoke)
LDraw: 40 (or 32)
RGB: 99 95 82
POV-Ray: <0.39, 0.37, 0.32, 0.90>
Trans Green
LDraw: 34
RGB: 6 100 50
POV-Ray: <0.02, 0.39, 0.20, 0.90>
Trans Light Cyan (Trans Light Blue)
LDraw: 41
RGB: 174 239 236
POV-Ray: <0.68, 0.94, 0.93, 0.95>
Trans Pink
LDraw: 45
RGB: 223 102 149
POV-Ray: <0.87, 0.40, 0.58>
Trans Red
LDraw: 36
RGB: 196 0 38
POV-Ray: <0.77, 0.00, 0.15, 0.90>
Trans Violet
LDraw: 37
RGB: 100 0 97
POV-Ray: <0.39, 0.00, 0.38>
Trans Yellow
LDraw: 46
RGB: 202 176 0
POV-Ray: <0.79, 0.69, 0.00, 0.90>
Turquiose (Cyan)
LDraw: 11
RGB: 51 166 167
POV-Ray: <0.20, 0.65, 0.65>
Violet (Purple)
LDraw: 22
RGB: 129 0 123
POV-Ray: <0.51, 0.00, 0.48>
Violet Blue
LDraw: 23
RGB: 71 50 176
POV-Ray: <0.28, 0.20, 0.69>
White
LDraw: 15
RGB: 255 255 255
POV-Ray: <1.00, 1.00, 1.00>
Yellow
LDraw: 14
RGB: 255 220 0
POV-Ray: <1.00, 0.86, 0.00>
Flesh (from Duplo figures)
RGB: 250 163 157
LDLite: 28
Lime green (Blacktron II)
RGB: 173 221 80



Edge colours

In LDraw colour number 24 refers to a contrast/complement colour for the current colour (number 16).

Notice that complementing is not reversible for colour numbers 6, 7, 14, and 15.
Surface Edge
0 8
1 9
2 10
3 11
4 12
5 13
6 0
7 8
8 0
9 1
10 2
11 3
12 4
13 5
14 8
15 8


Dithered Colors

LDraw can render mixes of the basic 16 colors. This is commonly called 'dithering'. You can use dithered colors on any line.

If you want to dither two colors from the range 0 - 15, use this formula to find the proper color code:

[Dithered Code] = [Color 1] + [Color 2] * 16 + 256

For example, if you wanted to mix black (color 0) and blue (color 1), the calculation would be:

[Dithered Code] = 0 + 1 * 16 + 256

Which is pretty to easy to find: 272.

Finally, the edge-color of Color 1 is used as the edge color of the dithered color.





This meta-statement will specify the properties of a single LDraw colour code. This statement may appear at any time in an LDR file, but will probably be most useful in the file header.

In official LDraw.org materials, !COLOUR will appear in the ldconfig.ldr configuration file, to define the standard LDraw color set. It will not appear in any official part or primitive files.

The current version of ldconfig.ldr can be found here

The ldconfig.ldr file that contains the standard colour definitions will contain the following in its header:

0 !LDRAW_ORG Configuration UPDATE YYYY-MM-DD

Scope

It's recommended that colour definitions be limited in scope. A color definition will affect colors from the point it first appears, continuing through the end of the file. Commands preceding a colour definition will not be affected by the definition. Color definitions will expire at the end of the file in which they appear, effectively falling out of scope. Color definitions will be passed to subfiles.

The configuration file, ldconfig.ldr, is not affected by the scoping rules, in the sense that the definitions in ldconfig.ldr remain in effect after the renderer is finished processing ldconfig.ldr.

Syntax

The entire statement must appear on one line. It may be line-wrapped in this document for clarity.

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

Tags. CODE, VALUE, EDGE, ALPHA, DITHER, LUMINANCE, CHROME, PEARLESCENT, RUBBER, MATTE_METALLIC, METAL and MATERIAL are keyword tags. Some tags are followed by a single parameter value. Tags are case-insensitive. Numeric parameters, other than RGB color values, should be specified in decimal. RGB values must be specified in hexidecimal, and must be prefixed with # or 0x. Byte values are integers in the range 0-255. Identifiers are strings of text. The allowable characters are alphanumerics from 7-bit ASCII set: a-zA-Z0-9_. Additionally, the first character in an identifier must an alphabetic (a-zA-Z). Identifiers are case-insensitive.

Definitions of Parameters

* name - A short name for the color. Name may be any identifier. This item is provided mainly for human recognition. Name is a required element.
* CODE x - The LDraw color code. For LDraw compatibility, x is an integer 0-511. If strict LDraw compatibility is not required, x is any identifier recognized by a rendering program as a color code. Code is a required element.
* VALUE v - The color value. v is a 24-bit RGB value. VALUE is a required element.
* EDGE e - The contrasting edge color. e may be either a color code or an RGB value. EDGE is a required element.
* ALPHA a - The alpha channel (transparency) value. a is a byte value, where 0 is totally colorless and 255 is completely opaque. In official materials, standard transparent colors will specify ALPHA 128. A 0 value is useful for temporarily hiding sections of models. ALPHA is an optional element.
* LUMINANCE l - Brightness for colors that glow. l is a byte value. Luminance is not generally used by LDraw renderers, but may be used for translation to other rendering systems. LUMINANCE is optional.

Only one of CHROME, PEARLESCENT, RUBBER, MATTE_METALLIC, METAL and MATERIAL may be specified for a single color. They all specify the finish/texture to be applied to an object being rendered. Other finish-tags may be defined over time.

* CHROME - A flag indicating that surfaces should have a mirror-like finish. Not currently used by LDraw-compatible programs, but may be implemented in the future. CHROME is optional, and may not appear with other finish tags.
* PEARLESCENT - A flag indicating that surfaces should have a finish like Lego's 'metallic' colors. These colors are commonly called 'pearlescent' by fans. Not currently implemented in LDraw-compatible programs. PEARLESCENT is optional, and and may not appear with other finish tags.
* RUBBER - A flag indicating that surfaces should have a finish like rubber (typically rubber tubing or rubber tyres). RUBBER is optional, and may not appear with other finish tags.
* MATTE_METALLIC - A flag indicating that surfaces should have a finish that simulates brushed metal finishes. MATTE_METALLIC is optional, and may not appear with other finish tags.
* METAL - A flag indicating that surfaces should have a finish like actual metal (not a simulation of a plastic simulation of metal). METAL is optional, and may not appear with other finish tags.
* MATERIAL [name <params> ...]</params> - Some other surface finish requiring customized parameter(s). Name is an identifier. MATERIAL is optional, and may not appear with other finish tags. Since it may have complex parameters that don't follow the standard syntax of the !COLOUR statement, MATERIAL should be the last tag in the !COLOUR statement.

The following MATERIAL definitions are official:

GLITTER VALUE v [ALPHA a] [LUMINANCE l] FRACTION f VFRACTION vf SIZE s | MINSIZE min MAXSIZE max
SPECKLE VALUE v [ALPHA a] [LUMINANCE l] FRACTION f SIZE s | MINSIZE min MAXSIZE max

GLITTER is used to specify a color that includes glitter mixed into the transparent plastic. Individual glitter grains are assumed to be flat squares, with arbitrary orientation.
SPECKLE is used to specify a color that has a speckled pattern of an alternate color on its surface. Individual speckle grains are assumed to be roughly round.

FRACTION f is the portion of the surface that uses the alternate color, expressed as a decimal number greater than 0.0 and less than 1.0.
VFRACTION vf is the portion of the volume that uses the alternate color, expressed as a decimal number greater than 0.0 and less than 1.0. Renderers that support volume rendering will use this value instead of the FRACTION value.
SIZE is the size of each speckle/glitter grain, in LDraw units. It must be greater than 0. This is mutually exclusive with MINSIZE and MAXSIZE.
MINSIZE and MAXSIZE provide a range of sizes for grains, in LDraw units. If either of these is specified, both must be specified, and they are mutually exclusive with SIZE.

Here is an example usage of SPECKLE:

0 !COLOUR Speckle_Black_Silver CODE 132 VALUE #000000 EDGE #595959 MATERIAL SPECKLE VALUE #595959 FRACTION 0.4 MINSIZE 1 MAXSIZE 3











Scope

The !CATEGORY and !KEYWORDS meta-statements provide information for organizing and searching the LDraw parts library. Before these meta-statements were defined, the only way to organize the library was by the descriptive name and part number. While useful, the name and number do not provide enough information to thoroughly catalog a large library of parts.

The !CATEGORY meta-statement provides a means to place the part in a comprehensive classification system and is used for locating a part within a list of categories, while the !KEYWORDS meta-statement provides a means for associating free-form search terms with the part.

These meta-statements are used exclusively in part files; they do not appear in models, primitives, or subparts.

!CATEGORY Syntax

0 !CATEGORY <categoryname>

The !CATEGORY meta-statement, if present, must appear in the part header, as defined by the LDraw.org Official Library Header Specification. A part can have only one !CATEGORY meta-statement. If a part has no !CATEGORY meta-statement, the category is assumed to be the first word in the part name (ie. the first word of the first line of the part file).

The text after !CATEGORY is treated as a single category name. So, if a part contained the meta-statement "0 !CATEGORY Minifig Accessory" it would specify that the part belongs in the category "Minifig Accessory" (as opposed to belonging to the "Accessory" subcategory of the "Minifig" category or both the "Minifig" and "Accessory" categories).

The current list of categories is as follows:
Animal
Antenna
Arch
Arm
Bar
Baseplate
Belville
Boat
Bracket
Brick
Car
Cone
Container
Conveyor
Crane
Cylinder
Door
Electric
Exhaust
Fence
Flag
Forklift
Freestyle
Garage
Gate
Glass
Grab
Hinge
Homemaker
Hose
Jack
Ladder
Lever
Magnet
Minifig
Minifig Accessory
Panel
Plane
Plant
Plate
Platform
Propellor
Rack
Roadsign
Rock
Round
Scala
Slope
Staircase
Sticker
Support
Tail
Tap
Technic
Tile
Tipper
Tractor
Trailer
Train
Turntable
Tyre
Wedge
Wheel
Winch
Window
Windscreen
Wing


New categories are added by the Parts Library administrators and the official list of categories can be found in the Categories and Keywords FAQ on the Parts Tracker. (The above list can therefore be varied by the Parts Library administrators without affecting the validity of the Category and Keyword specification.)

!KEYWORDS Syntax

0 !KEYWORDS <first keyword>, <second keyword>, ..., <last keyword>

The !KEYWORDS meta-statement(s), if present, must appear in the part header, as defined by the LDraw.org Official Library Header Specification. A part may have many !KEYWORDS meta-statements.

The list of words and phrases following the !KEYWORDS meta-statement is delimited by commas. Any white-space should be reduced to a single space, and leading and trailing spaces on the keyword ignored. Multiple lines can be used to structure or group keywords into themes. The lines should be limited to 80 characters. Words and terms from the part name are not allowed; neither is the part number.

The keywords are a list of words and phrases that further describe the part and specify any terms the author feels would aid in identifying the part. Keywords typically include: terms not included in the part's descriptive name; geometric terms; synonyms (for example, if the part name includes the term "rounded", a keyword might be "curved"); the unique set the part appeared in; LEGO official playthemes; other category names that the part is similar to (for example, wheels without separate tyres could also have the keyword "Tyre"); alternate spellings.
I'm proud of myself for actually having read all of that, and mostly understood it, and compiling the important bits together. My last 3 attempts have resulted in my getting a sandwich after 10 minutes or so.
Heh, sammiches ftw Smile
It sounds dooable, and worth the effort. The trouble is the effort. This seems like something to consider a little later in the game than where we are at right now, perhaps after or leading to the first version release.
My hope is to make the first release as soon as possible, and then make lag fixes + LDraw modeling a top priority.
indeed. I downloaded the suite but I am having some trouble decifering the seemingly cryptic set of programs and buttons. Let me know if you could help, I would love to get modeling.
CyberPrime wrote:
indeed. I downloaded the suite but I am having some trouble decifering the seemingly cryptic set of programs and buttons. Let me know if you could help, I would love to get modeling.


MLCad is pretty good if you're using Windows, and I'm gonna guess it'll run fine with WINE too.
*Fat Guy Looks Up From Pizza*

....Huh?

*Returns To Food*


Maybe Someday I'll Figure This Out.... :/
Yea, I was planning on using it under a VMachine, just because the stupid installer requires .NET. It's just as well though, I will "fiddle about" with MLcad. "Whoo! I'm hot tonight!" Oh, man, two in one post. Amazing.
We're also gonna have to add a meta-command for nodes.
Paul Gyugyi, the author of LDLite (a GPL'd open source LDraw model viewer) has just granted me a license to use his lex/yacc code as part of my in game parsing+rendering. This is a HUGE boon to development.
elfprince13 wrote:
Paul Gyugyi, the author of LDLite (a GPL'd open source LDraw model viewer) has just granted me a license to use his lex/yacc code as part of my in game parsing+rendering. This is a HUGE boon to development.
Epic win, sir! I am personally fond of lex/yacc, having used them to write myself a compiler for my Compiler Design class.
Very, very cool elf. Can't wait to see this all get off the ground.
I've started porting ldlite.l to TGE code.
elfprince13 wrote:
I've started porting ldlite.l to TGE code.
This.
calc84maniac wrote:
elfprince13 wrote:
I've started porting ldlite.l to TGE code.
This.
THIS
KermMartian wrote:
calc84maniac wrote:
elfprince13 wrote:
I've started porting ldlite.l to TGE code.
This.
THIS



ccccoommmmbooo breeakkkerrr

p.s great job cannot wait to see the results
blitz_9100 wrote:
ccccoommmmbooo breeakkkerrr
jerk... Laughing

Good to hear, elfy! Very Happy
swivelgames wrote:

Good to her, elfy! Very Happy


are you saying i wouldn't be.
rotfl. Fixed Laughing
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 4
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement