Wow, since our start 3 months ago we have covered literally most every aspect of voxel animation! There is but one area left I want to cover: translucency. By now, if you have followed us through you may have tried your hand a creating your own voxel program to suit your fancy, and if you've tried transparent things you may have encountered a problem. Because the drawn portions of voxels overlap, the drawing gets uneven and in some places can even look plaid or worse. Problem? You bet.

Voxel Render problems

• Solidity Make your voxel objects solid. This does not really fix the problem, but it can hurt framerates. Make your voxel model solid rather than hollow, if it isn't that way already. This can make the problem less apparent by making the voxel model look more or less transparent in different areas in a different way. Make it look more deliberate, and thus better.
• Hollowness If that didn't work or made the problem worse, you can hollow out the voxel model and make it more evenly transparent. This can have drawbacks too, because if it tries to be evenly translucent but has overlapping and has plaid spots, it is a lot more apparent than with solid models.
• Sprite caching This method is very difficult to do without a library like DirectQB, as you have to hide the drawing of the voxel model from the screen, and doing so in pure QB is kind of hard. What happens is you draw the model before hand, on a separate layer, and then you GET it into a separate array and blend it into the scene. This has the disadvantage of being slower, more memory-consuming, and much less versatile.
• Cuisineart Maneuver Change your blender map. I have found that using an additive or subtractive blender map instead of an average or weighted average map helps the appearance of blended voxel maps. This helps even more if you use it with the solid method above.
• Deal with it! Sometimes imperfection can be left in with no ill effects. Look at Quake. By all means, that game should not have left the shelf for all the graphical glitches. It is, mathematically, so incorrect that it's amazing it's even playable. Why does no one notice this? Because the graphics are done just barely well enough that the human eye can't see the errors unless you specifically look for them. If you make your action fast enough, it's possible that no one will ever notice. Michael Abrash (ASM programming God) wrote "Motion and fast action can surely cover for a multitude of graphics sins."

On to alternate projections
This article will deal exclusively with isometric projection because, of all the 3D projection methods out there, this is one of the best. It has the advantage of being quicker to calculate, and very easy to see and understand. The major downside is that it is very possible to make it look like something is in the wrong place - which is very annoying when you're trying to play a game! If you don't know how far you have to make the jump, you can't know if you're going to make the jump. I'll explain more later.

In the first installment of MA*SNART's 3D series, he gave us this algorithm for 3D projection:

x' = (((x - vx) / z) * 90) + vx
y' = (((y - vy) / z) * 90) + vy

(I will call this FPS projection from now on, as that is what it is primarily used for. That is, ALL FPS games use this formula.)

Where x' and y' are the projected coordinates of any point and vx and vy are the coordinates of the pixel in the middle of the screen. (Or they should be at least - if you ever have some free time you can play around with these and have some REAL fun.) The formula for isometric projection goes like this:

x' = (x - y) + vx
y' = ((x + y) / 2) + z

As you can see there is only one divide and everything else is add / subtract, making for a very fast algorithm. It's also amenable to all the same deformations FPS projection is - whatever you can do to a point there you can do to a point here and it generally looks just as cool. (The only thing I really miss is having the main character throw a missile right at the screen, and freeze-framing when the tip of the missile is so close to the nose of the player that my pentium's FPU can't tell they're apart at all so the missile is left there waiting to explode, and the player by this time has wet his pants because he _FINALLY_ made that big jump across the canyon and now, before he could hit quicksave, he's being destroyed by a pentium FP bug!!! But I digress.)

The problem with this I mentioned earlier - it often makes things appear in the wrong position. Take this example:

That looks, in the isometric world, like a long line of blocks but below is what it really is

Screenshot taken from Attack of the Blobeteers

Que? Believe it! The projection model has that one major flaw, that something in one position can appear to be in another. There is a very simple, very elegant way around it though - it's called rotation. Yes, it's true, if you rotate every point around the Z axis -8 degrees, it will make everything unmistakeable. Here's the formula to do that:

x' = cos(-8) * x - sin(-8)
y' = sin(-8) * y _ cos(-8)

Please note that the -8's in there need to be changed to -8 * (3.14159 / 180) because theta is in a different measure than degrees.

Now that you understand projection in Isometric form and everything there is to know about voxels, my work here is done. On the 23d of this month you will see a fine example of isometric perspective, that is, a demo of my game, Attack of the Blobeteers. Thanks for reading and I'll see you on the release date.

Alias doesn't know that rotated along the sine wave, z' = w* of the quaternion.