Jump to content
  • Advertisement
Sign in to follow this  
RPTD

OpenGL incorrect pixels with GL_LINEAR_MIPMAP_LINEAR combined with GL_REPEAT

This topic is 3823 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 ):
Quote:
glTexParameteri( target, GL_TEXTURE_WRAP_S, GL_REPEAT ); glTexParameteri( target, GL_TEXTURE_WRAP_T, GL_REPEAT ); glTexParameteri( target, GL_TEXTURE_MAG_FILTER, GL_LINEAR ); glTexParameteri( target, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR ) );
I then changed the last line to
Quote:
glTexParameteri( target, GL_TEXTURE_MIN_FILTER, GL_LINEAR ) );
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)?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Because when the texture is sampled to filter it, it is going over the borders and using those values also.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!