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

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

<p>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.</p>

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

<p>becomes 
 <span class="math-container">$$\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]$$</span></p>

<p>where <span class="math-container">$$\overline{X_{RGB}}=X_{RGB}*X_A$$</span></p>

<p>Notes:</p>

<ul>
<li>The operations are generally not commutative so, sadly, you still can't just process the polygons in random order. </li>
<li>(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)</li>
<li>Additive blending can also be expressed in a premultiplied form as the colour [0, RBG_to_Add].</li>
</ul>

CC BY-SA 4.0
2019-12-02T10:01:35.623Z
2019-12-04T09:26:40.030Z
2019-12-04T09:26:40.030Z
Simon F
<p>It may be worth mentioning that the <a href="https://en.wikipedia.org/wiki/Painter%27s_algorithm" rel="nofollow noreferrer">reverse painter's algorithm</a> <strong>does not handle</strong> 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.</p>

CC BY-SA 4.0
2019-12-02T09:38:07.227Z
Surely that will (or may) depend on what blend modes are being used? As long as they are "associative" (and you keep a destination alpha) it should be fine.  For example, if you use premultiplied alpha, you can go in either direction.

Please read Jim Blinn's "Compositing, Part 1: Theory"
Simon F
CC BY-SA 4.0
2019-12-02T08:53:50.780Z
2019-12-02T08:53:50.780Z
Levente Koncz
<p>The common way to render transparent polygons in a rasterizer is by use of <strong><a href="https://en.wikipedia.org/wiki/Alpha_compositing" rel="noreferrer">Alpha Blending</a>, which basically combines the colour of the supposedly transparent pixel with the colour of the background at that pixel's position</strong>, 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.</p>

<p>But since the <strong><a href="https://en.wikipedia.org/wiki/Painter%27s_algorithm" rel="noreferrer">Painter's Algorithm</a> <em>already</em> requires ploygons to be sorted from back to front</strong> (which is pretty much the entire essence of the algorithm), this just fits naturally into the rest of the algorithm. Thus, <strong>supporting transparency becomes rather straight forward</strong> by simply doing any variant of alpha blending of the pixel with the background instead of overwriting the background.</p>

CC BY-SA 4.0
2018-05-14T09:32:23.437Z
Thank you for your very helpful and perfectly explained answer :) Greatly appreciate it - just required an explicit explanation like the one above.
AC007
CC BY-SA 4.0
2018-05-13T23:49:57.573Z
2018-05-13T23:49:57.573Z
Christian Rau
<p>I was wondering if anyone could explain how the Painter's algorithm would handle transparent objects? Can the Painter's algorithm handle transparency?</p>

<rendering><algorithm><transparency><pixel-graphics>
How does the Painter's Algorithm handle transparency?
AC007
# How does the Painter's Algorithm handle transparency?

(Asked by: username_0 on 2018-05-13)

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

**Tags:** rendering, algorithm, transparency, pixel-graphics


---

## 3 answers

### Answer by username_3 on 2018-05-13. Score: 7 | Accepted answer

The common way to render transparent polygons in a rasterizer is by use of **[Alpha Blending](https://en.wikipedia.org/wiki/Alpha_compositing), 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](https://en.wikipedia.org/wiki/Painter%27s_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.

> **Comments:**
> **username_0**: Thank you for your very helpful and perfectly explained answer :) Greatly appreciate it - just required an explicit explanation like the one above.  

---

### Answer by username_1 on 2019-12-02. Score: 3

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 by username_2 on 2019-12-02. Score: 0

It may be worth mentioning that the [reverse painter's algorithm](https://en.wikipedia.org/wiki/Painter%27s_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.

> **Comments:**
> **username_1**: Surely that will (or may) depend on what blend modes are being used? As long as they are "associative" (and you keep a destination alpha) it should be fine.  For example, if you use premultiplied alpha, you can go in either direction.  Please read Jim Blinn's "Compositing, Part 1: Theory"  

---

