LDraw.org Discussion Forums

Full Version: Colour use
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This is a repost of something I just put up on Flickr. Hopefully this image works; if not, the link to Brickshelf should at least be active...

[Image: colours_complete.png]

Here is something that has been bugging me for ages, and I was wondering if anyone could shed some light on it.

These images show the POV-Ray output for various rendering conditions. Three colour definitions are used - MLCAD standard, LGEO and Koyan's list. For the standard MLCAD colours, POV-Ray checks the list of pre-defined colours (I am assuming this – please correct me if wrong) and uses those, leaving everything else as “color 7” (lt grey). For example, the reddish brown and lt flesh plates are both lt grey, as these are newer colours and not on the standard list. For the modified “solid” and “24-bit” colours, POV-Ray defines each colour itself, rather than referring to a list, so every colour is included. The down side is that they do not look very realistic in POV-Ray, with the exception of the 24 bit colours (I have been using these recently).

When using LGEO, POV-Ray first checks each colour against LGEO's list and then defines that colour if it is not there. However, having done this, it goes on to associate “color 7” with those parts which have colours not on the MLCAD standard list, even though new definitions are available. Again, this can be seen for the reddish brown and lt flesh plates. The same thing happens if you use the “koyancolours” file – apparently all it does is redefine the colours on the standard list, even though it includes many more. Adding new colours to the list does not work, but reassociating existing colours to ones that are not working (e.g. changing a bizzare purple to lt flesh and calling the bizzare purple colour code) does work – the lt flesh plate is now the right colour. Now for the weird bit – if you go into the POV-Ray file and change the remaining “color 7” tags (Koyan added reddish brown to his list, so this plate is no longer an issue) to colours on the koyancolours list, which were the originally intended ones, they come out fine. The case here is the lt and dk bley, colours 71 and 72 – these do not work in standard MLCAD, LGEO or unmodified POV files for koyancolours.

In short, does anyone know why on earth this is happening, or is this a more general concern for how MLCAD does its thing?

Many thanks,

A few questions first, I guess someone with more knowledge of Povray than I have will answer...
- What MLCad version do you use?
- Do you have latest ldconfig.ldr installed?
- What do you use for LDraw -> pov conversion?
Otherwise, your image doesn't work because your Brickshelf folder is not yet public. Could you provide a deeplink in the meantime? (deeplink how-to here)

Sorry, should have included this information before. I am using:

MLCAD v 3.4 (latest), with latest ldconfig (all installed using the new all-in-one installer)
POV-Ray RC 6 (not the latest but RC 8 is very similar)

The computer has just been formatted, so there is no possibility of older versions of these files lingering in the system.

To convert between MLCAD and POV-Ray I simply export the files to a folder and then use L3PAO to generate the .pov file from the exported MLCAD document (by exporting, it removes all references to submodels, which L3PAO cannot handle). This was a method I worked out myself, so it might be the cause of the problem...

Apologies for the poor image link - the URL was to the folder, not the image (I used to make exactly the same mistake on the Classic Space forums, all those years ago). Now fixed.
Chris Beckett Wrote:To convert between MLCAD and POV-Ray I simply export the files to a folder and then use L3PAO to generate the .pov file from the exported MLCAD document (by exporting, it removes all references to submodels, which L3PAO cannot handle). This was a method I worked out myself, so it might be the cause of the problem...
Have you tried LDView Pov export?
As long as LDView is configured to use LDConfig.ldr (which it is by default), LDView's default color output for POV export should match what is in LDConfig.ldr. Note: the option is "Process ldconfig.ldr" in the Colors box of the General tab in LDView's Preferences dialog.
I had the same problem with the "newer" colours. I got everytime a lt. gray result.
But I don't know what I did, it works now on my computer.
There is something in my head, that I changed something in LDraw.ini
Nevertheless nowadays I use only Ldraw for the export.

I'll give LDView a try as an exporter, and see if I can get the colours to work. Thanks for the tips!

I tried the LDView export function, but ran into a few errors. Firstly, the render wouldn't run, as the language version wasn't correct for lg_defs. I corrected this (I think) by including the line "version 3.1" (no quotes). The render then ran, but none of the pieces were visible (LDView version first, resulting POV-Ray image second):

[Image: ldview_01.png]

[Image: ldview_02.png]

Any idea why this might be happening? The parts are declared in the .pov file (as far as I can tell). Interestingly, this .pov file contains all of the correct colour definitions, so it is a stage further on than the MLCAD export errors I began this thread with.

Thank again everyone,

can you please attach the resulting pov file here?
I'm wondering if maybe hits you...
Hi Steffen,

Sure thing - I'll post it as soon as I get back to the right computer. The second issue sounds the more likely, as the .pov renders (although without displaying anything) with the added "version 3.1" line - no \48 problems are reported as errors (although maybe as warnings? I haven't checked out the warnings dialogue). Thanks for all the help!

Are you sure your POV include paths are set up properly for LGEO? Try unchecking the "Use XML mapping file" option in LDView's POV Export Options. That will turn off LGEO so that we can see if that is the source of the problem. If so, we can work on figuring out that problem.
Hello all,

I'll get a .pov code up ASAP, although my computer has picked the perfect time to die. I'll try to get it uploaded this eve.

Thanks again,

Hello all,

Apologies for taking a while to get these files uploaded - my computer is on its last legs. As the files are quite long, even for the few plates used in this example, I have uploaded the files to Brickshelf:


"colors.pov" is the file generated by L3PAO, using the LGEO parts list. To include Koyan's colours, all I do is replace the line "#include "lg_color.inc"" with "#include "koyancolours.inc"" (file "koyancolours.inc" is in the main POV-Ray include folder, and so additional navigation terms are not required).

"colorsld.pov" is the LDView exported pov file, which results in a background showing no parts.

Thank you again!

Sorry for the delay. Your BS folder wasn't public initially, and I just got back to looking at this.

Could you send me colors.ldr? I can't tell what's wrong purely based on the POV file.
Sure thing - how would you like it sending? I can upload to Brickshelf, but again you would need to wait for it to become public.


A .ldr file can be simply attached to a forum post...
Didn't think it would be that easy - should be available now : )
Has anyone had a chance to have a look at this? I have cast an eye over it, but to no avail.

Thanks again, everyone!

Hello all,

I recently upgraded my computer and re-installed all of the LDraw programs, using the all-in-one installer. This time, I was able to export a .pov file to POV-Ray and render it successfully, unlike the last attempt when the pieces did not show up. I did not change any of the export settings, as far as I can remember.

Unfortunately, it does not seem to respond to the substitution of "koyancolours.inc" for "lg_color.inc", which was the process I was using before. Also, the new POV-Ray version language requires a semicolon at the end of every "#define" line in any included code, which requires changes to every part file; this is not a problem per-se, but is time consuming. The main problem now is that POV-Ray is unable to find several parts files despite their "lg_xxxx" being present both in the "lg" subfolder of LGEO (where POV-Ray has been instructed to look for them) and the LGEO xml file in LDView. Clearly, one problem has been solved to introduce many more.

I have uploaded the new LDView-generated .pov file to Brickshelf ("colorsldnew.pov", http://www.brickshelf.com/cgi-bin/gallery.cgi?f=514561, also attached to this post) and a picture of the successful render ("colorsldnew.png") if anyone would like to have a check, or use them for reference if anyone is having a similar problem.

Best wishes to all,