Occlusion Queries, strange result

OpenGL
1

Hello,
I try to implement an efficient lens flare, and to do that I need to add an occlusion test. So after some researches, I have chosen to use occlusion queries to make this test.
There is my implementation :

GLuint a = 0;
GLuint result = 0;

// Create queries
glGenQueries(1, &a);

glDepthMask(GL_FALSE);
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE);

// Launch Queries
glBeginQuery(GL_SAMPLES_PASSED, a);

// Draw sun flare
glBegin(GL_QUADS);
glVertex3f(p.x - 258, p.y - 258, p.z);
glVertex3f(p.x + 258, p.y - 258, p.z);
glVertex3f(p.x + 258, p.y + 258,p.z);
glVertex3f(p.x - 258, p.y + 258, p.z);
glEnd();

glEndQuery(GL_SAMPLES_PASSED);
glGetQueryObjectuiv(a, GL_QUERY_RESULT, &result);

glDepthMask(GL_TRUE);
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_TRUE);

The implementation seems good but the result is very strange. Indeed, when I draw an object in front of my lens flare, if this one is not far enough, the occlusion test is successful.

For example, if the current object is drawn at a Z-position of 0 and the sun flare is drawn at a Z-position of -1000. The test is positive, but if the sun flare is drawn at a Z-position of -10000, the test is negative as it should be.
Someone can find an answer to this problem?
Thanks by advance.

2

What is your perspective matrix? Keep in mind that non-orthogonal projections have a very non-linear behavior.

3

My perspective matrix don’t change between the drawing of the object (I know it is correct during this step) and the drawing of the lens flare (and it is not null).

4

There might be elements of your flare quad gemoetry which are fully transparent in the texture but which still poke out from behind your object, in which case it will pass the query.

It’s worth nothing that an implementation is allowed to fully support occlusion queries but yet have GL_QUERY_COUNTER_BITS of 0, although in that case the behaviour is supposed to be the opposite of what you’re getting. You should be doing a glGetQueryiv on GL_QUERY_COUNTER_BITS anyway, just to be certain.

Might be a driver bug.

Might be, as suggested, that your depth buffer precision is sufficiently low and the ratio between your near and far clipping planes is sufficiently high that 0 and -1000 resolve to the same Z, although this kind of problem generally doesn’t happen at the near end of the Z buffer (unless you’re linearizing depth in which case it very much does happen).

5

For example, if the current object is drawn at a Z-position of 0 and the sun flare is drawn at a Z-position of -1000.

If you are using a perspective matrix of the form that glFrustum would generate (i.e. standard frustum jazz), setting the near plane as close to zero (or negative) does very bad things. Could be that portions of the object are between the eye and near plane. Again, what is the perspective matrix you are using?

6

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.