Skip to main content
GameDev.net gamedev.net
🔒 Locked

opengl depth buffer

OpenGL
Started by ari556655 Apr 6, 2010 at 11:47 PM 7 replies 2.5k views
Original Post
ari556655
ari556655
I'm writing an opengl gui, so far it only supports 2d drawing. Here's my setup 

#define Z_NEAR 10.0
#define Z_FAR 100.0

glClearDepth(1.0);
glDepthFunc(GL_LEQUAL);


void drawStuffInWindw()
{
       // each is drawn over the entire window's content area so
      // the red quad should never be visible

         drawRedQuadOverEntireWindow();
          drawTexturedQuadOverEntireWindow();
}


//the lower the window->layer the closer it is, 0 always is the top window 
void drawWindows()
{  
    for (i = 0; i < num windows; i++)
     {
         winDepth = getWindowWithLayer(i)->layer - Z_NEAR;
        drawStuffInWindow();
     }
}
Now drawStuffInWindow draws everything using winDepth as its z value for glVertex(), so that every piece of geometry drawn in a given window has the same z value. The problem is I'm getting some very strange results. Example, with my z near set to 10.0, if I have 4 windows visible, the window with a layer of 2 will have the red quad totally visible and not the textured quad. But it only happen with the third window down from the top(visible), and then if I have 5 or more windows the window's with layers 2 and 4 will display this behavior. Now I tried switching around the Z_NEAR and Z_FAR and what happens is, windows at different layers will display this behavior, so instead of window 2 and 4 it might be 3 and 1 or whatever. I'd really appreciate some help on this one, hope I've been descriptive enough. I should mention that by incrimenting the"winDepth" variable each time I draw within a window, the problem goes away, leading me to believe that it's somehow related to ogl depth buffer precision. [Edited by - ari556655 on April 7, 2010 12:29:20 AM]
Arvydas
Arvydas
Your calculated winDepth values are -10, -9, -8..., and they are out of defined visibility range. Don't know about your specifics, but my bet is you should write:
winDepth = getWindowWithLayer(i)->layer + Z_NEAR;
ari556655
ari556655
Sorry about that, it was a mistype on my behalf, it was suppose to be written as -(winLayer + Z_NEAR).
ari556655
ari556655
Just to be totally clear, the mistype was with respect to my post, the problem itself still stands.
Kwizatz
Kwizatz
Isn't it easier to disable depth test and draw the windows bottom up, with the focussed one last?

You will likely get z fighting if two windows with the same z value overlap, not so with depth testing disabled.
Katie
Katie
"Isn't it easier to disable depth test and draw the windows bottom up, with the focussed one last?"

That's the way I've done it for our commercial app. Didn't seem worth any other aggro.

Generally the only thing you want to do is snap a window to the top, so actually having to think about what Z values to put in is a pain -- it's easier just to have an ordered list. Then you can just promote things by pulling them out and sticking them back onto the front.

You need to paint back -> front, but pass mouse/keyboard events front -> back until something handles them.
ari556655
ari556655
Originally I was doing back to front with depth testing disabled but I figured that turning the depth buffer on and drawing front to back would be a worthwhile optimization, am I wrong in thinking so?
Katie
Katie
By doing things that way, you're saving on pixel overdraw -- which is no bad thing in itself. However, it's not all that likely that your app is fillrate limited {It's possible, but modern cards can easily draw the entire screen dozens of times per frame so it's not that likely}. Note also that disabling depth testing (and alpha testing if appropriate) will quite possibly speed up your pixel pipeline anyway. So you've got pixel drawing to spare so you might as well use it to offload work from the CPU (the calculating and managing all the Z depths).

Another reason to go back-to-front is so that you can do transparent compositing in the future... which is why we're doing things that way round; some of our displays are translucent so users can see context behind them. Even if all you want to do is fade the elements up and down as they open/close, you need to draw back-to-front to get the effect to work.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.