View Full Version : Front to Back Alpha Blending

04-04-2005, 01:52 AM

I was wondering how could we achieve a front to back rendering that gives the same visual result than a back to front one.

Usually I use the formula :
Cd = (1-a)Cf + aC
Cd being the destination pixel(new frame buffer)
Cf being the pixel currently in the frame buffer
C being the pixel being treated and "a" its alpha value
I also do for the alpha :
Ad = (1-a)Af + aa (same thing as before with the color values being the alphas)

First, is this correct for a back to front rendering?

And how do we do a correct front to back rendering?(It is for a scientific visualisation program so I cannot afford such imprecisions)

Thanks in advance,

04-04-2005, 03:54 AM
This isn't correct.
Your blending operation isn't commutative. It appears to work out if you do one layer, but the result will be different if you overwrite a pixel multiple times.

If OTOH you'd work with purely additive blending, the ordering wouldn't matter.

Note that there's really no good reason to go front-to-back with blending. F2B sorting is beneficial for opaque geometry, because of early z mechanisms. For transparent geometry, you'd have to disable z writes if you render F2B. You gain nothing.

04-04-2005, 05:30 AM
W.r.t. the second question:

| |
| |-+---|
| A | | |
| | |B |
| |-+---|

Objects A and B intersect, c is the camera.
What do YOU think is proper front to back sorting? The closest point of the object, closest edge of the object, center of the object, farthest edge or farthest point.

If you ask me, there is no one "correct" way.

Purpose of front to back sorting is to allow early fragment elimination, so the hardware does not have to do a lot of frame buffer writes.

I personally would not even bother sorting my triangles front to back.
I'd sort my meshes by center point (or center point and radius), since that requires very little CPU power to do.
Let the 3D card do its early Z, and depth buffer calculations. That's what it's designed for.
It will also overwrite what surfaces weren't filtered through sorting, which means the results will be correct.

(Obviously with transparent surfaces, it's a completely different story - depending on your requirements, you need to sort back to front, you may need to do clipping, and you definitely need to do it at the triangle level)

04-04-2005, 06:46 AM
You can do pixel-perfect front-to-back and/or back-to-front sorting, by using a BSP-Tree. It will increase your trianglecount dramatically, though.


04-04-2005, 11:52 PM
Okay I just got it working by using an accumulator keeping trace of the alpha I go by in front to back, the result is exactly the same as back to front visually.

And yes the reason I achieve this in front to back is for early alpha stop(when I encounter a (very) opaque fragment.

Cheers, Jeff.