Accessing GL_LUMINANCE_ALPHA32F_ARB texture with Shader

OpenGL Development JOGL Development
#1

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?

#2

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
R1L2, G10, B1*0.

#3

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};

#4

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.