PDA

View Full Version : Using more than 8 bits to specify color



vladlen
09-12-2002, 02:16 PM
I would like to use an OpenGL buffer as an auxiliary for a geometric algorithm. My algorithm renders a large number of rectangles on an initially black background (all pixels have value 0), such that each rectangle _increases_ the value of the pixels inside it by 1. So I would like a pixel on which 1,000 rectangles were drawn to have value 1,000. I am aware of the 'blending' functions for the color buffer, and of the 'increase' functions for the stensil buffer, but I am not an expert. In particular, I do not know how to get to values larger than 255 (8 bits in the stencil buffer, or in one field of color, like red, in the color buffer). Can I somehow implement the above algorithm so that it will be able to use values in the range of _millions_ - in other words, render millions of rectangles with correct values in the buffer?

Thank you very much,
Vladlen

V-man
09-12-2002, 03:58 PM
1. If you use the accum buffer, you automatically get 16 bits per component, so that's something.

2. Another method would be via pbuffer: create 1 buffer and render only 255 rectangles in each. Retreive all the buffer and do some arithmetic yourself, and continue like that.

3. Perhaps fragment shaders have a means to setup this kind of functionality. I dont know much about them so ...

4. If you can get a 32 bpp stencil on your hardware, you are set.
V-man

Nakoruru
09-12-2002, 05:37 PM
You could get around 1024 levels by drawing 255 rectangles to each channel. I assume you are going to download the image anyway, so a little post processing on the image should not be bad, especially if you issue the commands to draw the next 1024 rectangles before adding up the color components (while the CPU is crunching the image, the GPU can be busy drawing another 1024 rectangles).

1. Draw 255 rectanges in using Colorbu(1,0,0,0)

2. Draw 255 rectanges in using Colorbu(0,1,0,0)

3. Draw 255 rectanges in using Colorbu(0,0,1,0)

4. Draw 255 rectanges in using Colorbu(0,0,0,1)

5. Download the framebuffer

6. Repeat steps 1 - 4

7. Accumulate all the color components into your count buffer (doing 6 allows the GPU to have something to do while you do the addition)

8. Repeat steps 5 and 6 until you have drawn all your rectangles.

May I ask what you are actually doing?

vladlen
09-12-2002, 06:15 PM
Having a 32-bit stencil buffer sounds great! Does anybody know which chipsets provide that?

The accumulation buffer solution is possible, although presumably a bit slow - as I understand, you cannot write directly onto the buffer, you have to write onto another buffer and then add that whole other buffer onto the accum. buff. This would mean drawing batches of 256 rectangles on some buffer, accumulating it onto the accum. buff., and repeating... Of course, the number of repetitions is limited to 256 because only 16 bits are available.

P.S.: What I actually need this for is a cute problem that arose in the robotics lab in my university. It would take too long to explain, and it has very little to do with graphics, but since I have background in computer graphics I saw that the problem can be efficiently solved using graphics hardware - can be solved, that is, if the hardware allows me to accumulate many thousands of rectangles the way I described.

flo
09-12-2002, 10:24 PM
Imho, no graphics hardware supports 32 stencil bits. 32 stencil bits can however be requested with Mesa (software rendering)

A simple possibility to get 15 bits accuracy without CPU aid and in hardware would be the following: For each shape, increment the stencil buffer. Each time 128 shapes have been processed, draw a quad over the whole framebuffer, and set the stencil test for >=128. When the stencil test passes, increment the alpha buffer value by one and reset the highest stencil buffer bit to zero. The end result would be
(alphavalue * 128) + stencilvalue

flo

Humus
09-13-2002, 03:51 AM
Originally posted by flo:
Imho, no graphics hardware supports 32 stencil bits.

Heh, have to say it in this topic too ... Interesting use of the IMHO acronym. http://www.opengl.org/discussion_boards/ubb/smile.gif

flo
09-13-2002, 04:41 AM
Why? I meant with "Imho" that there is no hardware *I* *know* *of* that offers that many stencil bits ...

Anyway, I think using a texture copy, the alpha test, and subtractive alpha blending (-128), the same trick i explained for the stencil buffer could be also applied to the alpha buffer. That would give an accuracy of 22 bits if using one color channel.

Ultimately, using register combiners to copy a color to alpha, all three color channels and alpha testing, the maximum accuracy I can think of is 36 bits therefore. So who needs 32 bit stencil anyways :-)

flo

[This message has been edited by flo (edited 09-13-2002).]

Mezz
09-13-2002, 08:08 AM
Imho, Imho generally generally infers an opinion rather than a statement of knowledge. Imho, instead of imho, you should have used something like "to my knowledge" or, that other acronym "afaik".

No disrespect intended, I'm just kidding around http://www.opengl.org/discussion_boards/ubb/wink.gif

-Mezz