Accessing GL_LUMINANCE_ALPHA32F_ARB texture with Shader

[AI Guy]

I have a fully functional set of 3 textures, and a fragment shader with functions that access the textures and return structures, to effective have a database.

What I am concerned with is that one of them is comprised of 2 element, 32 bit float, texels. I access it like:

vec4 texel = texture2DRect(sampler_nm, addr);

What happens is texel[0], texel[1], & texel[2] all have the value of the first element that went in.  texel[3] has the value of the second element.  This sort of scares me.  I was hoping the first 2 elements would have the values, and [2] & [3] either be the next texel or be garbage.

This is occurring on a GeForce 8800 GTX/PCI/SSE2 renderer, but compiled using the ARB version of shaders.  How thin is the ice I am on, in terms of portability?  Should I redesign?  Does anyone know what 3 element texels do?

[Riven]

It's a few years ago that I worked with greyscale textures, but I'm fairly sure this is normal behaviour.

In the 'old times' with fixed-pipelines, the texture-multiplies must have had values in the G and B, or else:
RGB1 * L2
would have resulted in
R1*L2, G1*0, B1*0.

[Chris61182]

Don't worry, everything is working just like it should be. If I'm not mistaken, the behavior should correspond to Table 3.20 in the OpenGL spec....

Alpha Texture = {0, 0, 0, A};
Luminance Texture = {L, L, L, 1};
LuminanceAlpha Texture = {L, L, L, A};
Intensity Texture = {I, I, I, I};
RGB Texture = {R, G, B, 1};
RGBA Texture = {R, G, B, A};

Games published by our own members! Check 'em out!

[AI Guy]

Thanks,

It makes sense that the luminance, the first element, would be spread across the 3 colors & and the alpha, the second element, would be in the alpha.  What a shock.

I find it easiest to specify vec4's as arrays rather than a color structure, because my data has nothing to do with color.  I need to take it more into account that color is the reason for OpenGL in the first place.