How does the Painter's Algorithm handle transparency?

Question

I was wondering if anyone could explain how the Painter's algorithm would handle transparent objects? Can the Painter's algorithm handle transparency?

Answer 1

The common way to render transparent polygons in a rasterizer is by use of Alpha Blending, which basically combines the colour of the supposedly transparent pixel with the colour of the background at that pixel's position, this way rendering the pixel transparently onto what was already rendered before. This technique, however, requires your polygons (or at least the transparent ones) to be sorted from back to front, at least in general non-trivial cases, since you can only combine the transparent colour with what has already been rendered behind it.

But since the Painter's Algorithm already requires ploygons to be sorted from back to front (which is pretty much the entire essence of the algorithm), this just fits naturally into the rest of the algorithm. Thus, supporting transparency becomes rather straight forward by simply doing any variant of alpha blending of the pixel with the background instead of overwriting the background.

Answer 2

I would like to add that Painters' algorithm can be run from front to back with transparency provided your blending operations are associative. I would recommend reading Jim Blinn's "Compositing, Part 1: Theory". (Indeed, reading anything graphics related by Jim Blinn is highly recommended).

In this article, Blinn explains (amongst their other advantages) that premultiplied alpha blending operations are associative and, assuming "C" is the furthest polygon and "A" the closest, the usual the back-to-front blend operation $$Result=Blend(A, Blend(B,C))$$ can be replaced with $$Blend(Blend(A,B), C))$$

It does mean that you need to keep a destination alpha value with each pixel - you can't just assume each pixel is 100% opaque.

If you're unfamiliar with premultiplied alpha, the typical OpenGL "GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA" blend, i.e. $$DstOut_{RGB} := Src_A * Src_{RGB} + (1-Src_A) * DstIn_{RGB}$$

becomes $$\left[DstOut_A, \overline{DstOut_{RGB}}\right] :=\\ \left[Src_A + (1-Src_A)*DstIn_A, \overline{Src}_{RGB} + (1-Src_A) * \overline{DstIn_{RGB}}\right]$$

where $$\overline{X_{RGB}}=X_{RGB}*X_A$$

Notes:

• The operations are generally not commutative so, sadly, you still can't just process the polygons in random order.
• (IIRC, some games use(d) additive-only blending, e.g. for lighting effects, which is of course commutative and so can be done in arbitrary order)
• Additive blending can also be expressed in a premultiplied form as the colour [0, RBG_to_Add].

Answer 3

It may be worth mentioning that the reverse painter's algorithm does not handle transparency. If you read and understand @Chris's answer the reason for this is straightforward. Combining the already rendered color (using alpha blending) does not work if the objects behind your transparent object have not been rendered yet.