Release Notes, LDLITE Version 2.3

What is LDLITE?

LDLITE is a program that displays 3D models. Its file format is a superset of the *.dat format used by the program LDRAW. A vast library of parts for LEGO-brand building bricks have been defined in *.dat format , and it is a popular format for exchanging descriptions of LEGO models.

Version 2.3 is a functional, stable release for the MS Win95/98/NT platform, fully compatible with LDRAW. Source code for LDLITE is available under the GPL.

Paul Gyugyi,

Release date: September 3, 2001.


LDLITE version 2.3, Copyright (C) 1998-2001 Paul J. Gyugyi

LDLITE comes with ABSOLUTELY NO WARRANTY; for details see the file COPYING distributed with this program. This is free software, and you are welcome to redistribute it under certain conditions; for details see the file COPYING distributed with this program.


The LDLITE project is now hosted at where you can obtain the latest binaries and source code, make feature requests, file bug reports, and join the mailing list.

Platforms supported

Version 2.3 Release Notes

New features:

Known limitations:

Version 2.2 Release Notes

New features:

Known limitations:

Version 2.1 Release Notes

New features:

Known limitations:

Version 2.0 Release Notes

New features:

Known limitations:

Commandline Options

The following are an exhaustive list of the commandline options supported by LDLITE. Command line options do not need to be specified in any particular order. Options consist of a dash, a single character, and sometimes an argument. Note that there must not be a space between the character and the argument. Currently all options are not case sensitive.


  1. To have access to the building brick libraries, you should first install the LDRAW program. I'd also recommend installing the LDRAW Add On (LDAO) program. LDLITE does not actually need anything from those programs, but works well with them.
  2. Locate your "Base LDRAW directory", where you installed your LDRAW files. This is usually named C:\LDRAW. If you didn't install LDRAW, just create a directory somewhere. In this directory, create a subdirectory called LDLITE.
  3. Place the files in this archive into the LDLITE directory. LDLITE will look for files in the ..\MODELS, ..\P and ..\PARTS directories. (you could actually put the LDLITE files in any directory and it would work OK).
  4. Run the ldlite.exe file. If you have never installed LDAO, you will get a dialog box asking you to set the base LDRAW directory. You should see a blank window with a white background. Go to "File-Open" and click on "ldl-logo.dat", which is distributed with this archive. You should see a grey rectangle. Click on the image (with the left button), and LDLITE will draw the next step, which will draw the letter L. You will see comments from the ldl-logo.dat file appearing on the status bar in the second field. Continue clicking on the image until all steps have been drawn and the title bar says "Finished" and the letters spell LDLITE. The file "ldl-logo.dat" does not use any of the LDRAW library *.dat files.
  5. Start Ldlite, and chose "File/Open" to find "..\models\car.dat", a standard file distributed with LDRAW. You should see the first step in the car.dat file, a pair of axle plates and a plate. Click on the image (with the left button), and LDLITE will draw the next step. Continue clicking on the image (or quit the program by clicking on the close box) until all steps have been drawn and the title bar says "Finished". Then click on the close box. If you get an error message, the base path in your LDRAW.INI file may be incorrect. Go to the "Options" menu and select "Set path for LDRAW parts", select the LDRAW base directory and press OK.
  6. Go to the "Options" menu and select "View". This will allow you to change the zoom factor and view position for the model. If you have not installed LDAO, the view position list box will not work.
  7. You can use all the standard LDRAW command line options, either from a command windows, the Start/Run dialog, or using a shell program, such as LdrawAddOn (Highly recommended).
  8. Ldlite will register itself as the default program for .dat files if no other program is already configured that way. You can then double click on a .dat file from the Explorer window and it will start ldlite.
  9. Netscape can be configured to automatically run ldlite when it encounters .dat files. After running LDLITE at least once, go to the Netscape menu item Edit/Preferences/Navigator/Applications, select "ldlite Document", Edit, and set the mime type to application/x-ldraw. Now if you download a .dat file from a properly configured server, such as lugnet or the two dat links here: wood4.dat, mudray.dat, you'll be given the option to download the file or view it with ldlite.


The entire LDRAW community is very helpful, and I've gotten a lot of advice and help. I'm especially glad to get code snippets in the mail. Much thanks to Steve Bliss, Lars Hassing, Leonardo Zide, Jeremy Sproat, and Don Heyse for making this a much better program than I could produce myself. Great thanks to Todd Lehman for setting up the LUGNET discussion group server to support LDLite and for listing the LDLITE home page as CLSotW. Of course none of this would have a purpose without James' LDRAW parts library and the continued work on pieces by other folks on the LCAD mailing list.

Release Note History

Release notes, Version 1.5

Version 1.5 has two sets of new features. First, there are improvements to the LDRAW-compatible operation. Second, there are extensions to the language to make it a more general-purpose program. While many LDRAW users will find the new extensions to save them time and effort when writing models, LDLITE supports converting the new language extensions back into LDRAW syntax for maximum compatibility.

LDRAW Compatible Features:

The following new features in version 1.5 will enhance your LDRAWing experience:

1. Improved graphics quality. Edge lines are now accurately drawn, as I changed the zbuffer routines to use fixed-point numbers and no longer experience large rounding errors.

2. Memory leaks have been plugged. This improves operation in "polling mode" as part of the LDAO modeller.

3. Mildly faster rendering, especially when zoomed in on a small part of a model.

4. Configuration now shares the LDRAW.INI file with LDAO, rather than using the LDRAWDIR environement variable. If you have already installed LDAO, LDLITE will use that base directory setting; if not, you will get a nice dialog box to help you set the base directory. This should solve many of the installation/configuration problems people have been having.

5. Log files are now supported. Using the command line option "-l", and everything normally written to the status bar will be saved into a file named ldlite.log. By default, that includes all Type 0 comments, such as "~moved to" lines and reports of syntax errors or missing files. If you specify "-g" you will get a more extensive debugging output.

6. The zoom/scale and viewpoint can be set from a menu item dialog box. The viewpoint is a list of names taken from the LDRAW.INI file. These are the same ones used by LDAO.

7. A new option "-Zfloat" allows you to create cutaway views. It effectively cuts off anything closer than a given value "float". All pixels with a final transformed z value less than "float" will not be drawn. This only allows you to shear off in a plane parallel to your computer screen. Cutaway views on orthographic projections like you normally see in books will have to wait for a later release. To see what it would look like if you were the driver of CAR.DAT, try this:

8. I've added an eye-candy "twirling mode". If you specify "-t" as a parameter, then after the program is finished drawing the model it will set the view to be 10 degrees further around the y axis, redraw, and repeat. You should use this in conjunction with "-MC" or it will keep pausing for a mouse click. To exit, move the mouse (which will have an hourglass cursor) over the close box and click The program will exit when it finishes drawing the model. I would not advise using "-t" in conjunction with "-l", or "-p". For example, you can use the following command in a command window to check out how the Technic engine block part looks from all angles:
ldlite -V3 -S2 -MC -t 2850.dat

LDLITE Extensions:

LDLITE 1.5 supports a number of extensions to the LDRAW syntax. The commands are implemented as Type-0 META commands. These should be considered "beta versions", since I want to reserve the flexibility to change these to match more closely what is used by other LDRAW-related tools. Your comments and suggestions are welcome. The file "wood3.dat" distributed with the program demonstrates most of the new extensions.

1. Naming things. You can define alphanumeric names to represent colors, points and matricies.The names follow the same scoping rules you find in programming languages; think of .dat files as subroutines. The name must be defined before it is used in a file. The name then can be used or redefined throughout the rest of that file, including inside Type-1-included files. The name definition evaporates (leaves scope) at the end of the file. Names are local to files, meaning they apply to that file and all files it includes, but do not remain defined when returning to a higher level file. This means you cannot define a bunch of names in a file you call from your main model file and then use them later in the main model file. In other words, putting the line "1 16 0 0 0 1 0 0 0 1 0 0 0 1 default_colors.dat" at the start of your model will not work; the color names you defined in default_colors.dat will be gone by the time the second line of the model is parsed. On the other hand, you can be assured that including a part with a Type 1 line will never screw up the names you have defined. A future version of LDLITE will support a default.dat file which will be loaded at the beginning of the program and used to define names which will be valid at all times.

The following commands can be used to name things:

An example of use the names in a file:

The following color names are pre-defined by LDLITE. The ones marked "unused" should probably be given names.

2. Redefining color palette values. LDRAW defined two types of colors. Colors from 0 to 31 were solid colors (except 16 and 24), colors 32 to 63 were transparent, and numbers from 256 to 511 were dithered combinations of two colors from 0 to 15.

LDLITE allows colors from 0 to 255 (except 16 and 24) to be (re)defined to be solid or dithered combinations of 24-bit colors. Color redefinitions follow the same scoping rules as the names in the previous section. I'd like to reserve the entries 0 to 127 for standardized, official brick colors. Colors 128 to 255 are fair game for you to use in your own files.

The syntax of the COLOR statement is:


3. Direct colors LDLITE defines the color values from 0x4000000 to 0x7ffffff. These represent two 12-bit colors which are dithered together, and cannot be redefined. They are intended to be used in converting meshes from other 3D formats. While you can use decimal numbers, the hex representation makes the structure clear. The edge color for all direct colors is pure black.

The first (leftmost, most significant) hex digit defines whether the color will be transparent. "4" is an opaque color. "5" or "6" create transparent colors. "7" will create an invisible color which will not be drawn at all. You can interpret the two least significant bits of this digit as inverted alpha values.

The fifth, sixth, and seventh digits are the red, green, and blue intensities of the first dithered color. These digits are ignored for colors in the ranges 0x5000000 to 0x5ffffff and 0x7000000 to 0x7ffffff.

The second, third, and fourth digits are the red, green, and blue intensities of the second dithered color. For pure colors, set these to the same as the fifth, sixth, and seventh digits. These digits are ignored for colors in the range 0x6000000 to 0x7ffffff.

4. Nested transforms I find transform matricies to be obscure and tedious. Being able to give them names (see above) helped a little. This takes things one step further and provides the kind of nested transforms one commonly finds in raytracing programs. You can surround a set of lines with one of these nested transform commands, and the surrounded lines will all be affected.

The nested transform commands are:

5. Converting to LDRAW syntax. To maintain backwards compatibility as much as possible, LDLITE can be used to convert a file to LDRAW *.dat syntax. While COLOR commands are simply ignored, and direct colors will cause LDRAW to choke, all other commands (names, nested transforms) can be converted successfully. The syntax for converting a file with extended syntax (e.g. named "extended.dat") to one using just LDRAW syntax (e.g. named "oldstyle.dat") is:

When run in this mode, LDLITE will pop up a window, do the conversion, and exit. Nothing will be drawn, and in the future I'll try and improve how it works, since it is a little unnerving to have a full screen window appear and vanish right away. Note: the conversion process may produce floating point numbers in exponential format, such as 2.3e-008. Both LDRAW and LDLITE seem to work correctly with these numbers, but I havn't tested other tools.

Release Notes, Version 1.2

  1. Version 1.2 is an "internal release", not distributed on the web page.
  2. Routines in the code (currently disabled) will produce a limited type of POV code (just triangles and cylinders).
  3. Version 1.2 was the branch point for the Linux command-line version.

Release Notes, Version 1.1

  1. Fixed bug where the LDAO "Main Color" option was not being used. "-Cnumber" will now set the default color for the model.
  2. Fixed bug where ldlite was not searching all directories to find a command-line specifed filename.
  3. Ldlite now zooms to full screen if started without a -V option.
  4. If you specify a "-p" on the command line, ldlite will go into a polling mode, where it will watch the timestamp on the current .dat file and re-render it if the file is updated. When I develop models, I start up two ldlite programs, one looking at the model from the above view, and one looking at oblique view, both with the -p on -MC (continuous) option set. Whenever I make a change in the editor and save the .dat file, both view windows automatically update themselves. Changing the Options menu to "Show only full models being drawn" works well with this. I've never tested polling without specifying a .dat file on the command line. Currently, ldlite will eventually crash due to the memory leak bug below.

Release Notes, Version 1.0

  1. Complete LDRAW command line compatibility. This was the criterium for numbering the release 1.0, so I jumped straight to that from version 0.3.
  2. Greatly improved parsing speed thanks to a caching lex/yacc parser, which only requires files from the P and PARTS directories to be opened once. Caching sped up performance by a factor of two. Expect this to improve even more in future releases, as Lars Hassing has recently contributed a scanf-style parser that works 2-4 times faster.
  3. Parsing is now very robust to errors in the source files, including the problematic case of the last line of a file not ending in a carriage return.
  4. Improved graphics code from Lars rearranged the bitmap storage into a more windows-compatible format, eliminating the need for SetPixel(). This increased performance by a factor of 4.
  5. Added menu commands for changing Ldlite-specific options. These settings are stored in the registry and used next time ldlite is run.
  6. I added options for how the screen is updated. The screen is only updated at each STEP or after certain Type 1 lines. You can choose to have the screen updated after each primitive is drawn, after each part is drawn, or after each model is drawn, which is based on which directory the Type-1-included file is found in.
  7. I added a shading option, which darkens surfaces which are not perpendicular to the direction of viewing. There are no shadows cast, but this does help bring out the curvature of objects.
  8. I added support for bitmap creation when there are more than 100 steps, which is not handled by LDRAW. Similar to the way LDRAW works, the name of the dat file is truncated and digits are appended, with less of the dat file name being used as the number increases.
  9. Fixed up a few color settings. Made grey a bit lighter.
  10. Lex and Yacc source files are included in this release. After running ldlite.l through flex, you will need to make two changes. First, make sure the line "#include <stdlib.h>" appears in the lex.yy.c at the top, right below "#include <stdio.h>". When I run flex, it surrounds that line with some #if statements that do not work with VC++. If stdlib.h does not get included, the aotf() conversion routine will not have the right prototype, and all the numbers will be parsed as random, garbage values. Second, change the line "#define YY_DECL int yylex YY_PROTO(( void ))" to "#define YY_DECL int my_yylex YY_PROTO(( void ))". This makes the program call the faster, caching version which in turn calls the standard yylex() only when needed. If you forget to do this, you'll get link errors about the multiply defined function yylex().
  11. The ability to save to bitmap is provided by routines from the source files dibkernel.cpp and dibkernel.h, written by , RenÚ Dencker Eriksen ( and Hans-Martin BrŠndmose Jensen ( Since I have not yet gotten their permission to redistribute their code, you'll have to grab the files, which are freely available at

Release Notes, Version 0.3

  1. The screen drawing routines much faster now. Many thanks to Leonardo Zide for contributing the routing to render to an off-screen bitmap, and thereby inspiring me to add an invalidate-rectangle style algorithm to speed up rendering. I'm happy to say LDLITE seems to be rendering images in 2/3 the time of LDRAW!
  2. The colors are much more accurate, thanks to information provided by Steve Bliss. Included with that are Pantone colors for the bricks that Todd Lehman put together. LDLITE looks a little more realistic and has a little less contrast than LDRAW. I'm not sure if that is good or bad, but it looks pretty good anyways. Dithering and transparent colors are supported.
  3. The software is more Windows-friendly. You can exit without going through all the steps in a model. You can move the window around and print at any step. Line type 0 Comment strings are displayed in the status bar.

Release Notes, Version 0.2

  1. The screen drawing routines are insanely slow, because I wrote them that way. Expect this to improve, or grab the source and make it better. Perhaps doing the SetPixels on a bitmap in memory and then copying it to the screen would be faster. The zdraw rendering routines are as fast as they need to be.
  2. There is no command line support for viewing positions, etc. I don't plan on doing this myself, so it would be a good place to grab the code and add to it.
  3. Printing is somewhat limited. I've found that using the printer setup to change the DPI of my Deskjet from 300 to 150 or 75 resulted in a larger image on the sheet of paper.
  4. Clear and dithered colors are not correctly implemented yet, but are somewhat close.
  5. Support for STEP commands it limited. When drawing files with mulitple steps, LDLITE ignores everything else except left button clicks in the window. I mean everything -- no redrawing the window border, no resizing, no exiting. As soon as the final step is drawn, LDLITE will process all the other mouse clicks you have done. The next release will fix this behaviour, which involves making the code more windows specific by using a background thread.
  6. Comment strings are ignored. Any line starting with a zero that is not in the exact format of "0 STEP" will be ignored.
  7. If .dat files do not end in a newline character, the last line will not be draw correctly. There are only about 3 or 4 .dat files in the LDRAW distribution with this problem. I'll compile a list for the next release.
  8. LDLITE uses a lot of file I/O, opening and closing common files like stud.dat hundreds of times for a typical model. This I/O makes up the majority of the processing time. Finding a way to cache the binary token stream of common files would speed things up a lot.