I have what I hope is a simple problem. I have two GL_RGB texture maps. These never change, consider them background and foreground data. I want to blend them, in such a way that the background is fully visualized in non-interest areas, the foreground is fully visualized in interest areas, and there is a small area of alpha which ramps from 1,0 as a margin around the interest area. Now, the position of the interest area changes often, meaning that I would have to change the alpha channel of the foreground texture and upload it via glTexImage2d with every change.
I know that is slow, so I’d rather have another 1 channel buffer that I select in with GL_ALPHA and use the texture transformation matrix to scale/translate it into the correct position. I can use a border value in the texture and GL_CLAMP to ensure that the background gets the correct alpha value.
Unfortunately, I can’t seem to make this work. I’m just testing with a little small program drawing a quadrangle in multiple passes with two RGB textures and the ALPHA texture. I’ve tried virtually all combinations of the glBlendFunc and it’s not making any sense to me. I’ve been using glReadPixels to check the pixel values … alpha value never seems to change, it’s always 1. (And yes GL_BLEND is enabled … and everything works appropriately with GL_RGBA fore and background textures.)
Surely this isn’t impossible? If it is, then I have another question. What the hell else are GL_ALPHA textures for? Only for blending objects of solid colour?
You can do this in a single rendering pass using multitexturing (GL_ARB_multitexture)
Or, like you’re doing right now, do it in multiple passes. But then you have to make sure that your visual supports alpha values. If you’re using glut, specifying GLUT_RGBA is not sufficient, you also have to add GLUT_ALPHA in order to assign alpha-bits to the framebuffer. The opengl manual states that if the framebuffer does not support alpha values, it will return 1 for the alpha values.
Thanks Nico, but that confuses me. What do the visuals have to do with it. It may be what’s causing the constant value in the alpha value after the read pixel, but if I can do alpha blending with two RGBA textures in 2 pass, then the visual should not be getting in the way. So it remains to me that I am not sure what is going on with the two rgb buffers and an alpha buffer in 3 pass rendering.
I’m thinking something like this:
// play with the texture matrix
The question is what are the si,di values. I’ve always just used GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA to do regular alpha blending between two RGBA buffers, but with this, the alpha in a completely different buffer I’m not sure.
Without multitexturing, you’d have to use the destination alpha. Something like this:
glColorMask(GL_FALSE, GL_FALSE, GL_FALSE, GL_TRUE);
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE, GL_FALSE);
// play with the texture matrix
If you can use multitexturing with three texture units, you can set up a GL_INTERPOLATE combine mode to do the whole thing in a single pass.
Oh, and the “destination alpha” is the alpha component of the framebuffer. Alpha blending works fine if you’re always using GL_SRC_ALPHA and derivatives, but to use GL_DST_ALPHA et al., you have to explicitly request a 32 bpp framebuffer instead of a 24 bpp one. Check your window initialization code to make sure this is the case. That’s what NiCo was saying.
Alright. I understand now. Thanks a lot. Predictably my frame buffer is 24. Unfortunately the program must be a Qt program, and I can’t figure out how to ensure 32. Anybody have any idea by any chance, I know this isn’t Qt forum, but I thought I’d ask.