Any reason to still use power of 2 textures?

It would be much easier for production if a scale like 1 texel=1 cm was used, and the artist just made a texture however tall it needed to be. Is there still any reason to use textures sized to powers of 2? If so, is there a way around the problem that will work on all new-ish gfx cards?

Please don’t tell me that I can just resize the texture and map it correctly. I KNOW that. When using an editor that auto-generates UV coordinates, it is much easier to line the geometry up with the texture if the texture is some regular size, i.e. it’s going to be hard to line up the window geometry on a wall that is 244 cm high and has a 512x512 texture on it.

If you really want to use NPOT textures, you can use a card that supports ARB_texture_NPOT . Granted, there’s only one card that does this right now. But, the 6600 should be on that list too.

However, if you really need a specific scale, have you considered just not using the full resolution of a texture? If you need a 244 cm wall texture, just use a 256x256 and not use 12 pixels of it.

As for why POT textures are important? Performance. NPOT textures require more complicated mipmapping logic than POTs.

Bingo. POW2 textures are a boon for performance. Think about it.

You have two textures. One is 64x64, the other is 60x60.

You want to find a given texel within both textures. Let’s go to the math:

64x64 version:  Texel=64*s+t
60x60 version:  Texel=60*s+t

Certainly doesn’t look much more efficient, does it? Unless:

64x64 version:  Hey, 64 is a power of two!
60x60 version:  Can't readily simplify like that!

People will argue but shifting is ALWAYS faster than multiplying with powers of two.

The lesson here is, be sure to choose your partners carefully, and if you do get an itching down there, don’t be afraid to ask your doctor if you have crabs.


If I remember well, Opengl 2 won’t oblige power-of-two textures.
And if I remember well too, OpenGL 1.2 and higher have solutions to let the user specify a non-power-of-two textures and convert it internally. So you don’t need extra solutions, but if your texture loader (as rgb loader or tga loader…) limits to power-of-two.

Hope this helps.

If you profile NPOT textures and find that they run fast enough for your needs, you can use them. However, I believe there is hardware that will not swizzle NPOT textures, so texturing is MUCH faster in certain directions than others (!).

That being said, there’s also the question of what a MIP map actually looks like for a non-POT texture. I’m sure you can hack it, but if the hardware needs to make assumptions (such as for anisotropic filtering) it gets ugly quickly.