calling for color clarification

[ouattwtym]

I think that ...

The example code at http://www.opengl.org/resources/faq/technical/color.htm is wrong. Consider the case where the loop tries to walk all colors i.e. when numPrims is 2^(redBits+greenBits+blueBits). In this case it never submits the largest representable value (e.g. 0xffffffff). It only submits the largest color component shifted up to the top of the integer (e.g. 0xff000000). Consequently it never reaches full intensity because, as http://linux.die.net/man/3/glcolor3ui says, "Unsigned integer color components, when specified, are linearly mapped to floating-point values such that the largest representable value maps to 1.0 (full intensity), and 0 maps to 0.0 (zero intensity)."

... do we agree?

[Fool Running]

What it looks like to me (granted I haven't actually tried it):
indx will go from 0 to numPrims (where numPrims could be the max color value 2^(redBits+greenBits+blueBits))
In 32 bit mode (8 bits per color), the masks used will get only the first 8 bits of indx.
The red color will be shifted by 8 bits, the green by 16 bits, and the blue by 24 bits.

So it looks like you're correct. None of the values will reach full intensity (and everything will be blue).
As a matter of fact, I can't see how having numPrims more then 256 could work (it would repeat the color of the previous ones).

[ouattwtym]

Each of the shifts is enough to get the color component up to the top of the word. The bits are masked off from the color number indx in-place and then shifted up as far as they need to go to abut the top of the word. Weird way of doing things, perhaps, but that all works fine. For 24bit color (8bits per component) you end up with:

0xRR000000
0xGG000000
0xBB000000

So that bit is all fine. It is just that, if the Linux manpage I cite is right (and my experimentation indicates that it sure is), then that isn't enough. What you need for calling glColor3ui (or any of its similarly named friends) you need:

0xRR0RRRRRR
0xGGGGGGGG
0xBBBBBBBB

(in 24bit color you might not be able to see the difference but in 16bit color you will because 0xF8000000 is not so near to 0xFFFFFFFF)

My main point though is that http://www.opengl.org/resources/faq/technical/color.htm and http://linux.die.net/man/3/glcolor3ui cannot both be right. The one that is wrong is http://www.opengl.org/resources/faq/technical/color.htm. I think I'm going to try and get them to fix it as it really confused me for a while.

[ouattwtym]

I've taken this to
http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=293077

[broumbroum]

I don't agree, the red book example seems to be correct. "Unique colors" are defined as the highest number of colors that have distinct values. a 24 bits color scheme will give 8 bits for each component, that's 2^8 for red, 256 reds ! let one primitive (num prims equal 1) be : and you have a light mask(1 & FF = 01 for each component) let 12 be and you have all up to an average : 1100 &  FF= 0C for each). etc.
that means renderPrimitive(indx) will modulate to kind of a full spectrum colors when numPrims reaches the 2^number of bits (24 bits => 16 Millions of "unique colors").