[Software] LDD2PovRay

[Nachapon Lego]

Discussion about bbqqq rendering and relative contest moved in a separate topic.

Thank you very much, Calabar.

Please try new game the very hard maze puzzle here.

Edited July 13, 2012 by bbqqq

[hrontos]

This time without base plane and with a transparent background.

1366x768, 1803x1014, 2732x1536

Edited July 16, 2012 by hrontos

[Aanchir]

This software looks incredible. I doubt I will install it on the computer I'm using currently, but once I get a new computer for the college I am going to I will see if it will run well on that.

This will be a great way for people who enjoy using LDD to propose their LDD models on Cuusoo without the proposals simply blending in with more amateur proposals. Currently, with LDD's fairly basic shading, LDD projects on Cuusoo look somewhat sloppy no matter how complex they are, and sometimes there's a poor sense of scale. With this, however, those distractions of poor presentation will go away and people will be able to judge proposals based on the complexity of the models as they would appear in real life.

The bugs might be a bit of a hindrance, but overall this gives LDD builders far more options in how they want their models to appear. I will definitely need a lot of practice if I want to learn to render things in PovRay like the pros do it, but I look forward to the opportunity and the challenge.

[hrontos]

This will be a great way for people who enjoy using LDD to propose their LDD models on Cuusoo without the proposals simply blending in with more amateur proposals. Currently, with LDD's fairly basic shading, LDD projects on Cuusoo look somewhat sloppy no matter how complex they are, and sometimes there's a poor sense of scale. With this, however, those distractions of poor presentation will go away and people will be able to judge proposals based on the complexity of the models as they would appear in real life.

The bugs might be a bit of a hindrance, but overall this gives LDD builders far more options in how they want their models to appear. I will definitely need a lot of practice if I want to learn to render things in PovRay like the pros do it, but I look forward to the opportunity and the challenge.

Yes, the possibility to create real looking digital models easily using LDD so that also people with smaller brick collection can participate in EB building contests or present more atractive images of their CUUSOO ideas was quite strong motivation. This way talented people can without limitations present their creativity and try to compete with the others having wider brick collections. Sometimes I have a feeling that budget or size of collection was a bit unfair limitation. Moreover digital creations in such contests can be examined more deeply and give possibilty to judge also building technique and not only overal appearance.

Of course there are some geometry and material bugs. All geometry enhacements are applied to all bricks, because they should work with all of them, but not all brick were really examined and there will be some errors. Some of these come from wrong modelling of the brick (from POV-Ray's point of view) and some of the may come from enhancement rule being too simple. I presume additional automatic enhancements will be added (like circle smoothing) but some of the bricks will have to be modelled from scratch directly in POV-Ray. We can open a topic for such bugs and/or suggestions when it will be considered as usefull. Or just simply write me.

[purpleparadox]

These look amazing! Tomorrow I have to download this. Completely beautiful renders!

Remind me to browse the digital tools forum more.

[donut2k]

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!

[hrontos]

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.

[Superkalle]

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.

He only has 8 posts, so you can't send a PM. He needs 10 posts.

[donut2k]

The model was created from scratch with LDD 4.2, I feel there was something wrong with the model because when I was working on it when I opened it was the one I got as I closed the file. The two times I was testing the tool I got a straight front view.

I just added a 1x1 brick for reference and deleted it afterwards and it's doing the render! now at 3%..

Thanks, I will update with the finished model cheers!

1h54m later the model:

23072011 Mini Town Hall Render (LDD to POV-Ray) by yagodiaz, on Flickr

I have to study the options to get better luminance, size and detail.

Great software!

Edited July 22, 2012 by donut2k

[Shroud]

Hey guys,

I must admit it looks to be a great idea but I just cant get it to work. I've read through every page of this thread and tried every solution but to no avail! I get this message everytime:

Preset INI file is 'C:\Users\SHROUD\Documents\POV-Ray\v3.7\ini\quickres.ini', section is '[512x384, No AA]'.

Preset source file is 'C:\ARCHIVE\Finished Downloads\Untitled.pov'.

Rendering with 8 threads.

Parser Options

Input file: C:\ARCHIVE\Finished Downloads\Untitled.pov

Remove bounds........On

Split unions.........Off

Library paths:

\\.\LDDIncludes

C:\Users\SHROUD\Documents\POV-Ray\v3.7\include

C:\Windows\Fonts

Clock value: 0.000 (Animation off)

Image Output Options

Image resolution.....512 by 384 (rows 1 to 384, columns 1 to 512).

Output file..........C:\ARCHIVE\Finished Downloads\Untitled.png, 24 bpp PNG

Dithering............Off

Graphic display......On (gamma: sRGB)

Mosaic preview.......Off

Continued trace......Off

Information Output Options

All Streams to console..........On

Debug Stream to console.........On

Fatal Stream to console.........On

Render Stream to console........On

Statistics Stream to console....On

Warning Stream to console.......On

-

"\\.\LDDIncludes\ldd_default_colors.inc" line 20: Parse Error: Illegal character in input file, value is ffffff80.

Render failed

-

CPU time used: kernel 0.05 seconds, user 0.02 seconds, total 0.06 seconds.

Elapsed time 0.36 seconds.

----------------------------------------------------------------------------

Ive seen this same error but what works for people isnt working for me.

Im running Win 7 64 bit.

Im using the 64 bit converter and leaving it open, pov ray 3.7, the \\.\LDDIncludes is in the .ini file, ive moved the .pov file and the file im testing is one brick in the latest LDD.

Any ideas?

[hrontos]

New version of the LDD to POV-Ray Converter was released.

New features in version 1.1:

• faster parsing
  
• reduced memory required for scene parsing
  
• flex part support
  
• custom decorations
  
• special tab for the POV-Ray's rendering settings
  

You can download it from here.

If you experience any problems, please, let me know.

Edited July 23, 2012 by hrontos

[Calabar]

New version of the LDD to POV-Ray Converter was released.

Great work, I didn't thought to see flexible parts supported so soon.

I see the "custom decorations are not yet supported" is vanished from the Limitations, but it is not included in the Features. Has this feature been added?

Another little thing: is there a chance for a portable (stand alone) version?

[hrontos]

Great work, I didn't thought to see flexible parts supported so soon.

I see the "custom decorations are not yet supported" is vanished from the Limitations, but it is not included in the Features. Has this feature been added?

Another little thing: is there a chance for a portable (stand alone) version?

Yes, the custom decorations are supported. I see it in the features list as the last point - did I forget it somewhere else?

Could you, please, explain, what you expect from the portable (stand alone) version?

Edited July 23, 2012 by hrontos

[Calabar]

Oops... I readed the list more than one time and I miss the feature!

Could be the late time...

Even more great work, then!

From the (native) portable version, I expect the usual things:

- "unzip and execute" without installation

- work in its own folder (no registry settings or folders dispersed on the system)

- usable from a pen drive

[hrontos]

From the (native) portable version, I expect the usual things:

- "unzip and execute" without installation

- work in its own folder (no registry settings or folders dispersed on the system)

- usable from a pen drive

The application itself can work like that. It does not require anything special, except for the .NET 2.0 Framework.

But the virtual filesystem cannot work like that. It is not possible to create such special disk drive without a driver installation.

So that's why the whole solution needs an installation.

Unfortunatelly it is not possible to feed the POV-Ray "online" with the data. It can read only files and the scene and the includes have to be plain text files.

Virtual filesystem gives a possibility to present the data as needed - as textual to POV-Ray and binary to any other application.

But of course, if anybody comes with an idea how to solve it in some other way, we can discuss it - it would be usefull also for the Mac users.

Edited July 23, 2012 by hrontos

[Nachapon Lego]

Great update! Quick try the new features and they work very well.

The flex elements looks a bit flat shade/ cell-shade. Is it normal?

Edited September 1, 2012 by bbqqq

[Judah Nielsen]

Well I chose my most complicated file for the test run, so I won't have a real presentable image until sometime tomorrow, it seems, but this is a fantastic development. It seems like the positioning of the model needs to be done in LDD. Is there some easy way that I've overlooked to get perfectly "straight on" views, like a perfect side view or a perfect top view of a model?

[hrontos]

1h54m later the model:

Image

I have to study the options to get better luminance, size and detail.

Great software!

I am glad it finally worked.

The image looks good, just it is aliased. You can try some settings with antialiasing (or render at higher resolution and scale down with bicubic resampling) and you should nice get smooth lines.

The latest version should help you select better resolution and antialiasing to get the result you expected.

Great update! Quick try the new features and they work very well.

The flex elements looks a bit flat shade/ cell-shade. Is it normal?

Thank you for sharing. It looks like a problem with normals. I will check this to find out if it is a conversion or LDD modelling problem.

Well I chose my most complicated file for the test run, so I won't have a real presentable image until sometime tomorrow, it seems, but this is a fantastic development. It seems like the positioning of the model needs to be done in LDD. Is there some easy way that I've overlooked to get perfectly "straight on" views, like a perfect side view or a perfect top view of a model?

It is possible to try to select the best straight view in LDD, but I will provide a sample how to create mathematically straight view directly in POV-Ray.

[Judah Nielsen]

Once again, amazing work guys. This 560 stud, 23000 piece ship rendered overnight, and looks great, although at this scale it looks less like "real LEGO" and more like "computer graphics" than some of the other renders I've seen here.

Light Cruiser - POV Render by JudahMoTron, on Flickr

[hrontos]

Once again, amazing work guys. This 560 stud, 23000 piece ship rendered overnight, and looks great, although at this scale it looks less like "real LEGO" and more like "computer graphics" than some of the other renders I've seen here.

Light Cruiser - POV Render by JudahMoTron, on Flickr

The model is amazing. I wonder how big models you will try later, when your first "test" render was 23000 pieces.

Actually the size of the model is big memory and parsing time issue, but seems to have smaller influence on the rendering time than the output resolution and the number of light sources. POV-Ray seems to have some good search trees when computing which part was hit by the light ray.

The small creator front loader took longer time to render than the winter post office just because of different lighting. And the winter post office is much bigger model. Also technic models take longer, because there is a lot of beveling the technic beams.

What level of detail did you used and how much memory such big model required?

Do you plan to render it at higher resolution just to make it look more like LEGO and we see more details of the model?

It would be nice to see the ship from the view of a landing plane (camera standing above the front of the ship and looking at the other end of the ship). Or standing near by the top of the tower, to have some portion with detail and look at the other end.

Edited July 24, 2012 by hrontos

[Judah Nielsen]

What level of detail did you used and how much memory such big model required?

Do you plan to render it at higher resolution just to make it look more like LEGO and we see more details of the model?

It would be nice to see the ship from the view of a landing plane (camera standing above the front of the ship and looking at the other end of the ship). Or standing near by the top of the tower, to have some portion with detail and look at the other end.

I took the advice of some others in the thread and rendered it at 5 times the "final resolution" of 1920 x 1200 with AA off. I went ahead and left the LEGO off the studs because I knew they would be invisible even at 9600 x 6000.

Pixel level render of the rear battery - original size available on flickr on Flickr

I walked away during parsing, which took a little under 2 hours on a fairly competent machine. I suspect final memory usage was around 5000MB. But you're right, rendering itself went pretty quickly. I suspect it only took three or four hours, but I went right to sleep.

[hrontos]

I took the advice of some others in the thread and rendered it at 5 times the "final resolution" of 1920 x 1200 with AA off. I went ahead and left the LEGO off the studs because I knew they would be invisible even at 9600 x 6000.

I walked away during parsing, which took a little under 2 hours on a fairly competent machine. I suspect final memory usage was around 5000MB. But you're right, rendering itself went pretty quickly. I suspect it only took three or four hours, but I went right to sleep.

The "army" of studs visible on the rendered image is incredible.

At first sight I was looking what brick did you used for the surface until I recognized those are studs. It confused me completely.

Do you have also that large 9600x6000 version? Will you share it with us? I think, PixBuilder can offer you nicer antialiased resize than GIMP when resized down to 25% (2300x1500). But may be it is just a matter of taste.

Concerning the parsing time: it can be improved. I mean, when LDD to POV-Ray Converted will create bigger includes, parsing time can be shorter, because more data will be prepared, but I am not sure if anybody wants to have 1.2GB includes instead of 600MB.

[Judah Nielsen]

The "army" of studs visible on the rendered image is incredible.

At first sight I was looking what brick did you used for the surface until I recognized those are studs. It confused me completely.

Do you have also that large 9600x6000 version? Will you share it with us? I think, PixBuilder can offer you nicer antialiased resize than GIMP when resized down to 25% (2300x1500). But may be it is just a matter of taste.

Concerning the parsing time: it can be improved. I mean, when LDD to POV-Ray Converted will create bigger includes, parsing time can be shorter, because more data will be prepared, but I am not sure if anybody wants to have 1.2GB includes instead of 600MB.

Sure. The full 9MB png is at http://www.onemoreproject.com/LDD/CL-02.png

You mentioned a way to produce a mathematically straight view in POV-Ray. This model (and some of my other large models) is pretty unwieldy in LDD, but I'd like to be able to get identical views for the different ships I've made, so any kind of tutorial on that would be fantastic.

[hrontos]

Sure. The full 9MB png is at http://www.onemoreproject.com/LDD/CL-02.png

Thank you for sharing.

You mentioned a way to produce a mathematically straight view in POV-Ray. This model (and some of my other large models) is pretty unwieldy in LDD, but I'd like to be able to get identical views for the different ships I've made, so any kind of tutorial on that would be fantastic.

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.

Edited July 24, 2012 by hrontos

[Judah Nielsen]

// for the top view

//#declare ldd_camera_location = ldd_vtransform(<0, ldd_max_model_dimension/tan(ldd_camera_angle*pi/360), 0>, ldd_camera_transformation);

[/code]

My math suggests this number is a factor of 2 too high (i'm looking at a triangle with camera distance as the "adjacent" but only half the model length as the "opposite", which is where we differ by 2), and my test render does have a lot of whitespace. You need some whitespace, especially if you're rendering a shadow on the baseplane, but I'm going to see if replacing the denominator with 1.5*tan(...) gives me a better result.

I also suspect, but haven't done the renders to prove it, that this would be even worse if you had the smallest dimension facing the camera (in this case the front), since the distance is always calculated from the largest dimension, which might be going into the screen.