LDraw.org Discussion Forums

Full Version: Really Big Colour Code: 117313504
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3
I am working on an import feature for LDraw models, and when I tested it on the Front End Loader model that comes with the LDraw download (model 8464.mpd), I encountered a line with a very large colour code:

0 FILE 8464.ldr
0 Front End Loader
0 Version: 1.0a (20071123)
1 117313504 -125 -208 -400 0 0 1 0 1 0 -1 0 0 3941.DAT

In LDraw, the part looks like this:
[Image: eo0J5.png]

I thought it might be a blended colour, like the filespec would suggest, but the colour code is still too large for that. What is this colour, and how do I interpret it?
That color really probably shouldn't be in use in that model (which is an LDView sample model, created by Peter Bartfai, LDView's Qt version maintainer). However, it's a transparent direct dither color. If you can read C++ code, you can take a look at LDView's color number processing code in this file, starting at line 462. The code for 0x6xxxxxx color codes starts at line 525.

Here are the "special" colors that LDView handles, all of which have been used at some point in the past:

0x2RRGGBB: opaque RGB direct colors
0x3RRGGBB: transparent RGB direct colors
0x4RGBRGB: opaque RGB dither color (RGBRGB are two 12-bit colors)
0x5RGBxxx: transparent RGB dither (xxx is ignored and treated as fully transparent)
0x6xxxRGB: transparent RGB dither (xxx is ignored and treated as fully transparent)
0x7xxxxxx: invisible

Only 0x2RRGGBB opaque direct colors are officially supported in the spec, and they're only there because the LSC at the time wanted to allow those to be used in patterned parts. Personall, I think that the others should at least be mentioned, even if they are continued to be disallowed in official parts. Note, for the 0x4, 0x5, 0x6, and 0x7 numbers above, the bottom two bits in the 5, 6, and 7 can be thought of as ignore bits for the two components of the RGB dither. When a bit is set to ignore one of the components in the RGB dither, that component is treated as fully transparent.
One note, when you convert from 12-bit up to 24-bit in order to do the dithering, make sure to multiply each 4-bit component by 17, and not 16, because the maximum 4-bit value is 15, and 15 * 17 = 255.
Thanks, I managed to get that working. I implemented everything that was in that section of the source file that you linked me, except for the first branch that checks for custom colours (getCustomColorInfo). Is that for when the "0 !COLOUR" metacommand is used somewhere other than in the config file?

If I have implemented all of the "special" colours that you listed, do I additionally have to worry about the Blended Colours, or is that subsumed by what I have already added?
The "custom colors" in question are ones defined by "0 !COLOUR" (generally in ldconfig.ldr). LDView doesn't do a good job with these, treating them all as global, no matter where they appear.

You still need to deal with "blended colors" (colors with numbers between 256 and 511). LDView does that in LDLPalette::initDitherColors(). This is done using hard-coded values for the first 16 colors, so redefining color 12 won't affect the blended colors based on color 12.
This has historically proven contentious, but in my opinion (and as the spec is currently worded), you don't need to worry about either dithered colors or any direct colors other than ones beginning with 0x2. Color dithering was an extremely messy solution to a technical limitation which no longer exists. Nowadays, the dithered color range conflicts with LDConfig !COLOUR definitions, so if you support dithers, make sure to check for an LDConfig code first, as they have precedence.

Also, direct colors based on dither algorithms were never standard. They passed about by obscure tribal knowledge. I seem to have even missed 0x6 and 0x7, as my code doesn't even mention them.

If you really must support dithers, my C code to calculate RGB for dithered colorcodes is here, on Line 273. You even get bonus color commentary with the code.

I would suggest at least supporting the 0x3 ones, which are just 50% transparent versions of the 0x2 ones. IIRC, the only reason that the 0x2 ones made it into the spec was because people were clamoring for RGB colors for use in official patterns. I think I pushed for inclusion of the 0x3 ones also but was overruled (although I could be mistaken about all that).
I agree - I'd like to see the 0x3..0x7 encodings documented somewhere - perhaps as an 'informative' section in the official specs? We co-opted LDLite's syntax, we should acknowledge this.

Having attempted to implement support for these codes myself, I also had to do a lot of digging to find a useable spec - and it doesn't help that of the two main places on the net which do document it, one of them is completely and utterly wrong!
Which one is
completely and utterly wrong

Please note it here, so we will have an eye on that document.
Ah-ha! It's been fixed since I first found it :-) As you were...
Pages: 1 2 3