Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Aug 2005
Offline Last Active Sep 12 2012 01:51 AM

Posts I've Made

In Topic: Z-Buffer Issues on Android

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?!

In Topic: Z-Buffer Issues on Android

10 September 2012 - 05:16 AM

Thanks for the answers!

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.

In Topic: Z-Buffer Issues on Android

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_RANGE = 0,000000, 1,000000

In Topic: Z-Buffer Issues on Android

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

In Topic: 2D lighting from multiple point sources on GLSL ES 2.0 in iPhone

06 September 2012 - 08:59 AM

I don't know about cocos2d-x or IPhone development. So my answer is purely shader oriented.
Because the shader does not seem complicated, and only evaluated once per pixel, is it really the shader that limits the application? (60fps are quite fast isnt it? Maybe it will drop down anyway later on)

- For the shader: You could try to use the squared distance, which maybe calculates faster than taking the root for calculating the distance.
The Lightsource can also directly save the squared radius instead of radius.
But be aware that using the squared values for the (adapted) mixfunction will change the lighting into some kind of quadratic attenuation (maybe a benefit ;-))
Still I dont think this will help alot.

- vec2 pos could be calculated within the vertex shader and interpolated as varying to the fragment shader, maybe this is minimal faster (or slower :-))

- Does the speed vary when you use 1 light compared to when you use 10 ? (In order to test if the uniform is valid for the loop condition)

- You could try to make a full screen mesh grid (for example 20x20) instead of one quad and evaluate distances in vertex shader -> interpolate in fragment shader (quality depends on your light source radii)

- If the lights are small you could render multiple smaller quads, one quad per light at the position of the lights (one quad per light) (But this would most probably need an extra pass)

These are just some fast thoughts, not sure if it helps. Still I think, the shader and the task does not seem like a real performance hitter.