I am rendering terrain and putting some grass on it. Grass is gif texture with alpha channel on quad. What I get is strange - from one side of grass1, since it is transparent I can see other grass2 and terrain through it, but when I move to the other side of grass2, I can’t see grass1 but I still can see terrain through it! ??? Something with depth_function or blend_function or… ??
On screenshot below notice how grass 2 is cut of on the edges…
your polygons are 2 sided ?
Do you depth-sort your blended stuff from back to front?
yes, they are two sided. As you can see on pic, from the “back” you can see poly, texture (grass), even terrain behind, but another grass being cut off. From the “fromt” this is not happening. When I play with different depth function, I can get to see grass behind, but now it is in the front… So, it is not transparency problem after all, I think, but something with rendering order and depth function (now it is GL_LEQUAL)
erikd, I don’t know what you mean?
You should sort the blended polygons (your grass tiles) on the depth, so that the most distant grass tiles will be rendered first, the nearest last.
Not if you use AlphaFunc and only pass 1.0 alpha values, which is perfectly acceptable for grass. Great for intersecting polys (common in grass) which can’t be sorted. This saves you the depth-sorting and results into perfect results from any angle.
tnx, but it didn’t sovle the problem here. Now whole problem is just inverted. When I move with camera behind other grass poly, now he is untransparent for grass, and transparent for terrain… :’(
So you think that I should sort the rendering order in my Vector object which contains Grass objects? Each frame, hm… that should be time expensive, but i’ll try.
Really look into AlphaFunc as I mentioned above. It will fix all your problems at no effort.
riven, i tried to sort polys and it really worked. What I want now is to try your method, but didn’t quite understand it. I AM using
GL11.glBlendFunc(GL11.GL_SRC_ALPHA, GL11.GL_ONE_MINUS_SRC_ALPHA);
if that is what you were talking about. Please tell me more 
AlphaFunc != BlendFunc 
Let’s say you want to render a tree, would you really want to depth-sort all leafs every frame?
Let’s say the alpha-channel is either 0.0 or 1.0 in your texture. If you only want to show the pixels (and only let those write to the depthbuffer*) that have an alpha of 1.0, you enable alpha-testing and set the parameters with alpha-func.
* depth-buffer writes are the cause you have to depth-sort, so if you get those right, you don’t have to sort.
glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_EQUAL, 1.0F);
// or
glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_GREATER, 0.99F);
Now every fragment that is about to be rendered, is tested on it’s alpha-value. Only if it passes, the pixel is rendered and the depth-buffer is updated.
Yes, it works!!! 
Riven, tnx a lot…
Note that you shuold only enable alpha-testing when you really need it.
From my experience a while ago I remember it was quite a costly check.
Another nice thing is that because the scene is not sorted, the depthbuffer
will prevent the massive overdraw of back-to-front sorted scenes.
Oh, and I’m glad I could help you
Gord knows why, but enabling the alpha test turns off hierarcial depth buffer testing (on cards that support it, natch) which can cause a speed hit (I can only assume that they’re reusing the same physical bit of circitry for both).
Thanks to you guys (and reading couple of books ) I managed to make things work. Now grass transparency problems are history, see for example
http://hvor.madpage.com/magicwoodslwjgl.htm
screenshots on my pages…