That’s 7 bits rounded, almost HALF of the bits! Is the rounding really this heavy? How could I prevent this? I tried some other glColor??() functions but they go round and round and round… ;(
I’m very disappointed with this, as I’m trying to do scientific calculation here using pbuffers - whats the point in switching to a 16-bit mode if the accuracy is only half the bits ?
RGB16 is a floating point format right? It is probably impossible to represent the integer 0xABCD as a 16 bit floating point number.
There are not 16-bits of precision in the RGB16 format, some of those bits are used for the sign and exponent. The whole point is to have greater range (and I think, greater precision after doing multiple calculations, a case were fixed point would fail without extra effort).
[This message has been edited by Nakoruru (edited 06-16-2003).]
The colors interpolate with a bit less precision than the texture coordinates. I would suggest trying to pack them in a texture coordinate and using a pixel shader to pass them to the output.
BTW, I would warn you that you might see this issue other places, since the GL spec explicitly allows lower precision and range on color values than texture coordinates.
Originally posted by ehart:
[b]
The colors interpolate with a bit less precision than the texture coordinates. I would suggest trying to pack them in a texture coordinate and using a pixel shader to pass them to the output.
BTW, I would warn you that you might see this issue other places, since the GL spec explicitly allows lower precision and range on color values than texture coordinates.
-Evan[/b]
Evan,
This is not a matter of interpolation - the object in question was a single GL_QUAD with the GL_FLAT shading model, thus no interpolation…(?)
I see what you mean though, and I think I’m going to switch over to a 32-bit Red channel in hope for a bit more precision.
Thanks for the answers, they cleared things up a bit.
It seems the mode I am setting for my pbuffer (RGB16 mode), is floating point.
How can I set or even query for a non-floating point mode ? Neither WGL_ARB_pbuffer nor WGL_ARB_pixel_format say anything about the formats being float or fixed-point (?)
Do I have to iterate through all suitable modes and check which ones are fixed-point? This would be a very kludgy solution… I am assuming now that fixed-point 16-bit modes (R16G16B16xxx) or higher exist.
I need a fixed-point mode to enable blending. Blending doesn’t work in float modes it seems.
Thanks for any help,
Andru
[This message has been edited by Andru (edited 06-17-2003).]
First, when I said interpolator, I just meant the HW path that moves the color from the vertex level to the fragment level. The comment about the color attribute having less precision still holds.
Next, unless you request a floating point buffer, you should get an int buffer. Unfortunately, blending is still not supported in HW for RGBA16 surfaces.
I was under the impression that particular piece of hardware could only support 12 bits per channel max. And if you spread those 12 bits over the domain of 16 bits and do the math, you will come to an interesting conclusion.
[This message has been edited by DFrey (edited 06-17-2003).]
Originally posted by DFrey: How many bits does the gamma ramp support per channel?
You cannot tell without detailed analog measurement.
Win32 exposes gamma ramps as 16 bits unsigned.
But (coming straight to the point ), the gamma ramp is irrelevant for all things rendering. It only applies to RAMDAC operation. If you’d like to convince me of the opposite, go ahead