Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1075929 Posts in 44152 Topics- by 36119 Members - Latest Member: Royalhandstudios

December 29, 2014, 04:01:16 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Clipping problems [OpenGL]
Pages: [1]
Print
Author Topic: Clipping problems [OpenGL]  (Read 387 times)
Quarry
Level 10
*****



View Profile WWW
« 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
Moderator
Level 10
******


Alex Diener


View Profile WWW
« 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
Level 10
*****



View Profile WWW
« 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
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #3 on: November 02, 2012, 10:04:13 AM »

Wait, -1? You'll want a positive number.
Logged
Evan Balster
Level 10
*****


I live in this head.


View Profile WWW Email
« 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
Level 10
*****



View Profile WWW
« 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
Moderator
Level 10
******


Alex Diener


View Profile WWW
« 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
Level 10
*****



View Profile WWW Email
« 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
Level 10
*****



View Profile WWW
« 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

 
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic