Jump to content
  • Advertisement
hellgasm

OpenGL Texture filter and atlas image distortion problem

Recommended Posts

Posted (edited)

Hello,

I have a question about premultiplied alpha images, texture atlas and texture filter (minification with bilinear filter).

(I use correct blending function for PMA and all my images are in premultiplied alpha format.)

Suppose that there are 3 different versions of a plain square image:

1. In a separate file, by itself. No padding (padding means alpha 0 pixels in my case).
2. In an atlas in which the subtexture's top left corner(0, 0) is positioned on top left corner(0, 0) of atlas. There are padding on right and bottom but not on left and top.
3. In an atlas, in which there are padding in each of the 4 directions of the subtexture.

Do these 3 give the same result when texture is minified using Bilinear filter? If not I assume this means premultiplied alpha distorts images since alpha 0 pixels are included in interpolation. If so why do we use something that distorts our images? 

And even if we don't use premultiplied alpha and use "normal" blending, alpha 0 pixels are still used in interpolation. We add bleeding to overcome problems caused by this (don't know if it causes exact true pixel rendering though). So the question is: Does every texture atlas cause distortion in contained images even if we use bilinear (without mipmaps)? If so why does everyone use atlas if it's something that's so bad?

I tried to test this with a simple scenario but don't know if my test method is right.

I made a yellow square image with red border. The entire square (border included) is 116x116 px. The entire image is 128x128. 

I made two versions of this image. Both images are in premultiplied alpha format.

1st version: square starts at 0, 0 and there are 12 pixels padding on bottom and right.
2nd version: square is centered both horizontally and vertically so there are 6px padding on top, left, bottom and right.

I scaled them to 32x32 (scaled entire image without removing padding) using Bilinear filter. And when rendered, they both give very very different results. One is exact while the other one is blurry. I need to know if this is caused by the problem I mentioned in the question.

Here are the images I used in this test:

Image (topleft):
GbWGw.png


Image (mid):
IZ4jR.png

Render result:
07ZAn.png

I try to use x, y and width, height values for sprite which match integers so subpixel rendering is not intended.

Edited by hellgasm
Fixed img urls.

Share this post


Link to post
Share on other sites
Advertisement
1 hour ago, hellgasm said:

1. In a separate file, by itself. No padding (padding means alpha 0 pixels in my case).

1.) It has padding but images near the edges will have a stronger weight.

2.) Only if you don't use a Repeat mapping on the texture, if you are using a pre-made engine like Unity or Unreal, Repeat will be the default setting.

3.) Full padding. But if you don't leave space for padding it will sample the next image. Causing bleed.

2 hours ago, hellgasm said:

Do these 3 give the same result when texture is minified using Bilinear filter?

 @Angelic Ice gave me this example:

border-artifacts.png&key=bcb0ea447333ffabea0e6a9b7d35218e520f21fea76d8f72dc4e539995ed7e0b

The first image has no boarder to sample from and you get these ugly hard edges, where having a transparent boarder gives a better image sampled from the nearby sprites. This rotation shows it better but having more information provides better quality.

With a none rotating image the result isn't this much bit it can be noticeable at times.

2 hours ago, hellgasm said:

We add bleeding to overcome problems caused by this (don't know if it causes exact true pixel rendering though). So the question is: Does every texture atlas cause distortion in contained images even if we use bilinear (without mipmaps)? If so why does everyone use atlas if it's something that's so bad?

Bleeding is a artifact caused by having no boarder between sprites or textures. As you can see from the above example, having the little boarder in a atlas actually improves quality. Just don't set your sprites right next to each other, so there color bleeds into each other.

Atlases save on both memory and performance. Computers work with power of two 1,2,4,8,16,32,64,128,256,512,1024,2048,4096 etc... This is because of how binary and graphics cards work so keeping textures axis each in a binary saves performance.

If your character is 100 by 200 pixels you can store it on a 128*256 image and still have space on that image for small trinkets.

2 hours ago, hellgasm said:

One is exact while the other one is blurry. I need to know if this is caused by the problem I mentioned in the question.

You need to consider how bilinear filtering works. It takes 4 pixels and turns it into 1 when scaling down or it takes 4 pixels and makes 16 pixels.

Filtering.jpg.0e6884cda5a3232de17dbf06ef5ab275.jpg

So you see it either makes a single pixel from the colors of the 4 pixels or it fills the spaces by mixing a bit of the colors.If you don't provide the right amount of pixels you should expect problems.

The above is just a simple demonstration, bilinear is more advanced than just this.

 

Some unwanted blur can be passed from mip maps, that is why a lot of artist use DDS files, you can add sharpen effects to the mips that reduce quality loss. These days the mips can be made with very accurate scaling formulas,that prevent this.

If your image is seen at a angle or scaled at one axis more then consider Anisotropic filtering, it unlike bilinear also takes the objects shape into consideration when sampling.

 

 

In short, as long as you use proper mip maps, filtering and texture sizes there should be no problems. Filtering is cheap as far as performance goes and almost always produces better results.

There is so much to explain here so feel free to ask more. Showing your resulting renders will also help more than linking the textures.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!