How to set Texture Border's Color?

If I set the glTexImage1D’s parameter width as 64+2,How to load border’s color and data color
Is it like this:

  BYTE table[64+2][4];
  int i;
  for(i=0; i<64+2; i++)
     table[i][0] = i;
     table[i][1] = i;
     table[i][2] = i;
     table[i][3] = i;
  //=======Set Left Border Color========//
  for(i=0; i<1; i++)
     table[i][0] = 0;
     table[i][1] = 0;
     table[i][2] = 255;
     table[i][3] = i;
  //=======Set Right Border Color========//
  for(i=257; i<258; i++)
     table[i][0] = 255;
     table[i][1] = 0;
     table[i][2] = 0;
     table[i][3] = i;

  glBindTexture(GL_TEXTURE_1D, Texture);

index 0 is the left border color
index 1~256 is the data color
index 257 is the Right border color
Is it right?

Here’s the bottom line: don’t set border colors. Borders are unsupported on a whole range of hardware (which is hopefully shrinking, but don’t count on it).

GL2.0 spec, page 175, on [Copy]TexSubImage{123}D:
Negative values of xoffset, yoffset, and zoffset correspond to the coordinates of border texels, addressed as in figure 3.10.

So I would say that there’s a single border color (not a surprise I guess) and that you need to pass


to make it work.
Im’ not sure you can pass them in the pixel data. By quickly overlooking at the specification, it seems that only image pixels are fetched and not border ones.

So, I guess what you’re doing is wrong.

Check: if border colors would work as you do, then borders would really be “texture extensions” because you could be able to set a different color at each border texel. Definetly not something happening!

You haven’t set the border parameter! What you have is just a non-power-of-two 1D texture with 66 texels.

GL_RGBA, // Better use newer internalFormat enum GL_RGBA8.
64+2, // Correct, 64 + 2 * 1 border texel on either side.
0, // border! Set this to 1.

The for-loops for the border texels are not necessary, both iterate only once, and the one at i=257 loads that into alpha on an unsigned byte data which only goes to 255 and worse, your array is BYTE table[64+2][4], so that would crash accessing table[257]. Not good.

For CopyTexImage, yes the border texel download coordinate start at -1. That’s in texels.

Access on these border texels during rendering depends on the texture parameter WRAP mode and needs the correct texcoord values.
From the OpenGL Spec:
Wrap mode CLAMP_TO_EDGE clamps texture coordinates at all mipmap levels such that the texture filter never samples a border texel.”

Means even if you had downloaded it correctly it wouldn’t have been accessed.

Didn’t you want the border on the 3D volume textures instead of the 1D transfer function(?).

Obli, what useful hardware is missing border texture support ??? None according to :

Don’t spread vague obsolete informations.

oh, Relic, I understand what you mean. And The things confused me have been showed in shading language area in this forum.

Didn’t you want the border on the 3D volume textures instead of the 1D transfer function(?).

No, The 3DTexture data store in GL_ALPHA format.
And it can be GL_RED, GL_BLUE or GL_GREEN.It is not important. I just want to use BYTE data which will consume more less memory than GL_RGBA mode.As you said, BYTE data value is from 0 to 255. In frag shader, we got float data through this

float data = texture3D(volume, glTexCoord[0].sqt}.a;

And I think this float data value should be this
Index/256. Index is the BYTE data store in 3Dtexture which match the TexCoord.
And the problem is how we can index the 1Dtexture border?

Originally posted by ZbuffeR:
Don’t spread vague obsolete informations.
So I guess my sistems drop to software rendering when I use borders just because I am really unlucky and they like to make me crazy (last tested on NV3x - I apologize for not being able to test this every day).
So, I guess CLAMP_TO_BORDER was was dropped from GL ES just because they wanted to make me unhappy with the lack of this functionality.

Ok, color mapping then. I thought you were concerned about linear filtering across volume bricks, that’s where the fun starts.

Texture fetches from unsigned integer data always return values in the range 0.0 to 1.0.
The unsigned bytes data in the volume texture is converted by dividing with 255, not 256.
Look at the OpenGL spec Table 2.9 color conversions.

What should the border texels in the 1D texture do? I see no real need for it yet.

Anyway, with linear filtering in the 1D texture and GL_CLAMP or GL_CLAMP_TO_BORDER you can access the border texels with texcoord.s <=0.0 or >=1.0.
You cant access the border texel with nearest filtering, or wrap repeat, or wrap GL_CLAMP_TO_EDGE.
Since the texture3D lookup will only return that range you will automatically filter in the border texel if you’re on the edges of the 1D texture image (the 64 core pixels spreading over the range [0.0,1.0].)

Note that there’s also a texture border color, which is sampled if you don’t download texture border texels. That color is normally black by default.

Originally posted by ZbuffeR:
[b] Obli, what useful hardware is missing border texture support ??? None according to :

Don’t spread vague obsolete informations. [/b]
ZbuffeR, do you understand that this extension (GL_ARB_texture_border_clamp) has nothing to do with the presence of hardware support for textures with border?
It simply allows to clamp any texture to the border, no matter if it actually has it or if it comes from the constant border color.

Serge K, you are right. I could not find a list showing hardware support for texture borders. If anybody has more precise data …

I took your comment as inspiration to check out border support again.

Let’s say it clear: I am using default driver settings (I know there’s an override somewhere) because this is what the average Joe is going to do.

Fact (tested today): CLAMP_TO_BORDER seems to provide the same results as CLAMP_TO_EDGE on NV4x (I dind’t compare it per-pixel however).
I think it’s the same as GL_CLAMP.

At the end of the line however, I admit NV4x does not drop to SW paths anymore (so my sentence IS actually false NOW: maybe I was using some weird format?), nor does produce expected results however.

tested yesterday on a geforce fx5200, all these tokens seem to work properly :
GL_CLAMP show 50%mix between edge and border texels at integer texcoords
GL_CLAMP_TO_EDGE never show the border texels.
GL_CLAMP_TO_BORDER allows to see the border texel with texcoords outside [0,1]

I have to apoligize: I forgot I was mangling the tcCoords in a shader.
After removing the mangling, the border showed correctly, ( :eek: ) so I felt the need to post back that I was wrong and that it’s finally supported.