View Full Version : How big exactly is 16bit depth???
04-20-2002, 08:09 AM
Hi, I am using Windows 98 and when I set up the PIXELFORMATDESCRIPTOR I am tasked to tell OpenGL my depthbuffer, i searched around the net and found no answer but instead codes that put the number 16 on the depthbuffer field. So my question is, if I put 16 on the depthbuffer field, does it mean that my polygons could have the value up to 2^16??? Thanks in advance.
04-20-2002, 08:40 AM
You put your desired depth buffer bit depth (not a type) in there. You can also insert zero to let OpenGL make the choice for you.
16bit means your z values have 16bit precision, this has almost nothing to do with actual representation and values in the card's memory.
The actual range of depth values is controlled by the projection matrix.
04-20-2002, 10:56 PM
i'm sorry, but i don't understand...if i have 16bit precision, what does that mean? thanks. I'm obviously a beginner here...
Normally the near clip plane has the value 0 and the far clip plane has the value 1 in terms of depth. The depth values of every pixel rendered are always between 0 and 1.
16 bits is just the precision of the floating point format used to represent that number. The smaller the precision, the more "rounding" is made when calculating the depth value of a pixel, so there are more chances of errors in such calculations.
If you don't know what a projection matrix is, you really should read the Red Book. It's not very easy to explain in a few words.
[This message has been edited by t0y (edited 04-21-2002).]
04-21-2002, 05:23 AM
oh...ok, thanks for the reply guys! i'll search the net for further info regarding this problem of mine...
2^16 = 65,536
2^24 = 16,777,216
thus with 16 bit depth buffer u can only have approx 65,000 different depth values which shows that z fighting can easily happen (esp far from the camera)
a good description is available here http://www.sjbaker.org/steve/omniv/index.html
also check the faq
(16bit or 15?)
04-22-2002, 05:06 AM
ok, so far, here's what i understand, please let me know if I'm super-wrong!
when you have 16bit precision, it means you have up to 16 numbers after the decimal point of your floating number. Is this correct? thanks.
You are on the right track. The number of bits decides the precision of the number, which is more or less the number of decimals.
If you have 16 bit's of precision, the smalles change in the number can be 1/(2^16) = 0.000015. That means you have about 4-5 correct decimals. Or to be correct, values, not decimals.
04-22-2002, 07:33 PM
i see, and since my near clip plane is 0 and my far clip plane is 1, the change in my z-values could be at a range of 1/(2^16)??? Ohh...I think I got it now...thanks!
Oh yeah, since I know that my change is z-value could be 1/(2^16), then does it mean that THAT value is the minimum value I could add (or subtract) to, say, another vertex so there's no z-fighting? Is this what 16bit depth buffer means?
a great thanks to those guiding me here so far!
04-22-2002, 07:36 PM
Well, concerning Z-fighting, it's not that simple as making sure you add/subtract 1/(2^16) to/from your geometry to avoid Z-fighting. But I must say I get the impression you understand the whole idea by now.
Thing is, in perspective projection, you don't have a linear distribution of the precision. You have better precision closer to the near clip plane, and worse precision closer to the far plane. That means you have to add more than 1/(2^16) closer to the far plane, and less than 1/(2^16) is needed closer to the near plane. The distribusion in precision is directly linked to the values of the near and far plane (the two last parameters to glFrumstum/gluPerspective). The greater the ratio (ratio = far/near), the worse precision you get furher back. For a 16-bit depthbuffer, you shouldn't keep your ratio above 1000-2000 (near=0.1 far=200, or near=10 far=20000, for example), or you will loose to much precision.
[This message has been edited by Bob (edited 04-23-2002).]
04-23-2002, 05:15 AM
i see...i got it! i finally got it! (the concept, i mean... http://www.opengl.org/discussion_boards/ubb/smile.gif ). Actually, my next question was why the last two values of gluPerspective() aren't 0.0 to 1.0...but you answered by question in advance, thanks Bob!
So as long as my ratio in my gluPerspective() is OK, then I guess I have a minimal z-fighting? I see, thanks.
Another thing, do you calculate the last two values of gluPerspective() or just pick some values whose ratio are within the range that was posted above??? thanks in advancE!!!
The last two parameters of gluPerspective is the distance to the near and far plane in eye coordinates, that is, before perspective projection. The Z-range [0, 1] is the range after perspective projection. That means, object at the near plane in eye coordinates will be located at Z=0 after perspective projection. You get the point I hope.
And concerning the near plane, you should not set it to zero. Just look at what happens to the ratio. As near approaches zero, ratio=far/near approaches infinity. And you should always keep your ratio as small as possible. Can't say infinity is "as small as possible" http://www.opengl.org/discussion_boards/ubb/biggrin.gif
The near and far planes are generally not calculated, but rather set to some value by the programmer. Say you program an indoor game, and 1 OpenGL unit correspond to 1 meter. Since it's an indoor game, you won't see that far away (due to walls and stuff), so you set the far plane to 50, which is equal to 50 meters. To keep a ratio of 1000, you set the near plane to 0.05, which means 5 centimeters. Thats about how you can get the proper values for the near and far plane. You can of couse change them dynamically, for example by calculating the nearest and farthest object to make sure everything is always visible.
One more thing to keep in mind. If you are experiencing Z-fighting, you need to make your ratio smaller. Then you should push the near plane further out, since it affects the ratio far more than pulling the far plane in.
[This message has been edited by Bob (edited 04-23-2002).]
04-23-2002, 08:34 PM
ok! I got it! I finally got it! thanks everyone! thanks Bob! http://www.opengl.org/discussion_boards/ubb/smile.gif
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.