Sunday 7 June 2009

Z-Buffer....

Ok, I'm finished with the 5th level!



It is just the same as my previous Mr Ball 2, the one which got stolen away by that idiotic thief. It's one tricky battle, but by the time you reach this level, I assume the player has beefed up Mr Ball a lot.

Anyway, from the video, I would like to highlight one horrible graphic problem which all game developers face, the z-buffer transparency problem. Well, I don't really care much about it, but for game developers who are developing high-class games, this is one serious matter as it can totally ruin the aesthetics of the game.

Anyway, here's a picture to show that z-buffer transparency issue:

If you look very closely, you can see that some part of the blue laser seems to "disappear". As you can see, it doesn't look very pretty, but because the lasers disappear quite fast, I don't really care whether you can see this graphic glitch. It's only for a brief moment anyway.

But why does that happen? Well, it all boils down to one of the 3D graphic things called the Z Buffer.

Now, Z Buffer is just something that helps to sort all the polygons in the 3d world, so that things that can be seen by the camera is rendered and parts of the other objects that are behind some other objects will not be rendered.

It's actually quite a useful tool. It just makes sure that parts of any object that hide behind another object will not be seen. Otherwise, everything will look funky.

But normal z-buffering does not take alpha transparency into account. Alpha transparency is just a fancy way of saying that an object is translucent or fully transparent.

This z-buffer transparency problem only arises depending on which order you draw the polygons. Here's a better example:


The red block is fully opaque, while the blue block is partially transparent. The textured block at the back is just to make things look clearer, sort of. Ok, from here, the drawing order is:
1) Textured Block
2) Red Block
3) Blue Block

But, in the following picture:

The drawing order is:
1) Textured Block
2) Blue Block
3) Red Block

In both cases, Z Buffer is on. In the second picture, you can see that part of the red block seems to have disappear, and there's only one simple cause for that - switching the drawing order.

If you're working with only opaque objects, this is not really an issue for you, but with the presence of partially transparent objects, this is just ugly, if you're aiming for super cool graphics, unless, of course, you wanted it like so.

What happened in the second picture is this:
-The Textured Block is drawn and it is written to the z-buffer
-The Blue block is drawn and it is written to the z-buffer. Nothing wrong yet, since it is drawn after the Textured Block. So, now, the Blue Block blends with the background according to it's alpha value.
-The red block is then drawn. The red block is behind the blue block. Now, here's the problem: because z-buffer will not allow the rendering of polygons that are behind another polygon, it "discards" part of the Red Block which is behind the Blue Block, and therefore, you can't see the Red Block behind the Blue Block, but you can only see the Red Block outside the Blue Block.

There are workarounds for this problem. Here's one of them:
First, draw all opaque objects. Then, draw all partially transparent objects from back to front.

Another workaround: Some might also consider turning off z-buffer while drawing partially transparent objects, but this poses another problem: Without the z-buffer depth sorting, objects that are drawn will hide everything beneath it, regardless of their distance from the camera. In other words, the visibility of the polygons depends on their draw order. Sometimes, this is okay. But usually, this is just annoying. To ensure proper drawing, you've got to work out your own depth sorting algorithm and sort all the polygons from back to front, then draw them in that order.

Well, that's all about the Z-Buffer Transparency problem. I have to go now. It's quite late already. hahahah

0 comments: