   opengl depth buffer
  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.0glClearDepth(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]
  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;   ;  Sorry about that, it was a mistype on my behalf, it was suppose to be written as -(winLayer + Z_NEAR).   ;  Just to be totally clear, the mistype was with respect to my post, the problem itself still stands.   ;  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.   ;  "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.;  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?   ;  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.;  anyone?   