[OpenGL ES] NPOT Texture rendering (Z fighting) when using triangle fans to draw

Newbie & Debugging Questions
#1

I’m following along the book, OpenGL ES 2 for Android : A Quick Start Guide, in Chapter 8, texture rendering.

The codes I followed along were typed according to the book. The texture I used in my program is a custom 128x256 image, while the texture the book used is a 512x1024 image. I figured since both texture image ratios are the same, the textures shouldn’t be causing any issues.

Below is an image of a screenshot I took in Android, concerning the Z fighting.

And here’s the code, mostly the same as in the book.:


{
	private static final int POSITION_COMPONENT_COUNT=2;
	private static final int TEXTURE_COORDS_COMPONENT_COUNT=2;
	private static final int STRIDE=(POSITION_COMPONENT_COUNT+TEXTURE_COORDS_COMPONENT_COUNT)*Constants.BYTES_PER_FLOAT;
	
	private static float[] VERTEX_DATA={
		
		//using a different texture.
		0f,0f,0.5f,0.5f,
		-0.5f, -0.8f, 0f,0f,
		0.5f,-0.8f,1f,0f,
		0.5f,0.8f,1f,1f,
		-0.5f,0.8f,0f,1f,
		-0.5f,-0.8f,0f,0f
	};
	private final VertexArray vertexArray;
	
	public Table(){
		vertexArray=new VertexArray(VERTEX_DATA);
	}
	
	public void bind(TextureShaderProgram program){
		
		vertexArray.setVertexAttribPointer(
			POSITION_COMPONENT_COUNT,
			program.getTextureCoordsAttributeLocation(),
			TEXTURE_COORDS_COMPONENT_COUNT,
			STRIDE
		);
		vertexArray.setVertexAttribPointer(
			0,
			program.getPositionAttributeLocation(),
			POSITION_COMPONENT_COUNT,
			STRIDE
		);
		
	}
	
	public void draw(){
		//GLES20.glFrontFace(GLES20.GL_CCW);
		GLES20.glDrawArrays(GLES20.GL_TRIANGLE_FAN,0,6);
	}
}

The problem is in the center of the screenshot, the white link flickers through the blue portion of the texture rapidly. My guess would be that tje triangle fans were drawn incorrectly or something, but I couldn’t think of any other ways of drawing triangle fans that doesn’t work as it is supposed to do.

Any clues?

#2

I don’t think I see an issue, can you post an example of what it should look like?
Shouldn’t the book also include a site for all the resources you’re supposed to use?

#3

The white line shouldn’t be drawn going through the table, that’s it. I don’t have a good example available to show what it should look like, but here is the texture, and how it should look when it is laid flat, like in the screenshot.[quote]
[/quote]

The book’s example and my project are the same, I just swapped out the textures.

Is it okay enough?

#4

Why are you rendering 6 vertices? A triangle fan only requires 4 vertices to form a quad. If the problem really is Z-fighting, it’s because you’re rendering two overlapping triangles at almost the same depth. The flickering is due to rounding differences between the two triangles.

#5

I did check that already, but didn’t see an error. Of course theagentd is right that one only needs 4 vertices for a quad, but his approach should be correct too. He starts in the middle and then goes around the four corners (first needs to be stored twice).

I don’t get why the texture is so fucked up either.

#6

The texture is completely distorted, so his coordinates are incorrect in that case. Try rendering fewer vertices to narrow it down.

#7

Ok, I will try to cut down on the number of vertices.

More frustratingly, the rest of the Table-related codes are just initializing variables, loading textures, and binding them.

TextureHelper.java
http://pastebin.java-gaming.org/d44b6608a7e

TextureShaderProgram
http://pastebin.java-gaming.org/44b607a8e7d

#8

Some more pictures of the table flickering, taken within a second of each other: :clue:

Here is the updated code:


	private static float[] VERTEX_DATA={
		
		//using a different texture.
		-1f,    1f, 0f, 0f, 
		-1f, -1f, 0f, 1f,    
		1f, -1f,   1f, 1f
		//0.5f,  0.8f,   1f, 0.1f, 
        //-0.5f,  0.8f,   0f, 0.1f, 
        //-0.5f, -0.8f,   0f, 0.9f
	};

That is all I changed. It looks like there is more to the perplexed texture distortion.

#9 

       vertexArray.setVertexAttribPointer(
         POSITION_COMPONENT_COUNT,
         program.getTextureCoordsAttributeLocation(),
         TEXTURE_COORDS_COMPONENT_COUNT,
         STRIDE
      );
      vertexArray.setVertexAttribPointer(
         0,
         program.getPositionAttributeLocation(),
         POSITION_COMPONENT_COUNT,
         STRIDE
      );

I assume the first argument is the offset into the buffer. That should be in bytes, not components. You need to multiply that by 4 since you use floats.

#10

It didn’t change a thing when I multiplied the values by 4. I tried changing the GL_FLOAT to GL_UNSIGNED_BYTE, but it made the texture unrenderable.

Here’s the code for the VertexArray object:


package z.a.data;
import java.nio.FloatBuffer;
import java.nio.ByteBuffer;
import z.a.RenderView;
import java.nio.ByteOrder;
import android.opengl.GLES10;
import android.opengl.GLES20;
import z.a.Constants;

public class VertexArray
{
	private final FloatBuffer floatBuffer;
	
	public VertexArray(float[] vertexData){
		floatBuffer=ByteBuffer.allocateDirect(vertexData.length *Constants.BYTES_PER_FLOAT)
		.order(ByteOrder.nativeOrder())
		.asFloatBuffer()
		.put(vertexData, 0, vertexData.length);
	}
	
	public void setVertexAttribPointer(int dataOffset, int attributeLocation, int componentCount, int stride){
		floatBuffer.position(dataOffset);
		GLES20.glVertexAttribPointer(attributeLocation, componentCount,GLES20.GL_FLOAT, false, stride, floatBuffer);
		GLES20.glEnableVertexAttribArray(attributeLocation);
		//floatBuffer.position(0);
	}
}

I thought it is possible the buffer hasn’t been rewinded, but that didn’t work either.

#11

Since you’re setting the position of a FloatBuffer, the offset should indeed be in the number of floats. I was under the impression that you were using vertex buffer objects.

There’s a huge number of things that could be going wrong actually. Try changing the shader to not sample the texture. Instead just have it output the texture coordinates to the red and blue channels. You need to figure out exactly where it’s going wrong.

#12

Okay, if I can’t solve it, I may as well just call it unsolveable, and redo the whole thing over.