L3P

L3P is a neat little console program that will produce a ready-to-render POV-Ray-file from any LDRAW model using any part.
L3P now supports the LGEO library with high quality parts designed specifically for POV:
 

POV file generated exclusively from DAT files by the command l3p -b -f -cg30,65 -ca20 -q3 testcar.mpd

POV file generated from LGEO parts (and a few DAT files) by l3p -b -f -cg30,65 -ca20 -q3 -lgeo testcar.mpd

Here is one of the models in the 1995 set 4555 Freight Loading Station, a racing car:
 

l3p -b -f -ca40 -q3 m4555d.dat

l3p -b -f -ca40 -q3 -lgeo m4555d.dat

Here is the 4WD car from the 1995 set 6596 Wave Master. The POV-Ray rendering is shown together with the LDraw drawing:
 

l3p -b -f -q3 m6596a.dat

ldraw m6596a.dat

Here is a set from 1970, a veteran car:
 

l3p -b -f m603

ldraw -b7 m603

Here you have the model file m603.dat. You may have a look at the Veteran car in an ad from a Swedish Disney comic magazine from 1970 scanned by Tore Eriksson. The car is to the left in the image. You may notice that I have left out the two clear headlights and added a light on top of the roof in the right side in stead. This is to check that the image is not mirrored.
 

L3P Gallery

The motive to L3P.

From the FAQ, the L-CAD mailing list and various homepages I understood that LDraw was simply drawing lines and 3- and 4-edged polygons. So an obvious idea came to my mind: why not just transfer the polygons to POV? I then studied the format of the DAT-files and the meaning of the line type parameters. I began dissecting the 3004.DAT (Brick 1 x 2) and its subfiles. To ensure that my understanding of the DAT-files was correct and to play with 3D-geometry in general I actually began writing a Win95 program to read the DAT-files and display the lines and polygons in 3D. The main purpose of the display-part of the program was to test the many 3D transformations applied to the polygons, since I wanted to transfer the polygons to POV. The transformations work recursively as you follow the line type 1 inclusion of other DAT-files.

The program had many buttons to experiment with e.g. toggling the different line types on and off. It offered many different views and even let you rotate the model or part by the mouse. I did not, however, put any effort into z-buffering or hidden line/surface removal, as this was not the object of the program, so the display could sometimes be somewhat confusing because lines and polygons were just drawn in the order they appeared in the DAT-files. But it did give a good conception of the 3D geometry.

The program was called L3: when you begin a new project in Microsoft Visual C++ 5.0 you are prompted for a project name, so I just typed L3 for Lego+Ldraw+Lars :-). It was released as L3Lab in February 2000.

I then began generating the POV-files. In stead of drawing the polygons on the display, I simply wrote them to a file in POV syntax. But even for a simple 35 brick model like the 603 Veteran car the number of polygons quickly adds up: 3,400 triangles and 8,300 quads giving a total of 20,000 triangles. No wonder that LDraw may take time (and L3 too :-). So, in my first attempt the POV-file was 23,500 lines long, an overwhelming 1.7 Mega Bytes! It did, however, render relatively fast (<2 minutes for 320x240 no AA, and even <1 minute using meshes (Pentium 100MHz)). Apparently POV is very good at handling triangles.

Well, after some browsing in the POV manual I discovered the matrix keyword. In stead of feeding POV with all the transformed triangles, why not let POV take care of the line type 1 transformations? In the next attempt I made L3 convert each DAT-file into a POV object. The simplest DAT-files with only line type 3 and 4 became POV object having only triangles. DAT-files with line type 1 then became POV objects referencing other POV objects using the matrix for the transformation. The POV-file now got considerably smaller (950 lines, 49 kBytes) but took slightly longer to render (as POV now had to do the transformations itself).
 

Camera positioning, the L3 Globe

The L3 program had all the information about the geometry of the parts in memory, so it knew (or rather was able to calculate) the size and position of the model. With polar coordinates (relative to the center of the bounding box of the model) I only needed to supply the viewing angles and the distance. But how should I define the two angles in an easy understandable way? The answer was right below my feet: the Earth. We all know the globe and the Latitude and the Longitude. Think of a model placed inside a globe, with the center of the model's bounding box placed at the globe's center. You can now easily place camera (and light sources) in the 3D space by specifying Latitude, Longitude and Radius.

The L3 Globe. Click on the globe to see it in 1024x768 (265 kB). Download the POV source code l3globe.zip (10 kB).

L3 uses LDraw's coordinate system and measures. The floor is parallel to the XZ-plane and Y is negative upwards. Latitude is in the range from -90 degrees (south, along the positive y-axis) to 90 degrees (north, along the negative y-axis). 0 degrees is at the equator.
Longitude is in the range from -180 to 180, where 0 degrees is along the negative z-axis. 90 degrees (east) is then along the positive x-axis and -90 degrees (west) is along the negative x-axis.
The basic LDraw views can be represented by these Latitude,Longitude pairs:
Front=0,0 Right=0,-90 Left=0,90 Back=0,180 Over=90,0 Under=-90,0.
The 3D view can e.g. be 45,45 or 30,45.

But what about the camera distance, the Radius? I really wanted just to specify the viewing direction (Latitude,Longitude) and then have the camera to be "as close as possible" in order to minimize the space around the rendered model. So I devised the following algorithm:

• Think of the camera view towards the model as a funnel or a pyramid.
• Rotate the pyramid so that its centerline is parallel to the viewing direction vector.
• Then move the pyramid towards the model until it cannot come any closer.
• Now you have the camera position as the location of the top of the pyramid.

The viewing direction vector will be parallel to the direction given by (Latitude,Longitude) but not necessarily through the globe's center (which is the same as the model's center). To avoid problems with irregular shaped models I used all the bounding boxes of the parts when checking against the pyramid, rather than the total bounding box of the model, which can be "too big". (Ideally all triangles and quads should be considered, but in order to speed up calculation and reduce memory usage the program just fits the bounding boxes of the parts in the model into the camera view, i.e. one level of bounding boxes. (This has, however, turned out to give some problems with irregular shaped sub models, which are just treated as ordinary parts. If it becomes a real nuisance, I might use more levels some day. But often you won't use the closest view anyway, see later)). Some "space" will always exist either horizontally or vertically to maintain the aspect ratio. The calculations turned out somewhat comprehensive and involve solving six equations with six unknowns, but they worked just fine.

The camera position calculation worked well, almost too well: the rendered images might now look a bit distorted (some fish-eye effect), when the camera was moved that close; but remember the object was to minimize the waste of empty rendered area. However, to get a nicer looking image (and a better look at the shadows) it could actually be advantageous to have some "space" around the model. I obtained this by moving the camera away again from the model along the direction vector. Depending on your taste and the model, you get nice images when moving the camera 5-20% further away (5-20% of the calculated closest radius). After generating the POV-file you can continue experimenting with the camera distance (without generating a new POV-file) simply by editing the line near the end of the file:

   #declare PCT = 20 // Percentage further away

The positions of the light sources may also be specified as globe coordinates (polar coordinates), but these are always relative to the center of the bounding box of the model (and not to the point that the camera is looking at, as this point may be offset when you choose the closest camera view): if you want to make an animation I think it would be better to place the lights relative to the model than to a more or less random camera look-at-position.
 

Primitive substitution

However, I ran into a bug in POV-Ray: the disc object did not render correctly. I made a request to comp.graphics.rendering.raytracing and Vahur Krouverk from Estonia was very helpful and examined the POV source code (which is public available) and pointed out the bug ("matrix transformation for disc does not modify disc's normal vector and therefore it gets coloured differently") which was reported to the POV-Ray development team. The error has been fixed in v3.1, but to support older versions L3P can also use a very thin cylinder rather than the disc.

There is one drawback using the primitive substitution. Some complex parts interface the primitives by drawing triangles and quads up to the edges of the primitives. When a 16-edged cylinder is then replaced by a perfectly round cylinder, you get "holes" in the part. E.g. the 3482 Wheel Centre Large:

With primitive substitution:   l3p -b1,1,1 3482	Without primitive substitution:   l3p -b1,1,1 3482 -p

Finishes

I think that choosing the right colors, textures and light sources is the most difficult task in rendering. The colors and textures used today in L3 are empirical values from many experiments. I am not completely satisfied and would like to hear any suggestions. Currently I use the same RGB color for normal bricks and for transparent bricks. But this does not seem to hold for all colors, e.g. color 2 (green) and color 34 (transparent green) should use two different sets of RGB values. Also it is difficult to determine the amount of ambient light and the number of light sources. If you use little ambient light bricks not directly lit become too dark, and if you use more ambient light especially white bricks tend to get "overexposed".
 

Publishing my efforts

Version 1.0 19980818

Version 1.1 19990114

Quality Level control

Seams between bricks

Camera Viewing Angle

Stereo view

// Camera (Latitude,Longitude,Radius = 30,45,0)
camera {
   #declare PCT = 0; // Percentage further away
   #declare STEREO = 0; // Normal view
   //#declare STEREO = -degrees(atan2(1,12))/2; // Left view
   //#declare STEREO =  degrees(atan2(1,12))/2; // Right view
   location vaxis_rotate(<117.841,-102.464,-140.713> + PCT/100.0*<119.146,-97.2821,-119.146>,
                         <-11590.7,-28391.4,11590.7>,STEREO)
   sky      -y
   right    -4/3*x
   look_at  <-1.30431,-5.18241,-21.5678>
   angle    67.3801
   //orthographic
}

A good distance between the eyes is one twelfth of the distance from the eyes to the model (the look_at point). 1/12 corresponds to an angle of 4.8 degrees. You may vary this by replacing 12 with other values (e.g. in the range 5 to 20) in the atan2() function to obtain more or less depth in the scene.

Bumps

POV-Ray v3.1 compatible code generation

One of the most important new features in v3.1 is that texture is now replaced by material which comprises both interior and texture. Some features like refraction and ior (index of refraction) has been moved from texture to interior, which is really logical: texture is for the surface of an object, interior is for the - yes - interior.

By the use of the #if directive, L3P now generates POV code that runs without any warnings on both v3.0 and 3.1. If you experience a burp from POV, please let me know.

Support for MPD files

File search also in directory of model

Unlimited number of light sources + option to add default light sources

11 new primitives

Version 1.2 20000616

STUDS flag in POV file

TRANSLATE, ROTATE, SCALE, TRANSFORM meta commands

-c=<color> Default Part Color

   1 4  0 0 0  1 0 0  0 1 0  0 0 1 3001.dat

   l3p -c4 3001

LDRAWDIR or ldraw.ini

Extended colors (direct colors)

As MLCad also supports these colors, L3P does too.

However, Gyugyi packed two RGB's (for dithering) into each Direct Color leaving only 12 bits to each RGB, e.g. 0x04RGBRGB. Some L3P and L3Lab users have asked for the possibility to specify "true colors" (24 bit RGB's), so I have defined the range 0x02000000-0x03FFFFFF for this. 0x02RRGGBB for solid colors and 0x03RRGGBB for transparent.

I will support, but not require, hex notation for colors (0x/0X prefix). You are welcome to specify the color value in decimal ;-)

The following description is partly taken from the LDLite documentation:

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 second, third and fourth digits are the red, green and blue intensities of the first dithered color. These digits are ignored for colors in the range 0x6000000 to 0x7ffffff.

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

Note that this is the correct description! Paul Gyugyi has swapped the hex ranges in the last two paragraphs in his LDLITE documentation!

Valid colors

I haven't spent any time adjusting the new LDraw colors, they were just added from the FAQ. But I'll play a little with POV again to make some better colors. Most importantly the transparent colors should not necessarily be based on the corresponding non-transparent colors, but may have their own RGB values.
Please make any suggestions.

In the POV file an "#ifndef ColorXX" / "#end" pair is now put around L3P's color definitions. This makes it easier to use your own definitions.

Unlimited number of colors

14 new primitives

Support for hi-res primitives

More checks

Many parts actually have identical lines. Probably because of copy'n'paste blunders by the author, or because the same line or surface was simply coded twice in the file. Since this is a waste of rendering time, L3P can now report such repeated lines. The DOS version of L3P just reports that a given line has been seen before, the Win32 verson also shows you the line number of the previous occurrence.

Another common mistake is to reference lines with color 16 instead of color 24, so L3P now warns about this. The only legitimate example I have seen is in PARTS\S\973p46a.dat.DAT "~Subpart Minifig Torso with Forestman and Purse Pattern" by Chris Dee where he used color 16 linetype 2 to make sure an outline is visible at low resolution, see also http://news.lugnet.com/cad/dev/?n=4161 and http://news.lugnet.com/cad/dev/?n=4248. A clever but questionable technique because it makes some assumptions about the renderer. All other examples I have seen are errors, and that justifies the "Lines should not use color 16" warning.

Ill-formatted lines like "01 ..." are also noticed.

Bad lines before first valid commands are now allowed. You should now be able to directly render e.g. a DAT or MPD file sent by mail without complaints about the mail header.

L3P -check now checks (recursively) if all subfile references can be found.

-stdout  Redirect stderr to stdout

Version 1.3 20010120

Back in August 1999 Lutz Uhlmann agreed that L3P could reference his high quality LGEO POV parts. He promised to send some info regarding the binary format of the element table files. However, I have not heard from him since then, despite several mails.

But since he did consent that L3P could reference the LGEO parts, and since many users have requested it, I've decided to update L3P now anyway. So, with a little hacking I've managed to tweak L3P to use LGEO parts whenever possible. The missing parts are generated on the fly like today.

You now get the best of both worlds: high quality POV parts and L3P's support for automatic camera positioning, primitive substitution, MPD files, TRANSLATE, ROTATE, SCALE, TRANSFORM meta commands, extended colors (direct colors), etc.

Besides the LGEO support several nice features have been added, read on:

Support of LGEO parts

Like LDRAW, LGEO also has a set of primitives. Non-LGEO parts generated on the fly will use some of the LGEO primitives rather than the L3P primitives (POV equivalents).
Currently the following are used:
   stud.dat    lg_knob
   stud2.dat   lg_tech_knob
   stud4.dat   lg_plate_cylinder
Additionally the L3P studlogo is dynamically added to lg_knob, so it appears on LGEO parts too when rendering with -q3 (QUAL=3), see the -q<n> Quality option.

I found out that we (mis)use stud4.dat by scaling its height by 5 in bricks! (and other factors in other parts). LGEO uses lg_plate_cylinder and lg_brick_cylinder and we should use two different studs in LDraw too.

Primitive primitives (grin) like cylinders and discs are OK to be scaled, but studs should never be scaled - or they cannot be substituted correctly...
The stud4.dat's in 3001.DAT (Brick 2 x 4) look funny now, because the rounded corner gets scaled by 5...
 

1) You can download the LGEO parts library here. The latest part seems to be from September 23 1999, but there are 842 parts.
Install (extract) the LGEO files to your harddisk into e.g. C:\LDraw\Apps\LGEO. The LGEO directory contains the POV .inc files (include files) and some table files .tab meant for L2P.
Some LGEO files have bugs so you should also get the latest set of fixed LGEO parts from here.

2) L3P needs to know where it can find the three files, L2P_ELMT.TAB, L2P_COLR.TAB and L2P_PTRN.TAB, which contain info on the LGEO elements, colors and patterns. The three files are typically located in the directory named LGEO.
You can tell L3P where the LGEO directory is located either by setting the environment variable LGEODIR or by adding a line to ldraw.ini.
If LGEODIR is not set, L3P looks for ldraw.ini in C:\Windows (or the directory specified by the environment variable WINDIR). If found, L3P uses the LgeoDirectory setting in the [LDraw] section. L3PAO can handle this for you.

3) You must also tell POV-Ray where to find the LGEO include files: in POV-Ray for Windows v3.1 select "Edit Settings/Render" in the "Render" menu. Then type +LC:\LDraw\Apps\LGEO in the "Command line options" box and click the "Set but don't Render" button.

Now you should be all set to take advantage of the high quality LGEO parts. I've tried to overcome some of the bugs in L2P and in the LGEO parts. Also transparent LGEO parts are scaled a little bit to avoid coincident surfaces. The QUAL flag is supported to substantially speed up test renderings, see the -q<n> Quality option.
The LGEO colors are darker than L3P's colors. You can add extra light sources if you want.
 

-cla<x>,<y>,<z>  Camera look_at Coordinates

-pov  Launch POV-Ray upon successful writing of POV file

-upd  Check L3P's homepage for newer version

Vast number of new primitives

New search path

See the thread in lugnet.cad.dev Searching for parts.

-sc  StepClock, add "#if (clock > n)" at steps

L3P will print out the number of steps in the model, e.g. 8. You can now generate the instruction images by:

   wine -- L3P.EXE -sc -o car.dat
   povray +I car.pov +O car.png +FN +W400 +H300 -J +KFI1 +KFF8 +KI1 +KF8 +D +A

The output images will be named car1.png, car2.png, ..., car8.png.

The StepClock option was added on suggestion from Fredrik Glöckner, who supplied the command lines above. He said: "These are UNIX style command line options. I really have no idea what this looks like in the Windows world. Check the manual."

New rubber color

l3p -check

Color 24

So, color 24 is now considered illegal for linetypes 1,3 and 4, see the thread in lugnet.cad.dev Colour 24 in non type-2 lines (was Updated S\973S01.DAT).

Conditional POV code generation

I had been playing with the idea of embedding POV code in the DAT files since 1998. It was triggered by the 2473 Brush Car Wash, which unfortunately uses lines. This is poor design, it should have used cylinders, which will look correctly if you zoom in.
For rendering the 6649 Street Sweeper I converted the lines to POV cylinders and it now looked like this (new LGEO rendering, but still with 2473 generated on the fly):

l3p -b -f -cg22,135 -ca45 -lgeo -q3 m6649.mpd

You can have a look at the POV-friendly 2473 Brush Car Wash in the model file m6649.mpd and in the thread in lugnet.cad.ray Re: Is there some pov-ray friendly version of car wash brush part?.

However, I was reluctant to put it into L3P, because I believed LGEO was the proper solution to this kind of problem. But after several mails, Chuck Sommerville made me put into L3P v1.2 - unofficially though.
The POV code embedding can however supplement LGEO and find use in many cases, so I hereby announce it. I think Chuck Somerville has explained it rather well in a lugnet.cad.ray posting, so with kind permission from him I'll quote him on the subject:
From the thread in lugnet.cad.ray L3P user primitive substitution:

L3P still produces the normal object references and meshes in an IFNOTPOV section, but puts a conditional around it.

-enp  exclude non-POV code generation (L3P IFNOTPOV)

Bug fix

Version 1.4 BETA 20080930

In 2005 I was revising the LGEO support, and I realized that I couldn't go on using the LGEO tab files. They lacked support for letter suffixes in part file names and I decided to make a simple text file with all the data needed by L3P to use the LGEO files. I had it all working and I was going to release in September 2007, but then I got an e-mail from Lutz Uhlmann talking about his plans for the future of LGEO. So we agreed on a new text file format and two new files (lg_elements.lst and lg_colors.lst) to replace the tab files. I rewrote the LGEO support once more while Lutz kept adding more LGEO parts. We had many fruitful discussions about closer integration of LGEO and L3P, and we are proud to present the latest development.

L3P v1.4 does not support the old LGEO files, you'll need the new LGEO files.
 

-lgeo  use LGEO parts and colors

-ar  use Anton Raves parts and LGEO colors

-nolgc[f]  don't use LGEO colors [nor finishes]

Colors from ldconfig.ldr

-ldc[<path>]  alternative ldconfig.ldr or none

Color options now also take name or #RRGGBB

L3P now also accepts #RRGGBB as a color.

Thus <color> is an LDraw color name or number, extended/direct color (0x0tRRGGBB), #RRGGBB or <r>,<g>,<b> in the range 0..1 like POV-Ray.
 

-ib<file>  include file at beginning of POV file

//// IncludeFile AtBeginning
#include "mydef.inc"

-ie<file>  include file at end of POV file

-ic[<file>]  no camera, optional include file

-il[<file>]  no lights, optional include file

Many more primitives

LDrawDir revisited

ldraw.ini or org.ldraw.plist

   [LDraw]
   BaseDirectory=C:\Lars\LDraw
   LgeoDirectory=C:\Lars\LDraw\Apps\lgeo
   [LDrawSearch]
   1=<MODELDIR>
   2=<HIDE><DEFPRIM><LDRAWDIR>\P
   3=<DEFPART><LDRAWDIR>\PARTS
   4=<LDRAWDIR>\MODELS
   5=<DEFPART><LDRAWDIR>\UnOff\PARTS
   6=<DEFPART>C:\My Own Parts

Here is a sample org.ldraw.plist file you can download and save to the Library/Preferences directory in your home directory. Remember to change lch to your user name.
 

SearchDirs

However, since L3P is now using the LDrawIni library, the search can be defined by the user by specifying a number of SearchDirs. A SearchDir is an absolute path to a directory containing LDraw files, optionally prepended with some flags.
The search for parts/primitives will still begin inside the model document if it is an MPD, but after that L3P uses SearchDirs specified as follows:

      <MODELDIR>
      <HIDE><LDRAWDIR>\P
      <LDRAWDIR>\PARTS
      <LDRAWDIR>\MODELS
         

Improved LDraw file type detection

-ldd<dir>  set LDRAWDIR, <dir> must have the P, PARTS and MODELS directories

-lgd<dir>  set LGEODIR, <dir> must be the lgeo directory

-studs0  no studs

#declare L3Studs = 1;  // 1=on 0=off

//// Part 3710.dat
#ifndef (_3710_dot_dat)
#declare _3710_dot_dat = #if (L3Quality = 0) box { <-40,-4,-10>, <40,8,10> } #else union {
// Plate  1 x  4
// Name: 3710.dat
// Author: James Jessiman
// Original LDraw Part
   #if (L3Studs)
      object { stud3_dot_dat matrix <1,0,0,0,-1,0,0,0,1,20,4,0> }
      object { stud3_dot_dat matrix <1,0,0,0,-1,0,0,0,1,0,4,0> }
      object { stud3_dot_dat matrix <1,0,0,0,-1,0,0,0,1,-20,4,0> }
   #end
   object { box5_dot_dat matrix <36,0,0,0,-4,0,0,0,6,0,8,0> }
   mesh {
      triangle { <40,8,10>, <36,8,6>, <-36,8,6> }
      triangle { <-36,8,6>, <-40,8,10>, <40,8,10> }
      triangle { <-40,8,10>, <-36,8,6>, <-36,8,-6> }
      triangle { <-36,8,-6>, <-40,8,-10>, <-40,8,10> }
      triangle { <-40,8,-10>, <-36,8,-6>, <36,8,-6> }
      triangle { <36,8,-6>, <40,8,-10>, <-40,8,-10> }
      triangle { <40,8,-10>, <36,8,-6>, <36,8,6> }
      triangle { <36,8,6>, <40,8,10>, <40,8,-10> }
   }
   object { box5_dot_dat matrix <40,0,0,0,-8,0,0,0,10,0,8,0> }
   #if (L3Studs)
      object { stud_dot_dat matrix <1,0,0,0,1,0,0,0,1,30,0,0> }
      object { stud_dot_dat matrix <1,0,0,0,1,0,0,0,1,10,0,0> }
      object { stud_dot_dat matrix <1,0,0,0,1,0,0,0,1,-10,0,0> }
      object { stud_dot_dat matrix <1,0,0,0,1,0,0,0,1,-30,0,0> }
   #end}
#end
#end // ifndef (_3710_dot_dat)

-cra<a>  camera roll angle

-csky<x>,<y>,<z>  camera sky vector

-cpct[<p>]  percentage to move camera further back, default is 0

-car<ar>  camera aspect ratio

-co[<s>]  orthographic camera

-csa<a>  camera stereo angle

-csl  left stereo camera

#declare L3StereoAngle = 5; // degrees
//5 degrees corresponds to a distance between eyes (stereo cameras)
//of 1/12 of distance to model.
#declare L3StereoView = 0; // Normal view
//Uncomment either two lines below to make stereo images:
//#declare L3StereoView = -L3StereoAngle/2; // Left view
//#declare L3StereoView =  L3StereoAngle/2; // Right view

-csr  right stereo camera

-lsl  shadowless lights

Bookmarks

L3P CAMERA_CALC meta command

   0 L3P CAMERA_CALC OFF
   ...
   0 L3P CAMERA_CALC ON

-cpa<a>  co-planar-angle, default is 3 degrees (1 if -check)

The -cpa option lets you change the default maximum angle, which is 3 degrees. Warnings are only printed if warning level is 1 or above. If -check is specified, the default maximum angle is 1 degree.
The -cpa option replaces the old -det and -dist options.
 

-mp<v>  MegaPOV version statement

//// MegaPOV
#version unofficial megapov 1.2;
// The above line of POV code must be included in every include file as well,
// not just the main POV file.

-scm  StepClock only at steps in Model (not in submodels)

L3P variables in the POV file renamed

QUAL         L3Quality 
SW           L3SW 
STUDS        L3Studs 
BUMPS        L3Bumps 
BUMPNORMAL   L3NormalBumps 
AMB          L3Ambient 
DIF          L3Diffuse 

-q<n>  quality level 0..4, default is 2

-b[<color>]  background color, -b gives 0.3,0.8,1

-pp  print primitives, prints a list of the primitives having POV equivalents

-pp -check  check all primitives in P if they have a POV equivalent

1-16cyli.dat     L3P
1-16edge.dat     irrelevant
1-4ccyli.dat     L3P
...
4-4ring9.dat     L3P
4-8sphe.dat      L3P
48\1-4con1.dat   L3P
48\1-4con13.dat  L3P
...
48\4-4ring9.dat  L3P
48\4-8sphe.dat   L3P
62 files in C:\Lars\LDraw\P\48 checked.
5-8cyli.dat    
5-8edge.dat      irrelevant
8-8sphe.dat      L3P
arm1.dat         L3P
arm2.dat         L3P
axle.dat         L3P
axleend.dat    
axleho10.dat   
axleho11.dat   
axlehol2.dat     irrelevant
axlehol3.dat     irrelevant
axlehol4.dat     L3P
...
t04q3333.dat     L3P
t04q4000.dat     L3P
toothr.dat     
tri3.dat       
254 files in C:\Lars\LDraw\P checked.
Primitives in P: 316
POV substitutes: 237 (75%)

-pc  print known color names

0 !COLOUR Black               CODE   0 VALUE #212121 EDGE       8
0 !COLOUR Blue                CODE   1 VALUE #0033B2 EDGE       0
0 !COLOUR Green               CODE   2 VALUE #008C14 EDGE       0
0 !COLOUR Teal                CODE   3 VALUE #00999F EDGE       0
0 !COLOUR Red                 CODE   4 VALUE #C40026 EDGE       0
...
0 !COLOUR TransBlack*         CODE  32 VALUE #4D4D4D EDGE       0 ALPHA 128
0 !COLOUR Trans_Blue          CODE  33 VALUE #0020A0 EDGE #002266 ALPHA 128
...

LDraw lines as comments in the POV file

//// Model car.ldr
#ifndef (car_dot_ldr)
#declare car_dot_ldr = union {
// Car
// Name: Car.dat
// Author: James Jessiman
// Original LDraw Model - LDraw beta 0.27 Archive
// Car
   // 1 0  0 0 -90  1 0 0  0 1 0  0 0 1 4315.dat
   object {
      _4315_dot_dat
      matrix <1-L3SW/80,0,0,0,1-L3SW/12,0,0,0,1-L3SW/28,0,L3SW/6,L3SW/-7>
      matrix <1,0,0,0,1,0,0,0,1,0,0,-90>
      material { L3Color0 }
   }
   // 1 7  0 0 -60  1 0 0  0 1 0  0 0 1 4600.dat
   object {
      _4600_dot_dat
      matrix <1-L3SW/68,0,0,0,1-L3SW/16.06,0,0,0,1-L3SW/40,0,L3SW/3.98511,0>
      matrix <1,0,0,0,1,0,0,0,1,0,0,-60>
      material { L3Color7 }
   }
   // 1 0  0 0 0  1 0 0  0 1 0  0 0 1 3031.dat
   ...
}
#end // ifndef (car_dot_ldr)

Bug fixes in v1.4

Problem with fallback color fixed (model with one element (colored))

Could not launch PovRay on file with spaces, added doublequotes

Only substitute parts/primitives, not other MPD members like 926.ldr

Support for filenames with spaces in LT1 and "0 FILE". Also support for filenames in quotes like "new car.ldr".
 

Download

  L3P (MacOSX ppc/i386) v1.4 BETA 20080930 l3p14betamacosx.zip (117 kB)

  L3P (Linux i386) v1.4 BETA 20120311 l3p14betalinux.zip (299 kB)

There is no longer a 16 bit DOS version. Let me know if you really need one.

Please enjoy and let me know what you think.
 

Get a Mac! Watch the Pep Rally ad ;-)
 

More examples

ldraw -b7 -s0.7 m646

l3p -b -f -q3 -ca45 -sw1 -bu m646

ldraw -a-1,0,-1,-0.5,1,0.5,1,0,-1 -s0.67 -b1 m6836

l3p -cg30,220 -b1 m6836 -sw0

ldraw -a1,0,-1,-0.5,1,-0.5,1,0,1 -b1 m6818

l3p -cg35,-15 -b1 m6818 -sw0

My LDRAW parts

Parts Catalog

Links

POV-Ray. The Persistence of Vision Raytracer is a high-quality, totally free tool for creating stunning three-dimensional graphics. It is available in official versions for Windows 95/98/NT, DOS, the Macintosh, i86 Linux, SunOS, and Amiga. The source code is available for those wanting to do their own ports.
http://www.povray.org

LGEO POV-Ray parts by Lutz Uhlmann:
http://www.digitalbricks.org.

Anton's Webpages by Anton Raves:
http://www.antonraves.nl.

Fixed LGEO parts by Lars C. Hassing:
http://www.hassings.dk/l3/lgeofix.html

LDAO by Steve Bliss:
http://home.earthlink.net/~steve.bliss/ldao/
http://www.ldraw.org/download/win/ldao

LDLite by Paul Gyugyi:
http://www.gyugyi.com/l3g0/ldlite/
http://www.ldraw.org/download/win/ldlite

LdGLite by Don Heyse. Making LDLite portable with OpenGL.
http://ldglite.sourceforge.net
http://www.ldraw.org/download/win/ldglite

MLCad by Michael Lachmann. The Windows CAD program.
http://www.lm-software.com/mlcad/
http://www.ldraw.org/download/win/mlcad

LeoCAD by Leonardo Zide. Windows/Linux CAD program.
http://www.leocad.org
http://www.ldraw.org/download/win/leocad

LDView by Travis Cobbs. Real-time 3D OpenGL viewer.
http://home.san.rr.com/tcobbs/LDView/
http://www.ldraw.org/download/win/ldview

LUGNET (International LEGO Users Group Network) by Todd S. Lehman and Suzanne D. Rich
http://www.lugnet.com/
http://news.lugnet.com/cad/    CAD newsgroup

lugnet.com/cad by Todd (Suz?)

ldraw.org in general

James J memorial

L3Lab by Lars C. Hassing. Viewer/examiner.
http://www.hassings.dk/l3/l3lab.html
http://www.ldraw.org/download/win/l3lab

L3P by Lars C. Hassing
http://www.hassings.dk/l3/l3p.html     Download Area: http://www.hassings.dk/l3/l3p.html#download
http://www.ldraw.org/download/win/l3p
 

LEGO Software Power Tools, Including LDraw, LPub, and Ledit by Miguel Agullo and Kevin Clague. Covering applications such as LDraw, MLCad, LeoCAD, L3P, POV-RAY, BlockCAD, Ldglite, LDAO, and Lpub. Though my name appears on the front page (as a Technical Reviewer) I only reviewed Chapter 8 L3P and POV-Ray. Full credit for the book goes to the two authors Kevin Clague and Miguel Agullo.

Put a link to L3P on your page

DISCLAIMER

Lars C. Hassing's Homepage          E-mail me!   (remember to delete spam blocker from e-mail address)

Last updated September 30, 2008