Depth Buffer / Testing basic question...

Member
Posts: 321
Joined: 2004.10
Post: #1
I've got a birds eye game with 2D objects (textures) at different x, y, z
coordinates. Right now I simply render the objects from farthest (first) to
nearest (last) to the (name escapes me now) great-eye-in-the-sky.
This works, but ocassionally when I update code I goof up the render order
and so I get airplanes flying under ships, etc.

I presume this is a primative method?

I'm looking at the Red Book under Depth Test, p 447. If I understand
this right: if I enable GL_DEPTH_TEST, set the correct depth comparison
in glDepthFunc(), and clear the depth buffer before you redraw each frame,
does that mean that the objects will be correctly covered up or displayed
based on the z value of the objects (textures)?

I presume this is the preferred method?

Just wanted to check before I dive in coding.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Not the z coord as such, but the distance from the virtual camera.

You'll also need to request a depth buffer from the window system -- precisely how to do that depends on what API you're using.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #3
WhatMeWorry Wrote:I presume this is a primative method?
Allocating a depth buffer eats more VRAM, and enabling the depth test eats some fill rate.

So, if all of your content is 2D, doing the sorting yourself is perfectly reasonable. You only really need a depth buffer if you have three dimensional geometry. Even then, if you have translucency you still need to sort things yourself.

On modern video cards the overhead from the depth buffer is small, but if you are dealing with a small number of 2D objects it is probably better overall to sort yourself.
Quote this message in a reply
Member
Posts: 321
Joined: 2004.10
Post: #4
Quote:Not the z coord as such, but the distance from the virtual camera.

Just a clarification: isn't the distance from the virtual camera (assuming x and
y are same for both camera and object) the delta between the z of the camera
and the z of the object?


Quote:You only really need a depth buffer if you have three dimensional geometry

Is this required because of the interaction (maybe overlaying is a better word)
between 3D objects, or are we talking about the differences of depth of
actual points on a 3D object itself. Or maybe both? (If the previous sentence
made any sense whatsoever)
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #5
All you do is glEnable(GL_DEPTH_TEST) and add GL_DEPTH_BUFFER_BIT to your call to GL_CLEAR, and don't worry about what it will do: it will make everything display correctly without any intervention from you. It would also probably be faster than manually sorting everything, depending on the efficiency of your sort. The only thing where depth matters with GL_DEPTH_TEST enabled is with transparency.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #6
WhatMeWorry Wrote:Is this required because of the interaction (maybe overlaying is a better word)
between 3D objects, or are we talking about the differences of depth of
actual points on a 3D object itself.

Here's a bit of an overview.

Imagine you are trying to draw a donut. It is a single 3D object, but it is made out of lots and lots of individual vertices, which each have unique X,Y,Z positions. When you initially calculate the geometry for this object, you can put all of the X,Y,Zs into a large array. Then to make the donut spin around on screen, you'd translate/scale/rotate it by some amount and issue a draw command like glDrawArrays(GL_TRIANGLE_STRIP, ...). The problem here is that you're passing in an essentially unordered list of triangles, which are each going to be transformed by the modelview/projection matrix into window space before rasterization. So it is a little tricky to make sure that the far away triangles are all drawn before the nearby triangles.

The depth buffer solves this problem by remembering the Z coordinate for every pixel that is drawn. So you can draw any of the triangles, near or far away, and remember the Z that is produced for each pixel. By convention, the Z coordinates are scaled by default during rasterization such that very far away = 1.0 and very close by = 0.0. Then, when the next triangle is drawn, the depth test will only allow a pixel through if (by default) its Z is less than the previous Z for that location in the depth buffer. This has the effect that drawing far away triangles on top of nearby triangles turns into a no-op, nothing is drawn. You end up with the same result as if you had carefully sorted everything beforehand from back to front.

So, the depth test can do this for you, and it is hardware accelerated so it is generally very fast. But is it always required?

No. For simple geometry, you don't need depth test. Consider a rotating solid cube. It has six faces, but only three can be visible at any given time, the other three will always be facing away from you. If you turn on backface culling, those three will never be drawn, regardless of the order that you draw the faces in. This works for any completely convex object. A donut won't work though, the hole through the middle makes it "concave".

Also for completely 2D scenes, like side scrollers or shoot-em-ups, you don't need a depth buffer. You can always draw the background layer(s) and sprites in the correct order so that they overlap properly. It is just up to you to track the order they are drawn in.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Basic OpenGL reshape function question... WhatMeWorry 2 6,662 Mar 30, 2011 07:05 AM
Last Post: Ingemar
  Depth Buffer Question AnotherJake 10 4,737 Sep 23, 2008 01:43 PM
Last Post: AnotherJake
  Texture Basic Question(s)... WhatMeWorry 2 3,280 Feb 27, 2007 10:06 AM
Last Post: arekkusu
  Am I using depth testing incorrectly or something? Jones 10 4,261 Sep 11, 2006 05:38 PM
Last Post: Jones
  problems getting the depth buffer akb825 3 4,188 Jun 2, 2006 12:51 PM
Last Post: akb825