• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
MattFranklin

Strange z buffer artifacts GLES20

14 posts in this topic

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
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote]I'm currently not passing any vertex or face normals with my geometry.[/quote]
And why not? The issue has nothing to do with depth as far as I can guess. It could have to do with normals and would be the first thing I would look at. Try glCullFace() and cull nothing.
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
? Are you using GL_LEQUAL or whatever the parameter for less than or equal to is in glDepthFunc?


And also normals are used for culling. That is the point of culling, surfaces that face away from the viewer.
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
[quote name='dpadam450' timestamp='1342479568' post='4959795']
[quote]I'm currently not passing any vertex or face normals with my geometry.[/quote]
And why not? The issue has nothing to do with depth as far as I can guess. It could have to do with normals and would be the first thing I would look at. Try glCullFace() and cull nothing.
[/quote]
http://www.opengl.org/sdk/docs/man/xhtml/glCullFace.xml

"glFrontFace specifies which of the clockwise and counterclockwise facets are front-facing and back-facing."

Culling is only dependant on winding order. Normals has nothing to do with it.
Culling is done per triangle. How should gpu decide wich is most important normal if every one point in different direction?
0

Share this post


Link to post
Share on other sites
I never wind my vertices so it is odd that mine has worked for 6 years. I'm curious to test this now and change the normal to see if it works. I even thought that years ago drawing my first triangle I screwed up the normal and one way it culled and one it didnt. You are correct in that a vertex normal would allow you to slightly see the triangle before its face normal is pointing at you.

[quote]I need to apply up to 16 textures per tile[/quote]
What? That is a lot for anything, let alone a GLES app, plus the fact is on a smaller screen. If it is supported you can use a texture array. Or worst case draw it two times with 8 texture applied at once. You can always disable depth writing for sub-sequent draws. You can use glPolygonOffset with one or both of the values being negative so bring the depth values closer to the viewer, but not the actual geometry. So it will draw the same but with pulled forward depth values so that it will pass the depth test against the previous terrain. Edited by dpadam450
0

Share this post


Link to post
Share on other sites
[quote name='dpadam450' timestamp='1342799635' post='4961347']
I never wind my vertices so it is odd that mine has worked for 6 years. I'm curious to test this now and change the normal to see if it works. I even thought that years ago drawing my first triangle I screwed up the normal and one way it culled and one it didnt. You are correct in that a vertex normal would allow you to slightly see the triangle before its face normal is pointing at you.
[/quote]

This maybe explain winding better.
http://www.arcsynthesis.org/gltut/Positioning/WindingOrder.svg

Vertex data allways have some winding. Either the triangles are in clockwise order or counter clockwise. Its just up to position.
And you can tell the gpu which winding means front face. And yes there is a default value so you don't have choose it if you don't care.



MattFrankling: you can query maximum supported texture units from gpu. This maybe could help you http://www.gamedev.net/topic/548400-glsl-max-number-of-texture-units-per-pass/
0

Share this post


Link to post
Share on other sites
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?
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0