it is suggested that textures dimensions are multiples of 64 pixels, square, and no more than 512 pixels square to work on most video cards
I know that odd (like 640*480) textures work, and I think this is what is happening
when the texture is resized for mipmapping (by the glu libraries), it is set to the proper size, and the different levels are created as well.
I also think I heard somewhere that glu mipmap routines also will scale a texture to the largest a video card can handle if it is too big.
does anybody know if this is true:
that textures are being scaled to square
and that oversize textures will be shrunk
(and does anybody know of a glu library that I should avoid because it doesn't do this?)
I would rather know what is really going on 'behind the scenes' than to have false truths running around.
According to the man page of gluBuild2DMipmaps:
Initially, the width and height of data are checked to see if they are a power of 2. If not, a copy of data (not data), is scaled up or down to the nearest power of 2. This copy will be used for subsequent mipmapping operations described below. (If width or height is exactly between powers of 2, then the copy of data will scale upwards.) For example, if width is 57 and height is 23 then a copy of data will scale up to 64 in width and down to 16 in depth, before mipmapping takes place.
Then, proxy textures (see glTexImage2D) are used to determine if the implementation can fit the requested texture. If not, both dimensions are continually halved until it fits. (If the OpenGL version is <= 1.0, both maximum texture dimensions are clamped to the value returned by glGetIntegerv with the argument GL_MAX_TEXTURE_SIZE.)
So textures don't have to be square, but must be a power of 2 along each side, and it will resize to fit the graphics card.