[2.1] Weighted Blended-Order-independent transparency

What it says on the tin: a place to discuss proposed new features.
Post Reply
User avatar
devxkh
Halfling
Posts: 84
Joined: Tue Aug 02, 2016 6:07 pm
Location: Germany
x 3

[2.1] Weighted Blended-Order-independent transparency

Post by devxkh » Sat Dec 10, 2016 10:27 pm

Weighted Blended-Order-independent transparency. :)
Last edited by devxkh on Sun Dec 11, 2016 12:25 am, edited 2 times in total.
0 x
My little OGRE engine -> FrankE WIP

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3662
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 109
Contact:

Re: [2.1] Order-independent transparency

Post by dark_sylinc » Sat Dec 10, 2016 11:51 pm

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.
0 x

User avatar
devxkh
Halfling
Posts: 84
Joined: Tue Aug 02, 2016 6:07 pm
Location: Germany
x 3

Re: [2.1] Order-independent transparency

Post by devxkh » Sun Dec 11, 2016 12:25 am

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.
0 x
My little OGRE engine -> FrankE WIP

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 3662
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 109
Contact:

Re: [2.1] Order-independent transparency

Post by dark_sylinc » Sun Dec 11, 2016 4:10 am

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.
I'm almost sure there's sample code in jcgt.org, just need to search for it.
devxkh wrote:I didn't know that transparency is such a problem.
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.
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).
0 x

Post Reply