Would a 1024x16384 texture generally perform as well as a 4096x4096 texture? Memory wise they should be the same but perhaps having such a large dimension as 16384 would be worse anyway?

I'm considering making a texture atlas like a long strip where it would be tilable in one direction.

10 minutes ago, CarlML said:

Would a 1024x16384 texture generally perform as well as a 4096x4096 texture?

Normally as long as you use power of two on both axis your fine. So 64x 1024 is fine. However most graphics cards in use now supports 4K not 16K. So more computers can use 4096x4096 than 1024x16384.

You will be storing the same amount of data but will have more problems with the 16K one. There is no real reason you can't do it, just that more computers will have a problem with it.

Most DirectX 11 cards can read 16K textures. Still more than 50% of the worlds population don't have graphics cards that support DirectX11. The number grows if we include mobiles. 

Thanks for the reply. The game will have a minimum requirement of Directx 11. From what I understand of these resource limits all directx 11 cards are required to support a texture width/height of 16384:

https://msdn.microsoft.com/en-us/library/windows/desktop/ff819065(v=vs.85).aspx

What would be the drawback of having a non power of 2 texture size like 1024x10240 (1024*10)?

1 minute ago, CarlML said:

What would be the drawback of having a non power of 2 texture size like 1024x10240 (1024*10)?

A list to big to post here.

In short computers work with 0 and 1. So there is 2 possible states. This means computers work from the root up in power of two. That would mean performance problems and calculation problems if you don't use power of two.

Take mip maps, they are formed using a cubic calculation. So 1024 -> 512 -> 256 -> 128. Also because each mip is half the size of the other before it they can all fit on one texture of the same size. So your 1024 can use a 1024 texture to store all it's mips.

now if you broke the power of two rule, the mips can't be formed using the same calculations. So most engines just disable mips for none power of two textures. This leads to performance problems and noisy looking textures.

The good news is there is an easy fix. You can just fill the rest of the texture with black pixels till you reach the nearest power of two. So a 1000x1000 texture is converted to 1024x1024 with black edges. This fixes all calculation problems and you can still pull the 1000x1000 from the other image.

A atlas is also intended to fix this. Say you had 10 buttons of 250x100 pixels you could fit them all on a 1024*1024 texture and have space for more buttons. So instead of having 10 bad textures you have 1 good texture. This saves a lot of performance.

Thanks, yeah mipmaps is a big thing. 1024x8192 might not be enough for my purposes though so the next step would be 1024x16384. That is a lot... but perhaps it would not be a bigger deal than having a 4096x4096 texure, as long as the card supports the size?

Why are you hooked on 1024x16384 for an atlas when 4096x4096 is the same thing and supported on more cards?  Unless your textures are 1024 in width going into the taller one you're going to be implementing a full featured texture atlas class/suite anyways. 

4 minutes ago, Mike2343 said:

Why are you hooked on 1024x16384 for an atlas when 4096x4096 is the same thing and supported on more cards?  Unless your textures are 1024 in width going into the taller one you're going to be implementing a full featured texture atlas class/suite anyways. 

The idea is to have it be tilable in one direction. Tiling parts of a 4096x4096 texture is tricky.

3 minutes ago, CarlML said:

The idea is to have it be tilable in one direction. Tiling parts of a 4096x4096 texture is tricky.

You can still make it tile in one direction. To be clear a atlas is only where you store a texture.

Think of this 1024*64 as your long one.

Now I can just store it as 256*256:

See it's still tiling in the same direction, there was no need to have it tiling in a new direction.

1 minute ago, Scouting Ninja said:

You can still make it tile in one direction. To be clear a atlas is only where you store a texture.

Think of this 1024*64 as your long one.

Now I can just store it as 256*256:

See it's still tiling in the same direction, there was no need to have it tiling in a new direction.

Each square would be a different 1024x1024 texture so it would not tile like that. I can be done if the mesh is split up and repeated but that gets tricky with irregular geometry and the mipmapping makes other parts of the atlas bleed into the texture, so you need pixel borders for that. With the atlas in a long strip none of that would be necessary.

6 minutes ago, CarlML said:

With the atlas in a long strip none of that would be necessary.

How so? Pixels will still bleed into each other if you use the wrong types of mips and irregular geometry stays the same no matter if the texture is long or square.

Changing the shape of your texture does not change the way it all works.

Can you show a small example of what your trying to do?