Question 1

Why must semi-transparent triangles be rendered in front-to-back (or back-to-front order) to achieve proper alpha compositing?

Solution:

Because composition is not commutative. A over B != B over A. You can see this in math:

(A over B) = (Ar + (1-Aa)Br, Ag + (1-Aa)Bg, Ab + (1-Aa)Bb)

(B over A) = (Br + (1-Ba)Ar, Bg + (1-Ba)Ag, Bb + (1-Ba)Ab)

More intuitively, students gave some good examples here.

Question 2

One of the nice properties of computing occlusion using the depth buffer (or "Z-buffer") is that the approach works just fine resolving occlusions when triangles interpenetrate (see slide 19). Now consider the case where the interpenetrating triangles are semi-transparent. What problem does this situation cause? (Hint: consider your answer to Question 1.)

Solution: Proper transparency in a rasterization-based renderer requires the objects covering each sampling point to be composited in depth order. However if objects interpenetrate, depth order of objects for one sample point might be different than the depth order of objects at another sample point. Therefore, there may be no single order of drawing geometry that is depth order for all samples.

Question 3 (optional)

Slide 33 gives pseudocode for alpha-compositing the results of rendering semi-transparent triangles. Why does the pseudocode NOT update the depth buffer when a triangle passes the depth test? (Notice this update was done in the pseudocode for rendering opaque triangles in slide 16. Why does the the pseudocode check the depth buffer at all? (Hint: see the discussion of combining opaque and semi-transparent triangles on slide 34.)

Solution: This answer is now given in the comments for these slides. The summary is that assuming opaque surfaces are drawn first, it is desirable to check the Z-buffer from drawing transparent surfaces so that transparent surfaces behind opaque surfaces are never drawn. However, when a transpareny surface contributes to the frame buffer, the depth-value should not be updated since objects behind the current object may still be visible. When rendering in front-to-back order we certainly want those objects to be compositing in when they are subsequently processed. When rendering in back-to-front order the depth buffer does not matter since all future geometry will be in front of the closest-so-far value in the depth buffer.