开发者

Issues when processing an image using OpenGL ES 2.0

I made a simple app that takes an input image and outputs a processed one using a fragment shader. When using a 2^n image it's OK. But if I use a rectangular not-power-of-2 image I get a black stitch running from top to bottom.

This is the original:

Issues when processing an image using OpenGL ES 2.0

This is after being processed:

Issues when processing an image using OpenGL ES 2.0

Here's my fragment shader:

precision mediump float;
uniform vec2 uSize;
uniform sampler2D sTexture;
void main()
{
    gl_FragColor = texture2D(sTexture, vec2(gl_FragCoord) / uSize)
}

Where, uSize is a vec2 having the size of the image

Generally I can work with a power-of-2 textures, but as OGLES2 supports rectangular textures I was thinking of sparing myself some work.

Thanks!

UPDATE

Here go my vertices:

static GLfloat vVertices[] =
    {
     -1.0f,  1.0f, 0.0f,
     -1.0f, -1.0f, 0.0f,
      1.0f, -1.0f, 0.0f,

      1.0f, -1.0f, 0.0f,
      1.0f,  1.0f, 0.0f,
     -1.0f,  1.0f, 0.0f,
    };

And here is the vertex shader:

attribute vec4 vPosition;
void main()
{
   gl_Position = vPosition;
}

UPDATE

Now, that's strange. Here are the two triangles rendered separately (first using the first 3 vertices, and then using the next (last) three).

Here go for the square image (as expected):

Issues when processing an image using OpenGL ES 2.0

Issues when processing an image using OpenGL ES 2.0

And here are how the same triangles look for the rectangle image/texture. They look bizarre:

Issues when processing an image using OpenGL ES 2.0

Issues when processing an image using OpenGL ES 2.0

They don't look like triangles at a开发者_运维百科ll. Does anyone know what's happening?


Are we looking at a chunk of the image or the full thing ? Asking, because the triangle boundary does not align with the diagonal.

That said, every single non-artifact pixel is a perfect match between the 2 images, which I think rules out off-by-one errors that I thought of. Not only that, the artifact is actually based on a single of the color channels being completely wiped. (For each series of 3 pixels, the first one has R=0, the second has G=0, and the third has B=0).

All in all, this looks like an error that is completely unrelated to the shader or the drawing. Are you sure it's not something that stomps on the memory post reading ? It could also be a platform bug (h/w, driver ...). Is it reproducible on multiple platforms ?


Seems the drivers were bad. Updating them fixed the problem.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜