2
\$\begingroup\$

Basically, see the title: for whatever reason, I load a texture into OpenGL, bind it, draw a quad with texture coordinates specified, and the quad remains totally white regardless of what the texture is.

I have made sure that GL_TEXTURE_2D is enabled. I have verified (using glGetTexImage) that the Texture has the correct data in it (or, if not the correct data, data that should be visible, as the pixels have different values).

My glTexture2D function is called as follows:

glTexImage2D(GL_TEXTURE_2D, 0, pixelFormat, this->width, this->height, 0, pixelFormat, GL_UNSIGNED_BYTE, &(pixelData[0]));

This is where pixel format is either GL_RGBA or GL_RGB (according to pixel depth), and pixelData is the array of pixels. I verified that pixelFormat and pixelData and width and height have within them the correct values. Note that pixelData is a std::vector.

I bind the texture as such:

glActiveTexture(GL_TEXTURE0 + this->multiTexNumber); glBindTexture(GL_TEXTURE_2D, this->texID);

For the purposes of my testing, this->multiTexNumber = 0;

Have I done something wrong here? Is the problem elsewhere?

EDIT: via very thorough checking, I have ensured that OpenGL doesn't throw any errors. The problem persists.

Improve this question
\$\endgroup\$
8
  • \$\begingroup\$ pixelFormat These are not the same thing! There is a big difference between the internal image format and the pixel transfer format. I really wish the OpenGL ARB would have just made two separate sets of enums so people wouldn't be confused. \$\endgroup\$
    – Nicol Bolas
    May 4 '12 at 2:55
  • \$\begingroup\$ I tried screwing around with changing their values, which did nothing. \$\endgroup\$
    – Publius
    May 4 '12 at 2:56
  • \$\begingroup\$ That wasn't a suggestion to fix your problem; that was telling you how OpenGL works. That's why it was a comment instead of an answer. Though I would suggest, if you want an actual answer, you need to get a Short, Self Contained, Correct (Compilable), Example \$\endgroup\$
    – Nicol Bolas
    May 4 '12 at 2:58
  • 1
    \$\begingroup\$ If we assume your code is working (since you haven't provided it, we can't say), then the only thing to suggest is an OpenGL bug, that texturing on your graphics card is broken. Since that's unlikely, the bug must be in your code. And since we can't see your code, because it's too big to provide and you can't pull together a small example that has the problem... what exactly do you expect us to do to help you? You have a code bug. In order for us to help you debug it, we would need to see your code. \$\endgroup\$
    – Nicol Bolas
    May 4 '12 at 3:14
  • 4
    \$\begingroup\$ The safest place for a bug to hide is in code that you are utterly convinced is correct. \$\endgroup\$
    – Nicol Bolas
    May 4 '12 at 3:23
1
\$\begingroup\$

If you're not providing a full mip chain for the texture, ensure that mipmapping is disabled (set a filter mode that doesn't use mipmaps). IIRC, OpenGL may disable texturing if you try to use mipmapping on a texture that doesn't have mips.

Improve this answer
\$\endgroup\$
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .