What can make the texture disappear in Opengl?

Question

I’m using a flame engine Engo, and made a Fork and I’m adding some things and at the same time trying to learn more about Opengl.

As it is a graphic question there is how to put an image of what is occurring:

All the images that create the square are the same, and all use the same texture sent to Opengl, just rotate and set the position:

It is a small edge, 8 pixels, the image is 128x128 pixels in total.

---

As you can see some of the "grids" get smaller or bigger, and depending until they disappear altogether.

This seems to be being caused by TEXTURE_MIN_FILTER, since he is responsible for determining what should be done when the image needs to be shrunk.

I saw that there are several types of TEXTURE_MIN_FILTER, since GL_LINEAR and GL_NEAREST and also others who require the Mipmap, with the NEAREST_MIPMAP_NEAREST.

To make work these parameters that need Mipmap you need to create the Mipmap, for this I used the GenerateMipmap shortly after the TexImage2D, in this way:

gl.TexImage2D(uint32(target), int32(level), int32(internalFormat), int32(width), int32(height), int32(0), uint32(format), uint32(kind), gl.Ptr(pix))
gl.GenerateMipmap(uint32(target))

Anyway, the problem still persists, and in fact it can get worse. When using Mipmap it turns gray:

Also, use any filter LINEAR (Whether you need Mipmap or not), it adds a small edge with distinct opacity:

I enlarged this image in Photoshop to make sure there was an edge, and it’s there.

Remember that the image is transparent inside and the edge is all the same opacity, there would be no reason to create an edge, if there wanted to know what would be the reason. And this behavior doesn’t happen in NEAREST.

---

The Vertexshader used is:

attribute vec2 in_Position;
attribute vec2 in_TexCoords;
attribute vec4 in_Color;

uniform mat3 matrixProjView;

varying vec4 var_Color;
varying vec2 var_TexCoords;

void main() {
  var_Color = in_Color;
  var_TexCoords = in_TexCoords;

  vec3 matr = matrixProjView * vec3(in_Position, 1.0);
  gl_Position = vec4(matr.xy, 0, matr.z);
}

Already the Fragmentshader used is:

#ifdef GL_ES
#define LOWP lowp
precision mediump float;
#else
#define LOWP
#endif

varying vec4 var_Color;
varying vec2 var_TexCoords;

uniform sampler2D uf_Texture;

void main (void) {
  gl_FragColor = var_Color * texture2D(uf_Texture, var_TexCoords);
}

The source code is on Github, if necessary. Obviously, the modifications I made, and mentioned above, are not there.

---

I am a few days ago looking for a solution to the problem, I mentioned here some attempts that came closer to give some result.

I wanted to know what could cause this problem and how could I fix it, if it is a problem with Opengl or if it might even be a problem in arrendomento when calculating the position, for example.

Although the code is in Golang it uses the same API in C, via CGO, and I am using Opengl 4.6

Answer 1

I don’t know if this should be an answer, or an issue to the question.

---

Among several attempts to solve the problem, the problem was actually mitigated using "power of 2", if that makes any sense to say so.

---

Textures

The textures were 100x100, however Opengl, from what I saw, only stores the textures in "power of 2", that is: 32x32, 64x64, 128x128. This way the texture would be saved in 128x128, regardless of the initial value be 100x100.

This had already been modified by the time I asked the question. But, this did not solve the problem, not alone.

Zoom ("Z axis")

The zoom was increased every 0.125, or the default would be 1. The first zoom level was 1.125 and then 1.25, then 1.375... The problem with this is that the textures had to be resized (either expanding or shrinking), TEXTURE_MIN_FILTER is really responsible for shrinking the image and he now uses still the NEAREST_MIPMAP_NEAREST.

Then, combining with the previous change (of the textures), making the zoom be also in "power of 2" solved the problem. That way the zoom can be: 1, 2, 4, 8, 16, this solved textures disappear. Even at higher values, as extremely far the texture is still visible in its original color.

O X/Y

The X/Y axis is also problematic and I haven’t found an exact solution. If you are in a point {X: 1, Y: 1} everything will be perfect, independent of the zoom (provided one of the values mentioned above). But, it doesn’t work if it’s in the coordinate {X: 6, Y: 6}, for some reason the thing doesn’t work, some lines get smaller than others.

I’m still hunting for a better solution.

The camera’s rotation was also locked for every 45º, rather than small steps of 0.1. It also made the lines not fall into limbo and disappear.

---

Anyway, this mitigated the problem. The texture size and the zoom and rotation levels solved the problem in general. There’s still some exotic case that causes the same problem, but it’s rare and I’m investigating.