 | | | | | | |
| |
|
In lugnet.cad.dev, Lars C. Hassing wrote:
> The LDraw colors are 0-15, 32-47, 256-511 (and of course 16 and 24).
> Paul Gyugyi defined some more colors for LDLite, 17-23, 25, 57
> and "Direct Colors" in the range 0x04000000-0x07FFFFFF.
>
> As MLCad supports these colors, I'm going to add support for them too.
>
> However, Gyugyi packed two RGB's (for dithering) into each Direct Color
> leaving only 12 bits to each RGB, e.g. 0x04RGBRGB.
> Some L3P and L3Lab users have asked for the possibility to specify
> "true colors" (24 bit RGB's), so I would like to define/reserve the range
> 0x02000000-0x03FFFFFF for this.
> 0x02RRGGBB for solid colors and 0x03RRGGBB for transparent.
>
> I will support, but not require, hex notation for colors (0x/0X prefix).
>
> I hope MLCad, LDLite and other tools will support the new range too.
During implementation of Gyugyi's Direct Colors, I browsed his LDLite code:
| if ((c >= 0x4000000) && (c <= 0x7ffffff))
| {
| /Numbers of 0x4000000 to 0x7ffffff are hard coded color values.
| zcp->r = 16 * ((c & 0x00000f00) >> 8);
| zcp->g = 16 * ((c & 0x000000f0) >> 4);
| zcp->b = 16 * ((c & 0x0000000f) >> 0);
| if (c & 0x1000000)
| zcp->a = 0x0;
| else
| zcp->a = 0xff;
| zcs->r = 16 * ((c & 0x00f00000) >> 20);
| zcs->g = 16 * ((c & 0x000f0000) >> 16);
| zcs->b = 16 * ((c & 0x0000f000) >> 12);
| if (c & 0x2000000)
| zcs->a = 0x0;
| else
| zcs->a = 0xff;
| }
and read his doc:
|3. Direct colors
|LDLITE defines the color values from 0x4000000 to 0x7ffffff. These
|represent two 12-bit colors which are dithered together, and cannot
|be redefined. They are intended to be used in converting meshes from
|other 3D formats. While you can use decimal numbers, the hex
|representation makes the structure clear. The edge color for all
|direct colors is pure black.
|
|The first (leftmost, most significant) hex digit defines whether the
|color will be transparent. "4" is an opaque color. "5" or "6" create
|transparent colors. "7" will create an invisible color which will not
|be drawn at all. You can interpret the two least significant bits
|of this digit as inverted alpha values.
|
|The second, third and fourth digits are the red, green and blue
|intensities of the first dithered color. These digits are ignored
|for colors in the ranges 0x5000000 to 0x5ffffff and 0x7000000 to 0x7ffffff.
|
|The fifth, sixth and seventh digits are the red, green and blue
|intensities of the second dithered color. For pure colors, set these
|to the same as the second, third and fourth digits. These digits are
|ignored for colors in the range 0x6000000 to 0x7ffffff.
The code and the doc doesn't match!
If the code is the "truth", then the hex ranges in the last two
paragraphs should be swapped:
|The second, third and fourth digits are the red, green and blue
|intensities of the first dithered color. These digits are ignored
|for colors in the range 0x6000000 to 0x7ffffff.
|
|The fifth, sixth and seventh digits are the red, green and blue
|intensities of the second dithered color. For pure colors, set these
|to the same as the second, third and fourth digits. These digits are
|ignored for colors in the ranges 0x5000000 to 0x5ffffff and
|0x7000000 to 0x7ffffff.
Please decide which to change, the code or the doc.
(FYI MLCad follows the code)
Also I would like to suggest that 16 is replaced with 17 (0x11):
| zcp->r = 17 * ((c & 0x00000f00) >> 8);
| zcp->g = 17 * ((c & 0x000000f0) >> 4);
| zcp->b = 17 * ((c & 0x0000000f) >> 0);
In this way the max color intensity of 15 (0xF) gets mapped to 255 (0xFF)
in stead of just 240 (0xF0).
/Lars
| | | | | | | | | | | | | | |
Lars C. Hassing wrote in http://www.lugnet.com/cad/dev/?n=4187
> (snip)
> During implementation of Gyugyi's Direct Colors, I browsed his LDLite code:
> (snip)
> and read his doc:
> (snip)
> The code and the doc doesn't match!
> If the code is the "truth", then the hex ranges in the last two
> paragraphs should be swapped:
> (snip)
> Please decide which to change, the code or the doc.
> (FYI MLCad follows the code)
Well, Paul, have you decided?
> Also I would like to suggest that 16 is replaced with 17 (0x11):
>
> | zcp->r = 17 * ((c & 0x00000f00) >> 8);
> | zcp->g = 17 * ((c & 0x000000f0) >> 4);
> | zcp->b = 17 * ((c & 0x0000000f) >> 0);
>
> In this way the max color intensity of 15 (0xF) gets mapped to 255 (0xFF)
> in stead of just 240 (0xF0).
What do you think?
/Lars
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev, Lars C. Hassing writes:
> Well, Paul, have you decided?
I just now noticed the thread. (Thanks for the email).
I'll add support for the 24-bit range, it is a good idea.
I'll look into the documentation bug. The code is correct
and I'll change the docs to match.
For the scaling, multiplying by 17 just seems to be
so "impure". On a 16 bit color display, it
produces an unsightly jump in color around 0x7
(jumping by 3 levels rather than 2), but few people
will be doing shading or color gradients by having many
different-colored triangles, so I guess it is OK.
But I can see the problem: any sort of
black and white output will want to see pure white ffffff
and pure black 000000, and anything else would cause
unsightly dithering on a printer.
Luckily a sclae by 17 is just a shift and an add, so the
performance hit will not be much (maybe nothing depending on
how the code pipelines). So I'll change the code to scale
by 17.
Thanks,
-gyug
| | | | | | |
