Hi, I’am trying to display some primitives (GL_QUADS) with transparency. I’ve got the strange effect, that the transparency depends on the order of drawing (i.e. the first created primitive can be seen if it’s located behind the second one, but not vice versa). Any help would be appreciated.
Thanks!
P.S. Please excuse my bad english
I don’t remember hadling transparency that good but I’ll give it a try.
To enable transparency you usually use glEnable(GL_BLEND);
Then the polygons are checked agains a function that you define with glBlendFunc. This function takes many options which define how the new pixels are computed according to the old value and the new value. Try thinking it this way, every pixel (or fragment?) of your polygon, carries with it its alpha value along with its color components. Depending on how you’ve set up your blend function, the value that comes in (the next polygon that you render) is multiplied or divided to the old pixel value, weighted by the alpha value. If the new pixel is opaque (not transparent) then it will overwrite the old value. This is why we first draw our opaque objects and then our transparent objects. I hope I’ve made myself clear. Also If someone else can confirm this or not because I’m not 100% sure. Hope I’ve helped. Good luck!
Originally posted by freshman:
Hi, I’am trying to display some primitives (GL_QUADS) with transparency. I’ve got the strange effect, that the transparency depends on the order of drawing…
This is simply right, parsing out polys to find correct rendering order is a problem. Never heard of order independant blending? No? Look below.
The problem is basically what moucard said.
Originally posted by moucard:
Then the polygons are checked agains a function that you define with glBlendFunc.
Not exactly. BlendFuncs and blending in general does not test. It does computations (as you are saying). Alpha testing is another thing.
Originally posted by moucard:
This function takes many options which define how the new pixels are computed according to the old value and the new value…
Just nice! I remember this formula-like thing:
<blendFunc>($source <srcFactor>, $destination <dstFactor> );
Where:
<blendFunc> is by default ADD, can also be SUBTRACT, REVERSE_SUBTRACT, MIN, MAX (in those two cases, <xxxFactor> are not used). In OpenGL this maps to the blend equation. I didn’t like this name so I have my own conventions (sorry to trouble your mind).
It works in a way so $source is always multiplied by <srcFactor> before getting processed by the specified function and the same applies to $destination and <dstFactor> (exception: see above).
$source is a “constant”, in the sense I can’t change it in the formula above. This is what should have been written to framebuffer at position (x, y) if blending were disabled.
$destination is similar to above but this is the actual framebuffer value.
<srcFactor>, <dstFactor>: in OpenGL those two togheter are called “BlendFunc”. Depending on the extensions supported / OpenGL version, those two can very. Im not sure, but constant blend color shall go there.
Originally posted by moucard:
If the new pixel is opaque (not transparent) then it will overwrite the old value.
Else some kind of interpolation will happen, as specified above.
Originally posted by moucard:
This is why we first draw our opaque objects and then our transparent objects. I hope I’ve made myself clear. Also If someone else can confirm this or not because I’m not 100% sure.
Maybe you’re clarified yourself but I don’t really understood this. However it looks correct to me. Good job.
EDIT: forgot to tell you about order independant transparency, in case you care.
This is really a joke, in the sense it’s all but order independant. In fact, it’s rather proper usage of GPU resources (mainly Z-test and stenciling) to peel away layers of geometry and finding correct rendering order on a per-fragment basis. Wow.
[This message has been edited by Obli (edited 03-17-2004).]
A simple solution that’ll work fine if you don’t have too many overlaps and you’re not particularly worried about slight changes in color is to disable depth testing while drawing your transparent polygons, and enabling it again as and when needed.