A simple task: a Sky Dome. As the techie I am I did it in GLSL of course without the hack of a sky dome mesh but doing correct math on a full screen quad. Everything works fine with one problem and this is a mean interrupted line with garbled pixels from the top down the seam ( a spherical map texture ). I used the following for the texture ( 512x256 ):
This removed the seem. What is the problem here? Does OpenGL not support GL_LINEAR_MIPMAP_LINEAR on a 2:1 ratio texture? Or does GL_LINEAR_MIPMAP_LINEAR in general mock up at borders? It's just a very strange behavior that I think should not happen. How exactly does OpenGL decide what LOD levels to combine? Could it be due to the full screen quad which uses w=1 and rendering directly from (-1,1) to (1,-1)?
GL_LINEAR_MIPMAP_LINEAR Blends between the four texels nearest to the sample point and blends between the two mip levels that most closely match the size of pixel being sampled.
Well, that's the definition of GL_LINEAR_MIPMAP_LINEAR. So far I got too but this definition itself does not explain why a seem happens if used together with GL_REPEAT.
It depends on the texels you have in your mipmaps. Try to make your entire texture white. Also, make sure you let GL generate the mipmaps so call glTexParameteri(GL_TEXTURE_2D, GL_GENERATE_MIPMAPS, GL_TRUE) for each texture your create, and call glTexImage2D(....) to upload the texture. If you still get a seam, then you need make a stand alone demo that shows the problem.
Sig: http://glhlib.sourceforge.net an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
It's not a solitary problem. MipMap has a lot of problems and looks not so fine as it should. That said could it have an influence if the driver chooses auto-compression? Could this mess up MipMap?
Not to this degree. I suspect you're seeing the seam in the sky... as the ground gets filtered as suggested above.
I suggest to adjust your texcoords (not really recommanded) or simply use CLAMP, CLAMP_TO_EDGE and stuff like that.
Repeating, as noted, will cause the ground (typically dark) to go floating above the sky (typically light colours). As the kernel filter will interpolate around boundaries the dark ground creates a seam. This is the correct behaviour, regardless of mipmap, borders, drivers, compression or whatever.
No, it's not like this. I use a shader to calculate the proper UV coordinates right from the screen coordinates. At the border in U-Direction the MipMap messes up and produces the seem running from the zenith down to the equator along the welding point of the sphere. It only happens with MipMap on and works fine with only GL_LINEAR.
If you don't believe me, make a texture of a solid color and with the edge around that cube one pixel wide e.g. 256x256 texture make a border of 1 pixel around the other 254 pixels in x and y directions. Make the border yellow and the rest blue, and if they are sampled like I think they are you should see some green hue then.
I think you talk about a different situation. I have only the sky without any other geometry in front of it. The sky is a full sphere with one texture covering all so at the equator there is no seem ( since this is along the center line of the texture ). The seem is where the left and right side of the texture meets. The texture is continuous so the colors have no abrupt change in value. Hence it's not about dark color meeting light color but about two nearly identical colors meeting and the artifact seem has a color not being part of those two.
