Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've working on a voxel like game like Minecraft, but I'm not sure how I should handle alpha. I've got the world split into chunks and I render each chunk, I have things like leaves which have alpha which is either on or off, but if you look through them you can only see other chunks which have already been rendered, here's a picture because I can't explain it.


It also works with leaves from the same chunk, for example if I'm looking through them from one direction to another then I can see the other leaves through the leaves, but if I'm looking the other way I get the same effect.

Almost every gotcha you can encounter in XNA is addressed by Shawn Hargreaves in his blog. blogs.msdn.com/b/shawnhar/archive/2009/02/18/…. –  ClassicThunder Apr 25 '12 at 17:45
I dont know if this is correct, but you seem to have only fully transparent objects and you can discard those in pixel shader so they wont be written to depth buffer. But i never tried this so I dont know about performance of this or even if its feasible with shader model 3. –  Kikaimaru Apr 25 '12 at 17:48
Ahh I got that to work, sort of, it works fine now but leaves etc which are past a certain distance just appear totally invisible. –  jacker Apr 25 '12 at 18:09

4 Answers 4

up vote 1 down vote accepted

In example you gave, you don't need any sort of alpha blending. (Pixel is either visible or not - and i suspect most of studd in minecraft like game will be like this)

You can just call discard in shader for pixels you want to be transparent (and they won't write to depth buffer)

(In XNA 3 it was possible to set RenderState.AlphaTestEnable which will do the same.)


If i'm not utterly mistaken, it's to do with the depth information. If you first render the transparent material before solids are drawn, it will skip rendering the solids becouse of the z-index. Render transparent materials afterwards as extra step.


You need to leave the rendering of objects with transparency to the end of your rendering cycle and, preferably, render them from the furthest away to the nearest (as this is generally more efficient. Inversely, non transparent objects are most efficiently rendered from the nearest to the furthest away).

To try this out initially, just put in a flag for each object to mark it if it has transparency then, in your normal render function, just run it twice, once where you only draw non transparent objects and then again for only transparent objects.

How would I go about rendering them from furthest to nearest? They're stored in the same vertex buffer. –  jacker Apr 25 '12 at 17:45
@Levi Thats a performance optimization that probably is not necessary. Most important thing is to draw the opaque items before the transparent ones. –  ClassicThunder Apr 25 '12 at 17:48
You would have to rearrange the vertex buffer. You may want to look at bsp trees. Alternately, because it's a blocks world, you should check out oct-trees and avoid drawing everything in one massive buffer. If you are reconstructing the buffer, just change that code to have two seperate buffers, one for transparent and one for non-transparent. –  OriginalDaemon Apr 25 '12 at 17:51
as Levi says, rearranging the blocks to be front to back or vice versa is a performance optimisation that isn't always necessary. But for a blocks world you should be using some tree structure and at the least culling blocks that are outside the view frustum. This is also good for collision detection. –  OriginalDaemon Apr 25 '12 at 17:55
There's no in between value, in the texture the pixels are either fully transparent or fully opaque. I'm pretty sure Minecraft doesn't rearrange the vertex buffer every time :/. –  jacker Apr 25 '12 at 17:58

I quite agree to Toni and OriginalDaemon. It's true that handling transparent objects need care.

Especially for tree which has both transparent part, and opaque part. At least, we have to draw it twice for optimum of quality of result for look & feel.

If it's relevant at all, please take a look at this link (from Riemers). It explains how to handle this stuff.

For brief (as it requires 2 passes/steps to accomplish this)

1: Draw only the opaque part (with the power of alpha testing function, and alpha reference value set) with z-depth writable enabled. This way your depth buffer will be correctly written by the actual tree!

2: Draw transparent part of tree. This will give a correct and better look & feel of group of trees.

You're done.

Please note as from my own experiment, it's up to your tree whether it's billboarding or polygons forming into itself. For billboarding, it usually require 2 steps above to completely give a better look & feel. But for poly-tree (as for my case), I can ignore step 2 and save cost but still have a decent look without much different.


Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.