Alpha Blending: To Pre or Not To Pre

Alpha Blending is a small--but important--part of virtually every 3D application. Conceptually, alpha-blending is used to communicate the transparency of a surface. Generally, consumer applications (games) tend to use RGB to communicate the color of the underlying surface, relying on the alpha channel to indicate the "opaquness" of that color. More specifically, when alpha blending is enabled in the pipeline, developers tend to use this form for their blending:

In old, fixed functionality, this would be known as "SourceAlpha, InvSourceAlpha"; also known as "post-multipled alpha." However, this form of alpha blending suffers from a critical flaw: it results in the wrong color in many cases! The simplest of these cases can be illustrated with a simple, two pixel image:

One red pixel with red = 1 and alpha of 1, one green pixel with green = 1 and alpha 0.10

Consider the above image, whose resolution is 2x1 pixels. The artist wanted to communicate that there was a red, opaque pixel adjacent to a green pixel that would just give the slightest tinge of green to objects behind it. However, something interesting happens when we generate the next mipmap level, the 1x1 level. The result is probably surprising; the resulting mipmapped texel is this:

RGBA = (0.5, 0.5, 0, 0.55)

As we approach this mipmap level, we will get a very different result than when working with the 2x1 level--entirely because we decided to use postmultiplied level. You can see this in the following images:

Three versions of the canonical image test "mandrill". The first, the original mandrill. The second contains the mandrill when blended with our 2x1 image, and the last is blended with the 1x1 mipmap of the 2x1 texture.

Enter Pre-multiplied alpha

With pre-multiplied alpha, we multiply the texture components by the alpha component first, before storage. We also modify the blend function, changing SourceColor.a to One:

This is much more reasonable. We've still lost some information (and note that if the green component were small enough, or if our precision is too low the green will drop out entirely), but we've preserved the intent of the higher resolution mipmap. For comparison, here are the images again, with the addition of our pre-multiplied blender:

All versions of the mandrill. In top-to-bottom order, the original mandrill, the original mandrill covered by our pre-multiplied alpha 2x1, the post-multiplied alpha 2x1, the pre-multiplied 1x1 and finally the post-multiplied 1x1.

Transitioning from our post-multiplied world

Conveniently, the conversion from a post-multiplied alpha pipeline to one utilizing pre-multiplied alpha is trivial. At texture save time, or asset baking time, or even load time, multiply each non-alpha channel by alpha. That is:

And don't forget to modify your "alpha blending enable" to use One for the Source Alpha value. If we plug in pre-multiplied alpha to the original blending equation, it's easy to see that switching to pre-multiplied alpha gives us the exact same result:

So you might be asking: If the result is the same, why bother with pre-multiplied alpha? The reason is texture filtering. When you take samples from a texture, unless you have disabled texture filtering, the hardware is blending neighboring texels together and returning a weighted average as a result. With traditional post-multiplied alpha, this result will be incorrect. If your browser supports WebGL, you can play with pre- and post- multiplicative blending below: