texture clamping

though i’m afraid this cant be done without a fragment program, i’ll try and ask all the same
can i clamp a texture between the range of, say, [0,.7]?
i would need this to be a per fragment operation
thanks for any help you may provide

I believe there are extensions that add GL_MIN and GL_MAX as allowed TexEnv operations. Thus, you’d send in 0.7 in the texture environment color, and turn on these texture environment modes.

However, I’m too lazy to look it up in the extension registry, so I may be entirely on crack.

I had a quick look, but couldn’t find anything like that jwatte. I do have this inkling that I saw something about min and max a while back tho…

thanks for providing some pointers, i’ll start searching for more over the net

mh i guess you were referring to this (from GL_ARB_texture_border_clamp spec):

Texture coordinates are clamped to the range [min, max]. The minimum
value is defined as

    min = -1 / 2N

where N is the size (not including borders) of the one-, two-, or
three-dimensional texture image in the direction of clamping.  The maximum
value is defined as

    max = 1 - min

so that clamping is always symmetric about the [0,1] mapped range of a
texture coordinate.

if so, it looks like there’s no way i can solve my problem :

maybe you could setup the texture matrix with glScalef and glTranslatef so that (0,1.0) gets mapped to (0,0.7) ?

I thought we were talking about fragment texture application, i e clamping the color values. If you’re talking about clamping the texture coordinates, then, no, there’s nothing like that unless you use ARB_fragment_program, or the rectangular texture extensions.

i’ll try and explain this a little more in detail
say i want to draw a quad with texture coordinates going from 0 to 1 along both s and t vectors
if i could clamp s+t the way i need, say in the range of [0,.5], only the lower left quarter of this quad would be textured correctly (if the texture is 128 pixels wide and high, one would see only pixels going from 0 to 64), all the rest would be clamped to .5, so the upper left quarter would clamp t, the lower right would clamp s and finally the upper right quad would be clamped to the color of the texture that is at [.5,.5]
sorry for not explaining this before

I think that you are not interested in clamping the colors, but just the tex coords.

You want something like this I think

if(texcoord[0].s<0.0)
texcoord[0].s=0.0;
else if(texcoord[0].s>0.5)
texcoord[0].s=0.5;

That would best be done in a vp but ARB doesn`t offer conditional statements (yet), but NV_vp2 does.

Also, clamping the colors in a fp would be good too, but I`m not sure how to do that. Maybe there is some trick like a depency on a 1D texture that contains certain values in it.

glMatrixMode(GL_TEXTURE);
glTranslatef(-0.5f,-0.5f,0.0f);

should do it at least for quads, set the wrap modes for s and t to GL_CLAMP

It must be done in an fp but it works

MUL tmp,texCoord,0.5;
FRC tmp,tmp;
TEX col, tmp, texture[0], 2D;

thanks for your replies

@v-man: yes that’s exactly what i want to do, but i hoped to do that without using programs
vertex progs would not work, i need this to be a per fragment operation, by the way that would not require conditional statements (though these are not supported they’re quite easy to emulate), MIN and MAX instructions would do that

@scott: translating will cut out the lower left half of the texture, scaling wont work either since i’m trying to do this:

i’m copying a 1152x864 screen area into a 2048x2048 texture, then i use this texture as the input for a texture offset operation (aka embm) and draw the result to screen (1152x864)
the texture that perturbs my copied area will sample texels that are outside the 1152x864 area thus showing black pixels at the edges of the screen
i guess the only way to avoid this is writing a frag prog that completely replaces native embm
i just wish there was a way to clamp textures to values other than 0 or 1, some extension like the one jwatte was thinking of would have been just great

Originally posted by Mazy:
[b]It must be done in an fp but it works

MUL tmp,texCoord,0.5;
FRC tmp,tmp;
TEX col, tmp, texture[0], 2D;[/b]

mazy i guess this would be enough:

MAX tmp,texCoord,0;
MIN tmp,tmp,.5;

and then sample

tellaman’s fragment program is correct and should be efficient.

v-man: the vertex program version won’t work, because the clamped coordinates would be emitted per-vertex, and interpolated per-vertex, which would lead to texture skew.

I still think that the rectangular texture extension would be well suited to the use that’s described (render-to-texture, basically).

texture rectangle would be cool, i think i remember there is an arb version planned to be released soon isnt it?

my mistake, it should be done at the fragment level otherwise you might get skewing like jwatte said.

I asked when [ARB/EXT]_texture_rectangle was gone be available a while back.
The good news is that ATI has the EXT version and it has a lot in common with NV_texture_rectangle (same token values, same defaults, same limitations)

Its quite likely that if they create an ARB version, it wont be very different (except that they might choose [0…1] over [0…width]x[0…height])

Its quite likely that if they create an ARB version, it wont be very different (except that they might choose [0…1] over [0…width]x[0…height])

Has anyone seen ARB_texture_non_power_of_two ?