Jump to content

  • Log In with Google      Sign In   
  • Create Account

Z-Buffer Issues on Android


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 buddysk   Members   -  Reputation: 127

Like
0Likes
Like

Posted 06 September 2012 - 08:14 AM

Hi there!

I am facing a problem on an Android Application using GLSurfaceView.
The problem seems to happen only, when quite alot of objects are drawn.
Although most of the time, the depth test seems to work, there are some positions of the camera, when glitches appear. That is, objects in the back appear infront of nearer objects.

In order to track the problem, i visualized the depths (gl_FragCoord.z) within the pixel shader (z, pow(z,20), pow(z,80)). (the whiter the further away, red = really near)
Here is a combined image to show the problem. (alot of jeeps aligned in a x,z grid with a plane as bottom)
On the left all is working fine. The mid shows the "bug", the right image is the visualization of the fragment.z value for the mid image.

Posted Image


The fragment depths seems to be OK, but not properly used for visibility determination.
Is it possible, that the z-buffer gets corrupt/overflown/deactivated somehow?
Can a low framerate lead to a silent disabling of the depthbuffer?

Z-Fighting does only appear between objects that are near to each other, right? So in general a far away object should still not appear in front of a near one?

I don't know if it is a problem within my camera implementation, an android specific problem, or a general opengl thing.
Any help is appreciated :-)

buddysk


(The quadMesh on the floor is 40x40 centered around 0, near plane 0.1, far plane 100 (problem also appears for nearplan 1, far plane 1000))

(I sometimes notice, that a frame changes between the first draw and the succeeding ones. Is openGL allowed to drop drawing calls? And I "remember" to have once read that it is not guaranteed, that all drawing commands are executed within one batch?! Maybe there are two frames rendered and combined afterwards?! (just a wild guess))

Sponsor:

#2 dpadam450   Members   -  Reputation: 921

Like
0Likes
Like

Posted 06 September 2012 - 03:50 PM

No idea what I am looking at or where the bug is. You have 100 trucks packed together in 64x64 pixels. You could try increasing the depth buffer precision if you can on GLES.

#3 buddysk   Members   -  Reputation: 127

Like
0Likes
Like

Posted 07 September 2012 - 03:02 AM

Yes sorry, I must admit the images look quite chaotic. But when I reduce the amount of cars, the problem does not seem to happen.
The weird thing is, that it is always whole objects, that pop up in front of the others that are really near, so I don't think it is a pure precision problem.

It also seems to be always the latest objects that are rendered. When I render the base plate before the cars, it does not pop up.
Every object is drawn using GLES20.glDrawArrays(GLES20.GL_TRIANGLES, 0, _numVertices);

Maybe something like double buffering out of sync or clearing/loosing the depth buffer during rendering when the rendering call takes to long or the "pipeline" is filled up? Well sounds unlikely ...

Maybe this image does illustrate the problem better: See the left lane of cars popping up in front although they should be hidden.
Also note the car in the middle lane pop up in front.

Posted Image

#4 BornToCode   Members   -  Reputation: 925

Like
0Likes
Like

Posted 07 September 2012 - 11:06 PM

What do you have the depth buffer precision set to when you create your surface.

#5 buddysk   Members   -  Reputation: 127

Like
0Likes
Like

Posted 10 September 2012 - 02:52 AM

In the onCreate method of my Activity I only call
[source lang="java"]_glView = new GLSurfaceView(this);_glView.setEGLContextClientVersion(2);_glView.setRenderer(this);[/source]

When I query in onSurfaceCreated (like
[source lang="java"]GLES20.glGetIntegerv(GLES20.GL_DEPTH_BITS, tempInt, 0)[/source]
...), I get the following values:

GL_DEPTH_BITS = 24
GL_DEPTH_RANGE = 0,000000, 1,000000
GL_DEPTH_TEST = 1

#6 Katie   Members   -  Reputation: 1330

Like
0Likes
Like

Posted 10 September 2012 - 02:56 AM

Does it fail the same on another android device known to have a different GPU?

#7 Olof Hedman   Crossbones+   -  Reputation: 2822

Like
0Likes
Like

Posted 10 September 2012 - 04:24 AM

Are you sure you aren't accidentally disabling depth test, or clear the z-buffer between draw calls?

I agree it does not look like a precision problem, it looks like the zbuffer or the test is somehow switched off completely.

Though it does look like it might work within the object itself, thats what lead me to think that the z-buffer might be cleared between draw calls.

Edited by Olof Hedman, 10 September 2012 - 04:26 AM.


#8 buddysk   Members   -  Reputation: 127

Like
0Likes
Like

Posted 10 September 2012 - 05:16 AM

Thanks for the answers!

@Katie:
I currently have no other android device for testing. At the moment I am running it on a Samsung Galaxy S i9000.

@Olof Hedman:
I was looking for glClear in my whole project code. I am only calling it once, in onDraw and in the form of:
[source lang="java"]GLES20.glClear(GLES20.GL_COLOR_BUFFER_BIT | GLES20.GL_DEPTH_BUFFER_BIT);[/source]
Sadly I dont know how to log all gl calls, in order to verify there is no implicit glClear inbetween.
[source lang="java"] _glView.setDebugFlags(debugFlags | android.opengl.GLSurfaceView.DEBUG_CHECK_GL_ERROR | android.opengl.GLSurfaceView.DEBUG_LOG_GL_CALLS);[/source]
seems not to work for OpenGL ES 2.0, and the GLTracer tool is only supported by Android 4.1 and higher.
I will try to get some other device to test it on.

#9 Olof Hedman   Crossbones+   -  Reputation: 2822

Like
0Likes
Like

Posted 10 September 2012 - 05:49 AM

Have you checked for calls to glDepthMask? also, what is your glDepthFunc?

#10 buddysk   Members   -  Reputation: 127

Like
0Likes
Like

Posted 10 September 2012 - 06:21 AM

I only have one glDepthMask call at the beginning, and I set the comparison function to GL_LEQUAL.

I now tried different shaders for visualizing the depth:

One vertex shader A only calculated the gl_position.
The other vertex shader B also assigned a texCoord attribute to a varying.
This is more or less the only difference between!!

While shader B shows the artifacts, shader A doesnt ....
I can switch between the two shaders and see the artifacts present a not ...

Really seems to be some kind of memory thing?!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS