[Software] LDD2PovRay

[BEAVeR]

Thanks BEAVeR that was the exact issue. Test model rendered well and now i get to play with all the settings Muahahha lol

Great I could help. I know the feeling. It's like Christmas all over again. Have fun!

[BEAVeR]

Sorry for the double post, but I want to know if other people are experiencing the same 'errors' I get.

What I render a model with "LEGO logo on studs", hollow studs are filled as well. Sometimes, this happens with renders with regular LDD geometry as well.

If you don't know what I mean, have a look at the following picture. concentrate on the volutes, represented by 2x2 radar dishes:

[MOC] Corinthian column - capital by Bert.VR, on Flickr

An even more annoying bug is when I render a 1x1 cone. Somehow, in the render there's an extra square hovering above the opening of the cone. I don't hava a picture right now, because I only edit those out.

Am I the only one with this problem?

[Dilvish]

Has anyone considered writing a Yafaray converter as well?

Yafaray is an opensource raytracer with it's own SDL, just like POV-Ray. However, I've heard that it is faster than POV-Ray, especially when adding on fancy extras to a scene like radiosity or global illumination.

Mike

Edited January 7, 2014 by Dilvish

[Darking]

Help please, everytime I try to download Pov Ray from it's website my antivirus shows up saying the exe file comes with a trojan!

Has this happened to anyone else? Because if not it could just be by antivirus going crazy, but I don't wanna take any risks before knowing for sure.

[Darking]

Sorry for double posting, but it would be very helpful if someone could answer my question in the post above.

[legolijntje]

Well, my anti-virus (Kaspersky 2014 doesn't warn me for any trojans. I suppose it's indeed your anti-virus going crazy.

Don't worry about it.

[Darking]

Thats weird, because Karpesky is my antivirus and is up-to date. But thanks!

[Flipz]

Sort of an odd question; it's more about LDD and POV-Ray than either of the converters, but since LDD2POV-Ray is the reason I'm encountering it...

Does anyone know how to translate the part coordinates found in LDD files into coordinates for POV-Ray? I'm wanting to put some light sources inside a number of transparent gem pieces (to represent the glowing embers on torches in a night scene), and I think I've worked out what POV-Ray code I should use (though I still haven't found where to paste it in in POV-Ray itself), I just need to find the right coordinates.

Also, tips on adjusting the LDD2POV-Ray sliders to best simulate an outdoor nighttime environment would be much appreciated; I have a nighttime sky sphere, but turning all the lights off just makes the render look like it's straight out of LDD.

[hrontos]

Does anyone know how to translate the part coordinates found in LDD files into coordinates for POV-Ray? I'm wanting to put some light sources inside a number of transparent gem pieces (to represent the glowing embers on torches in a night scene), and I think I've worked out what POV-Ray code I should use (though I still haven't found where to paste it in in POV-Ray itself), I just need to find the right coordinates.

Try to render this scene. It is a simple spotlight demostration in POV-Ray. And it shows also how to place a light on the same position as some brick. It is just tricky to find the right brick.

#version 3.6;

#declare ldd_level_of_detail = 3;

#declare ldd_white = <255/255,255/255,255/255>;

#declare ldd_black = <0/255,0/255,0/255>;

#declare ldd_stretch_palette = 1;

#declare ldd_light_color = <255/255,255/255,255/255>;

#declare ldd_ambient_light_color = 0/100*ldd_light_color;

#include "ldd_lego_colors.inc"

#include "ldd_main.bin"

#declare ldd_camera_transformation = transform { matrix <0.76167279481887817,0,-0.64796173572540283,-0.30815255641937256,0.8796766996383667,-0.36223039031028748,0.56999683380126953,0.4755721390247345,0.67002588510513306,11.696864128112793,12.339683532714844,17.410989761352539>}
#declare ldd_camera_location = ldd_vtransform(<0, 0, 0>, ldd_camera_transformation);
#declare ldd_camera_look_at = ldd_vtransform(<0, 0, -22.957365036010742>, ldd_camera_transformation);
#declare ldd_camera_angle = 25;
#declare ldd_model_transformation = transform { translate <0,0,0> }

#include "ldd_3814.bin"
#include "ldd_3818.bin"
#include "ldd_3819.bin"
#include "ldd_3820.bin"
#include "ldd_3626.bin"
#include "ldd_3815.bin"
#include "ldd_3816.bin"
#include "ldd_3817.bin"
#include "ldd_4599.bin"
#include "ldd_6141.bin"
#include "ldd_33320.bin"
#include "rad_def.inc"


global_settings {
assumed_gamma 1.4
max_trace_level 50
adc_bailout 0.01/2
radiosity { Rad_Settings(Radiosity_Fast, on, on) } // fast radiosity - comment out for better quality
/* uncomment these radiosity settings for better quality
radiosity {
pretrace_start 0.08
pretrace_end 0.005
count 1600
nearest_count 20
error_bound 0.02
recursion_limit 1
low_error_factor 0.25
gray_threshold 0
minimum_reuse 0.015
brightness 1.0
adc_bailout 0.01/2
normal on
media on
}
*/
}

background { color rgbft <255/255, 255/255, 255/255, 1, 1> }

// traditional light is commented out - uncomment to make scene brighter
/*
light_source {
<101,101,101>
color 75/100*ldd_light_color
area_light 30, 30, 10, 10
adaptive 1
jitter
circular
orient
transform { ldd_camera_transformation }
media_interaction off
}*/

camera {
right -(image_width/image_height)*x
location ldd_camera_location
look_at ldd_camera_look_at
angle ldd_camera_angle
}

#declare brick_0 = union {
ldd_3814(array[3]{21,0,0},array[2]{0,0},array[1][12]{{1,0,0,0,1,0,0,0,1,-0.39999991655349731,1.6000000238418579,0.39999961853027344}})
ldd_3818(array[1]{21},array[1]{0},array[1][12]{{0.98325490951538086,-0.18223552405834198,0,0.17517611384391785,0.94516557455062866,0.2756374180316925,-0.050230953842401505,-0.27102187275886536,0.96126192808151245,-0.61999970674514771,2.5099999904632568,0.39999961853027344}})
ldd_3819(array[1]{21},array[1]{0},array[1][12]{{0.98325490951538086,0.18223552405834198,0,-0.18223552405834198,0.98325490951538086,0,0,0,1,0.62000006437301636,2.5099999904632568,0.39999961853027344}})
ldd_3820(array[1]{24},array[1]{0},array[1][12]{{0.98474615812301636,-0.17398057878017426,0.0024053670931607485,0.16658905148506165,0.94671988487243652,0.27562692761421204,-0.050230953842401505,-0.27102187275886536,0.96126192808151245,-0.91031485795974731,2.0959556102752686,0.97849023342132568}})
ldd_3820(array[1]{24},array[1]{0},array[1][12]{{0.98480772972106934,0.17364819347858429,0,-0.17364819347858429,0.98480772972106934,0,0,0,1,0.87797993421554565,2.2703990936279297,1.0828781127929687}})
}
#declare brick_1 = ldd_3626(array[4]{24,0,0,0},array[3]{55196,0,0},array[1][12]{{1,0,0,0,1,0,0,0,1,0,2.880000114440918,0.39999961853027344}})
#declare brick_2 = union {
ldd_3815(array[3]{23,0,0},array[2]{0,0},array[1][12]{{1,0,0,0,1,0,0,0,1,-0.40000000596046448,1.6000000238418579,0.39999961853027344}})
ldd_3816(array[4]{23,0,0,0},array[3]{0,0,0},array[1][12]{{1,0,0,0,1,0,0,0,1,-0.40000000596046448,0,0.39999961853027344}})
ldd_3817(array[4]{23,0,0,0},array[3]{0,0,0},array[1][12]{{1,0,0,0,1,0,0,0,1,0.40000003576278687,0,0.39999961853027344}})
}
#declare brick_3 = ldd_4599(array[1]{26},array[1]{0},array[1][12]{{-0.98659539222717285,0.16226089000701904,0.017338462173938751,0.068929694592952728,0.51068824529647827,-0.85699862241744995,-0.14791196584701538,-0.84431588649749756,-0.51502722501754761,-0.91503679752349854,1.9815648794174194,2.2981905937194824}})
#declare brick_4 = ldd_6141(array[1]{44},array[1]{0},array[1][12]{{-0.98659539222717285,0.16226089000701904,0.017338469624519348,0.068929694592952728,0.51068824529647827,-0.85699862241744995,-0.14791196584701538,-0.84431588649749756,-0.51502722501754761,-0.93709433078765869,1.818144679069519,2.5724301338195801}})
#declare brick_5 = ldd_33320(array[1]{28},array[1]{0},array[1][12]{{0,0,-1,0,0.99999970197677612,0,1,0,0,-2,0,3.6000001430511475}})

#declare ldd_model = union {
object { brick_0 }
object { brick_1 }
object { brick_2 }
object { brick_3 }
object { brick_4 }
object { brick_5 }
}

ldd_model

ldd_statistics()

// removed standard plane
//plane { y, min_extent(ldd_model).y texture { pigment { color rgb ldd_colors[1] } finish { ldd_finish_shinyPlastic_255 } } }


// this is spotlight placed in the same location as "brick_4" which is the trans 1x1 round plate

light_source
{
<0,0.4,0> // location is slightly offset from <0,0,0> because otherwise stud from the black brick_3 would overlap the light source and no light would be visible
color rgb 1 //pure white
spotlight // spotlight - has conical shape
radius 15 // angle of the cone with full light intensity
falloff 25 // angle of the cone within which the light is gradually dimmed to 0
point_at <0,-1,0> // direction in which light points - in this case, it points down, because 1x1 plate has basic orientation in LDD with stud hole down and we want the light to come out of stud hole
matrix <-0.98659539222717285,0.16226089000701904,0.017338469624519348,
0.068929694592952728,0.51068824529647827,-0.85699862241744995,
-0.14791196584701538,-0.84431588649749756,-0.51502722501754761,
-0.93709433078765869,1.818144679069519,2.5724301338195801> // this is the same transformation matrix as is specified in declaration of brick_4
media_attenuation on // media will influence the intensity
media_interaction on // media will make light beam visible
}

// this box is filled with media, that interacts with light beam and makes it visible

box
{ ,
pigment { rgbt 1 } hollow
interior
{ media
{ scattering { 1, 0.2 extinction 0.01 }
samples 30
}
}
}


// wooden floor starts here

#include "woods.inc"

#declare Floor_Texture =
texture { pigment { P_WoodGrain18A color_map { M_Wood18A }}}
texture { pigment { P_WoodGrain12A color_map { M_Wood16B }}}
texture {
pigment { P_WoodGrain12B color_map { M_Wood18B }}
finish { specular 0.25
roughness 0.02
reflection { 0.1, 0.3 }
}
}

plane { y, min_extent(ldd_model).y
texture { Floor_Texture
scale 5
rotate y*90
rotate <5, 6, 5>
translate z*15
}
}

Help please, everytime I try to download Pov Ray from it's website my antivirus shows up saying the exe file comes with a trojan!

Has this happened to anyone else? Because if not it could just be by antivirus going crazy, but I don't wanna take any risks before knowing for sure.

I have seen similar question from somebody else from China using some local antivirus. I am using NOD from the ESET software and checked also the published files (to make sure, they were not altered). I presume some heuristic analysis in Kaspersky could be the source of similar false alarms.

Edited January 20, 2014 by hrontos

[Courleciel]

Hi everybody !

I'm beginning to learn to use this software. I've already made a few renderings with different options. But I'm still not happy with these renderings.

Did I hear right ? The lights at 23% (instead of 40%) give better renderings ?

According to you, what are the best parameters about level of details, lights & shadows, outlines, rendering, radiosity and colors ?

I precise that I adjust all the parameters in the LDD2POV-Ray window, I don't change anything in POV-Ray.

Thanks !

[Yooha]

I tried to install LDDtoPOVRay and POVRay again and I get the error message again: ldd_colors_declarations.bin is missing.

Previously I had other problems but this one is new.

UPDATE: The file is here now: c:\Users\Otthon\Documents\POV-Ray\include\

But it doesn't help.

UPDATE 2: By changing the output file location it works.

A silly question: why can't it be simple? Install, set, run, compute, be happy? Why making magic tricks with output folders and such?

Edited February 2, 2014 by Yooha

[Courleciel]

Hi,

I'm wondering how I could change the ambient light of only certain parts. Is there a simple way by modifying the .pov file or does it imply to do "illegal" things (like modifing .bin or .inc files) ?

Thanks !

[hrontos]

The part materials are defined as:

#ifndef(ldd_materials[21])
#declare ldd_materials[21] =
		texture {
			pigment { color ldd_colors[21] filter ldd_filters[21] transmit ldd_transmits[21] }
			#ifdef(ldd_normals[21])
				normal { ldd_normals[21] }
			#end
			finish { ldd_finishes[21] }
		}
#end

That is an example for material ID 21.

So easiest way is to declare you own definition for given material ID at the begining of the POV file:

#declare ldd_materials[21] =
	texture {
		pigment { color ldd_colors[21] filter ldd_filters[21] transmit ldd_transmits[21] }
		#ifdef(ldd_normals[21])
			normal { ldd_normals[21] }
		#end
		finish { my_own_finish }
	}

Of course, you can define it in the way, that it uses color from some other material:

#declare ldd_materials[21] =
	texture {
		pigment { color ldd_colors[2] filter ldd_filters[21] transmit ldd_transmits[21] }
		#ifdef(ldd_normals[21])
			normal { ldd_normals[21] }
		#end
		finish { my_own_finish }
	}

Above does not work with color variance. With color variance you have to redeclare only finish:

#declare ldd_finishes[21] = { my_own_finish }

[Courleciel]

Many thanks for your help hrontos !

I have another issue. It seems there is a global effect as all edges are somehow glowing. I have the feeling that on each edge there is a small beading or a bulge. For instance, look at minfig hands or the lightsaber's hilt.

It is more flagrant on a minifig, but I think I have the same problem with all bricks. I can't explain that...

I have used the following settings:

- basic LDD geometry with the visible bevels and the LEGO® logo

- one light source = 23% (from left, right, top or front, there is the same weird effect)

- radiosity: Final

- crease and silhouette outlines and color outlines (I think it's 25% by default)

- quality = 9 or 11

I really don't understand where does this problem can come from.

Edited February 9, 2014 by Courleciel

[JunkstyleGio]

Be carefull with putting down the lighting. take small steps of 2 or 3%

one lightsource does give a strange result; remember that is real life you always have moore than one lightsource..

[John W]

Many thanks for your help hrontos !

I have another issue. It seems there is a global effect as all edges are somehow glowing. I have the feeling that on each edge there is a small beading or a bulge. For instance, look at minfig hands or the lightsaber's hilt.

It is more flagrant on a minifig, but I think I have the same problem with all bricks. I can't explain that...

[iMAGE]

I have used the following settings:

- basic LDD geometry with the visible bevels and the LEGO® logo

- one light source = 23% (from left, right, top or front, there is the same weird effect)

- radiosity: Final

- crease and silhouette outlines and color outlines (I think it's 25% by default)

- quality = 9 or 11

I really don't understand where does this problem can come from.

That's caused by the use of outlines. Lines are drawn all seams, like with what is seen in instructions.

Edited February 10, 2014 by legolijntje
Please don't qoute images

[Courleciel]

That's caused by the use of outlines. Lines are drawn all seams, like with what is seen in instructions.

Ok. Does it mean that I should switched off all the outlines like this ?

[The Real Indiana Jones]

Why does the visible bevels option take so long? I rendered for 16 hours with bevels on my SSD. It was going 1% / 3 hrs before I quit. I turned off bevels and it fully rendered in 90 minutes!

Wow! Well if you are doing a very large model, then you don't need to render the bevels at all, because they would just be too small to see. Each bevel line would be much smaller than a pixel, so it won't make any visible difference.

[hrontos]

Ok. Does it mean that I should switched off all the outlines like this ?

Yes, they should be turned off for rendering purposes. Use them only when you want to create images for building instructions or similar puposes.

Wow! Well if you are doing a very large model, then you don't need to render the bevels at all, because they would just be too small to see. Each bevel line would be much smaller than a pixel, so it won't make any visible difference.

Exactly, on such large model bevels do not make too much sense, since they are smaller than one pixel. And rendering will be much faster.

[Shine]

OK, so for perfectly top/bottom, left/right, front/rear view here is a script and instructions.

I assume, that your model is not rotated in LDD, this means, that it is aligned to LDD grid.

1. Add following code to the end of the POV file in the POV-Ray. Uncomment always one of the #declare ldd_camera_location lines.

#declare ldd_camera_transformation = transform { translate (max_extent(ldd_model)+min_extent(ldd_model))/2 }
#declare ldd_camera_look_at = ldd_vtransform(<0, 0, 0>, ldd_camera_transformation);

#declare ldd_model_width = vlength(<max_extent(ldd_model).x, 0, 0> - <min_extent(ldd_model).x, 0, 0>);
#declare ldd_model_height = vlength(<max_extent(ldd_model).y, 0, 0> - <min_extent(ldd_model).y, 0, 0>);
#declare ldd_model_depth = vlength(<max_extent(ldd_model).z, 0, 0> - <min_extent(ldd_model).z, 0, 0>);
// for the top view
//#declare ldd_camera_location = ldd_vtransform(<0, max(ldd_model_width, ldd_model_depth)/tan(ldd_camera_angle*pi/360), 0>, ldd_camera_transformation);

// for the bottom view
//#declare ldd_camera_location = ldd_vtransform(<0, -max(ldd_model_width, ldd_model_depth)/tan(ldd_camera_angle*pi/360), 0>, ldd_camera_transformation);

// for the right view
//#declare ldd_camera_location = ldd_vtransform(<max(ldd_model_height, ldd_model_depth)/tan(ldd_camera_angle*pi/360), 0, 0>, ldd_camera_transformation);

// for the left view
//#declare ldd_camera_location = ldd_vtransform(<-max(ldd_model_height, ldd_model_depth)/tan(ldd_camera_angle*pi/360), 0, 0>, ldd_camera_transformation);

// for the fromt view
//#declare ldd_camera_location = ldd_vtransform(<0, 0, max(ldd_model_width, ldd_model_height)/tan(ldd_camera_angle*pi/360)>, ldd_camera_transformation);

// for the rear view
//#declare ldd_camera_location = ldd_vtransform(<0, 0, -max(ldd_model_width, ldd_model_height/tan(ldd_camera_angle*pi/360)>, ldd_camera_transformation);

2. In the generated POV file locate lights and camera definition. Use Cut and Paste and move it to the end of the POV file just after the newly added lines. The definition looks very similar to this:

light_source {
<100,100,0>
color 40/100*ldd_light_color
area_light 5, 5, 10, 10
adaptive 1
jitter
circular
orient
transform { ldd_camera_transformation }
}

light_source {
<-100,100,0>
color 40/100*ldd_light_color
area_light 5, 5, 10, 10
adaptive 1
jitter
circular
orient
transform { ldd_camera_transformation }
}

light_source {
<0,100,0>
color 40/100*ldd_light_color
area_light 5, 5, 10, 10
adaptive 1
jitter
circular
orient
transform { ldd_camera_transformation }
}

camera {
right -(image_width/image_height)*x
location ldd_camera_location
look_at ldd_camera_look_at
angle ldd_camera_angle

}

It is possible that left view will be actually right and front will be rear, because I don't know how is your model oriented in the LDD.

EDIT: added calculation of the max. dimension of the model.

Awesome, thanks. I know this is a really late response, but I've been looking for a way to do this for quite some time. Though using your technique seems to make POV-Ray ignore nonstandard camera angles. Is there any way around this?

Also, can a "perfect" 3/4s view be achieved using a similar method?

Edited February 17, 2014 by Shine

[Flipz]

All right, here's a tutorial for those folks who went through the difficulties I went through!

Tutorial: Nighttime Rendering and In-Scene Light Sources

The first step, of course, is to build your model. In this case, I'm using a very small-scale mock-up of the final scene I want to render, simply so that it's faster to experiment with specific settings via trial and error. You may want to try this as well, at least when you're first getting started with the renders.

Your next step is to achieve the nighttime look you want for overall lighting in LDD2POVRay. For me, the color "Midnight Blue" works best; set the lights on the Lights tab to RGB 25, 25, 112, and adjust the intensity as desired. For the following image, I set the right light intensity to 45% (representing a strong direct source of moonlight from the moon), left light intensity to 25% with shadows disabled (to represent reflected light and to keep the shadows from being too dark), and top light to 10% (since in my image the moon isn't really coming from straight above). I also set the ambient light to 40%, which is important because most of the lighting in nighttime shots will be either from ambient light or from in-scene light sources.

This is the result:

Miniscale_Cathedral_Courtyard_Mockup_Midnight by Poochythegenius, on Flickr

Next, make sure you know the colors of the parts you want to place lights in, and try to make sure no other parts share that color. Most of the time, you'll want to use Translucent Fluorescent Orange (Material ID "47") for things like flames and torches, but whatever color(s) you choose, be sure you know their Material ID, available from the Peeron Color Chart.

Once you have your model built in LDD, save your model as an .LXFML file. Once you've done this, you'll want to open the LXFML file in your text editor of choice--I use WordPad, since I'm on Windows, but Mac users can get a free program called TextWrangler that will work just as well. Once there, you'll see a document that looks something like this:

LXFML Coordinates by Poochythegenius, on Flickr

There are two things of importance here. First is the text I've highlighted in blue--this is the string you'll want to search for. You should have the material ID from the Peeron chart I linked earlier; if not, look it up now. Once you have the number, use the "search" function of your text editor to search for the string materials="##", where ## is the Material ID from the Peeron chart; this will take you to the entries for the bricks in that color.

Now comes the other segment of highlighted text: the coordinates. The transformation field contains a lot of numbers, but only the last three are needed to place the light source in the scene. Copy these numbers to a separate file, and if you have multiple parts in different colors be sure to note which ones are which.

Now comes the tricky part. Run the LXF through LDD2POVRay with the nighttime settings from earlier (along with any other personal choices--in my case, I'm using outlines for a cel-shaded look), but this time instead of letting the scene render when LDD2POVRay asks if you'd like to start rendering, say "yes" and then stop it prematurely. Now we are going to insert some additional arguments to the POV-Ray window.

Once you've closed the render window, you'll see a large text field with a bunch of what looks like computer coding. Make sure the tab with the name of your LDD model is selected, and then paste the following code into a new line:

light_source {< -0.40218925476074219, 5.8889670372009277, 2.0000004768371582> color rgb <255.5, 147.5, 41.5>
    fade_distance 0.3 fade_power 3
}

This will create an omnidirectional light source that will fade out over distance (like real lights do). You should now click the "render from INI button, make sure the INI file generated by LDD2POVRay is selected, and hit "Render" (being certain to save when prompted, otherwise the changes you've made won't be taken into account). There are a couple of things to note, however.

1.) The numbers between the <> brackets should be replaced with the coordinates you copied from the LXFML file. (Be sure to add spaces between the numbers, as POV-Ray wants spaces while LDD does not.)

2.) The "color" argument should be set according to the type of light you're creating. For me, I was simulating torchlight, so I chose the color of candlelight, which is RGB 255, 147, 41. (This page has a lot of helpful RGB values for various light sources.) The decimal after the color is another way to adjust the light intensity; I find that going much higher than .1 tends to make the light too bright for a night scene, but it's up to you.

3.) IMPORTANT! These numbers will be off! LDD defines its parts from their corner, rather than their center, so as it is, your light source will be on the corner of your part instead of inside it.

It will take a little trial-and-error to get your light source to move inside the brick--remember that even a change of 0.1 is a substantial distance at this scale. For the gem piece commonly used as a lighting source, I found that adding +0.3 to the x-coordinate and +0.7 to the y-coordinate achieved a workable result, though I'm sure I could have accomplished even better results if I had been even more precise. You may also want to play with the "fade distance" and "fade power" fields to make your scene be more or less illuminated by your light source. In any event, when you're finished moving the light source to the appropriate point within your brick the result should be something like this:

Miniscale_Cathedral_Courtyard_Mockup_Light_wshadows by Poochythegenius, on Flickr

This is perfect for simulating what things will look like when lit by LEDs, so if you're going for realism you can stop here. However, if, like me, you're rendering for a more artistic or "in-universe" result, we need to go a little further.

First, go back to the text field we had before. Now, find the code you added earlier and change it to look like this:

light_source {< -0.10218925476074219, 6.5889670372009277, 2.0000004768371582> color rgb <255.1, 87.1, 1.1>
    fade_distance 0.3 fade_power 3
    shadowless
}

The shadowless tag will prevent your light from casting shadows, so the shadows from the edges of the gem will not be rendered. However, this also means the light will no longer take the jewel's translucency into effect, so we have to darken the light's color ourselves. After some trial and error, I came to the numbers you see above, with the following result:

Miniscale_Cathedral_Courtyard_Mockup by Poochythegenius, on Flickr

And that's it! You now have a lit night scene; repeat for all of the other lights within your scene and you're ready to go!

[Nachapon Lego]

@Flipz. Thank you for the very useful tutorial above!

Lego light brick pressed by Nachapon S., on Flickr

LDD by penguinz LEGO 70810 - MetalBeard's Sea Cow _draft 4k AA 12min 13.7mb by Nachapon S., on Flickr

Lego LDD2povray LED eyes sword test by Nachapon S., on Flickr

Edited March 7, 2014 by bbqqq

[Shine]

Is there a file somewhere that controls which bricks get part materials and which don't? There's a lot of slopes that end up with the "sandpaper" texture that have no business with it.

[Yooha]

I tried playing with lights earlier, and I never understood, why the coordinates are wrong even though I copied the exact numbers! Because the light was at the corner! All I need now is a database with the size of the most common pieces that can be used as light sources.

[JM1971]

The 6141 pieces are good for getting coordinates when done like the pic, but when you attach the part the other way the light will get hidden in the piece its attached to.

ldd_6141(array[1]{40},array[1]{0},array[1][12]{{0,0,0.9999997615814209,-0.99999988079071045,0,0,0,-0.99999994039535522,0,-8.0800008773803711,0.39999917149543762,6.7999997138977051}})

Copy all the numbers between the {} brackets

Which is:- 0,0,0.9999997615814209,-0.99999988079071045,0,0,0,-0.99999994039535522,0,-8.0800008773803711,0.39999917149543762,6.7999997138977051

And paste between the <> brackets below.

light_source {<0,0,0>, color rgb 1 matrix <> fade_distance 1 fade_power 5}

Like this:-

light_source {<0,0,0>, color rgb 1 matrix <0,0,0.9999997615814209,-0.99999988079071045,0,0,0,-0.99999994039535522,0,-8.0800008773803711,0.39999917149543762,6.7999997138977051> fade_distance 1 fade_power 5}

Its a slightly different method but same result.

Edited March 10, 2014 by JM1971