[Software] LDD2PovRay

[Seluryar]

Am I right to assume that lowering the light levels(top, left, right) will give the finished product a more realistic look? Does anyone have light level recommendations?

[The Player Nº1]

What can I do to make these black dots desappear?

I used:

LDD to POV-Ray Converter:

default except - all bevels + lights 23%

POV-Ray:

[3200 x 2400 No AA]

Thanks in advance!

Edited November 20, 2012 by The Player Nº1

[Seluryar]

Has anyone had these weird squares show up in the finished product(front well well thingy)?

An how about random dark spots when other bevels dont have that dark spot(near the turret)

Image

Edited November 21, 2012 by Calabar
Oversized Image converted in text link (Maximum size allowed is 800x600)

[The Player Nº1]

Has anyone had these weird squares show up in the finished product(front well well thingy)?

An how about random dark spots when other bevels dont have that dark spot(near the turret)

http://imageftw.com/uploads/20121120/43dsfrfA3.png

How did you put that background?

[Seluryar]

go find post# 313 by hrontos

http://www.eurobrick...00#entry1432326

and this post by him below that:

http://www.eurobricks.com/forum/index.php?showtopic=71654&st=300#entry1433913

Edited November 20, 2012 by Seluryar

[Gunner]

Can anyone help me?

So, I've been making decals to use as custom decorations on LDD to POVRay, and the color of the minifig torso look somehow different from its arms:

It looks like a different shade. It's less noticeble in other colors, but quite apparent in black. Anyone knows why this happens? Or how can it be fixed?

I used Fast Radiosity, Moddify LDD black color, Strech LDD palette and unmarked Use color variance. The decoration has a transparent background.

Thanks.

[hrontos]

Can anyone help me?

So, I've been making decals to use as custom decorations on LDD to POVRay, and the color of the minifig torso look somehow different from its arms:

It looks like a different shade. It's less noticeble in other colors, but quite apparent in black. Anyone knows why this happens? Or how can it be fixed?

I used Fast Radiosity, Moddify LDD black color, Strech LDD palette and unmarked Use color variance. The decoration has a transparent background.

Thanks.

This is due to reflections. White surrounding environment (background) is reflected by the body which makes it look dark gray. You can try this behaviour also with real bricks: build a wall out of black bricks and try to place some piece of white paper near the wall. Areas where the paper is reflected will not be so dark black as the rest of the wall. In POV-Ray when background is set as transparent, it's color is still taken into account when computing reflections. So in your case the white was reflected.

You can try to select black background color (of course transparent).

The artifacts on the minifig face are caused by the fast radiosity.

[Seluryar]

hrontos, Is it possible to add the wood floor part to the povray.ini?

Edited November 30, 2012 by Seluryar

[hrontos]

hrontos, Is it possible to add the wood floor part to the povray.ini?

INI files cannot contain scene elements, they are just for parameters for the rendering.

But try this:

1. Create a file named ldd_wood_floor_base_plane.inc. You can choose any name, LDD2POVray looks for a files named using pattern ldd_XXXXX_base_plane.inc. File has to be created in the same directory as you use for the other LDD2POVRay include files.

2. Put the floor code there:

#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
}
}

3. Save the file.

4. In the converter, on the Scene tab check the "Use custom base plane" checkbox and select the "ldd_wood_floor_base_plane.inc". The file name will be offered only if named according to that pattern and placed in a proper directory.

Converter will use wood floor instead of the default plane.

Since version 1.2.5 has a bug and ignores this checkbox , you have to download latest version to make this work.

To get more textured and less "glassy" wood use this definition:

#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.15
			 roughness 0.02
			 reflection { 0.04, 0.06 }
    }
   }
plane { y,  min_extent(ldd_model).y
   texture { Floor_Texture
	    scale 25
	    rotate y*90
	    rotate <5, 6, 5>
	    translate z*15
    } 
}

When combined with HDR lighting, rendered image may look like this:

Edited November 30, 2012 by hrontos

[hrontos]

With this base plane file content:

plane { y, min_extent(ldd_model).y
texture {
average
texture_map {
#declare Ind = 0;
#declare S = seed(0);
#while(Ind < 40) // higher number of iterations=less artifacts
[1
pigment { ldd_colors[1] }
finish {
ambient 0
#if (version>=3.7)
emission 0
#end
diffuse 0.2
brilliance 1
phong 0.0 phong_size 20
specular 0.0
roughness 1
reflection { 1 }
conserve_energy
}
normal {
bumps 0.05 // smaller value = less blured reflection
translate *100
scale 0.001 // scale it small(0.001) or big(1000)
}
]
#declare Ind = Ind+1;
#end
}
}
no_reflection
}

You can get floor that shows blurred reflections like this:

Amount of blur is adjustable.

Rendering of this base plane is much more slow than the rendering of the model itself.

[AzMiLion]

Thanks for making this great tool, Makes it easier to display LDD models in a good-looking way, i have one question though. How do i get the metallic materials to render as proper metallic looking bricks. they currently all look matte or flat.

Hypersled - Turbo Viper by AzMiLion, on Flickr

The dark grey and brown bits are supposed to be metallic. or does the metallic only show up on the highest quality render?

[hrontos]

How do i get the metallic materials to render as proper metallic looking bricks. they currently all look matte or flat.

The dark grey and brown bits are supposed to be metallic. or does the metallic only show up on the highest quality render?

Metallic materials are quite difficult to define and quite difficult to render properly. They reflect surrounding environment differently than a plastic material. When there is nothing to reflect for metallic parts, they reflect only white surrounding enviroment and this makes them look flat.

I also did not find yet an environment, lighting and material definition that works properly in most cases, so anybody willing to help is welcome.

[Seluryar]

INI files cannot contain scene elements, they are just for parameters for the rendering.

But try this:

1. Create a file named ldd_wood_floor_base_plane.inc. You can choose any name, LDD2POVray looks for a files named using pattern ldd_XXXXX_base_plane.inc. File has to be created in the same directory as you use for the other LDD2POVRay include files.

2. Put the floor code there:

#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
}
}

3. Save the file.

4. In the converter, on the Scene tab check the "Use custom base plane" checkbox and select the "ldd_wood_floor_base_plane.inc". The file name will be offered only if named according to that pattern and placed in a proper directory.

Converter will use wood floor instead of the default plane.

Since version 1.2.5 has a bug and ignores this checkbox , you have to download latest version to make this work.

To get more textured and less "glassy" wood use this definition:

I only see 1.2.5 on the ldd tools website, unless you meant that the next version will come out soon :)

Edited December 5, 2012 by Seluryar

[hrontos]

I only see 1.2.5 on the ldd tools website, unless you meant that the next version will come out soon :)

I did not changed the version number information, but download should give you version 1.2.7, so just download it.

[vynsane]

hrontos - I've started a Flickr group devoted to LDD to POVRay Converter renders. I took the liberty of using the logo from your site for the group icon. Please let me know if you are unhappy about this and I will remove it. You may want to link to the group from your site for further hands-free promotion (instead of adding them to your gallery page manually).

[hrontos]

hrontos - I've started a Flickr group devoted to LDD to POVRay Converter renders. I took the liberty of using the logo from your site for the group icon. Please let me know if you are unhappy about this and I will remove it. You may want to link to the group from your site for further hands-free promotion (instead of adding them to your gallery page manually).

Thank you, it's completely ok with me. I personally do not use Flickr, so I am glad that you created common public gallery for the rendered images.

The logo/icon image is the first model I rendered with maximum details, because I wanted to compare the result to the picture I saw here,

Later on, after the release of the LDD2POVRay, I was told, that this is a standard model shipped with LDRAW. I hope, I did not do any harm, when I kept the very first rendered image as an icon.

Edited December 11, 2012 by hrontos

[vynsane]

Glad to get your blessing. Now maybe I'll finally actually produce a render ;-)

[vynsane]

I'm trying to render a simple LDD file, and I've got an error in the generated .pov:

#declare ldd_camera_transformation = transform { matrix <>}

Error:

"C:\Users\Yago\Desktop\Mini TownHall.pov" line 22: Parse Error: Expected 'numeric expression', > found instead

As I'm not very familiar with the tool, neither povray, any help would be appreciated!

It looks like your LXF file does not contain camera definition. Is it a LDD4 file? Could you, please try to resave the model again in the LDD and convert it again? Or share it with us. Or I will send you a PM, if you do not want to share it.

I got this same error during my commute this evening. I was using the converter and POVRay on a Windows 7 virtual machine, running on my Mac host. I tried first importing through a shared folder, and got the error. Then I moved the file to the VM to see if it was something about the folder sharing, but no joy again.

Now that I'm home and had some spare time, I tried again - this time, I opened the file in the VM first, moved a brick, moved it back and re-saved the file. Now the render's running. So it's not just the LXF file that holds camera position data, it must be somewhere in the LDD program files as well.

[hrontos]

I got this same error during my commute this evening. I was using the converter and POVRay on a Windows 7 virtual machine, running on my Mac host. I tried first importing through a shared folder, and got the error. Then I moved the file to the VM to see if it was something about the folder sharing, but no joy again.

Now that I'm home and had some spare time, I tried again - this time, I opened the file in the VM first, moved a brick, moved it back and re-saved the file. Now the render's running. So it's not just the LXF file that holds camera position data, it must be somewhere in the LDD program files as well.

Converter takes it only from the LXF, but older versions of the LXF format had a different structure and camera position was stored differently, so making small change and resave of the file in the LDD4 should solve it.

[vynsane]

so making small change and resave of the file in the LDD4 should solve it.

I tried that - I made a change to the file (removing and replacing the canopy) on the Mac and moved the file to the Win7 VM and it didn't work. It wasn't until I made the exact same change to the file within the VM that I got the render to start. That said, when I opened LDD on the VM it asked to update from 4.2 to 4.3.5 - perhaps it was the update that made the difference? Your 'Requirements' page says it supports 4.1.7 and up, though...

[hrontos]

I tried that - I made a change to the file (removing and replacing the canopy) on the Mac and moved the file to the Win7 VM and it didn't work. It wasn't until I made the exact same change to the file within the VM that I got the render to start. That said, when I opened LDD on the VM it asked to update from 4.2 to 4.3.5 - perhaps it was the update that made the difference? Your 'Requirements' page says it supports 4.1.7 and up, though...

Could you, please, share the "before" and "after" file? I never had this problem with LDD4 file. And last year, when the development started, there was no 4.2.5, I had only 4.1.7 and some lower versions.

[vynsane]

I've placed both versions in a new folder on my Dropbox. I have to say, without even looking into the files, there's a slight difference in the file size! the Mac version is 18.2kb and the Win7 version is 16.75kb. Not a HUGE difference, but odd since it's supposedly a cross-platform format...

[hrontos]

I've placed both versions in a new folder on my Dropbox. I have to say, without even looking into the files, there's a slight difference in the file size! the Mac version is 18.2kb and the Win7 version is 16.75kb. Not a HUGE difference, but odd since it's supposedly a cross-platform format...

Thank you.

There is a slight difference in camera declaration in the MAC file (I am not counting many differences in bricks declarations).

On MAC the main camera has ID 1.

<Camera refID="1" fieldOfView="80" distance="54.928630828857421875" transformation="0.654235780239105224609375,0,-0.756290853023529052734375,-0.42869150638580322265625,0.823831856250762939453125,-0.3708432018756866455078125,0.62305653095245361328125,0.5668342113494873046875,0.538980305194854736328125,34.54363250732421875,33.94400787353515625,27.20844268798828125"/>

On Windows, it has ID 0.

<Camera refID="0" fieldOfView="80" distance="59.928615570068359" transformation="0.60770773887634277,0,-0.79416084289550781,-0.50713777542114258,0.76955282688140869,-0.38807198405265808,0.6111486554145813,0.63858318328857422,0.46766319870948792,36.945289611816406,41.077983856201172,25.629405975341797"/>

Converter looks for 0, so that's why it could not find it in the MAC file.

But the correct ID of the camera is stored in <Bricks cameraRef="0">. On Windows there is 0, on MAC there is 1. So I will read it from there in next release, instead of hardcoded 0 or 1 to avoid this error.

Edited December 12, 2012 by hrontos

[vynsane]

HA, wow, interesting. I wonder why it still works when moving from one to the other. Perhaps the program only looks at the <Bricks cameraRef> entry as well?

[hrontos]

HA, wow, interesting. I wonder why it still works when moving from one to the other. Perhaps the program only looks at the <Bricks cameraRef> entry as well?

Converter ignores this attribute, that's why camera could not be found in the MAC file, but LDD itself knows the LXF format better than me and does not have this problem.

I am just curious what is the source of this useless difference. Why the same application behaves differently in such small and definitely not platform specific detail.