So let's look at the file sizes and memory consumption:-
___________________________________
Code: Select all
512x512 (10 mipmaps) = 170KB
1024x1024 (11 mipmaps) = 682KB
2048x2048 (12 mipmaps) = 2.6MB
4096x4096 (13 mipmaps) = 10.9MB
8192x8192 (14 mipmaps) = 42.6MB
16384x16384 (15 mipmaps) = ~170MB
32768x32768 (16 mipmaps) = ~680MB
65536x65536 (17 mipmaps) = ~2.7GBFirst of all, when we talk about "double the resolution" we actually mean 4X/quadruple, because '2x 1024x1024' would actually be '2048x1024' or '1536x1536', not '2048x2048', in terms of pixel sum. Secondly, this includes every mipmap underneath that resolution included in the compiled compressed asset. Finally, honestly, as we increase in resolution, the distinction between what an average observer can actually notice will diminish, meaning - there's a huge benefit in the first few increases, but telling the difference between 4K and 8K becomes harder, and 32K to 65K becomes near impossible, yet as you can see, the memory demands are massively significant. The increase in hardware demands are 4X and include all other mipmaps underneath, until we reach 65K with a whopping 2.7GB. Truth be told, this figure may even be underestimated as I'm currently unable to compile such a huge texture with the hardware available to me.
Another thing about such massive resolutions is the colour-depth. 16.7 million colours sounds like a lot, and it is plenty for your average 2K standard, but getting much higher than that pushes the issue into focus, especially for things like special effects that derive from a greyscale, of which there are only 256 "steps". At the moment we use some nifty dithering techniques and texture-filtering does the rest, but even that can only get us so far. While it's possible to use higher colour-depths where the bits-per-pixel are not evenly distributed, it's an increase in memory consumption no matter which way you dice it.
I've seen countless "high-res" (4K/8K+) assets out there that are blurry noisy junk, and only begin to look good as a texture when de-noised, resampled down and sharpened back up, in the best case scenario. I notice this especially with skyboxes from HDR panoramas, while I would like a nice 4K skybox or two, we're limited to 2K each direction due to what cameras are capable of and the colour-depth we're limited to, to avoid banding. For "world textures", this does not mean the texture will tile nicely, anyway, which is one of the main aspects of what makes a good texture, and I see this as a lost art. Many of them were hastily thrown together using something like GIMP's "tile seamless" tool, which repeats features within the texture and doesn't necessarily means it will tile in a good way, just in a technical sense.
What a player will actually appreciate, at the end of the day, isn't the resolution of the texture, but how it's used, especially "texel-scale". The player doesn't care about whatever the maximum resolution of the project's texture-set is when in the experience of the game, and it's not really a selling point at all. There are a bunch of reasons why 8K isn't really better than 4K as a talking point - the perception issue as I mentioned, the bandwidth and storage space required, the load times, the hardware demands. A good texture takes hard work and care, and costs the end-user nothing extra. I'm not saying these higher resolutions will never be used, but I predict they won't be created and delivered in the traditional sense, and there will be (are) other concerns to address first, such as a more universal approach to material complexity and further use of higher colour-depth textures to fix all banding issues. These memory demands outweigh the need to simply take another step toward higher resolutions, and there are even more tricks than that. I don't see hardware and bandwidth keeping up with it for a long time, and one approach may be to deliver textures as "smart materials"/"substance" (see "Allegorithmic") that are compiled on the user's system during the install process, either chosen by the user or predicted by the software. The download will be much less but the install times and storage demands for high-resolution textures will be extremely long, if that's what the user wants. I see things going in that direction. Because textures are the biggest portion of the common 3D AAA game, nobody wants 500GB taken up on their system drive for something that is only marginally better than a 150GB version, so ultimately it will be the user's choice to either download or compile versions of the title with different resolution standards, which is currently our approach.
As I said, having the ambition and ability to aim to 65K and even beyond is something all developers should think about, but to roll around in puddles of sweat obsessing over it and being at the throats of other developers over it, it's just ridiculous. A great 2K texture is always going to be better than a blurry noisy 8K texture that wastes time, storage and memory.
.
.
.
