hrontos

85969 was not really removed. It is there, just LDD is not able to read it's name as I reported here.

Very nice and wanted feature and with a quite elegant solution. Works like a charm. Even the brick counts are working depending on the number of parts in the LXF.

Version 1.2.5 was released today. Changes in this release: added Don't bevel transparent parts checkbox as requested by bbqqq fixed problems with brickset version 835 from LDD 4.3.5 Please, let me know, if you experience any problems. EDIT: changed version to 1.2.5 since I had to rebuilt it.

There are 3 parts having wrongly stored name in the new brickset. Part ID 87799 has name "HEART" WITH 3.18 SHAFT, part ID 85969 has name RIM CASE Ø36.7 "CALLARDO" and part ID 43751 has name MINI WIG MAN "NO. 2". Problem is with the double quotes. According to XML standard double quotes has to be stored as " and not directly as ". So instead of designname="MINI WIG MAN "NO. 2"" it should be there designname="MINI WIG MAN "NO. 2"". LDD cannot load these parts and ignores them. In previous brickset version these parts were named properly and could be used in LDD without problems.

This error is caused by 3 parts having wrongly stored name in the new brickset. Part ID 87799 has name "HEART" WITH 3.18 SHAFT, part ID 85969 has name RIM CASE Ø36.7 "CALLARDO" and part ID 43751 has name MINI WIG MAN "NO. 2". Problem is with the double quotes. According to XML standard double quotes has to be stored as " and not directly as ". So instead of designname="MINI WIG MAN "NO. 2"" it should be there designname="MINI WIG MAN "NO. 2"". That's why you see that unexpected token 'NO.'. Not even LDD can load these parts and it ignores them. In previous brickset version these parts were named properly and could be used in LDD without problems. I will post an update to LDD2POVRay which will also ignore such errors in brickset to avoid problems in the future.

Some of the vital Unimog parts were also added. Very nice. And like the new grouping of the parts. It will be clearer also to my kids.

Did you noticed the new menu item for exporting BOM to excel/zip in the File menu? I wonder if there are some other new features.

Is there some transparent brick? Could you, please, share your LXF file with a relevant portion of the model?

Yes, as I said, this can be done without significant effort.

No, not at this moment. Transparent and non-transparent parts differ only in material definition and transparent parts are using merge and non-transparent are using union operation when enhancing geometry. All other handling and scene processing is the same.

Yes, I think we speak both about the same - when this option will be selected transparent parts will not be beveled and will be rendered only using LDD geometry (but with LEGO text when level of detail with LEGO text is selected).

You mean to add a checkbox to LDD2POVray GUI which will disable beveling of transparent parts when checked? Just like you did - you rendered transparent parts without bevels. It should be easily possible without any significant effort.

Yes, the real RC battery is much more powerfull with much higher capacity and almost 4x cheaper, real RC motors are stronger for the same or less money. LEGO RC components are made of pretty simple electric parts and are really highly overpriced.

Many people comment technic RC vehicles as having poor performance comparing to real RC vehicles or DIY kits. This is definitely true. For the same money the real RC vehicle performs much better. For 200USD you can get much better RC, but I personally miss the construction. I tried both. I assembled the RC model car myself and I found the assembly of the model much more fun that driving itself. I spent more time by construction experiments and improvements of the model than driving. So I found out, that I need construction toy (with optional RC) and not real RC toy (with optional possibility to built it myself). For the same money is the LEGO Technic better option for me.

Actually it behaves that way already now. It is not possible to replace one LDD decoration by multiple custom decorations. It is really picture for picture replacement. This means, that if one decoration is applied to multiple bricks, it is enough to specify new decoration picture once and it will be used on all of those bricks. Yes, I have read some articles on this kind of focal blur comparing advantages of both aproaches. It works well when there is one sharp area in the center of the picture. Problem may appear, when there are more objects, that should be sharp and each should be surrounded by blurred area. It requires bit more manual work to get it realistic when doing the post processing. But it is probably still faster than to calculate it using focal blur. Imagine a view from the clown position in your picture. Clown sees 2 or 3 horses at once and they should be sharp. People in the audience visible "through" the horses is further and should be less sharp.

At first sight I did not recognized what is the "idea" but it is very nice trick to make larger custom decoration by splitting into many smaller and applying to multiple tiles.

1366x768, 1803x1014, 2732x1536

The only purpose of the "Don't generate includes" checkbox is to avoid problem with LDD exclusive use of db.lif file. When model is converted for the first time, it is necessary to generate missing includes (if any). When the same model needs some small adjustments like change of colors or camera view, it is annoying to open/close LDD over and over to change, convert, try in POV-Ray. So it is better to check it, access to db.lif will not be necessary and LDD can be running during the conversion,

Currently the only way is to run RegEdit.exe and export key HKEY_CURRENT_USER\Software\LDD Tools\LDD to POV-Ray Converter to a reg file. This reg key contains the last saved default settings so do not forget to save you current settings as default (by clicking "Set as defaults" menu item in the Settings menu in the LDD2POVray.)

Original LDD decorations are png images having dimensions only 128x128 pixels. They may contain transparent areas - brick color is then visible in these areas. LDD2POVray displays the original decorations in their original size, with checkers pattern background which can be seen "through" transparent areas. As a starting ppoint, you can make a printscreen of the LDD2POVray window displaying the desired decoration (the same can be done by aplying decoration to 2x2 tile in LDD and positioning the camera to look directly at the tile, so I do not consider this little trick as a violation of anything). Actually LDD is using uv mapping to map triangles from decoration to triangles on brick. This makes idependent of the size and aspect ratio of the decoration. This means, that you can make decoration having the same aspect ratio as target surface and use it. It is easier to draw it like that. It is quite dificult to draw it square and try to estimate how it will look when stretched to some rectangular surface. It is easier to make it rectangular. You can put your existing real minifig on the scanner, scan the body, crop away the unwanted area and use it directly. This test is quite quick. If you will be satisfied, add those transparent areas and you will have nice new minifig body decoration.

For this rendering I did not used any traditional light source. I only added 5 emissive panels, so whole lighting is based on radiosity calculation. It produces nice soft shadows. Shading is a bit flat, since I used 10% ambient light value. May be I should stay with 0. 1366x768, 1803x1014, 2732x1536 Model was not built by me, I took it from the official set in LDD topic and made some correction of colors of transparent parts. But some other colors are also wrong (at least the version I have at home does not have black base plates and also some other pieces are different).

It's a pitty, but you still can restart the rendering. If you used the ini file add line with Continue_Trace=On to the ini file. If you did not used ini file, put +c into the text box which is next to the resolution dropdown list in POV-Ray GUI. POV-Ray will continue from the momement when it was aborted. I had similar problems, without blue screen, but with sudden shutdowns, due to processor overheating during hot days. I used power management to reduce the maximum frequency of the processor.

Very nice experiment. "Real" compressed air or carbon dioxide engines used by plane models do not use any valves. They have a small ball on the top of the cylinder. This ball covers the hole which is used to get the air into the cylinder. Piston has a small pin on the top. When piston reaches the top position within the cylinder, pin hits the ball, the ball at that moment will let the air get into the cylinder and the air moves the piston down. In the lower most position there is another hole in the wall of the cylinder which lets the compressed air get out so that piston can return back to top most position, hit the ball again, let the air in again, go down... like illustrated here. In this case two 2x2 plates would be needed for each cylinder. One base plate containing tiny hole with some cone for the ball and the other plate as they are - for the pipes. Pin has to be added to the piston. Real carbon dioxide piston contains a small hood on the top - it looks like you would wrap whole piston into selfadhesive plastic tape and let it be 1 mm over the top of the cylinder. Ballpoint pen tip can be used to "bend" that 1mm a bit outwards so that it is bit wider than the cylinder. Actually also the air presure will push it in that direction. Just take a look at your bicycle pump. Such small hood is also there. Benefit of this construction is, that it is air tight and still does not generated any unwanted friction. Friction is there only when air presure is there, which is ok. This construction would also need some kick to start. And of course a flywheel (spinner from Ninjago?).

The generated ini file has "higher" priority. Which means, the settings mentioned in that file will be in force and not those you selected in the POV-Ray GUI. They basically cover only the resolution, antialiasing and output quality. There should not be much difference between using and not using the ini file, only the resolution in the ini file is by default your screen resolution which is probably more than the size of the image. The main purpose of this generated ini file was to simplify the setup of the paths and adding of the new resoultions since it seems to be a problem for the people using the POV-Ray for the first time.

Thank you very much for your kind words. Rendering is really a test of user's patience, but the results can be very realistic. Technically POV-Ray "shoots a light ray" for every pixel of the picture and follows it along all reflections until some light source is hit. So higer resolultion means more pixels, more needed rays and more rendering time. High-res image may need less antialiasing so the rendering time may not exactly proportional to the size of the picture. Picture with double width and height contains 4 times more pixels so rendering should take 4 times longer, but it will not be exactly 4 times longer. As it was mentioned, when POV-Ray is running as foreground task, it gets almost all CPU time, when running in the background, it will get only the time "not wanted" by the other processes. So browsing the i-net will have almost not impact, but if you decide to encode a DVD, POV-Ray in the background will starve. Also memory issue is important. The whole model has to fit into your physical memory. When you have 2GB and Windows makes 4GB because it creates virtual memory using disk pagging file, it does not make sense to render model, that needs more than 2GB of memory. POV-Ray will parse it, but because of swapping to pagefile it will take forever to render. POV-Ray scene + all other programs has to fit into you physical memory. As it was mentioned, currently no way. I will have to improve the beveling algorithm to be able to detect such circles and semicircles and bevel them using different technique. This is interesting find, I have seen it on your Flickr account. I will take a look at it. I had similar problem with that winter village scene - the portion with the skate rink took forever. I had to replace the 2 larger transparent 8x8 plates by 128 1x1 plates. Until now it never happend to me, that rendering was really hung-up. But it may happend that the progress in some areas is really slow. I am not sure, if I understand the point of your question. Scene in POV-Ray uses only as much memory as needed for the scene. There is now way to force it to use more memory and render faster by using much more memory. When there is not enough memory, it will not parse the scene or it will render very slowly, but much more memory will not make it faster. It will only let you render much more complex models with that much memory.