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

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

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.