Jump to content
  • Advertisement

MattFranklin

Member
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

121 Neutral

About MattFranklin

  • Rank
    Member
  1. MattFranklin

    Strange z buffer artifacts GLES20

    Just played with things a bit more. I tried reducing the number of vertices in each tile to a quarter of their original number. The problem goes away. Each tile is still being drawn up to 16 times for each associated texture. If I force redrawing each tile twice, including all textures, the problem comes back. The number of redraws per tile, used for texturing, is the same for my original number of vertices and the version with a quarter of the number of vertices. As such I don't think it is a texturing problem. The size of the textures are the same in both cases. Since I am using VBO's I doubt it is associated with overall memory allocation as each redraw is simply referring to the same buffer. I have three theories that I am working with at the moment: 1) With the original number of vertices, the vertices are ending up so close togther that they are rendering to the same pixel more often. This causes an error in the z buffer 2) Some other buffer is being overrun as a result of multiple calls to render the same VBO. 3) I have an error in my VBO's, indexing and texturing that is causing the device driver to fall over somewhere during rendering. Any thoughts on other possible causes?
  2. MattFranklin

    Strange z buffer artifacts GLES20

    Just seen your responses to my previous post. How would you propose I use shaders to avoid redrawing the tiles? I need to apply up to 16 textures per tile. I'm fairly sure I can't use that many texture units at once.
  3. MattFranklin

    Strange z buffer artifacts GLES20

    It would seem that simply drawing each terrain tile more than once in a scene causes the artifacts to occur. Even if I draw the same tile with the same texture in the same location twice. I've got DepthTest set to GL_LESS so I expect that after the nearest tile is drawn the first time no more writes would occur. It would seem by drawing the tile more than once, despite the depth testing, some sort of error in the depth buffer occurs that allows tiles later in the pipeline to write to the screen. Anyone else seen this issue? Any ideas how I might fix it?
  4. MattFranklin

    Strange z buffer artifacts GLES20

    I've done some more digging. I am drawing the same terrain tile mulitple times and changing the texture between draws to generate layers on the scene. It would appear that drawing geometry multiple times in the same place causes the fault to occur. I'm guessing there may be a limit to the number of writes/overdraws that can be done on a scene before the depth buffer gives up. Any other ideas? Matt
  5. MattFranklin

    Strange z buffer artifacts GLES20

    I've tried incorporating normals into my buffer structure. As far as I can tell the normals information is ignored when it comes to front and back face culling. It is only used to calculate lighting. I don't have lighting in my scene so it isn't an issue. An I supposed to set any attributes in the shaders? I've tried turning Back face culling on and off with no change in the effect. when I turn Front face culling on I only get to see my terrain when I am under it as expected. Thanks for sticking with me. I'm wondering if it has anything to do with fast z calculations failing for some reason. Matt
  6. MattFranklin

    Strange z buffer artifacts GLES20

    I tried playing with logorithmic z buffer last night. Still seeing the same issue. It seems like the depth testing is simply being switched off or bypassed in some way. Any ideas would be very welcome.
  7. MattFranklin

    Strange z buffer artifacts GLES20

    My first thought was a z buffer fighting problem. so I have played with various near and far clipping planes. I have tried setting them to near=100 far=5000 and the same artifacts appear. I have tried setting the near to 1 and far to 1000 with the same results I have tried setting the near to 1000 and the far to 50000 with the same results. Even if I zoom in so that the near clip is close to the artifact location they still occur. The same thing happens randomly with the far clip close to the artifacts. In practice my near and far planes are recalculated based on how close I am to the terrain. The problem seems to be mostly caused by the skirts around the terrain which makes me wonder if it is a normal problem as they are at significantly different angle to the screen than the rest of the terrrain. If I render without skirts the problem is reduced but I still get terrain drawn at near the far clip range overdrawing terrain at the near clip range.
  8. 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
  9. MattFranklin

    Recreating Polygon Offset in shader

    Just noticed I posted my response twice. Apologies, I was not intending to be rude.
  10. MattFranklin

    Recreating Polygon Offset in shader

    FXACE what offset.z do you propose? I want to shift by one entry in the z buffer. Based on my understanding of the process I believe the values in mv_vertex are still in model space so have not been normalised and w=1. As a result I would need to offset x y and z to avoid any lateral shifting. As a result I believe that I should apply the following transform: z = length(mv_vertex); offset = z^2/((2^16-1)*Near) - z^2/((2^16-1)*Far) // taken from wikipedia dz/dz' mv_vertex = mvvertex * (z+offset) Does that sound sensible? It seems like a lot more calculation than applying offsets later in the process. The numbers are also likely to bust the floating point precision budget.
  11. MattFranklin

    Recreating Polygon Offset in shader

    FXACE what offset.z do you propose? I want to shift by one entry in the z buffer. Based on my understanding of the process I believe the values in mv_vertex are still in model space so have not been normalised and w=1. As a result I would need to offset x y and z to avoid any lateral shifting. As a result I believe that I should apply the following transform: z = length(mv_vertex); offset = z^2/((2^16-1)*Near) - z^2/((2^16-1)*Far) // taken from wikipedia dz/dz' mv_vertex = mvvertex * (z+offset) Does that sound sensible? It seems like a lot more calculation than applying offsets later in the process. The numbers are also likely to bust the floating point precision budget.
  12. 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
  13. 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 [size="2"]vec4 pos = mvpMatrix * vertexPoint; [size="2"]pos.w = pos.z/((z/w) + 1/(0.5s)); [size="2"][size="2"]gl_Position = pos; [size="2"]or even: [size="2"]float s = 65535 // 2^n-1 [size="2"][size="2"]vec4 pos = mvpMatrix * vertexPoint; [size="2"][size="2"]pos.z = pos.z + w/(0.5s); gl_Position = pos; [size="2"]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? [size="2"]Thanks in advance, [size="2"]Matt
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!