hrontos

Rendering speed depends on the structure of the POV-Ray scene, used materials, number and types of the lights sources, antialiasing etc. There is no way to speed up the same scene, you have to change some parameters. Good starting point is to turn off antialiasing and render at higher resolution. Multiply width and height by at least 2 - there will be 4 times more pixels to render, but it is faster that POV-Ray's default antialiasing. You can reduce number of light sources or make them shadowless. Transparent parts are slow to render. Smaller transparent parts render faster, so if it is possible replace larger transparent brick by some smaller bricks (for example replace 8x8 plate by 64 1x1 plates - depending on the point of view, there is high probability, that it will not be visible on the output image). More advanced users can make materials (bricks) less reflective since less reflective materials render faster. Render can take anything from few minutes to few days. In the second case I recommend to use the Pause in POV-Ray and Hibernate in Windows to give your computer some time to rest (it is also safer to hibernate the computer when you are leaving home). It is possible to split render to more partial renders by specifying desired starting and ending pixel colum and row. This is usefull to prevent loss of work when render is aborted due to any reason. And also when you need to rerender a portion of an image POV-Ray has also Continue_Trace ini option. When Continue_Trace=On is added to the ini file, POV-Ray will continue aborted render. Useful to prevent going mad when a few days trace is aborted after 90%.

Wow, I knew, that POV-Ray has long history and tradition but I did not expected to meet here anybody who remembers those early POV-Ray times. I hope, you will enjoy also the converter and I am pretty sure, that it is still possible to have some render taking 14 days also today even on i3@2.4GHz. I will be happy, if you share your experience and any comments with us.

I think it looks dusty/dirty because of the white background. Our brain knows that bricks should be white and also knows that background is white. Since the bricks has also some shadows they look dirty. I agree, that they may be need some yellowish tint to avoid that direct comparison with background. Making the material translucent is also possible, but it would increase the rendering time (and I would say dramatically for larger bricks). This image contains colors slightly shifted towards yellow in image editor. Colors looks may be even bit more appealing. I think, that the same effect can be obtained by using more yellowish light since it is almost impossible to have pure white light in real life (temperature of such light source would be extremly high). No, those images are direct output from POV-Ray, using just default (initial) settings. I think, the colors looks so good because there are many colors and human eye has less chance to see imperfections.

1366x768, 1803x1014, 2732x1536 The skating rink took extremly long time when built using two transparent 8x8 plates. I had to replace them by 1x1 plates. The original LXF model was built by yellost and published in this post. I made only small modifications.

I had similar problem with rendering on a notebook. During hot days CPU was more than 85 degC (185degF) and I started experiencing sudden shutdowns. There are some ways how to resolve it: 1. Limit number of parallel rendering threads in POV-Ray. This can be done by adding line "Work_Threads=n" to the generated INI file or +WTn switch to the command line textbox (it is located in POV-Ray's main screen right bellow Queue toolbar button, next to the resolution selection combo box). "n" is the maximum number of parallel threads. Try number of cores detected by windows - 1. 2. Second option in Windows 7 is to go to the Power Management. In the Advanced settings of the power plan there is a section dedicated to CPU. And there is one value named "Maximum CPU State" (or similar, I do not have English version of Win7). This one contains some percentage value - usually 100%. Decrease it to 90% or 85%. This value decreases maximum CPU frequency. 90% worked fine for me and saved me 10 degC (from 85C to 75C). This second approach seems to provide more "finer" settings, but has an influence also on other applications, not only POV-Ray.

This problem actually appears also on the other parts and is related to the fact that some parts are modeled in LDD as not completely closed volumes. To illustrate what does it means imagine a new part that looks like three cubes joined together - middle cube is smaller. In the LDD such part is modeled as 2 bigger cubes and the middle cube is not modeled as a cube, because it has only 4 wall visible. In LDD geometry those 2 invisble walls are omitted and the middle cube has only 4 walls. POV-Ray treats this cube as empty (as having only "paper" walls) and not as solid (filled) object. When such part is beveled and sharp edge is removed, what you get is exactly the same as in case of paper cube - a hole into empty cube. Technic 2M Axle Notched is modeled this way. One some parts this issue can be elminated by specifying different inside vector. Inside vector is used by POV-Ray to check what is inside of a shape and what is outside - for a given point within shape it calculates number of walls crossed by this vector - even number of crossed walls means outside, odd number means inside (like shooting a bullet - when bullet goes through first wall, it is inside, when second, it is outside). In case of those 3 cubes, when inside vector goes in direction from first to third cube it obviously returns to POV-Ray that when reaching second cube, even number of walls was crossed (only the 2 walls of the first cube) so inside of the second cube is outside from the POV-Ray point of view. If the inside vector was perpendicular to the previously mentioned one, number of walls crossed (intersected) by this vector would be correct and whole shape, all cubes would be treated as completelly closed volume. I will try to specify manually inside vector for most commonly used bricks having this problem. As far as I know, from commonly used bricks the technic beams have this problem. If you want to test this POV-Ray behavior modify ldd_inside_vector. #declare ldd_inside_vector = <0,0,1>; is the current declaration. For some parts disabled beveling or manual modelling will be the only solution.

Version 1.2 released. Change list: added new holes to the backside of some bricks as proposed by Superkalle - pin hole not configurable through gui yet corrected wrong shading of flex bricks as reported by bbqqq corrected bug in the reading of the default settings - output resolution was not read

This one already contains those holes (only on three bricks, but they are there). 1366x768, 1803x1014, 2732x1536 This is one of my favorite models. I think that for 7 years old boy this is a very nice toy, because it is a dinosaur, walking dinosaur, remote controled walking dinosaur and best of all it is a remote controled walking dinosaur made of LEGO so kids can build it themself. It not that much creator, may be more technic, but at least it shows, that technic does not necessarily means machine.

Yes, this is possible without problems, just how to name that checkbox. Everybody knows what is a stud, but I am not sure how to name that pin so that everybody knows what are we talking about. May be a small preview image of some default standard brick featuring all these details would be helpful for the user. As the user will change level of detail or activates this and similar checkboxes, preview image would change.

Yes, it looks better with those small holes. I have found 355 bricks, that have that "pin" you mentioned (and asked for a hole in that pin), but I am pretty sure, not all of them should have the pin with hole. Some of them should have the pin without the hole. To be honest, I did not tried to sort them out, because it probably means to look at each physical brick. I am not sure if Bricklink can help, since images there are usually from the top and not from the bottom. The other added holes are only under standard studs and not technic studs.

I am sorry, if I missed something. You are making a LEGO game and you need a high-quality authentic minifigure for animation. First of all, I would say, that when I am making a game, the effort needed to recreate a minifigure in some suitable modeling tool is only a fraction from the effort needed to create whole game. So why don't you create your own? As a second point, LDD is using simplified geometries, which are not very accurate when looking to closely so it does not fulfil the "high quality" requirement. And as a final point: minifigure is copyright protected design, you cannot use it for any purpose without permission from LEGO.

Is this what you expected?

Haha, may be we should move to higher level and add another field into the LDD2POVRay screen where user can specify a production year. Like make my render look like from 1980. Just kidding. Seriously, it is no problem to take care of these differences when two versions of the same looking brick have two different design IDs. When there is only one, it is possible, but probably too complicated and too much detailed for a standard LDD user.

OK, now I understand which one. Yes, it should be possible to add also that one. It is just less automatic, because it is necessary to specify exactly which bricks have it, since LDD categorization won't be sufficient. Once it is know, that some brick should have it, exact location of that hole can be determined automatically.

Yes, this shouldn't be a problem since there is a direct relation between a stud and a hole - all studs with logo have that hole (I think not only 1xX bricks and plates).

Thank you for sharing, I will try them. The "Custom" block used by LDD2POVRay looks like this. As I said, it is faster than Final and not that bad for most cases. I tried to find a settings which will not make an average user loose his patience. radiosity { pretrace_start 0.08 pretrace_end 0.005 count 450 nearest_count 4 error_bound 0.05 recursion_limit 1 low_error_factor 0.3 gray_threshold 0.0 minimum_reuse 0.005 //maximum_reuse 0.2 brightness 1 adc_bailout 0.005 normal on media on } @Smartiac: if you want to give it a try, replace the radiosity block in the POV file by the one proposed by C3POwen and render the brickley once again. It possible to render only a portion of an image, if you want

I also think that it is due to radiosity settings, that's why I asked which were used and what is the material. Yes, there is a possibility to use those POV-Ray's built in settings. User can select it from a combo, but the default option is "custom" which generates complete radiosity block into POV file. This radiosity block contain settings which perform quite well for most of the models and are much faster than built in Radiosity_Final settings.

I have seen this picture on your Flickr. Nice model, my kids would love it. And a nice render. What is the material for the eyes? Is it some mettalic? What radiosity settings did you used?

This related to the projection and perspective. Perfect fit strongly depends on them, but you can scale it as you proposed. Yes, you are right, max should be calculated only from the other two dimensions. I already corrected the example.

Thank you for sharing. 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.

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.

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.

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. 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. 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.

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.

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?