PDA

View Full Version : Does the draw order affects objects position in depth? (images included)



RareFever
06-27-2015, 04:20 PM
I have a few objects on the scene and even if I specify that the object A have y= 10 (the highest object), from the TOP camera I can see the bottom objects through the object A. Here is an image from my scene.

1896

And only today I found an interesting property that draw order of models matters, I may be wrong. Here is another image where I change the draw order of "ship1", attention: "ship1" is way bellow my scene, if I do ship1.draw(); first, the ship disappears (correct), but if I do ship1.draw(); in last, he appears on top (incorrect).
1897

Q1) Does the draw order always matter?
Q2) How do I fix this, should I change draw order every time I change camera position?

Edit: I also compared my class of Perspective Projection with the glm library, just to be sure that itīs not the problem with my projection Matrix. Everything is correct. Edit1: I have my project on git: Arkanoid git repository (https://github.com/RareFever/Arkanoid)

Some code:

void setupOpenGL() {
std::cerr << "CONTEXT: OpenGL v" << glGetString(GL_VERSION) << std::endl;
glClearColor(0.1f, 0.1f, 0.1f, 1.0f);

glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LEQUAL);
glDepthMask(GL_TRUE);
glDepthRange(0.0, 1.0);
glClearDepth(1.0);
glEnable(GL_CULL_FACE);
glCullFace(GL_BACK);
glFrontFace(GL_CCW);
}

void display()
{
++FrameCount;
glClearColor(0.1f, 0.1f, 0.1f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
renderScene();
glutSwapBuffers();
}
void renderScene()
{
wallNorth.draw(shader);
obstacle1.draw(shader);
wallEast.draw(shader);
wallWest.draw(shader);
ship1.draw(shader);
plane.draw(shader);
}

PS: I dont know how upload bigger images. =/

GClements
06-27-2015, 06:22 PM
p2.set(0.0f,100.0f, 60.0f, 1.33f);

You're setting the near distance to zero, which results in all of your depth values being equal. As your depth function is


glDepthFunc(GL_LEQUAL);

the depth test will always pass.

More generally, the smaller the near distance, the worse the depth resolution, so make the near distance as high as you can get away with.

RareFever
06-28-2015, 03:26 AM
Hey, thanks for the answer. But unfortunately I tried many values and nothing changes. I have near=20 and far=500, angle 60š, but still depth problem. It is very weird.
I made a post in stackoverflow, very detailed. I can not post links here (yet) so search for "Does the draw order affects objects position in depth? (images included)" on google or on stackoverflow site. My username is RareFever.
Guys, help this por guy. I just wanna make arkanoid in open source. All of my code is on github.




p2.set(0.0f,100.0f, 60.0f, 1.33f);

You're setting the near distance to zero, which results in all of your depth values being equal. As your depth function is


glDepthFunc(GL_LEQUAL);

the depth test will always pass.

More generally, the smaller the near distance, the worse the depth resolution, so make the near distance as high as you can get away with.

GClements
06-28-2015, 09:00 AM
Other possibilities include:

- Did you request a depth buffer by passing GLUT_DEPTH to glutInitDisplayMode?
- If you're using shaders, are they doing anything which would affect the depth values?

RareFever
06-28-2015, 03:34 PM
Well, my Vertex shader very simple:


#version 330 core
in vec4 in_Position;
out vec4 color;
uniform mat4 Model;
uniform mat4 View;
uniform mat4 Projection;

void main(void)
{
color = in_Position;
gl_Position = Projection * View * Model * in_Position;
}

And my Fragment shader is this:


#version 330 core
in vec4 color;
out vec4 out_Color;
void main(void)
{
out_Color = color;
}


And yes, I do that too. Like this:

glutInitDisplayMode(GLUT_DEPTH | GLUT_RGB | GLUT_DOUBLE | GLUT_ALPHA | GLUT_MULTISAMPLE);

In this moment I am very sad. Even guys from stack overflow have no idea whats wrong. I will start putting some lighting and textures with normals... because I have no idea how to fix this depth problem.

Other possibilities include:

- Did you request a depth buffer by passing GLUT_DEPTH to glutInitDisplayMode?
- If you're using shaders, are they doing anything which would affect the depth values?

RareFever
06-29-2015, 12:28 PM
grrr. I don't believe that Internet cant help me.

GClements
06-29-2015, 01:13 PM
grrr. I don't believe that Internet cant help me.
I suggest reducing your program to a single file (without any classes), and removing anything which isn't necessary to demonstrate the problem. It's unlikely that anyone is going to look at something consisting of 30 source files just to answer a forum post.

RareFever
06-29-2015, 01:26 PM
True.
Thanks for the reply.

I suggest reducing your program to a single file (without any classes), and removing anything which isn't necessary to demonstrate the problem. It's unlikely that anyone is going to look at something consisting of 30 source files just to answer a forum post.

Alfonse Reinheart
06-29-2015, 01:43 PM
Hey, thanks for the answer. But unfortunately I tried many values and nothing changes. I have near=20 and far=500, angle 60š, but still depth problem. It is very weird.

Hmm... that's telling. What happens if you set the near/far range to [1, 100], then try [101, 200]. Because there's no way you should see the exact same thing with both ranges; they're mutually exclusive.

If you do see the same thing with both settings, then either you're not using that matrix in your rendering, or your rendering is doing something really wrong.

mhagain
06-29-2015, 02:48 PM
As a general rule, if you encounter behaviour like this then you've either (rarely) found a driver bug, or (probably) have something wrong in your code.

In your case it's your code. Look at your Object3D::draw method - you clear the depth buffer after drawing each object.

Alfonse Reinheart
06-29-2015, 03:09 PM
Also, note that glIntercept (https://github.com/dtrebilco/glintercept) is a pretty good tool for tracking these kinds of bugs down. It can spit out a list of all OpenGL calls your application makes. It would have been easy to find the spurious glClear call.

RareFever
06-29-2015, 03:17 PM
I am sorry, I was not accurate in my sentence. What I wanted to say is that, by changing near and far values, the problem of depth was still an issue. And just now, I did the test with [1, 100] (saw my scene) and with [101,200] (didn't see anything, black window). Two days ago I downloaded the glm library, just to compare if my library produce the same matrix as the glm, and everything was equal. At this moment, I believe something is wrong with my draw method, the way I use it. What I did today, was draw 2 cubes in new project, al from zero. Then I added my class for camera and class for Perspective Projection. So far the depth is great. Here is an image:
1902
Now I will join my class to draw stuff. And after that I will report it here. So basically, I started new project.
I really want to create the Arkanoid game. And I am willing to learn and understand everything.

Hmm... that's telling. What happens if you set the near/far range to [1, 100], then try [101, 200]. Because there's no way you should see the exact same thing with both ranges; they're mutually exclusive.

If you do see the same thing with both settings, then either you're not using that matrix in your rendering, or your rendering is doing something really wrong.

RareFever
06-29-2015, 03:20 PM
wow. Thats news for me. =)
I will use it for sure !
Thanks. I will report soon as I can. (I have exam tomorrow, need to sleep well this night).

Also, note that glIntercept (https://github.com/dtrebilco/glintercept) is a pretty good tool for tracking these kinds of bugs down. It can spit out a list of all OpenGL calls your application makes. It would have been easy to find the spurious glClear call.

RareFever
06-29-2015, 03:21 PM
(bad reply)

RareFever
06-30-2015, 02:40 AM
=)
I read your reply yesterday, but was so tired that I didnt understood what you wrote. Omg. You are damn correct !
I deleted glClear() from the draw method, and it works !
Thanks

As a general rule, if you encounter behaviour like this then you've either (rarely) found a driver bug, or (probably) have something wrong in your code.

In your case it's your code. Look at your Object3D::draw method - you clear the depth buffer after drawing each object.