Z Buffer

Started by
13 comments, last by glPerfect 22 years, 3 months ago
Exist something like Z Buffering at OpenGL? glPerfect
Advertisement
yes
glEnable( GL_DEPTH_TEST);
i have enabled this Depth_Test, but i still have the problem that if the blending is turned on the the polygone in the background comes into the foreground.
i have enabled this Depth_Test, but i still have the problem that if the blending is turned on the the polygone in the background comes into the foreground.
Well it is my understanding that blending and the Z-buffer don''t get along too well. I think you have to draw all your non-blended polygons first WITH the Z-buffer, and then draw your blended polygons in a back-to-front order WITHOUT the Z-buffer.
Dirk =[Scarab]= Gerrits
is there no other way to solve the problem?
No, its the same in DirectX!
The problem is in how zbuffering works.

Basically, the zbuffer keeps track of how far away each rendered pixel is from the viewer. If we're drawing a pixel at distance 173, and the zbuffer value at that point is 140, then the pixel is behind something that's already been drawn, and so the pixel doesn't actually get output.

Put simply, with a zbuffer, a pixel is not draw if it is obscured by a nearer pixel. That's normally fine, because if a pixel is obscured, you obviously can't see it, so drawing it would be the Wrong Thing.

With blending, on the other hand, a pixel may only partially obscure another pixel. If I'm drawing two 50% opacity faces, one behind the other, and I draw the nearer one first, I don't want the zbuffer to be updated with the position of that face's pixels, because they would be deemed to obscure those behind - the far face would be invisible, which is also the Wrong Thing.

The technique used is to draw all 100% opacity faces first, using the zbuffer, then you draw all <100% opacity faces without the zbuffer.

PS. Surely it can't be right to turn the zbuffer of entirely? If we have a semitransparent face partially obscured by a opaque one, then don't we need the zbuffer to know which pixels on the former face are obscured by the latter, and shouldn't be drawn?

PPS. Apparently you're meant to draw your blended faces front-to-back, or the blending isn't quite right. Although I would have though blending was communative, there's another potentially good reason for that order: if you have ten 99% opacity faces lined up, the furthest face will probably not be able to contribute anything to the colour of each pixel. If you draw them back-to-front, you are obliged to drawn the far face anyway. If you draw then front-to-back, then the rasteriser may be able to figure out that the far face can't contribute anything. Whether or not this actually happens, I don't know.


This is wrong. The correct order is back-to-front. See later articles in this thread for clarification.


Uuuuuulrika-ka-ka-ka-ka-ka

Edited by - Mayrel on October 24, 2001 12:58:54 PM

Edited by - Mayrel on October 25, 2001 11:14:55 AM
CoV
You should first draw all non-blended primitives, and then draw all your alpha blended primitives in *back-to-front* order. The Z buffer should be enabled the whole time, since (as mentioned) you can''t be sure that a blended primitive won''t be (partially) covered by a non-blended primitive. You should also always draw them in back-to-front order, since many cards won''t blend correctly otherwise.

Drawing front-to-back is a good idea for non-blended primitives, because the Z buffer will be ''covered'' faster, thus saving some time by not rasterising far-away pixels that would be overdrawn anyway. However, since alpha blended primitives are (partially) ''transparent'' you want those far-away pixels to be rendered, since they will be visible ''through'' the blended pixels.

I hope you get what I mean, otherwise please post and I''ll try to explain a bit better (or maybe someone else can).

This topic is closed to new replies.

Advertisement