why does it HAVE to be in the power of 2?
WHY!!??!
lol I wonder the same thing
Textures won’t compress otherwise. Probably nobody bothered to create a GPU-friendly compressed format for non-power of two, because it would be slow, and it’s not hard to always use power-of-two.
has nothing to do with “not as fast” or “friendly”
It would plain simply not be possible.
S3TC (-> DXT) and PVR get their massive size reduction only due to their pot, because the compression compresses blocks of 2x2 pixels / 4x4 pixels etc.
if you aren’t pot, you can logically not compress such a texture at all.
I’m not sure what you’re saying. You can obviously have compressed images that aren’t of the types of compression used with Unity.
sure you can
but the moment you load them they will become bmp32 /16 images, they will not carry on any compression, which makes them meaningless when it comes to speed and vram.
PNG, TGA and JPEG are famous examples of this non-compressors
compression that persists in RAM and VRAM (hardware texture compression) is only offered through DXT on the desktop and PVR on the iphone and they have restrictions!
DXT must be power of 4 side length, must not be square
PVR must be power of 2 side length, must be square
That’s what I’m saying. These formats were surely chosen for good reasons, but that’s not to say that it could be done differently. There’s just no impetus for it because it’s not hard to work with, and performance is still an issue with the lame technology of today.
I only work with Unity iPhone, and I never encountered this before I switched to that. Is there no 128 / 512 / 1024 on the desktop?? That doesn’t sound right!
Sorry, small error on my end, the DXT requirement is not power of 4 but multiply of 4 (DXT is quite a bit weaker than PVR, but due to its way of working, it offers a wider amount of sizes and on the desktop it commonly can afford the larger size)
Texture size has almost nothing to do with compression issues, although like was said already the compression techniques work on blocks of a given size. But that doesn’t really restrict it to having to be powers of 2 for the overall texture dimensions, moreso it should be like multiples of 2, ie 2 4 6 8 10 etc rather than 2 4 8 16 32 etc.
What it boils down to, I think, is that basically it is simpler and easier to create hardware that works with binary values where setting or clearing one bit in a binary number is much easier for it to deal with than figuring out the value of the number. It’s much easier to make hardware that can deal with the values of each column of binary, which is the powers of 2 - 2 4 8 16 32 64 128 256 512 1024 etc
Notice that the horizontal dimension of a texture does not have to equal the vertical dimension of a texture, but in Unity it seems to enforce textures to being square. It’s not actually required in OpenGL, for example. You can have a 128 x 8 texture, or a 1024 x 256 texture. So long as each dimensions, in and of itself, is a power of 2, the hardware is happy.
It generally requires a bit more sophisticated hardware logic/drivers to accomplish a non-binary-based texture width… a little more overhead perhaps.
the binary nature was definitely a reason, as it allows bitshift optimization etc, a vital part for “0 power but 100% quality” optimization tricks.
on the iphone its kind of trivial anyway. until pretty recently, only pow2 sidelengths were supported at all on textures. now it would be possible to have non pow though I personally wouldn’t touch it even if we could cause the hardware is near granted more performant on pow2 and even more with pvr 
Unity works with those dimensions with no problems and doesn’t enforce textures being square at all.
–Eric