Part color issue

[Michael Horvath]

So, this calculation holds true for all unnamed colors, dating back to many years ago?

Also, is there a full list somewhere I can look at? I want to anticipate future problems.

I'm not exactly sure what you mean by "all unnamed colors", or what you mean by a full list. The calculation holds for all color numbers between 256 and 511.

In James Jessiman's LDRAW.EXE, all colors from 256 to 511 were "dither colors". They were called that because they used a 50/50 checkerboard dither pattern, where one color number in the pattern was computed using (color - 256) / 16 (truncated), and the other was computed using (color - 256) mod 16. (Note that 16 of these dither patterns exactly match the color numbers from 0 to 15, since both colors in the dither pattern are the same, and half of them are nearly indistinguishable from the other half, since simply swapping the two colors in the checkerboard pattern is something that is difficult to see visually.)

When I originally wrote LDView (in 2000), I simply calculated the average of the two colors instead of displaying a dither pattern, since the dithering was really an artifact of the fact that LDRAW.EXE was program that was only capable of displaying 16 colors. I don't remember if LDView was the first program to do this, or if I copied the behavior from some other program. (It doesn't really matter.) Most (if not all) LDraw-compatible programs behave this way now.

Later on, other color standards were introduced. For reasons that I never have understood, one early standard was 12-bit dither colors. These were dithers of two different 12-bit colors, and they look like this in hexadecimal: 0x4RGBRGB. They also have transparent versions: 0x5RGBxxx, 0x6xxxRGB, and 0x7xxxxxx (where x is ignored, but considered to be 100% transparent). (Yes, if you use any color number from 0x7000000 through 0x7FFFFFF, you get a completely invisible color.)

Finally, true RGB colors were added: 0x2RRGGBB for opaque and 0x3RRGGBB for transparent, where transparent means "LEGO transparent", or about 50% transparent. These RGB colors are what are allowed in the pattern portions of pattern and sticker parts.

When LDConfig was first created, it was decided that new colors would use the number from the closest available dither color. This (hopefully) explains the seemingly odd nature many of the LDConfig color numbers, and why those numbers are so patchy.

I'm not sure what to do in POV-Ray when I encounter these colors in a model. Somehow build variable names and convert them to declarations?

[edit]

Never mind. The correct solution is to change the colors to legal values in MLCad. And download replacement parts from the parts tracker.