What is a z-buffer?

Blitz3D Forums/Blitz3D Beginners Area/What is a z-buffer?

Drekinn(Posted 2006) [#1]
I'm new to the 3D realm of Blitz, and know these must be embarrassingly basic questions, but I'd like to know the following:

1) What is a z-buffer (and z-buffering)?

2) What is meant by the term 'normal'?

I tried scouring the forums for answers but only found obscure references. Any guidance would be most appreciated.


puki(Posted 2006) [#2]
Well, they are not Blitz specific. More general 3D related.

Normals are used in 3D calculations such as in checking what direction a polygon is facing - ie which way a polygon's normal is pointing.

The 'Blitz' definition is 'Recalculates all normals in a mesh. This is necessary for correct lighting if you have not set surface normals using 'VertexNormals' commands.'

In Blitz you generally use normals for lighting reasons - but you could use them for backface culling, etc too.

Here is a link regarding the z-buffer:
http://www.toymaker.info/Games/html/z_buffer.html

Blitz also has a wbuffer command. Type wbuffer into Blitz3D - click on the word, then press F1 for a bit of info.

You are best Googling your two questions as they are not Blitz-based. I believe though that there are quirks to the z-buffer in Blitz3D.


Mustang(Posted 2006) [#3]
One definition:


Z-Buffer

The z-buffer is a portion of the local memory that is used to store depth information about each pixel in a frame. Depending on what type of process is used, each pixel in the next new frame is checked against the values in the z-buffer - if the new pixel is nearer than the one in the z-buffer, its value overwrites the old one and appears in the final frame. However, if the new pixel is further away, then the old value remains in the z-buffer and the pixel is not displayed.
The z-buffer is often referred to as the depth buffer for obvious reasons.



Another z/w-article:

http://www.extremetech.com/article2/0,1697,1171859,00.asp


sswift(Posted 2006) [#4]
A ZBuffer is an extra integer for each pixel on the screen which specifies how far away that pixel is from the camera.

You used to have to sort polygons from far to near and draw them in that order to get them to draw right, and this would not work for polygons that intersected one another, or polygons which were otherwise both behind and in front of another.

Now, when you draw a polygon, each pixel's depth is calculated, and is compared to the depth of the pixel on the screen. If the pixel on screen is farther away from the camera, the pixel is drawn, otherwise, it is not.

Because of this behavior, transparent polygons must all be drawn in a second pass after everything else. And that is why so many people have problems with stuff like particles near bodies of water. The transparent polygons do not write their positions to the zbufffer when they are drawn, they only compare themselves to it to see if they should draw.

They do this because trying to zbuffer them normally would not produce correct results. You can't discard a transparent pixel if it is behind antoher transparent pixel after all. So amongst themselves they are drawn like in the old days, but they are zbuffered with the opaque stuff. And that is why people also have problems with alpha objects like trees made from a bunch of quads with alpha maps. So people have to use tricks like the olde days to split up the polygons where the planes intersect and presort them and all that junk.


sswift(Posted 2006) [#5]
Oh btw, the near and far planes for the camera define where 0 and the max z-value are as far as depths go, so the closer these two are together, the more accurate the zbuffer is. If you need to see really far then you'll have less accurate intersections between polygons and possibly objects behind trees appearing in front of them. That's why the far plane isn't just set to infinity. Also, the near plane will have more effect than you expect because te depths are calculated in an exponential way I think. So so if you move the near plane really close to the camera then you'll be compressing most of the zbuffer depths close to the camera. Of course if you move it too far away then you see stuff clipped when the camera moves close to it.


Mustang(Posted 2006) [#6]

depths are calculated in an exponential way I think



Yup - and this is the most important detail to understand... the link I posted describes this in more detail.


Beaker(Posted 2006) [#7]
http://www.sjbaker.org/steve/omniv/love_your_z_buffer.html


markcw(Posted 2006) [#8]
also see:

http://en.wikipedia.org/wiki/Surface_normals

http://en.wikipedia.org/wiki/Z-buffer


H&K(Posted 2006) [#9]
A Normal is a line that points in totaly NOT the direction of whatever it is the normal to (???)

For example if a line points straight up and down, (In 2d), then a Normal of that line, is any line that doesnt go up or down at all. ie A left to right line.

In 3d you have a plain. The plane is left, right , forward and backwards. Now ANY line that DOESNOT go either left nor right nee Forward Nor Backwards is a normal to that plain Ie UP and down


Drekinn(Posted 2006) [#10]
Thanks everyone for the wealth of information; time to study methinks.