Jump to content
THIS IS THE TEST SITE OF EUROBRICKS! ×
THIS IS THE TEST SITE OF EUROBRICKS!

Recommended Posts

Posted

Got a really frustrating problem with POV-Ray.

Okay, so I've been trying to render a few models with a light source, but have been running into the same problem every time...

14715609870_d64fc0451b_z.jpg1 by Rancorbait, on Flickray,

First, I open LDD2POV-Ray, select my LXF file, and click "Convert"

14902283235_9117048012_z.jpg2 by Rancorbait, on Flickr

Next, I click "Yes" on everything till the POV-Ray window opens.

14715746087_2c554dce84_z.jpg3 by Rancorbait, on Flickr

First problem: POV-Ray doesn't open my file in a new tab. As you can see, the only one there is "Messages" So I have to click "Open" and select the file I wish to render.

14715743677_d38eece663_z.jpg4 by Rancorbait, on Flickr

Now I have selected my file and pasted my light source code.

14901938862_24cfc1b4b0_z.jpg5 by Rancorbait, on Flickr

Now I click "Run" but all i get is this.

And at the bottom corner of the window you can see "Parse Error: Cannot open include file ldd_default_colors.inc"

What am I doing wrong?

  • Replies 879
  • Created
  • Last Reply

Top Posters In This Topic

Posted (edited)

And at the bottom corner of the window you can see "Parse Error: Cannot open include file ldd_default_colors.inc"

What am I doing wrong?

This looks like you did not added \\.\LDDIncludes as a library path to the povray.ini.

LDD2POV when you click "Yes" to start POV-Ray passes lights.ini as a file to POV-Ray. Not the lights.pov. Lights.ini contain also the necessary library path and selected output settings.

If you render using ini file, modification of povray.ini is not necessary.

If you render using pov file, modification of povray.ini is necessary (or you have to add library path using command line arguments to POV-Ray).

Edited by hrontos
Posted

The povray.ini file is a general configuration file of the POV-Ray.

You can access it from Tools menu by clicking "Edit master POVRAY.INI"

You have there somewhere the following line:

Library_Path="\\.\LDDIncludes"

For the other options that are configurable using this ini file, please, check the POV-Ray's help, but for "our basic rendering" you will not need to play with that file at all.

Posted

Anywhere. Order of lines is not important, each setting has to start on a new line like this:

Library_Path="\\.\LDDIncludes"

No space, semicolon or whatever before it.

Posted

It's a bit difficult, what the source of the problem with missing lights. You mentioned that you pasted some own source code for lights.

If you will share it with us, may be we can help you find the source of the error.

Posted

I must have just messed up on the code, because its working now :sweet:

But I noticed that after I stopped it and started it again that the picture was a lot smaller than it was when it had first started rendering. Any idea why? And more importantly, how can I change that?

14912531382_fda6a01d3b_z.jpgLDD2POV-Ray light test by Rancorbait, on Flickr

As you can see, the image quality isn't very good after I stopped it and added the light source...

Posted

LDD2POV generates minimum ini file which contains some output quality settings. When you "render" it, settings will apply.

When you render pov fille directly, quality settings depend on what you selected in POV-Ray's GUI, entered in the ini files etc. That's why your output might be completely different quality and resolution.

Posted

I am building a large scene involving some of my classic space models in LDD and quickly got to the point where changing the decorations on the torsos to the classic space logo became a laborious task.

Add to this a multitude of base plates and the task becomes off putting, especially for simply testing some things.

After loading an alternative file the other day I forgot to change the decorations on the figs and they still rendered with the classic logo and so I did a test.

Firstly I made a simple scene using single parts that required the decorations to be swapped multiple times in LDD to POVRay and allocated the new decorations.

Secondly I did a test render.

setup_file_.jpg

Then I loaded my complex file into LDD to POVRay and without re entering the decorations tab did a render and every instance of the base plates and torsos decorations were swapped to my own.

It seems that LDD to POVRay doesn't compute which instance of the decoration change to apply and so does them all (don't fix this please)

Can anyone verify that this isn't a silly occurrence on my machine, I would hate to rely on it in my workflow only to have it not function later on.

Cheers.

Please, can you share that Classic Space decorations for replacement in LDD To POV-Ray, please? Or any other you have...like grills, arrows etc. as I am looking for such pic files (probably .png) but unable find them anywhere, ah :(:(:(

Posted

Please, is there an option to somehow auto-confirm all those annoying small popup windows dealing with confirmation of overwriting existent files and starting POVRay?

It is quite drag to always click those 4 dialogues all the time manually, gee...I'm going mad about it now! :thumbdown::angry::wacko::devil:

Posted

Yes, of course such feature should be possible.

It is a patience training. If you will complete this training, you have a big chance to hold on also the long rendering times. :laugh:

Posted

Yes, of course such feature should be possible.

It is a patience training. If you will complete this training, you have a big chance to hold on also the long rendering times. :laugh:

Well, being scorpio zodiac sign patience is not one of my favorite features... :grin:

But really, if I understnad it right you are the one "responsible" for this briliant kind of SW, so you could add this simple option, hm? :wink:

Also for some reason under Settings button there are two useful options being greyed therefore not for use (Import settings & Export settings) - why? :look:

Posted

+ I do not know but may it be these are sw bugs? See:

1.) When LDD2Povray makes .pov and .ini files of respective .lxf it places them in the same dir where the .lxf file is, BUT for some reason it places/makes all .pov and .ini files in the directory of one .lxf, probably the first I open (see: when I am testing I normally renders more .lxf one after another without closing LDD2Povray between the sessions...)

2.) If you using your own scene .inc file and there is another one with the same name in directory where LDD2Povray places .pov and .ini file/s for respective .lxf (it happened that for some reason it places them all into one directory) then it uses the one in .pov/.ini directory instead of the "main" one in "includes" folder where it normally should look for it (and actually really it is still looking only there cos when I press the roll menu for Scene .inc files in the sw there are only those ones from the "includes" folder, exactly as it should be but for some reason it acts as I described here)

3.) LDD2Povray indicates POV-Ray "#version v3.6;" in its generated .pov file instead of actually installed v3.7, seems to be hardcoded in you sw, why? :look:

BTW: using x64 version 3.2.110.277 and POV-Ray x64 v3.7.0

Posted

1.) When LDD2Povray makes .pov and .ini files of respective .lxf it places them in the same dir where the .lxf file is, BUT for some reason it places/makes all .pov and .ini files in the directory of one .lxf, probably the first I open (see: when I am testing I normally renders more .lxf one after another without closing LDD2Povray between the sessions...)

Converter tries to maintain the output path and changes only file name. There is no way to guess, if the output file name and it's location has some logic related to input file name. For the first file, converter offers the same directory as the input file name has. From that moment, it assumes that output path and file name was edited/entered/accepted by the user and so for following files only file name is changed directory is maintained. You complain that it should change also the path, because you want have lxf, pov and ini in one directory. Somebody else has lxfs in one directory and wants to have all povs and inis also in one directory. For him is better preset behavior. We can vote and what more people preffer, can be the default behavior

2.) If you using your own scene .inc file and there is another one with the same name in directory where LDD2Povray places .pov and .ini file/s for respective .lxf (it happened that for some reason it places them all into one directory) then it uses the one in .pov/.ini directory instead of the "main" one in "includes" folder where it normally should look for it (and actually really it is still looking only there cos when I press the roll menu for Scene .inc files in the sw there are only those ones from the "includes" folder, exactly as it should be but for some reason it acts as I described here)

This is behavior of POV-Ray. Include files are first taken from the directory where pov file is located, then from the Library_Path in give order (order of Library_Paths is displayed on the messages pane. So files in pov directory have higher priority than any other.

3.) LDD2Povray indicates POV-Ray "#version v3.6;" in its generated .pov file instead of actually installed v3.7, seems to be hardcoded in you sw, why? :look:

Version specified in the pov file is not about version of POV-Ray being used. It is about selecting desired behavior of POV-Ray. POV-Ray actually requires that some version has to be specified. And so 3.6 was chosen. For example handling of background and sky sphere in combination with output transparency seems to be more logical than with 3.7 version settings.

Posted

Converter tries to maintain the output path and changes only file name. There is no way to guess, if the output file name and it's location has some logic related to input file name. For the first file, converter offers the same directory as the input file name has. From that moment, it assumes that output path and file name was edited/entered/accepted by the user and so for following files only file name is changed directory is maintained. You complain that it should change also the path, because you want have lxf, pov and ini in one directory. Somebody else has lxfs in one directory and wants to have all povs and inis also in one directory. For him is better preset behavior. We can vote and what more people preffer, can be the default behavior

First of all: I am not complaining, just making point...so calm down, please...I am not picking fight here, OK? :hmpf_bad:

Next thing: as one did not specify anywhere any special dir for pov and ini files then logic would suggest that if sw creates .pov and .ini in converted .lxf's directory on its own (why exactly there? depending on your logic it could also making them all in includes dir - which would go much more with the sw logic you have specified here - or anywhere it decides to, ah...this way it just messing up user) it means it creates concrete pov and ini in the directory of every converted lxf, not that it has somehow decided putting everything in that directory of first converted .lxf not telling anything about it anywhere and user is then wondering why...I do not know about you but to me it would makes definitely more sense without need of any vote...logic you've said, right? :wink::devil:

I do not want to be taken as/or sound aggressive or anything like that but if someone is playing on me that I do not understand some common logic I need to argue and sometimes it may sound rude, but it is not meant to be like that so if it sounds like that I am sorry (it is probably caused because of the fact that english is not my native language so I would use/describe it better in my native language...which in my case is slovak) :look::blush:

So I hope it is not a problem and that we understand each other well... :sweet:

Posted

First of all: I am not complaining, just making point...so calm down, please...I am not picking fight here, OK? :hmpf_bad:

I am sorry, if you found my answer somehow offending. English is not my mother's language, so it is better not take each word literally. Peter Collins Publishing Ltd. Business Dictionary says about complain: "to say, that something is no good or does not work properly". You found it as a bug, which is normally considered in case of a software as not working properly, so I thought that it is suitable word. But I am once again sorry, if you found it offending.

... depending on your logic it could also making them all in includes dir ...

This should be avoided. When you save files in the same directory as includes, rendering will not work. As we spoke before, files in the same directory as pov file have higher priority and therefore POV-Ray will try to use them directly from disk and they are not readable for POV-Ray. They have to be accessed from \\.\LDDIncludes which is a connection to the virtual file system.

Posted

I am sorry, if you found my answer somehow offending. English is not my mother's language, so it is better not take each word literally. Peter Collins Publishing Ltd. Business Dictionary says about complain: "to say, that something is no good or does not work properly". You found it as a bug, which is normally considered in case of a software as not working properly, so I thought that it is suitable word. But I am once again sorry, if you found it offending.

OK, point taken :wink:

This should be avoided. When you save files in the same directory as includes, rendering will not work. As we spoke before, files in the same directory as pov file have higher priority and therefore POV-Ray will try to use them directly from disk and they are not readable for POV-Ray. They have to be accessed from \\.\LDDIncludes which is a connection to the virtual file system.

It was just an example (although practically a bad one, I agree) wanting to say that I do not see much hard logic in placing all pov and ini in the directory of the first rendered lxf which coverter makes his output dir for its files (pov/ini) comparing to placing them into directory of the converted file itself (and programatically speaking it is quite easy, isn't it?). Cos if it is able to make difference between dirs in which concrete lxf files are then it'd be more natural placing respective pov and ini in those dirs than decide to place them all "hlava-nehlava" in directory of one such lxf file when it was not defined in sw - I think "logical order of things" should always be ahead of "easy way out" tactics, that is all I am saying. :sweet: Looks like sw takes always that easy way...aaah, those AIs! :laugh:

Posted

It was just an example (although practically a bad one, I agree) wanting to say that I do not see much hard logic in placing all pov and ini in the directory of the first rendered lxf which coverter makes his output dir for its files (pov/ini) comparing to placing them into directory of the converted file itself (and programatically speaking it is quite easy, isn't it?). Cos if it is able to make difference between dirs in which concrete lxf files are then it'd be more natural placing respective pov and ini in those dirs than decide to place them all "hlava-nehlava" in directory of one such lxf file when it was not defined in sw - I think "logical order of things" should always be ahead of "easy way out" tactics, that is all I am saying. :sweet: Looks like sw takes always that easy way...aaah, those AIs! :laugh:

The present behaviour is just a simple consequence of two assumptions: 1. when output file name is empty, it is the same as input but with pov extension. 2. when output file name is not empty it is assumed that it was specified by user and it has to be honored as much as possible to avoid "fight with user". Therefore when new lxf is chosen, output path from existing output file name is preserved, but name is taken from new lxf file to prevent file overwrite. It looks like it is not very often used to render many files one by one, so nobody commented. :classic:

Posted

The present behaviour is just a simple consequence of two assumptions: 1. when output file name is empty, it is the same as input but with pov extension. 2. when output file name is not empty it is assumed that it was specified by user and it has to be honored as much as possible to avoid "fight with user". Therefore when new lxf is chosen, output path from existing output file name is preserved, but name is taken from new lxf file to prevent file overwrite. It looks like it is not very often used to render many files one by one, so nobody commented. :classic:

OK, so I take the honor being the first one... :laugh:

I render those "many files one by one" when adjusting my POVRay script, so I need to see how it behaves with different MOCs but with the same settings therefore LDD2Povray is open non-stop, just files are changing (as I have them in their own directories, logicaly, where every directory is one MOC) :wink:

Posted (edited)

QUESTION:

Under Render tab: is there any real quality difference between q9 and q11? If there is no visual difference in final picture, does the rendering take the same time or q9 takes less than q11 although their real output quality is the same?

Edited by bublible

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.

Announcements

  • THIS IS THE TEST SITE OF EUROBRICKS!

×
×
  • Create New...