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.

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 think, it should be possible to charge them using the existing connector on the battery box. Just cut one brick connector from the PF extension cable and replace it with proper connector for the charger. Final solution will look nicer than any connector added to battery box. As a charger for 8 batteries shops for RC car or plane fans offer chargers able to charge 8 AA batteries, since the same setup is used in RC remote controlers. Such charger takes care of the batteries properly, is able to sense the voltage and properly selects charging current according to state of the batteries. Price of these chargers is comparable to price of 8 NiMH AA rechargeable batteries. May be it is better to use standard AA rechargeable batteries, because you can select your preffered brand and capacity. From performance point of view, rechageable batteries can provide more current than alkaline and since you compensate lower voltage by using 8 instead of 6, it should be really nice battery box. I do not recommend LiPo batteries. They are better, but their charging is more complicated and it is easy to make them explode when charged improperly.

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.

This time without base plane and with a transparent background. 1366x768, 1803x1014, 2732x1536

Yes, I did, as you see, file was saved in Universe mode. But it offers only one black. If you just need complete palette, download Aanchir's color reference.

No problem, you are welcome. Here it is. LXF

You need only that LXF file with 1x1 bricks in all colors from that palette? If yes, I will create one for you.

This style of color palette is in LDD 3 (like 3.1.3) with LEGOUniverse mode enabled. At least in Windows.

Which one? I passed two of them and both in the same way. I thought they should be treated as stairs - enter on low side, leave on high side.

May be this way?

When color figure is met, should the white jump over the color one and continue? Because there seems to be no way to just pass by.

#6 hat of the soldier with oars on boat.

Hehe. Like find 10 differences. The net should be #2. The red-green parrot should be #3. The pirate flag should be #4. Anybody willing help?

This looks really amazing. The rendering and the post-processing to add all those custom decorations and sails.

Unfortunatelly the metallic, pearl and translucent materials are quite difficult to define. Mainly because their final appearance strongly depeneds on the lighting. So the current definitions of those materials are not very good, only some of them produce good results and sometimes only when not looking too closely. :-) As Superkalle mentioned, if anybody has some proposals or better custom materials or color definitions, please, share them with us. More people can make more tests so we can have better materials sooner. Thank you.

Which version of POV-Ray 3.7 are you exactly using (RC3, RC5, RC6, 32bit, 64bit)? And which OS are you using? Note: 32bit version of LDD2POVRay does not work with 64bit version of POV-Ray.

That was really fast, no chance to be that fast with only 4 cores. So I will have to wait a "bit" more for mine.

I am glad you like it. Do you have some example of that mentioned odd colours of slopes? Could you please, post some test image? Materials and colors of the materials are not defined on per brick basis so two bricks with the same colour and material should look the same.

Yes, of course, that's why we support mainly POV-Ray 3.7 - the older versions does not support parallel processing, so it was more complicated. With 24 parallel threads rendering a model you have really a mighty machine. I am rendering the 10179 right now, but you will have it faster, since I have only 4 parallel threads. Impressive on this model is the number of bevels 553 623 and number of objects the scene consist of - 796 874. Together consuming 2956 MB of memory. If you really want to heat-up a bit your CPU, try some of the alienwar9's models.

Thank you for the uploading. Is Flickr making JPG automatically? Because picture is still presented as JPG. I resized it down to 800x600 to reduce the moire caused by JPG. POV-Ray does not allow to modify scene without reparsing it completely. This means, you cannot move a light or camera without compiling also rest of the scene. "Only visible bevels" is the slowliest for parsing. Usually technic bricks contain much more bevels than studded bricks so with studded it does not make big difference during rendering, but parsing is faster with "all bevels". Fastest is to parse with Level of detail set to "basic LDD geometry". It corresponds to #declare ldd_level_of_detail = 0;. For the final render it can be changed to #declare ldd_level_of_detail = 2; or #declare ldd_level_of_detail = 3;. Generally, geometry includes are big so LDD2POVRay does not cache them during reading, because it may require a lot of memory. But I will check how POV-Ray accesses these files and try to cache at least those with POV-Ray scripts. Hopefully it will help to speed-up parsing.

Great, thanks. Is it possible to share the PNG version (without orange spot) on your Flickr account at least for a while? I presume the top light was shadowless, since it does not seem to cast any shadow.

Wow, looks really good and in a reasonable time. Did you used 2 of those 3 built-in lights or completely different light setup? Will you share it with us? May I put the first one into LDD2POVRay gallery? Do you have also PNG version?

Looks pretty good and would say in a reasonable time for such larger model. I wonder how these SW models would look like when rendered without base plane, with transparent background and then placed on some background image with stars, space or Milky Way. I did not tried such photoshopping yet, since my artistic talent is very limited.

Good job. Really nice and very well lit rendering. I presume high-res version will bring you a bit better bevels and more clearly visible brick edges. Just resize it with a tool that supports bicubic resize. EDIT: One more recommendation: I see you used JPG for your image. Use PNG instead. PNG is looseless compression and it will help you avoid those moire patterns. I think, it is also the default output format of POV-Ray in Windows.