8 replies to this topic

[larspensjo]

There has been discussion about this, but I have a case I can't fix. As can be seen in the attached picture, there is a white line above the flowers I can't get rid of. The details are as follows:

• I draw the flowers on a simple quad. The bitmap I send to OpenGL contains no visible white.
• I use mipmaps with GL_NEAREST_MIPMAP_NEAREST.
• The bitmap is of the format GL_RGBA8. The alpha channel is either 0 or 255 (yes, I will probably switch to GL_RGB5_A1).
• The fragment shader doesn't use blending, it uses the alpha to discard pixels.
• I use GL_CLAMP_TO_EDGE for S and T.
• The color of the transparent areas are pure white (Photoshop makes it that way). I think some of this white is bleeding through. Although, a little bit of the line is black sometimes (flickering depending when turning camera).
• If I don't use mipmaps, the problem goes away.

What am I missing?

Attached Thumbnails

• 

[Ashaman73]

I would bet, that you put multiple pictures on a single texture and your flowers are only mapped to limited part of your texture (aka texture atlas) ?

In this case read this thread, even if it sounds differently at first, it is most likely the same problem and should be solved in a similar way (add border).

[HolyDel]

may be problem in texture?
are you sure that all white pixels with alpha less in you discard value in fragment shader?

[Erik Rufelt]

Those areas shouldn't be white. When your mipmaps are created the mipmap pixels are set to the average of several pixels in the larger mip-levels, which causes part of the white pixels to be included in non-transparent pixels. Also, alpha will no longer be 0 or 255, but will also be averaged over several pixels. Depending on what your discard threshold is this can change behavior.
Change those white pixels to mirror the color of the edges of the flower. There are Photoshop plugins that can do this automatically.
Found this with Google: http://www.flamingpear.com/download.html Download the Free filters at the bottom. The filter you want to use in Photoshop is called Solidify.

[larspensjo]

may be problem in texture?
are you sure that all white pixels with alpha less in you discard value in fragment shader?

Thanks, this enabled me to fix the problem! In my shader, I used the condition "if (alpha=0) discard;". I changed it to "alpha<0.5", and the extra lines are gone. Obviously, not all transparent area had alpha exactly 0 when using mipmaps. This is a little funny, as I used "GL_NEAREST_MIPMAP_NEAREST", and the original bitmap only has alpha 0 or 1. Something funny is happening when using mipmaps. If I turn the mipmaps off, there are no lines anymore, which would indicate that there are no half-way values of alpha in the original bitmap.

Of course, comparing a float against exact equality to 0 is dangerous sometimes. But in this case, the threshold seems to be 0.33 (after some trial-and-error testing)

When your mipmaps are created the mipmap pixels are set to the average of several pixels in the larger mip-levels, ...

Thanks for the suggestion, which is the obvious answer, but probably not relevant as I don't use interpolation or averaging.

[Erik Rufelt]

Of course, comparing a float against exact equality to 0 is dangerous sometimes. But in this case, the threshold seems to be 0.33 (after some trial-and-error testing)

When your mipmaps are created the mipmap pixels are set to the average of several pixels in the larger mip-levels, ...

Thanks for the suggestion, which is the obvious answer, but probably not relevant as I don't use interpolation or averaging.

OpenGL uses averaging when creating mipmaps. Your problem has nothing to do with floating point comparison, in which case 0.33 would be a ridiculously high threshold for a number between 0 and 1, but the fact that mipmaps use averaging even with GL_NEAREST_MIPMAP_NEAREST. Mipmaps are defined that way, and level 2 will always be half as wide and high as level 1, and each pixel in level 2 will be the average of 4 pixels in level 1. That way your alpha values could be 0, 0.25, 0.5, or 1.0 in the first created mipmap. In the next level it could have any possible average of 4 of the previous levels values.

[larspensjo]

OpenGL uses averaging when creating mipmaps.

I see, I have misunderstood how mipmaps were created. The

GL_NEAREST_MIPMAP_NEAREST controls how the mipmap is used, not how it is created. I also found, as could be expected, that using 0.5 as threshold for the alpha made some pixels go away that shouldn't. In that case, the problem was the other way around.

The problem is that I get alpha values between 0 and 1, but I have a pixel culling algorithm in the fragment shader that depends on the alpha being either 0 or 1.

I am not sure if this design can be combined with the use of mipmaps?

[Erik Rufelt]

The problem is that I get alpha values between 0 and 1, but I have a pixel culling algorithm in the fragment shader that depends on the alpha being either 0 or 1.

I am not sure if this design can be combined with the use of mipmaps?

You can create the mipmaps manually, and use an algorithm that doesn't do that. For example, instead of averaging 4 pixels, you can use the maximum value, or the minimum value, or the median, or the average of only pixels with alpha = 1, or similar.
How do you create mipmaps?
glTexSubImage2d can be used to manually specify a separate image for each mip level, which allows you to control how the different mip levels look.

[larspensjo]

You can create the mipmaps manually

That seems to be the way to go. And it looks like the natural way, as I have my own special requirements on them. The algorithm with averaging only those pixels with alpha=1 looks promising.

Today, I am simply using glGenerateMipmap(GL_TEXTURE_2D);