[2.1] Weighted Blended-Order-independent transparency
-
- Halfling
- Posts: 84
- Joined: Tue Aug 02, 2016 6:07 pm
- Location: Germany
- x 12
[2.1] Weighted Blended-Order-independent transparency
Weighted Blended-Order-independent transparency.
Last edited by devxkh on Sun Dec 11, 2016 12:25 am, edited 2 times in total.
My little OGRE engine -> FrankE WIP
-
- OGRE Team Member
- Posts: 5436
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1343
Re: [2.1] Order-independent transparency
It's not in my priority list but just leaving some background, because I happened to answer a question about OIT a few weeks ago:
Regular alpha blending (trasparency) requires sorting back-to-front to do proper blending. When two triangles intersect, rendering in the right order is hard.
OIT techniques lift away this restriction by sorting in the GPU using linked lists or other complex structures, or doing depth peeling. Any of these options are horribly slow. AMD & NV have a few nice tech demos, but these demos really are pushing what's possible. These techniques are useful if you're doing engineering or scientific simulations because they produce correct outputs and displaying at 5 FPS or consuming several GBs of GPU memory is acceptable. However these options are all hard to maintain (e.g. using linked lists means you need to not only integrate the UAV-based rendering into your compositor pipeline, but also correctly estimate your maximum number of overlapping primitives that need to be sorted so you can reserve enough GPU RAM).
The only decent OIT algorithm is a hack known as Weighted Blended Order Independent Transparency. This is a hack and isn't "correct", as it cares for "looking good" more than looking correct, but when you have to deal with a lot of transparents and need high performance, Weighted Blended OIT is a very good solution.
Personal opinion: while WBOIT has a few drawbacks for being a hack, it's a very nice, fast & decent technique and the only one I'd bother supporting.
Regular alpha blending (trasparency) requires sorting back-to-front to do proper blending. When two triangles intersect, rendering in the right order is hard.
OIT techniques lift away this restriction by sorting in the GPU using linked lists or other complex structures, or doing depth peeling. Any of these options are horribly slow. AMD & NV have a few nice tech demos, but these demos really are pushing what's possible. These techniques are useful if you're doing engineering or scientific simulations because they produce correct outputs and displaying at 5 FPS or consuming several GBs of GPU memory is acceptable. However these options are all hard to maintain (e.g. using linked lists means you need to not only integrate the UAV-based rendering into your compositor pipeline, but also correctly estimate your maximum number of overlapping primitives that need to be sorted so you can reserve enough GPU RAM).
The only decent OIT algorithm is a hack known as Weighted Blended Order Independent Transparency. This is a hack and isn't "correct", as it cares for "looking good" more than looking correct, but when you have to deal with a lot of transparents and need high performance, Weighted Blended OIT is a very good solution.
Personal opinion: while WBOIT has a few drawbacks for being a hack, it's a very nice, fast & decent technique and the only one I'd bother supporting.
-
- Halfling
- Posts: 84
- Joined: Tue Aug 02, 2016 6:07 pm
- Location: Germany
- x 12
Re: [2.1] Order-independent transparency
I've read the same article and already tried to find the code in the engine to take look at it, but didnt find it.
Since i have no graphic programming skills, i would need "years" of my sparetime to implement this.
I didn't know that transparency is such a problem.
Since i have no graphic programming skills, i would need "years" of my sparetime to implement this.
I didn't know that transparency is such a problem.
My little OGRE engine -> FrankE WIP
-
- OGRE Team Member
- Posts: 5436
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1343
Re: [2.1] Order-independent transparency
I'm almost sure there's sample code in jcgt.org, just need to search for it.devxkh wrote:I've read the same article and already tried to find the code in the engine to take look at it, but didnt find it.
Since i have no graphic programming skills, i would need "years" of my sparetime to implement this.
Another part of the issue is that it's very broad and flexible. For example if you need additive blending, then you don't need OIT at all, because a + b = b + a; thus the order doesn't matter.devxkh wrote:I didn't know that transparency is such a problem.
The problem happens with alpha blending because a * w + b * (1-w) != b * w + a * (1-w)
So either you ensure each pixel is in the right order, or you approximate the result of the formula (which is what WBOIT does).