Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

glPerfect

Z Buffer

This topic is 6107 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!