All I see in that OIT link is "we need more passes". Sounds pretty lame, why is that better or faster than sorting a few transparent obejcts within your view?

All I see in that OIT link is "we need more passes". Sounds pretty lame, why is that better or faster than sorting a few transparent obejcts within your view?

Any triangle sort is imperfect (c.f. pitfalls of painter's algorithm). Rendering transparent objects inside other transparent objects also becomes possible.

I'd have to defer to Yann L's experience in the matter with respect to the possiblity of improved performance, but I can confirm that it's certainly feasible, even on 4 year-old graphics hardware if the objects in your scene have limited depth complexity, which is often the case in games.

With depth peeling, if you render front-to-back you can choose the performance/accuracy cut-off point too, by limiting the number of layers (you might do your peels back-to-front instead if you were after a perfect render and wanted to save some memory).

There are many different approaches to OIT, depth peeling is only one class of algorithms. Just Google for order independent transparency, there are myriads of papers out there.

You can peel from the front, from the back, from the front and back at the same time, or even multiple layers in batches. The number of peeled layers can be dynamically adjusted to what is needed for a particular frame, so to not overpeel.

On modern DX11 hardware you can do the transparency sorting per-pixel, directly on the GPU, without any multipass peeling.

And multiple passes are not a big deal either. GPUs are really good at that. However, GPUs are really bad at handling lots of small geometry batches submitted via the CPU. And the latter happens easily if you have slightly more complex transparent objects in your scene. In fact, CPU-sorted transparent geometry is the worst case scenario for batching, because you need fine spatial granularity in order to get good sorting results. OIT doesn't suffer from this issue, you can just send all your transparent geometry in big GPU-friendly batches, just as you would (should) do with opaque geometry.

In conclusion, if the complexity level of the transparent geometry in your scene is anywhere above the occasional window glass quad, then OIT is definitely worth the try. On modern GPUs, it is really damn fast. And the quality is in a totally different league than the CPU sorting approach, both in terms of spatial resolution (intersecting transparent faces, transparency-in-transparency, etc) as well as in terms of the actual shading you can apply (since you are not limited to the old fixed-function blending anymore).

Just go ahead and try it. The basic algorithm is really easy to implement. And if it looks good to you (it will !), then you can use more advanced algorithms to speed it up. I shiver at the thought of having to implement a CPU sorted approach ever again. It feels so primitive compared to OIT, a bit as if you had to write a renderer without having a z-buffer.