455 replies to this topic

[SearchFunction]

hrontos, on 08 July 2012 - 10:36 AM, said:

This means, you are directly accessing the bin includes.

Your Library Path in POV-Ray should contain Library_Path=\\.\LDDIncludes and not direct path to the includes folder.

And of course LDD2POVRay must be running while POV-Ray parses the scene.

The path makes no difference. I´ve tried having them both and each seperately. Why must the converter program be running after conversion? Didnt make any difference though. I still get the same error. Message log:

Preset INI file is 'C:\DOCUMENTS AND SETTINGS\SF\DOKUMENTER\POV-RAY\V3.7\INI\QUICKRES.INI', section is
'[512x384, No AA]'.
Preset source file is 'C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools\TESTRENDER.pov'.
Rendering with 2 threads.
Parser Options
  Input file: C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools\TESTRENDER.pov
  Remove bounds........On
  Split unions.........Off
  Library paths:
    \\.\LDDIncludes
    C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools
    C:\Documents and Settings\SF\Dokumenter\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:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools\TESTRENDER.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
-
"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.95 seconds.
----------------------------------------------------------------------------

[hrontos]

Lego Otaku, on 08 July 2012 - 08:36 PM, said:

But from POV shows a couple oddities likely caused by 3mm hose.

Yes, those are the flex parts. LDD2POVRay does not convert their flex data during conversion so they behave as standard parts. It is better to have them removed in LDD before conversion.

Otherwise a nice render - I would say that this kind of view would deserve activated focal blur to make it look more realistic - focal point is on the brick that is selected in LDD as a center of camera rotation (the brick camera is looking at).

SearchFunction, on 08 July 2012 - 08:38 PM, said:

The path makes no difference. I´ve tried having them both and each seperately. Why must the converter program be running after conversion? Didnt make any difference though. I still get the same error. Message log:

Preset source file is 'C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools\TESTRENDER.pov'.
Rendering with 2 threads.
  Input file: C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools\TESTRENDER.pov
  Library paths:
    \\.\LDDIncludes
    C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools
    C:\Documents and Settings\SF\Dokumenter\POV-Ray\v3.7\include
    C:\WINDOWS\Fonts
-
"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.95 seconds.
----------------------------------------------------------------------------

The LDD2POVRay Converter must be running, because the virtual path \\.\LDDIncludes exists only while it is running.

I think, in your case the problem is, that you stored you POV file in the same directory as you have specified as target directory for the POV-Ray includes (both are C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools). This does not work, because when POV-Ray looks for the include files, it by default searches the directory where the POV scene file is stored. After that it searched Library Path. This means, that regardless of you Library Path it finds directly the binary includes.

Please, store your POV files in different directory than the include files generated by LDD2POVRay.

And please, remove the C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools from Library Path it is not necessary there.

Thank you.

[Seluryar]

Here is my first successful try at this program:


but I feel that it could look better/more realistic. any tips on correcting this?

I wish to achieve something like user bbqqq's Sopwith Camel posted on the first page of this topic

Edited by Seluryar, 09 July 2012 - 03:31 AM.

[hrontos]

Seluryar, on 09 July 2012 - 01:21 AM, said:

I feel that it could look better/more realistic. any tips on correcting this?

I wish to achieve something like user bbqqq's Sopwith Camel posted on the first page of this topic

It looks like you rendered it with outlines enabled. Click on the settings button and select Reset to initial. After that you can convert it once again and render it. Sopwith Camel had one more difference in comparison to "initial settings" - it was rendered with lights set to 23% and not 40%. Outlines were added as a feature for building guide style images (or coloring pages, if you have small kids - I agree that it is a bit odd to use renderer to produce white coloring page, it was just easy to add as a feature.  ).

Otherwise I would say, this picture looks still very nice, even with outlines enabled.

EDIT: The light settings on this rendering seems to be ok, so you can use the same, just remove outlines. It should be enough to delete these two declarations from your existing POV file:
#declare ldd_outlines = 2;
#declare ldd_white_outline_treshold = rgb <0/255,0/255,0/255>; // your values might be different

Edited by hrontos, 09 July 2012 - 06:12 AM.

[SearchFunction]

hrontos, on 08 July 2012 - 08:53 PM, said:

I think, in your case the problem is, that you stored you POV file in the same directory as you have specified as target directory for the POV-Ray includes (both are C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools). This does not work, because when POV-Ray looks for the include files, it by default searches the directory where the POV scene file is stored. After that it searched Library Path. This means, that regardless of you Library Path it finds directly the binary includes.

Please, store your POV files in different directory than the include files generated by LDD2POVRay.

And please, remove the C:\Documents and Settings\SF\Skrivebord\LEGO\LDD Tools from Library Path it is not necessary there.

Thank you.

Okay I just had a succesfull render. Here is what I did: After hitting the "convert" button in LDD2POVRAY, BIN files and POV files are created in the output folder. I then made another folder, and moved the pov file into it.
Then when opening the pov file from the new directory in POV-Ray it was able to render succesfully.
I am new to both programs so I guess there is an option to tell LDD2POVRAY to put the two types of files in two different directories? It seems counter intuitive to have to move the files manually afterwards. Or maybe its simply a function of Windows XP as opposed to newer operating systems?
Anyway thanks, off to do some renders!

[hrontos]

SearchFunction, on 09 July 2012 - 07:20 AM, said:

Okay I just had a succesfull render. Here is what I did: After hitting the "convert" button in LDD2POVRAY, BIN files and POV files are created in the output folder. I then made another folder, and moved the pov file into it.
Then when opening the pov file from the new directory in POV-Ray it was able to render succesfully.
I am new to both programs so I guess there is an option to tell LDD2POVRAY to put the two types of files in two different directories? It seems counter intuitive to have to move the files manually afterwards. Or maybe its simply a function of Windows XP as opposed to newer operating systems?
Anyway thanks, off to do some renders!

I am glad we found the source of your problems.

Of course, it does not make sense to store converted models and includes in the same directory.
Include directory may contain up to 2500+ files (one for each used type of brick) and to store models together with the includes is a mess.

That's why you have an option to set the include path using the Settings button and select the last menu item - Setup Paths. Specify an Include Path, that is different from your desired model location. Includes will be generated into that directory. You will never need to access it manually open any file manually from there, so it can be anywhere on your disk, not necessarily in your My Documents (I personally created folder LDDInc as subfolder in the folder where db.lif is located).

Model is by default converted to the same directory where the LXF file is located, so if you have some location where you store your model, do not set Include Path to that directory.

After that you will have one directory for includes and some other directory where you store LXF files and where converted model POV files will be stored.

[Reventist]

Hi, having a little trouble with the rendering. Message log:

Parsing Options
  Input file: C:\Users\Homepc1\Documents\LEGO Creations\Models\CarFrame.pov (compatible to version 3.62)
  Remove bounds........On
  Split unions.........Off
  Library paths:
    \\.\LDDIncludes
    C:\Users\Homepc1\Documents\POV-Ray\v3.6\include
    C:\Windows\Fonts

File: \\.\LDDIncludes\ldd_default_colors.inc  Line: 20
Possible Parse Error: Could not find file 'ldd_colors_declarations.bin'
File: \\.\LDDIncludes\ldd_default_colors.inc  Line: 20
File Context (5 lines):
#include "ldd_colors_declarations.bin"

#declare ldd_colors[1] = rgb <255/255, 255/255, 253/255>;
#declare ldd_colors[2] = rgb <135/255, 136/255, 122/255>;
#declare ldd_colors[3] = rgb <255/255, 216/255, 105/255>;

Parse Error: Cannot open include file ldd_colors_declarations.bin.
File: \\.\LDDIncludes\ldd_default_colors.inc  Line: 20
Parse Warning: Check that the file is in a directory specified with a +L switch or 'Library_Path=' .INI item. Standard include files are in the include directory or folder.

I've followed the setup instructions, inserted the Library_Path="\\.\LDDIncludes" line into the .ini file, and made sure that POV-Ray files are not in the same folder as the generated include files. I can't get it to render my model, and I'm not at all sure what I'm doing wrong, so I could use some help with this...

[hrontos]

Reventist, on 09 July 2012 - 11:07 AM, said:

    C:\Users\Homepc1\Documents\POV-Ray\v3.6\include

This line looks like you are using POV-Ray 3.6. You need POV-Ray 3.7, RC3, RC5 or RC6 from the POV-Ray's beta test page.

[Reventist]

hrontos, on 09 July 2012 - 11:39 AM, said:

This line looks like you are using POV-Ray 3.6. You need POV-Ray 3.7, RC3, RC5 or RC6 from the POV-Ray's beta test page.

Thanks. That did the trick.

[Smartiac]

Preset INI file is 'C:\Users\nathan.proudlove\Documents\POV-Ray\v3.7\ini\quickres.ini', section is
'[512x384, No AA]'.
Preset source file is 'C:\Users\nathan.proudlove\Desktop\testmodel.pov'.
Rendering with 4 threads.
Parser Options
  Input file: C:\Users\nathan.proudlove\Desktop\testmodel.pov
  Remove bounds........On
  Split unions.........Off
  Library paths:
    \\.\LDDIncludes
    C:\Users\nathan.proudlove\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:\Users\nathan.proudlove\Desktop\testmodel.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
Possible Parse Error: Cannot find file 'ldd_default_colors.inc', even after trying to append file type
extension.
-
"C:\Users\nathan.proudlove\Desktop\testmodel.pov" line 10: Parse Error: Cannot open include file
ldd_default_colors.inc.

Render failed
-
CPU time used: kernel 0.02 seconds, user 0.00 seconds, total 0.02 seconds.
Elapsed time 0.45 seconds.
----------------------------------------------------------------------------

Any ideas on what's going wrong for me here?

Edit: Never mind. Apparently it works now. Thanks for all the help.

Edited by Smartiac, 09 July 2012 - 06:16 PM.

[Mikey.]

Hey,

I have to say, this gave me a lot of motivation to get back to LDD, which is great!    
Anyhow, this is the first render I managed to complete, but the quality of the image isn't that great, so can anyone give me any tips on how to improve it?



Thanks in advance!

Mike.

[Lego Otaku]

Try using AA.  There is a drop down menu below File and Edit menu that offers various resolution sizes, select one with AA. Otherwise you'd get jaggies.

[hrontos]

Smartiac, on 09 July 2012 - 04:23 PM, said:

Edit: Never mind. Apparently it works now. Thanks for all the help.

I am sorry for not replying earlier, your settings are correct, I just assume LDD2POVRay was not running when the rendering was started and POV-Ray needed to parse scene.

Edited by hrontos, 09 July 2012 - 07:32 PM.

[hrontos]

Lego Otaku, on 09 July 2012 - 06:52 PM, said:

Try using AA.  There is a drop down menu below File and Edit menu that offers various resolution sizes, select one with AA. Otherwise you'd get jaggies.

Yes, the antialiasing is almost obligatory to get rid of those jagged(aliased) edges.

Another technique how to avoid antialiasing in POV-Ray and still get nice edges is to render without antialiasing but at higher resolution. For example, if your desired output image size is 800x600, render it at 1600x1200 or at 2400x1800 or at 3200x2400. Then use picture editor, that supports bicubic image resizing (like PixBuilder, which is free) and resize image down to desired size.

From my experience it is not enough to resize down to 50%, it should be 33% or 25%, which means, you should render at least at 2400x1800 (when resized down to 33%, you get 800x600) or at 3200x2400 (when resized down to 25%, you get 800x600).

If your desired resolution is not in the mentioned drop down bellow File and Edit menu, follow these steps:

1. From Tools menu in POV-Ray select "Edit resoultion ini file". Text editor opens with file containing one section for each defined resolution.
2. Add new section using square brackets, between brackets is the name of the section. Name can be anything, POV-Ray will not try to understand it, it will be just displayed in that drop down.

For example: [3200x2400, No AA] or [My Best Favorite Resolution]

3. Bellow the section name should be definition of the parameters for that section. Common parameters are Width, Height, Antialias, and Antialias_Threshold. There are much more, but for this case those are enough. Define value for each of these parameters.

For example, when you want to get image 3200x2400 without antialiasing you should define these lines in you new section:
Width=3200
Height=2400
Antialias=Off

So complete section will look like:

[3200x2400, No AA]
Width=3200
Height=2400
Antialias=Off

When you want to enable very fine antialiasing, you should define:
Antialias=On
Antialias_Threshold=0.1

or

Antialias=On
Antialias_Threshold=0.0

So the complete section will look like:

[3200x2400, AA 0.0]
Width=3200
Height=2400
Antialias=On
Antialias_Threshold=0.0


4. Save the file.
5. To make the new resolution appear in drop down, go to Render menu a select Edit Settings/Render.
6. POV-Ray render settings dialog will open, select your new section from the drop down and click on the Render button or Set but don't render (when you want to start rendering later). From this moment the new resolution will appear also in the drop down bellow File and Edit menu.

[Mikey.]

Thank you for the info! :)
I'm rendering again at the moment, at least for now it seems to be a bit better then before.

I tried rendering at 1024x768 but it took way too long for my patience. Of course, I'm not sure, what are the average rendertimes for POVray.

[hrontos]

Mikey., on 09 July 2012 - 07:47 PM, said:

I tried rendering at 1024x768 but it took way too long for my patience. Of course, I'm not sure, what are the average rendertimes for POVray.

Well, it mainly depends on the number of lights and transparent parts. Other important factors are level of detail, types of used bricks, number of bevels and size of the model.

And you get anything from few minutes to few days. It can be from few thousand pixels per second to few hundreds pixels per minute.

Parsing is influenced by level of detail (LOD) and types of bricks. LOD containing all bevels parses faster, but requires more memory, LOD containing only visible bevels takes longer to parse (because for each brick it is necessary to calculate which bevels are visible), but requires less memory. But. When rendering at high resolution, it may happen that all bevels are considered to be visible so it is better to use LOD containing all bevels.

[Seluryar]

How does part count play a role in how long a render takes?

I was under the impression that a file with alot of parts would take less time to render, But I was wrong as this file seemed to have taken all night to render:

But, it seems to have taken as long as a version of my earlier helicopter I posted in this topic that I am currently re-rendering with all bevels and Lego logo on studs

Should I choose the option for visible bevels instead of all bevels for quicker render?

[hrontos]

Seluryar, on 09 July 2012 - 08:59 PM, said:

How does part count play a role in how long a render takes?

I was under the impression that a file with alot of parts would take less time to render, But I was wrong as this file seemed to have taken all night to render:
But, it seems to have taken as long as a version of my earlier helicopter I posted in this topic that I am currently re-rendering with all bevels and Lego logo on studs

Should I choose the option for visible bevels instead of all bevels for quicker render?

There is no direct relation between render time and number of parts. The Tower Bridge has 4000+ parts and rendered much faster than the Winter Village Post Office with only 700+ parts. Transparent parts take much longer to render.

The outlined helicopter is bigger model but it rendered faster (or the same time), because outlined models are not beveled. Outlines render faster than bevels.

When rendering high-res (like 3000x2000) it does not make sense to use "only visible bevels", since on such resolution all bevels are visible. On such big picture all bevels and gaps between bricks are visible.

Of course, if the model is large and some portions are far away from camera, their bevels are not visible. With "only visible bevels" they will be eliminated and those bricks will render faster than with all bevels added. But parsing will take longer.

EDIT: I like that render. The top light should possibly have less intensity, but otherwise a nice image.

Edited by hrontos, 09 July 2012 - 09:15 PM.

[Seluryar]

That cart I rendered overnight, I started that before I saw a reply to one of my posts about lowering the light intensity, I am working on a similar helicopter to the one I first posted in this topic and its approaching 7 hours 40 minutes, but its at 99% now so it should be done soon, but, from the looks of it, I should have done it at a larger resolution as i see some jagged edges on it already as i used 1024x768 AA 0.3

[hrontos]

Seluryar, on 09 July 2012 - 09:58 PM, said:

That cart I rendered overnight, I started that before I saw a reply to one of my posts about lowering the light intensity, I am working on a similar helicopter to the one I first posted in this topic and its approaching 7 hours 40 minutes, but its at 99% now so it should be done soon, but, from the looks of it, I should have done it at a larger resolution as i see some jagged edges on it already as i used 1024x768 AA 0.3

Excelent, looking forward to see it.

Looks like POV-Ray's antialiasing is not producing very good results with LEGO bricks even with AA 0.1 or 0.0. Transparent bricks have even more problems with that antialiasing. That's why I also decided to follow advices of some more experienced people rendering LEGO models and now rendering high-res without AA and resizing down to 25-50%.

[Seluryar]

hrontos, on 09 July 2012 - 10:04 PM, said:

Excelent, looking forward to see it.

Looks like POV-Ray's antialiasing is not producing very good results with LEGO bricks even with AA 0.1 or 0.0. Transparent bricks have even more problems with that antialiasing. That's why I also decided to follow advices of some more experienced people rendering LEGO models and now rendering high-res without AA and resizing down to 25-50%.

Here is the result of the last 8 hours of rendering:


I will try and render at high res without AA tonight

[hrontos]

Seluryar, on 09 July 2012 - 10:18 PM, said:

Here is the result of the last 8 hours of rendering:
I will try and render at high res without AA tonight

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.

Edited by hrontos, 10 July 2012 - 12:03 AM.

[Seluryar]

I used JPG on purpose for the sake of my image hosts monthly bandwidth limit, But I am uploading the PNG to deviant art and then later, possibly to my brickshelf account.

[Lego Otaku]

10221 at 800x600 with 0.3AA, took about 30 minutes to load and calculate individual parts and 50 minutes for rendering.  Rendering is a lot faster with AA off though and I'll probably stick to higher res, non AA'd as explained above.

[hrontos]

Lego Otaku, on 10 July 2012 - 05:27 AM, said:

10221 at 800x600 with 0.3AA, took about 30 minutes to load and calculate individual parts and 50 minutes for rendering.  Rendering is a lot faster with AA off though and I'll probably stick to higher res, non AA'd as explained above.

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.