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.
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).
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:
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 awayand do another rendering. I use POV-Ray for Windows and it has an editing window with the POV-file and buttons for starting/stopping the rendering. You can easily experiment with the POV-file and do some fast, low resolution renderings for previews, before starting the high resolution with anti-aliasing etc.
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.
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 |
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".
// 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 }By removing the appropriate comment slashes (//) you may render either the left or the right image.
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.
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.
1 4 0 0 0 1 0 0 0 1 0 0 0 1 3001.datto render the part 3001 in red (4).
l3p -c4 3001
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!
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.
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.
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:
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.
See the thread in lugnet.cad.dev Searching for parts.
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."
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).
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:
Awhile back, I persuaded Lars Hassing to add a feature to L3P. I wanted the
ability to substutite POV language commands in the comments of a .DAT file
that could be used in place of the DAT primitives when rendering through
POV. This would allow users to add native POV commands that could render
better than the triangles and polygons defined in DAT files. Since the
commands are inbedded in comment fields, and only recognized by L3P, they
have no effect of any other tools. Lars was waiting untill I tested the
commands to announce the feature. The good news, is you probably already
have the ability to use these features. He built them into Version 1.2
20000616.
The commands are 0 L3P IFPOV Conditional section begin Begin POV statements in comment statement fields 0 L3P IFNOTPOV Conditional section begin Begin DAT statements 0 L3P ELSEPOV Switch between above section modes 0 L3P ENDPOV Terminate conditional section After running L3P, you can see in the POV file conditionals like if(0) or if(1) To see the alternate version for comparison, just change the constant in these conditionals. If you don't understand any of this, don't worry, I am following this post up with some examples. Remember to get L3P V1.2 or latter to use thse. -Chuck |
L3P still produces the normal object references and meshes in an IFNOTPOV section, but puts a conditional around it.
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.
1. | The -lgd<dir> option |
2. | The LGEODIR environment variable |
3. | Key LgeoDirectory in section [LDraw] in an ldraw.ini file. |
4. | Finally a couple of typical locations on the disk
are checked if they exist:
LDrawDir\lgeo LDrawDir\Apps\lgeo $HOME/Library/lgeo (MacOSX only) /Library/lgeo (MacOSX only) /usr/local/share/lgeo (Linux/MacOSX only) |
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.
//// IncludeFile AtBeginning #include "mydef.inc"Note that L3P merely outputs the above code; there is no check of the file. You must make sure that POV-Ray can find the file by specifying the necessary include path in POV-Ray.
1. | The -ldd<dir> option | ||||||
2. | The LDRAWDIR environment variable | ||||||
3. | Key BaseDirectory in section [LDraw] in an ldraw.ini file. | ||||||
4. | A number of typical locations on the disk is checked if they
contain subdirectories P and PARTS:
|
||||||
5. | Finally the current working directory is checked if it contain subdirectories P and PARTS: |
[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 PartsThe LDrawIni library will search for an ldraw.ini file in a number of places, the first one found is used:
1. | The LDRAWINI environment variable | ||||||
2. |
|
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.
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:
1. | The LDRAWSEARCH environment variable. SearchDirs are separated with a Vertical bar (|). You can set it to e.g. "<MODELDIR>|<HIDE><LDRAWDIR>\P|<LDRAWDIR>\PARTS|<LDRAWDIR>\MODELS" |
2. | Environment variables LDRAWSEARCH01, LDRAWSEARCH02, etc., each containing a directory with optional flags. |
3. | Keys 1, 2, 3, etc. in section [LDrawSearch] in an ldraw.ini file. |
4. | If no SearchDirs setting is found the default is:
<MODELDIR> <HIDE><LDRAWDIR>\P <LDRAWDIR>\PARTS <LDRAWDIR>\MODELS |
Directory keywords | |
<LDRAWDIR> | This keyword is substituted with the LDrawDir. Use it to specify a search directory relative to the LDrawDir, e.g. <LDRAWDIR>/P. |
<MODELDIR> | This keyword is substituted with the directory of the model. |
<HOMEDIR> | This keyword is substituted with the environment variable %USERPROFILE% on Windows and $HOME on MacOSX/Linux. Use it to specify a search directory relative to the home directory, e.g. <HOMEDIR>/MoreParts |
Flag keywords | |
<SKIP> | The search directory is skipped. Use it to un-comment a directory. |
<HIDE> | The directory is searched for files, but some editors may choose not to show files from this directory in lists presented to the user. |
<SHOW> | This keyword is ignored, as it is the default. However, you may choose to use it as an explicit opposite of <HIDE>. |
<DEFPART> | Files found in this directory are considered as part files,
unless the header indicates otherwise.
<LDRAWDIR>/PARTS will automatically have the <DEFPART> flags applied. |
<DEFPRIM> | Files found in this directory are considered as primitive files,
unless the header indicates otherwise.
<LDRAWDIR>/P will automatically have the <DEFPRIM> flags applied. |
#declare L3Studs = 1; // 1=on 0=offwhich can be 0 if using the -studs0 option. The parts generated by L3P test for L3Studs, e.g.
//// 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)So if L3Studs is zero you can have a faster render if you just want to have a rough sketch of the model.
#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 viewThis option removes the // for the left view above, so you don't have to edit the generated POV file manually.
//// MegaPOV | Enabling of MegaPOV |
//// Defines | All the #define statements |
//// IncludeFile AtBeginning | #include statement specified by the -ib option |
//// Finishes | Definition of POV finish's |
//// Macros | Definition of macros |
//// Textures for LGEO patterned parts | Special textures for LGEO |
//// Color 15 White | Color definition |
//// Color 15 White (from lg_color.inc) | Color definition |
//// Color 15 White (from ldconfig.ldr) | Color definition |
//// Color 257 | Color definition |
//// Color #02FFCC99 | Color definition |
//// Primitive stud.dat | Primitive definition |
//// Part 3001.dat | Part definition |
//// Submodel roof.ldr | Submodel definition |
//// Model car.ldr | Model definition |
//// ModelData | Bounding box and floor data |
//// Floor | Floor definition |
//// Background | Background definition |
//// Camera | Camera definition |
//// IncludeFile Camera | #include statement specified by the -ic option |
//// Lights | Lights definition |
//// IncludeFile Lights | #include statement specified by the -il option |
//// ModelObject car.ldr | Reference of the model |
//// Statistics | Some statistics as comments |
//// IncludeFile AtEnd | #include statement specified by the -ie option |
//// End | End of file |
0 L3P CAMERA_CALC OFF ... 0 L3P CAMERA_CALC ONNote, however, that it will only work in the main model file, since L3P doesn't "walk the tree" and only uses the parts/subfiles referenced directly from the model file for automatic camera positioning.
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.
//// 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.
QUAL L3Quality SW L3SW STUDS L3Studs BUMPS L3Bumps BUMPNORMAL L3NormalBumps AMB L3Ambient DIF L3Diffuse
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%)L3P means the primitive has a POV equivalent. irrelevant means the primitive is not relevant for L3P because it only has line type 2.
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 ...The asterisk (*) denotes that the color was not found in the ldconfig.ldr file, but is an L3P default color.
//// 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)
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".
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 ;-)
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 |
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. |
<a target="_top" href="http://www.hassings.dk/l3/l3p.html"><img border=0 hspace=0 vspace=0 width=88 height=31 src="l3pbanner.gif" alt="To L3P homepage at www.hassings.dk/l3/l3p.html"></a> |
Lars C. Hassing's Homepage E-mail me! (remember to delete spam blocker from e-mail address)
Last updated September 30, 2008