You will find 2 images here. The first one (imaginatively labelled One') shows the inside of a 3 layered cylinder. The two inner cylinders have been displacement mapped (or bumped’) and also alpha tested. This means that holes in the inner layer show bits of the 2nd layer, and holes in both layers show through to the outer layer.
(I won’t bother explaining what my application is). Anyway, obviously I’m not running the mesh at the same resolution as the texture, so there isn’t a one-to-one correspondance between texel and quad (actually, I’m using tri-strips, but you know what I mean).
Compare image one to image 2. Image 2 shows the `other’ side of image 2 and as you can see, the alpha test has culled away fragments of triangles where the texel alpha is zero, but as that texel probably stretches over many pixels, more of the fragment is being tested away than I want, leaving holes in the mesh and making it look awfully messy. What can I do to help with this problem? The only solution I can think of is to use one quad per texel and just not render a quad where its texel alpha is zero. However, with textures of up to 2048x2048 texels (depending on the user defined detail level) - I do not have the power to run such a large mesh in real-time (currently getting around 30fps with a GeForce 2 MX).
My second question is perhaps simpler. What are the rules for alpha test with multi-texture? When I use multi-texture, sometimes the fragments aren’t rejected with zero alpha - do I need to set the fragment alpha to zero and just use one of the texture alpha values to reject whole fragments? Or is each texture unit alpha considered seperately from the other?
In regards to alpha testing with multi textures I am not really sure. I am actually quite curious as too what the procedure is. Gonna have to look at the specs for a while.
I think the problem in the second image is rather too little depth precision. Push out your near plane and the z-fighting will get better.
You can test that by only rendering one ‘layer’ against a known background color. If the single layers look right, you’re not having alpha testing problems but depth resolution problems.
As for the second question, the alpha test operates on the final output of the complete texture blending pipe (if texturing is enabled). Only the alpha output of the last active texturing stage is used for the test.
Update: Actually I’m a bit lost on the language on color sum and fog regarding the alpha test. Intuition tells me that color sum should happen before the alpha test and fogging should happen after it, but I’m not quite sure right now.
/edit
The OpenGL block diagram indicates that both color sum and fog (which belong to the ‘rasterization’ stage) take place before the alpha test (which belongs to ‘per-fragment operations’).
[This message has been edited by zeckensack (edited 04-02-2002).]
I agree with zeckensack. I looked at the specification regarding alpha testing and it operates on individual fragments which are raster level, or more specifically after texture blending. So it is the final blending RGBA color or the fragment that goes into the alpha test.
It would be nice if alpha could be done first, tested and then possible the rgb computer upon passing. Actually now that I think about it that would be rather difficult. If doing multitexturing its no big deal but if using register combiners or a shader program and the like the output alpha value can be rather nontrivial.
I still find the alpha test to be useless but at the same time very good. If you do a lot of billboarding or anything that has a lot of empty pixels (alpha of zero) then it really helps out with the mem writes. In the projects I have worked on i generally didn’t even use alpha that much or when I did it was with multitexturing. In that case the alpha was used only by the texture units for blending and became useless by the time it got to the rasterizer.
I’m certain this isn’t a depth buffer problem - I don’t have any fighting in there (I’m using polygon offset anyway, because there was a lot of fighting between bits of the mesh with different heights).
However, the problem for me I think is the size of the fragment that is being alpha tested, given that it is more usually more than 1 pixel (at the very least, represented by more than one texel).
I guess this will be a problem until I have a 1 to 1 quad to texel representation (GeForce 5?).
In terms of the multi-texture - I suppose it must be done after texel combine but before everything else. I think the problem I have therefore is that one of my textures has dodgy alpha values - the other correct ones and where the dodgy overlap the correct, the dodgy wins!