Sign in to follow this  
TheBuzzSaw

The Transparency Conundrum

Recommended Posts

TheBuzzSaw    143
I have been working on my scene graph in C++, and I am fairly pleased with results so far. However, I have run into a major roadblock; I know I cannot be the first with this problem. I am curious as to what the accepted solutions are.

After my scene graph tree updates all the matrices, I place the items into buckets (to be rendered) organized primarily by shader. (I plan on sub-organizing by texture soon because I understand that to be an expensive operation as well.) However, now I am stuck on the issue of transparency. I have my buckets sorting the items by distance from the camera in order to properly render from back to front (for proper transparency). What do I do if I have items A B C D E where A C and E are in one bucket but B and D are in another? Do I really have to bite the bullet and rapidly switch shaders/textures to draw them in the right order? Is there another solution I am unaware of?

Share this post


Link to post
Share on other sites
inavat    317
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.

Share this post


Link to post
Share on other sites
bluntman    255
[quote name='A Brain in a Vat' timestamp='1307025855' post='4818677']
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.
[/quote]

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.

Share this post


Link to post
Share on other sites
Yann L    1802
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.

Share this post


Link to post
Share on other sites
TheBuzzSaw    143
[quote name='Yann L' timestamp='1307033293' post='4818727']
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.
[/quote]

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?

Share this post


Link to post
Share on other sites
Trienco    2555
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

Share this post


Link to post
Share on other sites
V-man    813
[quote name='Tachikoma' timestamp='1307085114' post='4818958']
Me too actually... is this something exposed by the graphics card as a feature?
[/quote]

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

Share this post


Link to post
Share on other sites
Tachikoma    575
[quote name='Trienco' timestamp='1307112197' post='4819062']
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: [url="http://www.slideshare.net/acbess/order-independent-transparency-presentation"]http://www.slideshar...cy-presentation[/url]
[/quote]

cheers, should come handy

Share this post


Link to post
Share on other sites
the_edd    2109
[quote name='dpadam450' timestamp='1307127643' post='4819182']
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?
[/quote]
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 [i]improved[/i] 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).

Share this post


Link to post
Share on other sites
Yann L    1802
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this