hrontos

Nice real looking example. Is it post processed or you exported the new part to POV-Ray and placed on existing LDD model and rendered?

Yes, I am sorry, I did not read carefully, as I was focused more on the pictures and it took me a while, until I noticed it. Yes, it would fit those houses perfectly and as a part, it does not be more expensive to produce. I am not sure how to ensure that reinforcement - the removable roof would be extremly fragile - at least for kids. Mine have somtimes problem even with the current opening roof (they are bit younger, than the target age for the creator houses, so it is ok).

I am sorry, if I miss the obvious, but will it be still possible to create that continuous arch? When the part is rotated 180degrees to make it continuous arch, it will not connect. Or I miss something? This is really nice detail part for the roofs. Symetric, clean and does not seems to be difficult to produce. I enjoy watching, how you come with the ideas - may be just for fun, but may be some of them will really be an inspiration for TLG and will be produced.

Higher version can be installed without uninstalling previous. Simply download the installation package and start the installation. Your existing settings will be also preserved.

Yes, I think, it is an effect of a part position variance. Looks like built by clumsy builder. The variance actually is a function of the brick size. To be more precise, the definition specifies how much can be the brick edge randomly offset. This also defines maximum size of the "gap" between bricks introduced by the position variance. The allowed range seems to be too large for this brick. Or, since variance is calculated along 2 axis for this brick, it is possible that the effect just sum up. I will examine the definition for the plate and also the surrounding bricks.

Yes, the tiling was completely wrong. It should be possible to retain the texture even after beveling the edge. But POV-Ray will do some kind of decoration average in this case, because the front and side textures are different. I did not checked the real bricks to see, if they are printed also on the edge. Focal blur is nice, but makes it quite slow. At least on my machine. I almost took the inspiration from that minifigure and started looking for some rope for me.

Thank you for pointing this out. The original problem was repeated textures. This one is a bit different. Unfortunatelly POV-Ray expects, that texture mapping is based on triangles having all coordinates in range from <0,0> to <1,1> where <0,0> means one corner of decoration and <1,1> means the opposite corner. LDD uses also coordinates out of this range which means, that POV-Ray will ignore them (they map out of the decoration bitmap). For the next release, I will have to "stretch" LDD coordinates to fit into POV-Ray's range. EDIT: when you look at the decoration image (just check Use custom decorations to see it), it can be seen that LDD is doing some kind of stretching, since the decoration image does not contain that large blue stripe, it contains only what is seen in the POV-Ray image. EDIT2: LDD is repeating last row of pixels. So for example in case of that checkered patern you used for the test, LDD renders it as checkered pattern, but lower half of the the legs show only black/white stripes altering from the left to the right. I am not sure if this is a bug or feature, but I will try to repeat it in POV-Ray.

I think you know this model: 1366x768, 1803x1014, 2732x1536 On this view I tried the focal blur (it is may be a bit too strong): 1366x768, 1803x1014, 2732x1536

Version 1.2.3 released. Change list: added CustomHQ radiosity settings (courtesy of EB member whitew0lf) corrected errors when outlines enabled corrected decorations mappings corrected errors in part position variances definition disabled beveling of flexible parts removed oily effect from some colors modified finishing of transparent colors

I think, Vista and Win7 User Access Control protects some filesystem directories and Program Files usually requires admin access to add or delete file. Please, select some other directory as output path for the includes.

Yes this is probably true, but original author still can apply for a patent and later sell it to anybody. I think, it is not important if you publish it before it is patented. The only risk is that somebody will steal your idea, if you publish it before it is patented. There are many cases when company started produce a product and only after some time applied for a design protection. Of course, if the key portion of your idea is some knowledge out of public domain, you cannot patent it.

I use this switch when the render is aborted due to some failure. This switch can make POV-Ray continue the render, but POV-Ray will calculate radiosity data once again for the area which was not yet rendered so it can make rendering take longer in total. I had also cases when some rendering block was skipped so I had to rerender that square. For pausing a render I really use Pause button in POV-Ray and hibernate the computer instead of shutdown. When computer is turned on again, it restores complete session so I just click Pause again and rendering continues without any extra time penalty.

Technically it is. POV-Ray supports add-ons, which can do anything. They can potentialy handle the virtual filesystem tasks, so that it will not be necessary to have LDD2POVRay running while scene is parsed. But. This does not remove the need for virtual filesystem, since those add-ons does not work like fileformat reading add-ons, they are more like gui add-ons. There is no way to register some new file format with POV-Ray to support direct reading of db.lif or something like that. And another limitation is that creators of POV-Ray require these add-ons to be open source. I don't know how much open source - if all libraries or just the main library containing the add-on. Unfortunatelly, there too many people making money out open source things without even giving some credit. I have seen on eBay instructions made by designer Han being sold by somebody else. So why should TLG or any other company make their core business open source? Most open source projects are not core businesses of some companies. They are either work of a large comunity of students, fans etc. or some additional line of business of some companies (these solutions make a good promotion to the company).

db.lif location is suggested by the converter automatically. It is folder that can be access in windows by running Windows Explorer and typing "%appdata%\LEGO Company\LEGO Digital Designer" as a folder path. Or click on Start, Run... and type "%appdata%\LEGO Company\LEGO Digital Designer" there. Output path for includes can by any path. Converter will create include files there. They can 1GB in total, so select some path where you can store 1GB.

I think yes. I do not know details of the LDRAW dat structure, but since it is also based on the triangle meshes, it should work also with LDRAW meshes. LDD has explicit information about stud locations, so it is much easier to replace them, but may be LDRAW also maintains this information. Thank you for kind words. Yes, rendering higher resolution and resizing down can help smoothing some edges, since the resizing averages some information so edges are not so sharp and jagged. I am sorry, that part is my bug, I accidentaly set it as having possibility to randomly rotate at 90degrees steps to simulate random positioning during building. It is already corrected for the next release. Until then disable part position variance or remove the part from ldd_part_position_variances.inc.

Yes, it will be removed in the next release. However, finetuning of those materials is still required.

This means, that it should work when installed in virtual machine just like it worked for me when installed in WinXP 32bit in VMware in Win7 64bit. In case of minor errors I usually re-render only the problematic area of the image. POV-Ray allows you to specify exactly which rectangle should be rendered. The gold and more general all metallic colors need something to reflect, otherwise they will always look like ordinary colors, since when there is nothing to reflect they reflect white background and this makes it look even more as standard plastic. So one step is to improve them and the second step is to provide some surrounding environment (usually by using some HDR image - HDRlabs is quite good source). The circles are still not perfectly smooth, so when looking too closely, they look like made of straight segments. I hope it can be improoved soon. Radiosity is good to get ambient lighting. It's difficult to achieve the same using different techniques in POV-Ray. AA and transparent pieces does not work well in POV-Ray. It is better to render at higher resolution, without AA and resize down in picture editor. Larger studed transparent pieces take forever no matter what settings are used. It looks like the key is to keep them small, so I will think about some automatic spliting of transparent parts (of course, without any visible consequences). Actually, as it was discussed many times, exporting brick data to any other format is considered to be a violation of LDD EULA. We asked LDD Team for permission and conditions that we must fulfil to avoid legal consequences. And the key requirement was to keep the brick data protected at least on the same level as in LDD. This looked like impossible to do, since POV-Ray works only with plain text files. That's why we used the virtual filesystem. Technically, it should be possible to the same with Blender. Problem is, that Blender allows you to save the model in other formats and this the moment, when LDD EULA gets violated. The instructions style render can be used with lowest quality settings on the Rendering tab. POV-Ray will use only plain flat colors, no shading and reflections so it will look even more as original instructions and take much shorter time to "render". Of course, it is at least strange to use renderer to produce such images, but at this moment, this is the only application that can do it (except for LDD itself). And it was very easy to put there (except for the outlining algorithm, which is not that easy to create, but very simple once it is created). The Coloring pages style was just created as fun for my kids since they like the model printed and they can color it themself. As it was reported, it has a bug in the current release, but it will be fixed in next release. In the future I would expect some standard building steps and picture generator, without all that parsing and other POV-Ray stuff for producing building guides.

Very nice soft lighting. Did you used some HDR image or V-ray supports some lighting box based lighting?

Thank you for posting on UkrBricks.com. POV-Ray is mainly raytracer no modeler, so for modeling there are much better tools. As far as I know, there are some modeling tools, that directly generate pov files, but reverse is very complicated and there is no tool available that can read and fully support POV-Ray script language. POV file generated by LDD2POVRay does not contain any usefull data, only colors and locations of bricks within the model, so it does not make sense to convert it to any software without coresponding brick library. There were several reasons to select POV-Ray, but one of the main reasons is that it does not support export to other formats. It is not allowed to distribute brick geometries included in the LDD (that's LDD2POVRay uses virtual file system) so it is not legal to convert LDD model to any triangle mesh based modelling software.

According to you taskbar icons, LDD2POVRay is not running. It must be running while POV-Ray is parsing the scene.

Thank you for finding this error, I will check it.

Hello Marc, welcome to the forum. I am glad you finally managed to install it and it works for you. Nice first render. Converter respects the model view you selected in and saved in LDD, so you can zoom your models as you need to fill whole image to avoid too much unused white area. Sometimes it is necessary to move and return back some brick to make LDD think that save is necessary and it will enable the Save button and you can save the camera view point. Because normaly change of camera view point is not considered by LDD as change and it will not save the model. Or you can crop it later in picture editor.

These random black pixels are a result from max_trace_level reached. When POV-Ray traces a ray it follows it respecting all reflections. Whenever a surface is reached and ray is reflected, it is followed. Number of such hops is specified by max_trace_level. When this number of such "hops" is reached before reaching light source, entire pixel will be black. To resolve this, increase a max_trace_level in the generated POV file - it contains value 50, max. is 255. Or render at higher resolution without antialiasing and resize down the rendered image. Rendering resolution without antialiasing should be at least double of the desired final resolution to able to resize down to 50%. I resize down to 25% or 33%.

LDD creates that file automatically when running LDD for a first time. LDD to POV-Ray initially offers a path that should correctly correspond to your db.lif location. This file is by default located in AppData subdirectory of your windows profile directory. You can get there by opening Windows Explorer and putting there %appdata% as a folder name. It will automatically open the correct folder. There should LEGO Company subfolder and in that the LEGO Digital Designer folder.

I am sorry I will disappoint you, but I cannot tell you if the LDD to POV-Ray Converter can work on any windows "emulator" on Mac. It needs windows, .NET framework and it creates a virtual disk. I tested it also on virtual machine created using VMware and it works without problems but I have no idea if it is possible to run it on Mac using similar approach. Could you, please, share with us content of your Messages tab from POV-Ray? There are several post in this thread having similar problems and it was either some directory setup problem or incorrect version of POV-Ray - it has to be 3.7 from POV-Ray's beta page.