float poly_x, poly_y;
GLfloat color_value[4] = { 1.0, 1.0, 1.0, 1.0 } ;
glEnable(GL_TEXTURE_2D);
glShadeModel(GL_FLAT);
color_value[0] = intensity;
color_value[1] = intensity;
color_value[2] = intensity;
glTexEnvf(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_BLEND);
glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, color_value);
glBindTexture( GL_TEXTURE_2D, *tex_id);
glPushMatrix();
if(dg_rotation != 0.0)
{
glRotatef(-dg_rotation, 0.0, 0.0, 1.0);
}
if(x_scale != 1.0 || y_scale != 1.0)
{
glScalef(x_scale, y_scale, 1.0);
}
if(x_offset != 0.0 || y_offset != 0.0)
{
glTranslatef(x_offset, y_offset, 0.0);
}
glBegin(GL_QUADS);
glTexCoord2f(0.0, 0.0);
glVertex2f(-poly_x, poly_y);
glTexCoord2f(0.0, 1.0);
glVertex2f(-poly_x, -poly_y);
glTexCoord2f(1.0, 1.0);
glVertex2f(poly_x, -poly_y);
glTexCoord2f(1.0, 0.0);
glVertex2f(poly_x, poly_y);
glEnd();
glPopMatrix();
glDisable(GL_TEXTURE_2D);
OGL: VERY annoying texture problem
Author
Howdy, all...
I am trying to texture a quad in straight OpenGL--a very simple process, I understand. (Actually, I am trying to make some preexisting code work.) It doesn't matter what I try, though, the quad always comes out a solid color. The solid color, however, is apparantly coming from some pixel in the texture itself. I know this because I started procedurally generating test textures to identify the problem, and if I change the texture from a red-black gradiant (for example) to a blue-black gradient, then the color of the quad will end up being some shade of blue... clearly affected in some way by the contents of the texture, but the quad is still solid in color.
The section that handles the binding of the texture and drawing the quad is ridiculously simple, but it is only part of an enormous codebase that I did not write, so I was thinking that something somewhere else may be doing something that prevents the texturing from working correctly.
Does anyone know of anything that might be causing a problem like this?
Oh, and before you ask, the texture coordinates are correct.
Here's an idea of what the function in question looks like... there are some things passed into the function, so any variables that seem to come out of nowhere are really there.
Hi smitty, can you post the texture creation code? Specifically any glTexParameteri/f calls and the glTexImage* call.
If I don't remember wrong so is it that you texture coords doesn't go from 0.0 - 1.0. Instead they actually go from 0-<texture width>, 0-<texture height>. However I don't remember what the reason for this behaviour was.
Author
At the moment, this is the texture generation code, which I threw in to see what happened...
glGenTextures(1, &img->texture_id);glBindTexture(GL_TEXTURE_2D, img->texture_id);unsigned char *dat = new unsigned char[512*512*3];for (int i = 0; i < 512; i++) for (int j = 0; j < 512; j++) { int index = (i * 512 + j) * 3; dat[index + 0] = 0; dat[index + 1] = 0; dat[index + 2] = i / 2;}glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);gluBuild2DMipmaps(GL_TEXTURE_2D, 3, 512, 512, GL_RGB, GL_UNSIGNED_BYTE, dat);
I may be wrong, but it might be "glTexEnvfv(GL_TEXTURE_ENV, GL_TEXTURE_ENV_COLOR, color_value)" line that is causing the problem. Have you tried to change color value or texture mode to something else (GL_MODULATE or whatever)? Or, for the sake of simplicity, simply ignore that line? If that's not the reason, you're probably doing something wrong when loading/setting up the texture.
Xetick: texture coordinates don't need to be in (0, 1) range (texture clamping/repeating is used). However, very large numbers may cause weird results, but that doesn't seem to be the case.
Xetick: texture coordinates don't need to be in (0, 1) range (texture clamping/repeating is used). However, very large numbers may cause weird results, but that doesn't seem to be the case.
Author
Yeah, I have actually commented it out to test that theory already. It didn't change anything.
That value is only used to scale the brightness of the image... color_value ranges from <0,0,0> to <1,1,1>. (Not the way I would have done it). In any case, the brightness scaling is the only part of the whole deal that works. It scales the brightness of an incorrectly solid texture perfectly!
That value is only used to scale the brightness of the image... color_value ranges from <0,0,0> to <1,1,1>. (Not the way I would have done it). In any case, the brightness scaling is the only part of the whole deal that works. It scales the brightness of an incorrectly solid texture perfectly!
Perhaps the texture matrix is being changed somewhere in that enormous codebase and not being changed back? Try setting the texture matrix to the identity before rendering.
Ok, I see.
Hm, what is this supposed to do? I'm not sure, but if it's meant to be BGR to RGB conversion, it should look something like:
Sorry if that doesn't do it though, it's quite hard to say what exactly is causing your problem.
for (int i = 0; i < 512; i++) for (int j = 0; j < 512; j++) { int index = (i * 512 + j) * 3; dat[index + 0] = 0; dat[index + 1] = 0; dat[index + 2] = i / 2;}unsigned char tempRGB;unsigned int counter; for (counter = 0; counter < texture_size; counter += 3) { tempRGB = dat [counter]; dat [counter] = dat [counter + 2]; dat [counter + 2] = tempRGB; }Sorry if that doesn't do it though, it's quite hard to say what exactly is causing your problem.
I'm not sure, but shouldn't the Y-coordinates be the other way around? So you get:
glBegin(GL_QUADS); glTexCoord2f(0.0, 1.0); glVertex2f(-poly_x, poly_y); glTexCoord2f(0.0, 0.0); glVertex2f(-poly_x, -poly_y); glTexCoord2f(1.0, 0.0); glVertex2f(poly_x, -poly_y); glTexCoord2f(1.0, 1.0); glVertex2f(poly_x, poly_y); glEnd();
I agree w/ DaBono. It seems like you're texturing in the wrong order. Unless you want the texture to be flipped or something. Wingman's right. It does seem your texture coding routine is iffy. It looks like you're assigning your own values to the dat structure.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
