Use of TEXTURE_RECTANGLE_ARB affecting TEXTURE_2D_问答_开发者

I am using OpenGL 1.3 to do 2D sprite rendering and supporting both POTS (power of two size) textures and NPOTS (non power of two size) textures with TEXTURE_2D and TEXTURE_RECTANGLE_ARB respectively.

I had started with POTS textures (using TEXTURE_2D), which worked fine, but now I am adding NPOTS textures (using TEXTURE_RECTANGLE_ARB). This addition has caused the POTS textures (with TEXTURE_2D) to break.

By break I mean that the POTS textures are rendered as a grayscale gradient ranging from gray in the bottom left corner and white in the top right.

An extra point (discovered whilst trying to fix this error) - One big difference between TEXTURE_RECTANGLE_ARB and TEXTURE_2D is that the first uses non-normalised coordinates on the textures, whereas TEXTURE_2D uses normalised coordinates ([0.0,1.0]). I decided to check and replace the TEXTURE_2D's normalised coordinates with non-normalised coordinates, and this removed the grayscale problem by creating another - it was rendering the wrong texture!

I.e. when using a P开发者_Go百科OTS and an NPOTS texture, my POTS texture tries to render the NPOTS texture.

Does anyone have any idea why this might be happening? Thankyou!

Okay, so it turns out that it was a rather silly mistake, that was found in the original TEXTURE_2D code. I had forgotten to end the rendering with the correct glDisable!

I.e. the rendering code began with glEnable(targetType), but did not end with glDisable(targetType) [where targetType was the correct choice of GL_TEXTURE_2D or GL_TEXTURE_RECTANGLE_ARB].

I guess, somehow, the two rendering environments got intertwined.

Lesson - make sure when you begin with glEnable that you end with glDisable.

Edit: Considering the below comment, I did a little digging and found out about target presidence. The idea is presented in the beginning of this article:

http://math.hws.edu/graphicsnotes/c4/s5.html

"At most one texture target will be used when a surface is rendered. If several targets are enabled, 3D textures have precedence over 2D textures, and 2D textures have precedence over 1D. Except for one example later in this section, we will work only with 2D textures."

In terms of TEXTURE_RECTANGLE_ARBs precedence, this is described in the specification in section 10: http://www.opengl.org/registry/specs/ARB/texture_rectangle.txt

I did not know about target priority or precedence at the time of the bug, so thanks to @datenwolf!

Even if you have solved your problem, I'd like to clarify a concept that might solve problems that you may have in a near future.

Here is what is wrong:

now I am adding NPOTS textures (using TEXTURE_RECTANGLE_ARB)

GL_texture_rectangle OpenGL extension is not mean to support Not Power Of Two (NPOT) textures; the correct OpenGL extention to query is GL_texture_non_power_of_two.

GL_texture_non_power_of_two cannot break existing applications which expect Power Of Two (POT) texture, because it relax the specification in order to accept textures having any width/height/depth (within the limits, of course). Here is a quote of the extension:

There is no additional procedural or enumerant api introduced by this extension except that an implementation which exports the extension string will allow an application to pass in texture dimensions for the 1D, 2D, cube map, and 3D targets that may or may not be a power of two.

Instead, GL_texture_rectangle allow you to specify texture coordinates by addressing the texture extents (width and height) by the pixel coordinate, which is an integer (instead of the usual floating point coordinate normalized in the range [0.0f, 1.0f]). Additionally, rectangle textures cannot support mipmapping.

additionally, if you read GL_texture_rectangle specification, it is not meant to support NPOT texture, because rectangle textures shall be affected by the same restrictions of 2D textures.