Hello,
I'm having a problem when creating textures with the Mali texture compression tool. I'm following this Mali tutorial to create a separate alpha mask that handles the alpha channel from an ETC1 texture using Method 2 as described. I managed to get this working but it appears that little white lines or artifacts are appearing round the edges where the alpha parts of the image meet the opaque parts. My current blend function is (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). This was the only blend function that would allow this to method to work. Maybe there is another blend function that would change this and rectify the problem. Or maybe some other setting in OpenGL, I aslo posted this on the OpenGl forums.
I think the problem may go away or be less noticeable if the first generated texture that contains the real RGB values has black for the transparent areas instead of white. Mali Compression tool sets the alpha areas to white and there is no option to change this in the tool. I also noticed that in the texture compression tool Texture Packer. When you generate .pkm files with that tool it sets the alpha areas to to black, which further supports this theory. As it is such a simple change, it would be great if the people who develop Mali could realease an update that allows you to set the colour of the transparaent areas in the generated image.
If anyone has any other insight on this problem that would be great.
EXTRA INFO:
OpenGL ES 2.0 (only supports etc1 not etc2)
The white borders you have are basically hitting a problem with post-multiplied alpha blending (which is how the API-level filtering and blending in OpenGL ES works, because it is fast and inexpensive to do in hardware). If you store textures using the normal post-multiplied approach the typical "buggy" behaviour is explained by the following example:
Imagine two neighbouring pixels [1.0, 0.0, 0.0, 1.0] (red, fully opaque) and [0.0, 0.0, 1.0, 0.0] (blue, fully transparent). If you sample in the mid point with bilinear filtering then you would logically expect "half transparent red" but because the channels are blended independently you would end up with half transparent purple [0.5, 0.0, 0.5, 0.5] even though the original blue color is never actually visible because of the transparency.
The fix to this is a technique called pre-multiplied alpha; simply multiply the RGB channel values by the A channel value before compressing them. As you imply this should mean black for areas where A is 0.0, but it will also scale colors in areas which are partially transparent.
As far as I can tell the Mali Texture Compression Tool doesn't do this, but you can do it easily enough using ImageMagick. The necessary command line is:
convert <original_texture.png> -write mpr:temp -background black -alpha Remove mpr:temp -compose Copy_Opacity -composite <premultipled-texture.png>
... and you can just compress the output texture "as normal" using the texture compression tool.
IMPORTANT It's worth noting that this fix isn't transparent to the application logic - you will need to "correct" the OpenGL ES blend equation for any alpha blended fragments (as well as any manual blending you do in shader code) if you want to keep the weighting of the color channels correct, because the source alpha has already been factored in due to the pre-multiplication. Set the source alpha in the blend equation to GL_ONE rather than using the alpha value out of the texture.
@ lorenzodalcol supporting this in MTC seems like a useful idea.
HTH, Pete