The Transparency Conundrum

You'll have to render semi-transparent objects after all the opaque objects. You're free to sort the objects within those two groups any way you like.

You'll have to render semi-transparent objects after all the opaque objects. You're free to sort the objects within those two groups any way you like.

The sorting of the semi-transparent objects matters. You have to sort them back to front for most situations. The only exception that I know of is if you are using cumulative transparency (accumulating colour*alpha in the colour buffer) and have depth writing turned off.

Graphics hardware has now advanced to a point where OIT (order independent transparency) is often just as fast, or even faster than the age-old CPU presorted transparent geometry. With the added benefit of pixel perfect transparency in all cases, the availability of much more advanced programmable blending and the possibility to easily add thickness dependent effects like refraction or fogging.

I've switched my engine to OIT some time ago, removing all this distance sorting crap. I never looked back.

How does order independent transparency work?

To OP: Your objects with any sort of transparency should have a separate bucket and it should be the last bucket to draw.

Graphics hardware has now advanced to a point where OIT (order independent transparency) is often just as fast, or even faster than the age-old CPU presorted transparent geometry. With the added benefit of pixel perfect transparency in all cases, the availability of much more advanced programmable blending and the possibility to easily add thickness dependent effects like refraction or fogging.

I've switched my engine to OIT some time ago, removing all this distance sorting crap. I never looked back.

I am very interested in hearing more about this. I had no idea we had progressed to this point. How does one go about achieving this OIT? I am using GLSL for all my rendering. What is the next step?

Me too actually... is this something exposed by the graphics card as a feature?

Things to google for would be "depth peeling", "weighted average" or "weighted sum" in combination with order independent transparency. Or get a quick overview of some methods (from 2008) here: http://www.slideshare.net/acbess/order-independent-transparency-presentation

Me too actually... is this something exposed by the graphics card as a feature?

No, it is not. It is a technique that you implement.

Things to google for would be "depth peeling", "weighted average" or "weighted sum" in combination with order independent transparency. Or get a quick overview of some methods (from 2008) here: http://www.slideshar...cy-presentation

cheers, should come handy

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.