|
Quarry
|
 |
« on: November 02, 2012, 08:08:38 AM » |
|
Recently I've tried 2D ready and 3D ready functions in order to draw GUI on my screen, it didn't end well;  Even the GUI seems to be working well, the chests (textured quads) seem to be clipping with eachother. My clear function; glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);My 2D ready; glMatrixMode(GL_PROJECTION); glLoadIdentity();
gluOrtho2D(0.0f, SCREEN_WIDTH, SCREEN_HEIGHT, 0.0f);
glMatrixMode(GL_MODELVIEW); glLoadIdentity(); glTranslatef(0.375f, 0.375f, 0.0f);
glDisable(GL_DEPTH_TEST);My 3D ready; glViewport(0, 0, SCREEN_WIDTH, SCREEN_HEIGHT); glMatrixMode(GL_PROJECTION);
glLoadIdentity(); gluPerspective(60, (float) SCREEN_WIDTH / SCREEN_HEIGHT, 0f, 5000.0f);
glMatrixMode(GL_MODELVIEW); glLoadIdentity(); glEnable(GL_DEPTH_TEST); glDepthFunc(GL_LEQUAL);The call order of above is clear, ready3D, render3D, ready2D, render2D. I'm also using an FBO to scale my display if needed, its render buffer settigns are; glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT24, SCREEN_WIDTH, SCREEN_HEIGHT); glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, scaledFBODBuffer);I'm not sure if anything is wrong with the settings and I'll be very glad if anyone comes with a solution, I can also provide the full source code if needed.
|
|
|
|
|
Logged
|
|
|
|
|
ThemsAllTook
|
 |
« Reply #1 on: November 02, 2012, 08:19:06 AM » |
|
I had to stare at it for quite a while, but I think I see your problem. It's in this line: gluPerspective(60, (float) SCREEN_WIDTH / SCREEN_HEIGHT, 0f, 5000.0f);
The amount of depth buffer precision you get has to do with the ratio between your near and far clipping planes. With your near clipping plane set to zero, the ratio is infinite, and you get no depth buffer precision at all. If you set your near clipping plane to some positive nonzero value, things should work better. The lower the value of zFar / zNear, the more depth buffer precision you'll get.
|
|
|
|
|
Logged
|
|
|
|
|
Quarry
|
 |
« Reply #2 on: November 02, 2012, 08:21:59 AM » |
|
Setting 0 to -1 fixed the problems, however there's still a depth problem, what might be the cause of that? 
|
|
|
|
|
Logged
|
|
|
|
|
ThemsAllTook
|
 |
« Reply #3 on: November 02, 2012, 10:04:13 AM » |
|
Wait, -1? You'll want a positive number.
|
|
|
|
|
Logged
|
|
|
|
|
Evan Balster
|
 |
« Reply #4 on: November 02, 2012, 10:38:46 AM » |
|
Depth values follow an exponential gamut from zNear to zFar; a given depth value translates to a Z value based on an equation like this:
Z = zNear * (zFar/zNear)depth_value/(2^depth_bits)
For this reason, you can't set zNear to 0 -- you can't multiply any number with zero and get a positive result. You also can't make it negative -- (zFar/zNear) becomes negative which means that exponentiation will result in complex numbers! Also, as you increase your zNear you'll reduce the amount of Z-fighting in the remaining area, because of the exponential gamut. With a zNear of .0001 and a zFar of 10000, half of the depth values will be spent on things that are less than 1.0 units from the camera, and objects will need to be much further apart to avoid Z-fighting!
Try to settle on a zNear that's as far as possible from the camera without causing objects near the viewer to disappear. A range like [.5, 100000] is good. A range like [1, 5000] is great if you can manage it.
|
|
|
|
|
Logged
|
Creativity births expression. Curiosity births exploration. Our work is as soil to these seeds; our art is what grows from them...Wreath, SoundSelf, Infinite Blank, Cave Story+, <plaid/audio>
|
|
|
|
Quarry
|
 |
« Reply #5 on: November 02, 2012, 04:11:49 PM » |
|
 I don't think that I ever had any forms of Z-fighting, anyways I set it to 1 - 5000 and that fixed the depth problems but apparently I still have some alpha (?) covering textures behind them
|
|
|
|
|
Logged
|
|
|
|
|
ThemsAllTook
|
 |
« Reply #6 on: November 02, 2012, 06:13:21 PM » |
|
Nice, looks like your depth test is working. So, blending is a tricky issue... What you're seeing in that screenshot is that the chest in front got drawn first and wrote its quad to the depth buffer, then the one behind it got drawn and discarded the fragments that were behind the transparent parts of the one in front. Essentially, all geometry is fully opaque as far as the depth buffer is concerned. You have a couple of options: - If you only ever have one bit of transparency information (as in, your texels are either fully opaque or fully transparent and never anything in between), you can enable GL_ALPHA_TEST, which will prevent transparent pixels from being written to the depth (and color) buffer. Last I knew, this had a hefty performance penalty on some mobile devices, so you'll want to be aware of that if you're targeting them.
- If you have translucent texels, your next best bet would be to sort your geometry by camera depth before drawing. You'll want to draw in order of farthest to nearest object onscreen. It's kind of a pain to manage all the sorting required, but it does the job.
|
|
|
|
|
Logged
|
|
|
|
|
InfiniteStateMachine
|
 |
« Reply #7 on: November 02, 2012, 06:51:02 PM » |
|
yeah alphatest is the equivalent of discard in the pixel shader. PowerVR GPU's which use Tile Based Rendering have to turn off an early fragment shader optimization. If you are doing 2D with this is shouldnt really matter.
I suppose the best thing to is TaT's solution but the one issue I have with that is everytime you have a different texture you have to restart your drawelements call. The only solution I've found so far is to pack all your textures into a monster texture at load time.
Is there a better way?
|
|
|
|
|
Logged
|
|
|
|
|
Quarry
|
 |
« Reply #8 on: November 02, 2012, 07:21:38 PM » |
|
I think I'll be using GL_ALPHA_TEST as I don't think that I'll be needing anything else, thanks all
|
|
|
|
|
Logged
|
|
|
|
|