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