Jump to content

  • Log In with Google      Sign In   
  • Create Account


MattFranklin

Member Since 21 May 2012
Offline Last Active Aug 13 2012 04:52 AM

Topics I've Started

Strange z buffer artifacts GLES20

08 July 2012 - 05:39 AM

I'm looking for ideas as to what might be causing a rendering artifact I'm seeing in my app. My app renders a terrain using tiles with vertical skirts to cover the gaps between tiles. When I render I get parts of the far terrain overdrawing the nearer terrain (see attachment).

I have tried ordering the tiles from nearest to furthest away with no effect.
I have tried ordering the tiles from furthest to nearest with some improvement.

It appears that the depth test is failing on some parts of a triangle but not others. You can see that the top of the hill to the left is being drawn correctly and some of the bottom, but not the middle.
The parts of the scene that get overdrawn seem to change based on the viewing angle. i.e. I can shift by a degree in one direction and suddenly the overdraw dissappears.

I have checked that GL_LEQUAL is being used and depth test enabled.
I've tried using GL_LESS with no improvement
I've checked the blendfunc
I've checked different depthrange values with no real benefits.

Any ideas what the cause might be?

Are there certain overdraw limits or z buffer shortcuts that may be being applied on certain mobiles that I might need to consider? I'm using a Galaxy S.

I'm currently not passing any vertex or face normals with my geometry. Anyone had any experience of that causing issues with depth testing?

Thanks in advance

Matt

Recreating Polygon Offset in shader

21 May 2012 - 06:33 AM

I'm trying to create a silhouette effect by drawing outlines of object then filling with polygons. I'm trying to avoid offseting the polygons because it effects the look of other objects close to the surface. Therefore I am trying to offset the depth of pixels that have been drawn using GL_LINES. I am using a mobile device and can't call polygonoffset on GL_LINES, and I can't draw polygons using "GL_LINES" mode.

I believe the depthbuffer stores the value 0.5 + 0.5(z/w) with a range of [0,1]. The value used by gl_FragDepth = z/w with a range of [-1,1]

All I want to do is offset the depth value to the next resovable value in the depth buffer. For a 16bit buffer I thought I could use the following vert shader:

float s = 65535 // 2^n-1
vec4 pos = mvpMatrix * vertexPoint;
pos.w = pos.z/((z/w) + 1/(0.5s));
gl_Position = pos;

or even:

float s = 65535 // 2^n-1
vec4 pos = mvpMatrix * vertexPoint;
pos.z = pos.z + w/(0.5s);
gl_Position = pos;

Neither of these seem to work correctly across the range of depths. Any ideas what I may be doing wrong? Am I trying to do something impossible? Perhaps there is another technique I could use to draw silhouettes?

Thanks in advance,

Matt

Recreating Polygon Offset in shader

21 May 2012 - 06:30 AM

I'm trying to create a silhouette effect by drawing outlines of object then filling with polygons. I'm trying to avoid offseting the polygons because it effects the look of other objects close to the surface. Therefore I am trying to offset the depth of pixels that have been drawn using GL_LINES. I am using a mobile device and can't call polygonoffset on GL_LINES, and I can't draw polygons using "GL_LINES" mode.

I believe the depthbuffer stores the value 0.5 + 0.5(z/w) with a range of [0,1]. The value used by gl_FragDepth = z/w with a range of [-1,1]

All I want to do is offset the depth value to the next resovable value in the depth buffer. For a 16bit buffer I thought I could use the following vert shader:

float s = 65535 // 2^n-1
vec4 pos = mvpMatrix * vertexPoint;
pos.w = pos.z/((z/w) + 1/(0.5s));
gl_Position = pos;

or even:

float s = 65535 // 2^n-1
vec4 pos = mvpMatrix * vertexPoint;
pos.z = pos.z + w/(0.5s);
gl_Position = pos;

Neither of these seem to work correctly across the range of depths. Any ideas what I may be doing wrong? Am I trying to do something impossible? Perhaps there is another technique I could use to draw silhouettes?

Thanks in advance,

Matt

PARTNERS