arb_fragment_program and lookup textures

Looking back on some posts, a nice way to do color lookups was using arb_fragment_shader but I can’t get this to work.

Here’s what I have:

!!ARBfp1.0
TEMP g;
TEX g, fragment.texcoord[0], texture[3], RECT;
TEX g, g.x, texture[1], 1D; #label
MOV result.color, g;
END

This produces black and I’ve checked alphas and made sure the texures are loaded and present. Texture 1 is just a 256 pixel wide strip of RGBA. Is there any issue with RECT that prevents this from working? For instance, s, t for TEXTURE_RECTANGLE_EXT are not in [0,1]. [0.1] so there maybe an issue there. How exactly does the TEX instruction index into the texture being sampled?I’m trying to get texture-3 color-corrected by using fragment.color to index into one of three LUTs and then using that as result.color (after assembling the result with appropriate MOVs and swizzles). Is there a better way for doing this type of thing and any suggestions as to why this isn’t working?

Edited because it was all wrong. Sorry for that.

[This message has been edited by zeckensack (edited 12-11-2003).]

Ah, I see

Originally posted by MacDaddy:
Is there any issue with RECT that prevents this from working? For instance, s, t for TEXTURE_RECTANGLE_EXT are not in [0,1]. [0.1] so there maybe an issue there. How exactly does the TEX instruction index into the texture being sampled?
The TEX instruction explicitly takes a target argument (“RECT”), so it can figure out the right addressing mode, no worries.

I’m trying to get texture-3 color-corrected by using fragment.color to index into one of three LUTs and then using that as result.color (after assembling the result with appropriate MOVs and swizzles). Is there a better way for doing this type of thing and any suggestions as to why this isn’t working?
That sounds like a nice way of doing it.
Ie

!!ARBfp1.0

TEMP lut_index;
TEMP post_lut;
TEX lut_index, fragment.texcoord[0], texture[3], RECT;
TEX post_lut.r, lut_index.x, texture[0], 1D;
TEX post_lut.g, lut_index.y, texture[1], 1D;
TEX post_lut.b, lut_index.z, texture[2], 1D;
MOV result.color, post_lut;
END

Should work. Watch the output alpha (irrelevant if you have neither blending nor alpha testing enabled). Make sure you have bound the right textures to the right targets. Can’t hurt to enable the texture targets, too.

What card and driver version are you using?

Zeckensack maybe a single cube map lookup could be better that 3 1D texture look ups ?

SeskaPeel.

Originally posted by SeskaPeel:
[b]Zeckensack maybe a single cube map lookup could be better that 3 1D texture look ups ?

SeskaPeel.[/b]
How would that work? I was thinking about 3D textures, but cube maps?

Either way, the separate lookups need less (texture) memory, a lot less if you compare it to a 3D texture (48 MiB vs 768 Bytes …).

Thanks guys. I’m using an NVIDIA 5200FX on one machine and a Radeon 9800 Pro, each on a G5 running 10.3. Blending and alpha testing are both off. I don’t think it’s the fragment program that’s screwing up, even regular texturing of the 1D stuff fails so it could be something more fundamental. Right now I’m using PixelMap to get lookups to happen but it’s just not flexible enough. What should be the bound texture just prior to Enable’ing the fragment program?

Uhmmm …

glActiveTextureARB(GL_TEXTURE0_ARB);
glBindTexture(GL_TEXTURE_1D,your_red_lut);
glEnable(GL_TEXTURE_1D);
glDisable(GL_TEXTURE_2D);  //just to make sure

glActiveTextureARB(GL_TEXTURE1_ARB);
glBindTexture(GL_TEXTURE_1D,your_green_lut);
glEnable(GL_TEXTURE_1D);
glDisable(GL_TEXTURE_2D);

glActiveTextureARB(GL_TEXTURE2_ARB);
glBindTexture(GL_TEXTURE_1D,your_blue_lut);
glEnable(GL_TEXTURE_1D);
glDisable(GL_TEXTURE_2D);

glActiveTextureARB(GL_TEXTURE3_ARB);
glBindTexture(GL_TEXTURE_RECTANGLE_EXT,your_index_rectangle);
glEnable(GL_TEXTURE_RECTANGLE_EXT);

Other than that, make sure you enable GL_FRAGMENT_PROGRAM_ARB (happens to the best of us …).
Also check the error string.

glProgramStringARB(<...> );
#ifdef _DEBUG
int err_pos;
glGetIntegerv(GL_PROGRAM_ERROR_POSITION_ARB,&err_pos);
if (err_pos!=-1)
{
    log_error("compile error: %s
",
              glGetString(GL_PROGRAM_ERROR_STRING_ARB));
}
#endif

[This message has been edited by zeckensack (edited 12-11-2003).]

Texture enables are not technically required, ARB_fragment_program deprecates this anyway.

Another thing worth mentioning would be mipmap completeness. If your 1D textures don’t have mipmaps, use GL_LINEAR or GL_NEAREST filters for both minification and magnification. Or just make them with gluBuild1DMipMaps.

Otherwise texturing will fail.

The definition of the texture rectangle extension used to specify that the texture coordinates turned into pixel offsets (range [0,width]) rather than normalized (range [0,1]). Is that still the case in ARB_fp? If so, do you need to scale your incoming texture coordinates by the width/height of the rect texture?

Thanks guys, you rock on! Turns out it was all with the sequence of glActiveTextureARB and binds. I didn’t quite have order right before and 1D and RECT textures work perfectly with each other.

Originally posted by jwatte:
The definition of the texture rectangle extension used to specify that the texture coordinates turned into pixel offsets (range [0,width]) rather than normalized (range [0,1]). Is that still the case in ARB_fp? If so, do you need to scale your incoming texture coordinates by the width/height of the rect texture?
It’s the same as with legacy multitexturing, rectangle textures use non-normalized coordinates.
About the scaling thing, you can do that in a vertex shader or just adjust the vertex data accordingly. I use rectangle textures only for large screen aligned quads, so this isn’t really much of a problem.