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.
Strange z buffer artifacts GLES20
I'm currently not passing any vertex or face normals with my geometry.
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?
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.
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.
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.
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/
Author
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?
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?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
