The classic blend vs depth problem.

Jul 2, 2008 at 4:01pm

The classic blend vs depth problem.

Hi,

Here is a patch in which I tried to illustrate the problem as clearly as possible.

Plane A intersects plane B, A and B are both half-transparent. But they never blend as expected, like in the attached image. Either A blends with B or B blends with A, depending on which one is rendered first.

I know this problem is impossible to solve due to the hardware restrictions of the graphics card. But there have been miracles in this community before, so in case anyone comes up with a trick, feel free to let me know ;)

Mattijs

#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P comment 311 104 117 196617 2) toggle back and forth;
#P newex 291 126 27 196617 !- 1;
#P toggle 291 104 15 0;
#P message 346 147 49 196617 layer $1;
#P message 291 147 49 196617 layer $1;
#N vpatcher -694 87 -136 407;
#N comlet (bang) do it;
#P inlet 42 42 15 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 42 64 30 196617 t b b;
#P window linecount 0;
#P message 303 106 34 196617 reset;
#P newex 238 86 79 196617 t b b b b b b;
#P message 264 160 54 196617 color 255;
#P message 290 124 79 196617 moveto 50 230;
#P message 277 142 83 196617 font geneva 290;
#P message 251 178 46 196617 ascii 66;
#P newex 238 205 111 196617 jit.lcd 4 char 320 240;
#P newex 238 229 133 196617 jit.gl.texture ding @name B;
#P message 107 106 34 196617 reset;
#P newex 42 86 79 196617 t b b b b b b;
#P message 68 160 54 196617 color 255;
#P message 94 124 79 196617 moveto 50 230;
#P message 81 142 83 196617 font geneva 290;
#P message 55 178 46 196617 ascii 65;
#P newex 42 205 111 196617 jit.lcd 4 char 320 240;
#P newex 42 229 134 196617 jit.gl.texture ding @name A;
#P connect 17 0 16 0;
#P connect 16 0 6 0;
#P connect 6 0 1 0;
#P connect 7 0 1 0;
#P connect 5 0 1 0;
#P connect 4 0 1 0;
#P connect 3 0 1 0;
#P connect 2 0 1 0;
#P connect 1 0 0 0;
#P connect 6 1 2 0;
#P connect 6 2 5 0;
#P connect 6 3 3 0;
#P connect 6 4 4 0;
#P connect 6 5 7 0;
#P connect 16 1 14 0;
#P connect 10 0 9 0;
#P connect 11 0 9 0;
#P connect 12 0 9 0;
#P connect 13 0 9 0;
#P connect 15 0 9 0;
#P connect 14 0 9 0;
#P connect 9 0 8 0;
#P connect 14 1 10 0;
#P connect 14 2 13 0;
#P connect 14 3 11 0;
#P connect 14 4 12 0;
#P connect 14 5 15 0;
#P pop;
#P newobj 84 124 96 196617 p generatetextures;
#B color 5;
#P newex 60 220 509 196617 jit.gl.videoplane ding @texture B @blend_enable 1. @scale 3. 0.26 1. @rotatexyz 0. 45. 0. @color 1. 0. 0. 0.5;
#P toggle 60 58 15 0;
#P newex 60 77 57 196617 qmetro 40;
#P newex 60 99 58 196617 t b b erase;
#P newex 60 196 402 196617 jit.gl.videoplane ding @texture A @blend_enable 1. @color 0. 1. 0. 0.5 @scale 1.25 1 1;
#P user jit.pwindow 58 248 510 256 0 1 0 0 1 1;
#X name ding;
#P newex 60 147 166 196617 jit.gl.render ding @camera 0. 1. 4.;
#P comment 78 58 86 196617 1) turn on metro;
#P connect 6 0 5 0;
#P connect 5 0 4 0;
#P connect 4 2 1 0;
#P connect 4 0 1 0;
#P connect 9 0 3 0;
#P connect 10 0 7 0;
#P connect 4 1 8 0;
#P connect 11 0 12 0;
#P connect 12 0 9 0;
#P connect 11 0 10 0;
#P window clipboard copycount 14;

#38713
Jul 2, 2008 at 5:05pm

The most interesting solution I know to this problem is here:

http://www.shaderx6.com/TOC.html

“3.5 Deferred Rendering using a Stencil Routed K-Buffer by Louis
Bavoil and Kevin Myers”

It’s certainly non-trivial to implement but simple in concept. What
you do is write fragments that stack on top of each other into a
buffer such that when everything is drawn, you can sort them based on
z depth. They use the stencil buffer as a counter and a
multi-sampling texture hack with feedback to store the drawn
fragments. I know this is not terribly helpful right now, but I
thought I pass the info along since it’s the most efficient method to
do this that I’ve read about.

wes

#135207
Jul 2, 2008 at 5:20pm

Wesley,

This is definitely helpful, thanks! At least we have a clue where to look for a solution.

So what you’re saying is they render the objects separately and then sort them per pixel based on the z-depth? You’re right, that concept seems simple. But it sounds like swapping around a few megabytes per object for every frame. Although, as you say, if they did it in the book it might be time to see if we can transform the code from the book to Jitter :)

Mattijs

Quote: wesley.hoke@gmail.com wrote on Wed, 02 July 2008 19:05
—————————————————-
> The most interesting solution I know to this problem is here:
> http://www.shaderx6.com/TOC.html
>
> “3.5 Deferred Rendering using a Stencil Routed K-Buffer by Louis
> Bavoil and Kevin Myers”
>
>
> It’s certainly non-trivial to implement but simple in concept. What
> you do is write fragments that stack on top of each other into a
> buffer such that when everything is drawn, you can sort them based on
> z depth. They use the stencil buffer as a counter and a
> multi-sampling texture hack with feedback to store the drawn
> fragments. I know this is not terribly helpful right now, but I
> thought I pass the info along since it’s the most efficient method to
> do this that I’ve read about.
>
> wes
>
—————————————————-

#135208

You must be logged in to reply to this topic.