Note to self: I can use target="_self" to override base target="_blank" in html/head. Works in IE and Firefox. That's a neat trick!
This project started on Monday, October 8, when I received Nathan's render_pieces, the script used to generate Rebrickable's LDraw images, and I created a forum thread Part Images with some of the problems surrounding these images. The next two days I tried to understand the workings of L3P, the program used to generate the POV-files used for rendering, and on Thursday, I started rendering my first part images.
After collecting all my images and notes into an html page, uploading the page on Bricksafe and posting a link to it, I realized I was creating a kind of "Guide to Rendering", and much of my images and text could also be used for that Help page. So I recreated the original images at a higher resolution, added some more information, and the result is what you are reading now. Basically a logbook of my experiments with LDraw, L3P, POV-Ray, Studio and Eyesight, with all the rendered images, code and background information.
In my opinion, we have a few small problem with our LDraw images. Here's an overview:
The simple question is, what do we need to do to solve these problems?
Code will be referenced like this:
D:\ldraw\lgeo>dir (this is windows code)
$ ls -l (this is linux code)
Background information like this::
Directory of D:\ldraw\lgeo
11/24/2008 8:30 AM <DIR> .
10/12/2018 7:47 PM <DIR> ..
12/15/2008 8:28 AM <DIR> ar
12/15/2008 8:23 AM <DIR> lg
12/15/2008 8:35 AM 2,577 lg_changes.txt
12/25/2007 11:16 AM 1,483 lg_colors.lst
12/15/2008 8:30 AM 20,332 lg_elements.lst
11/24/2008 8:30 AM 113,525 LGEO.pdf
4 files 137,917 bytes
4 directories 136,675,328,000 bytes free
To be able to see more details, I am rendering L3P images at 1000x1000 png, and Studio images at 1024x768 png. Then I use ImageMagick's mogrify to shrink them back to 250x250 jpgs, at 75% quality, adding whitespace on top and bottom if needed.
$ mogrify -resize 250x250 -background white -gravity center -extent 250x250 -format jpg -quality 75 *.png
Hovering over a rendered image will display basic information. Clicking on a rendered image will open the original png in a new tab. Click the newly opened image and it will zoom-in to full detail. If you open two images in seperate windows, you can use alt-tab to swich back and forth between them, which clearly shows the differences.
In Linux Mint 18.3 Wine 1.6 is pre-installed and runs perfectly, even though it is a little out-dated. LEGO Digital Designer and Studio can be installed normally, and will run. For Studio I am using the 32-bit version. Only Eyesight has a problem, I am still trying to fix this.
LDraw can be installed in an ldraw folder, somewhere in your Linux home directory. Then with winecfg create an additional D: drive mapped to the folder above the ldraw folder. A Wine CLI can be created with "Wine cmd" (***CHECK***), The Wine CLI starts in Z:\, which is mapped to your linux home directory. So I put a go.cmd in my home direcotory that sets all the needed environment variables, and switches to D:\ldraw. Then L3P can be started.
Setup Wine: add D: mapped to /home/simon/Documents/LEGO/Library/ using winecfg Drives In Wine CLI run go.cmd: set WINEDEBUG=-all set LDRAWDIR=D:\ldraw set LGEODIR=D:\ldraw\lgeo set PATH=%PATH%;D:\ldraw;C:\Program Files\POV-Ray\v3.7\bin D: cd \ldraw
When I open the part page for a basic 2 x 4 Brick, the 3001, there are two rendered images. Below, left is the LEGO element image, right is the LDraw image:
If we select the color Blue, we get these images (left element, right Ldraw):
The element image seems to have the right color, but the color of the LDraw image is wrong; this is LGEO blue. Below, the left is rendered myself using LGEO colors and sharp shadows, the right image is the same as above, copied from the website:
D:\ldraw>L3P D:\ldraw\parts\3001.dat D:\ldraw\test\3001-lgeo.pov -car1 -cg45,35,0 -ca30 -lg45,0,0,0.8,0.8,0.8 -lg30,120,0,0.8,0.8,0.8 -lg60,-120,0,0.8,0.8,0.8 -b1.000,1.000,1.000 -bu -sw0.5 -q4 -c0x020055BF -o -lgeo -nolgc
D:\ldraw>pvengine /render D:\ldraw\test\3001-lgeo.pov +W1000 +H1000 +A +FN8 +OD:\ldraw\test\3001-lgeo.png /EXIT
So lets render with the right color, add soft shadows and a few area lights. Left is the LDraw image we use on the main 3001 part page, right my rendered image:
D:\ldraw>L3P D:\ldraw\parts\3001.dat D:\ldraw\test\3001-lgeo-cust.pov -car1 -cg45,35,0 -ca30 -ilD:\ldraw\light.dat -b1.000,1.000,1.000 -bu -sw0.5 -q4 -c0x020055BF -o -lgeo -nolgcf
D:\ldraw>pvengine /render D:\ldraw\test\3001-lgeo-cust.pov +W1000 +H1000 +A +FN8 +OD:\ldraw\test\3001-lgeo-cust.png /EXIT
check -nolgcf at the end of the option list - additional f prevents loading the LGEO finishes
I am also replacing the 3 light sources -lg with an include -il of light.dat:
//// Custom Lights
light_source {
<0,-113.741,-123.741> // Latitude,Longitude,Radius: 45,0,174.997
color rgb <0.9,0.9,0.9>
area_light <100, 0, 0>, <0, 0, 100>, 25, 25
/// adaptive 1
jitter
}
light_source {
<131.247,-77.4983,75.7757> // Latitude,Longitude,Radius: 30,120,174.997
color rgb <0.9,0.9,0.9>
area_light <100, 0, 0>, <0, 0, 100>, 25, 25
/// adaptive 1
jitter
}
light_source {
<-75.7757,-141.551,43.7491> // Latitude,Longitude,Radius: 60,-120,174.997
color rgb <0.9,0.9,0.9>
area_light <100, 0, 0>, <0, 0, 100>, 25, 25
/// adaptive 1
jitter
}
Now we change the camera position, for the rendered image. Left the LEGO element image, right my rendering:
D:\ldraw>L3P D:\ldraw\parts\3001.dat D:\ldraw\test\3001-lgeo-angle.pov -car1 -cg45,-35,0 -ca30 -ilD:\ldraw\light.dat -b1.000,1.000,1.000 -bu -sw0.5 -q4 -c0x020055BF -o -lgeo -nolgcf
D:\ldraw>pvengine /render D:\ldraw\test\3001-lgeo-angle.pov +W1000 +H1000 +A +FN8 +OD:\ldraw\test\3001-lgeo-angle.png /EXIT
And we bring down the camera a little, and dim the area light in the back:
D:\ldraw>L3P D:\ldraw\parts\3001.dat D:\ldraw\test\3001-lgeo-angl2.pov -car1 -cg40,-35,0 -ca30 -ilD:\ldraw\light1.dat -b1.000,1.000,1.000 -bu -sw0.5 -q4 -c0x020055BF -o -lgeo -nolgcf
D:\ldraw>pvengine /render D:\ldraw\test\3001-lgeo-angl2.pov +W1000 +H1000 +A +FN8 +OD:\ldraw\test\3001-lgeo-angl2.png /EXIT
Note: light1.dat has second light source changed to 5 x 5 at <0.4,0.4,0.4>
The difference between the LEGO image and the rendered image is that the LEGO image is using orthagonal view, and the rendered image is using perspective view. But when we render in orthagonal view, we get some ugly artifacts at the edges of the brick:
-co is not implemented in L3P, so we add keyword orthographic to the POV camera definition...
which we solve by rendering at 500x500 and then resizing to 250x250 with Anti-Aliasing:
So now we have two nice rendered images, perspective (left) and orthagonal (right), both oriented the same as the LEGO element images, but using much more natural light mostly coming from above.
To be sure, this is all done in Linux, with both L3P and POV-Ray 3.7 running under Wine, and all of it is ran by Wine CLI, so it can all be automated. I also tried running in a native linux terminal, but then, for each call to Wine L3P, Wine needs to initialize, which takes about 5 seconds, while the actual pov generation takes less then .1 second. So the fastest way is to run the entire thing within a Wine CLI.
If I render at 500x500 with high quality and no adaptive light sources, it takes about 10 seconds to render a normal color, and I guess about 60 seconds for transparent colors. For our current 75,000 part/color combinations, that would cost me between 200 and 300 hours of computer time. If I use a fast system, I might get back to 50 to 60 hours.
Note: to create pov files for all LDraw parts: set OPTIONS=[l3p options] cd parts for %%A in (*.*) do echo %%A && L3P %%A ..\pov\%%A.pov %OPTIONS% cd .. Note: to render all pov files: cd pov for %%A in (*.*) do echo %%A && pvengine /render %%A +W250 +H250 +A +FN8 +OD:\ldraw\test\%%A.png /EXIT cd ..
Now I am switching to Windows, because Studio 2.0 does run in Wine, but alas, Eyesight does not. This is probably due to the Wine version, Mint 18 uses Wine 1.6, which is pretty old; Mint 19 doesn't come with Wine, but has a newer version in the repositories. In Mint 19, Eyesight works, but I prefer Mint 18 for other reasons. I am also switching to one of my desktops, to save rendering time.
stud.io 2.0.1 (29) on Windows 7 Pro 64-bit (SP 1) Using an Intel Core I5-2500 CPU @ 3.30 GHz 4 GB RAM / 160 GB HDD / dual boot with Linux Mint 18.3
Studio 1 had one irritating problem: it didn't save the camera viewpoint of the model, so each time you opened a model, the view was reset to default. Studio 2.0 does save the camera viewpoint, but, as far as I can tell, not in the model, but in ini-file that stores the configuration setting and the list of recently opened files. Now, if you always work on the same computer, you might not even notice this, but I usually create a scene on one system, and then copy the .io file to another system to do the rendering, and if you do that, you loose the camera viewpoint. So if some of the renders in this document seem to have a slightly different viewpoint, you know why - I moved the io file from my desktop to my notebook... -smile-
For rendering models and parts in Studio 1 I use an edited lg_color.inc (C:\Program Files\Stud.io\pov-ray\LEGO\lg\) which gives a little bit more reflection and some extra sparkle to add some liveliness to the images. As far as I can tell this doesn't work anymore in Studio 2.0 - whatever changes I make to lg-colors.inc, the result looks the same. I need to find out why.
C:\Program Files\Studio.io\pov-ray\LEGO\lg\lg_color.inc:
original (used for parts):
phong 1
phong_size 40
reflection { 0.025 falloff 1 exponent 1 }
changed (used for models):
phong 25 // SVM raised from 1 to 25
phong_size 40
reflection { 0.050 falloff 1 exponent 1 } // SVM raised from 0.025 to 0.050
The first thing that needs to be decided is the render quality; especially in POV-Ray this heavily influences the rendering time. For POV-Ray Studio allows four different quality settings: Low, Medium, High and Custom, the latter allowing to set four sub-options. For the Custom setting I use High quality model: Yes (this means use LGEO), Stud logo: On, Shadow Quality: High and Max trace level: Xtrm. Note that the rendering time goes up from 8 seconds for Low to 105 seconds for Custom. The difference between Low, Medium and High are clealy visible (Low: sharp studs, Medium: rounded studs, High: logo on studs) but I don't see real difference between High and Custom, even though the Curstom rendering takes twice as long.
POV Settings: Floor Color: Floor-Only on full white FFFFFF Light: Left-Front (with sub-light) Image Size: 1024x758 (4:3) in landscape mode Format: .png (8 bit)
From left to right: Low Quality, Medium Quality, High Quality and Custom (set to Very High) Quality:
With Floor Color: Floor Only all the images have a floor shadow, sharp at lower quality, smooth at higher quality. In POV-Ray you can hardly see the floor shadows, but if you look closely, you will see that the shadow is cut-off at the bottom where the white filler is added to make the image square.
To remove those shadows, we need to set Floor Color to Transparent, and, after rendering the image, replace the alpha-channel with clear white. Conversion to jpg will also take care of that, as jpg does not support transparency. For these tests, I have kept the original pngs with transparent background, while the jpgs show a white brackground. In POV-Ray, this will also reduce rendering time, especially for higher quality.
From left to right: Low Quality, Medium Quality, High Quality and Custom (set to Very High) Quality :
In Eyesight we also have four levels of quality: Medium (128 samples), High (256 samples), Very High (512 samples and Custom, which allows to set any sample size. I used 1024 samples for Custom. All other settings are kept at default.
Eyesight (Photo Realistic) settings: Background: Floor-Only on full white FFFFFF Light: Building Left-Front Rotation 0,0 Intensity 1 Camera Setup: Custom -32.11,-41 Pan 1.88,4.87 Zoom scale 0.37 Field of view 15 Material Effects: Stud logo ON, UV Degradation OFF Scratches OFF Image Size: 1024x758 (4:3) in landscape mode Format: .png (8 bit)
From left to right: Medium Quality, High Quality, Very High Quality and Custom (set to Extremely High) Quality:
To loose the shadows we set Background to Transparent and unselect Floor shadow. From left to right: Medium Quality, High Quality, Very High Quality and Custom (set to Extremely High) Quality:
Here too we see a reduction in rendering time at higher qualities.
The rendering time in POV-Ray is determined by quality, image dimensions, and the number and type of parts: the higher the quality, image dimension and the more parts, the longer it takes. Transparent parts take much more time than solid parts, up to 30 times as long, especially when the transparent part is close to the camera, and occupies a large portion of the image. Transparent slopes are notoriously slow, up to 40 times, and sometimes POV-Ray even freezes completely. As a result, it is very hard to predict how long a render might take. Even on a fast machine, a 4K HD render (4096x3072) can take between 4 and 16 hours.
The rendering time in Eyesight is independent of number and type of parts, and is only determined by quality, image dimensions and transparency. At the same quality, an 2048x1537 render takes about four time as long an 1024x768 render. A transparent render takes three times as long as a solid render. As a result, it is reasonably simple to predict how long a render might take. Eyesight can use the GPU to render images, if your system has the right GPU card. This is usually much faster then CPU rendering. Oddly enough there is little difference in rendering time between medium and high quality, and also between very high and custom quality which I set to 1024 samples. In theory, doubling the sample rate should also double the rendering time. There might be a small bug in Studio, preventing Eyesight from using the right sample rate.
Rendering is CPU intensive, and will use your CPU at 100%, so obviously, the rendering time in general depends on the speed of the CPU and the number of cores. Both POV-Ray 3.7 and Eyesight use all available cores (note that POV-Ray 3.6 only uses a single core). If you want to create HD images of large LEGO models, you really need a fast system. You can render an HD image on a Pentium III at 800 MHz, but it might take a week or so... -smile-
One tip - for both programs, if you close the preview window (in which you see the rendered image being created) it speeds up the rendering itself. On an old computer, this could save you half of the rendering time. And do NOT do anything else besides it - don't watch a video while rendering.
Now lets look at the different options for Light Sources. In POV-Ray we can only select the position of the light source. We have ten diffrent options: Left-Front (with sub-light), Left-Front, Left, Left-Back, Right-Front (with sub-light), Right-Front, Right, Right-Back, Front, and Back.
All images rendered at custom (Very High) quality with floor shadow.
From left to right: Left-Front (with sub-light), Left-Front, Left, Left-Back, Right-Front (with sub-light), Right-Front, Right, Right-Back, Front, and Back.
Shadows are now easier to see, and when the image is made square they don't look good. So let's remove the shadows again by setting Background to Transparent.
All images rendered at custom (Very High) quality without floor shadow.
From left to right: Left-Front (with sub-light), Left-Front, Left, Left-Back, Right-Front (with sub-light), Right-Front, Right, Right-Back, Front, and Back.
In Eyesight we have much more options. Five Types of light: Building, Mechanic, Astroid, Dawn and Piazza; and for Building and Mechanic we can set the light position to Left-Front, Right-Front, Left-Back and Right-Back. We can also rotate the light source (x,y) and set its intensity.
All rendered at Very High (512 samples) quality.
From left to right: Left-Front, Right-Front, Left-Back and Right-Back, with floor shadow.
From left to right: Left-Front, Right-Front, Left-Back, Right-Back and Left-Front with Intensity 0.5, all without floor shadow.
From left to right: Left-Front, Right-Front, Left-Back and Right-Back, with floor shadow.
From left to right: Left-Front, Right-Front, Left-Back and Right-Back, without floor shadow.
From left to right: Astroid, Dawn and Piazza, with floor shadow.
From left to right: Astroid, Dawn and Piazza, without floor shadow.
Looking at the 2 x 4 brick I have to say I prefer the POV-Ray rendering. Eyesight gives nicer edges, but the surface looks almost like glass, not plastic. In a model, were most part are smaller, this is probably not a problem, perhaps even good, but for individual part there is too reflection to look realistic. POV-Ray has sharper edges and perhaps too little reflection, but in my eyes, the bricks look more realistic. Or, perhaps, I am just more used to them...
Spend most of the day rendering the transparent images... -smile-
Relax, this is not as omnious as it sounds. Studio is based on LDraw, and LDraw definitions are plain text files. Furthermore, most of Studio's other data is also in text files, and when Studio calls POV-Ray or Eyesight to perform a render, the model information is also transfered in text files. By examining these text files we can learn more about the workings of the program, and we can change things, and see what happens.
There is one disadvantage, which has to do with updating Studio. When Studio start, it checks if there is a new version available, and if so, if suggests to download and install it. When some of the Studio text files have been changed, this update can go wrong and cause Studio to crash the next time it boots. So when you want to work with these changes, don't use the Auto Update. If you do want to update, then install a complete new version, and redo the changes.
When Studio invokes POV-Ray or Eyesight it creates a folder "RenderTemp" (in C:\Users\[user]\AppData\Local\Stud.io\) with all the data needed to render the image. When the render is finished, the folder is deleted. However, in POV-Ray you can press Pause, and then make a copy of RenderTemp. In Eyesign you just have to be fast, or render a large image.
The POV-Ray RenderTemp contains a .pov file with the model data and a povray.ini with settings. If you save both, you can rerun the render without using Studio and make changes to the model.
Directory of K:\guide\RenderTemp POV-Ray
10/13/2018 02:44 PM <DIR> .
10/13/2018 02:44 PM <DIR> ..
10/13/2018 02:44 PM 6,336 181013_214410.pov
10/13/2018 02:44 PM 11,542,856 181013_214410.pov-state
10/13/2018 02:44 PM 2,556 log_181013_214410.txt
10/13/2018 02:44 PM 0 log_181013_214410_error.txt
10/13/2018 02:44 PM 518 povray.ini
10/13/2018 02:42 PM <DIR> log
5 File(s) 11,552,266 bytes
3 Dir(s) 1,437,962,240 bytes free
Eyesight
The Eyesight RenderTemp contains a .dae file with the model data and a povray.ini with settings. If you save both, you can rerun the render without using Studio and make changes to the model.
Directory of K:\guide\RenderTemp Eyesight
10/13/2018 02:20 PM <DIR> .
10/13/2018 02:20 PM <DIR> ..
10/13/2018 02:18 PM 328,112 181013_211839.dae
10/13/2018 01:51 PM 518 povray.ini
10/13/2018 02:18 PM <DIR> log
2 File(s) 328,630 bytes
3 Dir(s) 1,437,962,240 bytes free
The part database of Studio is a large 812 KB tab-delimited text file called "StudioPartDefinition2.txt" located in C:\Program Files\Studio 2.0\data\. The layout is as follows (only showing the first two lines):
Studio ItemNo BaseStudioItemNo BL ItemNo BL ItemKey LDraw ItemNo LDD ItemNo Description isPerfectForCulling BLCatalogIndex BLCatalogSubIndex EasyModeIndex IsAssembly? flexible type 166494 166494 36841 166494 36841.dat Bracket 1 x 1 - 1 x 1 o 12 -1 9 false
The color database of Studio is a small 18 KB tab-delimited text file called "StudioColorDefinition.txt" also located in C:\Program Files\Studio 2.0\data\. The layout is as follows (only showing the first two lines):
Studio Color Code BL Color Code LDraw Color Code LDD color code Studio Color Name BL Color Name LDraw Color Name LDD Color Name RGB value Alpha CategoryName Color Group Index 11 11 0 26 Black Black Black Black #04121C 1 Solid Colors -1 o
The category database of Studio is a small 6 KB tab-delimited text file called "StudioCategoryDefinition.txt" also located in C:\Program Files\Studio 2.0\data\. The layout is as follows (only showing the first three lines):
BL CatalogName Shape Name BL Index subIndex easymode (Other)\A0 Object 1 -1 12 Aircraft\A0 Vehicle - Air & Sea 2 -1 27
It's now rather late, and I have been working on this for eight hours strait, so now it is time to have some fun...
From left to right: POV-Ray and Eyesight, without floor shadow.
POV-Ray has a problem at the top and bottom of the face. Must admit, Eyesight seems to be better at this...
From left to right: POV-Ray and Eyesight, without floor shadow.
No real problem with this one, still, Eyesight looks better.
From left to right: POV-Ray and Eyesight, without floor shadow.
Both look bad...
From left to right: POV-Ray and Eyesight, without floor shadow.
From left to right: POV-Ray and Eyesight, without floor shadow.
From left to right: POV-Ray and Eyesight, without floor shadow.
This is weird! Why is Eyesight missing the Cross Supports?
When a white brick is displayed against a clear white background, it becomes almost invisible. When rendering images, we have the same problem. Transparent bricks are even worse, if something is 100% transparent, you can't even see it! So how do show rendered image of white and transparent parts?
Let's first look at what we currently have on the website. From left to right: White Element, White and Trans-Clear LDraw, copied from website.
Let's then see what we can do in POV-Ray if we use different light sources.
All images rendered at High Quality, without floor shadow. This is all done on my desktop, so a reasonably fast system. I will also do a few on my Pentium Notebook to show the difference.
From left to right: Left-Front (with sub-light), Left-Front, Left, Left-Back, Right-Front (with sub-light), Right-Front, Right, Right-Back, Front and Back, all without floor shadow.
From left to right: Left-Front (with sub-light), Left-Front, Left, Left-Back, Right-Front (with sub-light), Right-Front, Right, Right-Back, Front and Back, all without floor shadow.
Both in Linux and Windows, I use a high contrast theme with a black background. So my Desktop is black, not white. After rendering the transparent bricks in POV-Ray and adding a white background I realized that the brick is really dark - it doesn't look right. In Eyesight it looks much better. First I thought somehow the background color of my system had influenced the rendering, so I switched back to the Windows Classic theme with a white background, and reran the POV-Ray render. No change! Then I switched from transparent background to solid white floor color. No change! Finally, I reran the render and created a jpg output file, which can't have transparency. Still no change! Thinking it might be a bug in Studio 2.0, I started Studio 1.0 and reran the render. Same problem! The brick is even darker!
From left to right: (in Classic theme) Transparent Background, Solid Background, JPG Output and Studio 1.0:
I am really worried about this, because I did several hundred set renderings, and I never noticed this. So I need to find out who Nathan solved this in L3P, and then see if I can change the color definitions in Studio to get the same result. Hmmm, that might take another day!
Let's see what Eyesight does to a white or trans-clear brick under different light conditions.
All images rendered at Very High Quality / Building, without floor shadow.
From left to right: Left-Front, Left-Back, Right-Front and Right-Back, without floor shadow.
From left to right: Left-Front, Left-Back, Right-Front and Right-Back, without floor shadow.
Rendering transparent bricks takes about 10 minutes in POV-Ray and 30 minutes in Studio (on a fast system -smile-), so I have some time to do something else. I have asked Nathan for directory lists of his ldraw folder, and of media/ldraw and media/elements (the folders that contain the originals used for part images), and with that data I can try to deduce what versions we have used when the LDraw images were generated. Then I can compare that with the most current versions.
Looking at ldraw.lst: -rwxrwxrwx 1 nathan nathan 237568 Sep 30 2008 L3P.EXE
My version of L3P.EXE is also 237,568 bytes, so we've both used L3P 1.4 beta from 2008.
./lgeo: total 656 drwxrwxrwx 1 nathan nathan 4096 Nov 25 2011 ar drwxrwxrwx 1 nathan nathan 524288 Jul 28 2012 lg -rwxrwxrwx 2 nathan nathan 2577 Dec 15 2008 lg_changes.txt -rwxrwxrwx 2 nathan nathan 1483 Dec 25 2007 lg_colors.lst -rwxrwxrwx 2 nathan nathan 20332 Dec 15 2008 lg_elements.lst -rwxrwxrwx 1 nathan nathan 113525 Nov 24 2008 LGEO.pdf ./lgeo/ar: total 68 ./lgeo/lg: total 22495 -rwxrwxrwx 1 nathan nathan 367 Jan 5 1999 l2p_colr.tab
My version of lg_elements.txt is also 20,332 bytes, and the date is the same. However, the lg folder is four year newer, while mine is dated December 15, 2008. Even more weird, it contains .tab files that, as far as I know, were removed by Lutz Uhlmann in 2007. It does contain some .lg files from April 17, 2012, which I don't have in my original set. The 2008 LGEO set I am using contains 1,507 parts. The LGEO set used by Studio 2.0 contains C3POwen's LGEO Update Pack and has 1,715 parts. And there there is the Darats Update Pack, with 855 part, some updates, but mostly new parts. In short, there might be 2,500 LGEO parts currently available, and we have only used 1,500 of them. I need to find out if I can make L3P work with those new update packs. That might take a few days, though...
The generated LDraw images are in media/ldraw, and we have part-color downloads in out downloads section. I have downloaded all of them, and extracted then, giving a total of 72,668 images. In media_ldraw.lst there are about 72,895 images, so the downloads are reasonably accurate. We currently have about 73,000 LDraw images.
Looking at media_element.lst, we currently have 38,168 element images. So 2/3 of our part images are LDraw, and only 1/3 are element.
drwxrwxrwx 1 nathan nathan 262144 Jan 5 2016 P drwxrwxrwx 1 nathan nathan 1835008 Sep 5 2016 PARTS ./PARTS: total 129097 -rwxrwxrwx 1 nathan nathan 1283 Apr 5 2010 003238a.dat -rwxrwxrwx 1 nathan nathan 755 Apr 5 2010 003238b.dat ... -rwxrwxrwx 1 nathan nathan 363 Dec 30 2015 u9301.dat
Nathan's LDraw parts folder was created on September 5, 2016, but it doesn't seem to contain parts newer then December 30, 2015. The folder contains 10,405 parts. I am using the latest version of the parts library, from January 30, 2018, which contains 13,461 parts. Nathan used color -1 as the default color, and generated images in the default color for every available part in the LDraw parts library. The download for that color contains 11,039 images. So there are between 2,500 and 3,000 newer parts available for which we have not generated even a default color image.