>>1214428
Most textures are going to be compressed. In the style that actually is read directly by the GPU, and does not have to be decompressed at any point. Aka, it’s still compressed in that format in VRAM, and passed in that compressed format to the shaders (which obviously uncompress bits of it that they use, but do not store the result or decompress the entire file.
The problem is, GPUs have uneven support for modern compression. How old of a GPU are you supporting? Do you support OpenGL 4.1 and older, or are you only supporting DX11+, Vulkan, and Metal?
If you want really wide compatibility, you need to compress in a mixture of DXT1 and DXT5. Usually, mostly. The problem is, these are grainy, and are not as efficiently compressed. So they suck at both their primary jobs.
If you want to only support the newer hardware, then you need BC7 or a few variants. Now first of all, these have a bunch of sub variants with different pros and cons. Secondly, they’re larger than DXT1, sometimes but not always, but still really good. The main problem is for certain things with a big gradient, because you can see the blocks in the gradient with this. So you can have something that looks grainy with DXT1, or you can just store the texture uncompressed. For GUI, something like RGBA32 native is going to be the best, but now that’s like 64MB for a single 4096px squared texture.
So let’s ignore everything else but compression. If you ship a game that is all at the best possible compression compared to its function, with only a few things uncompressed… a bunch of GPUs can’t run that. What happens in those cases is that they will convert to the nearest uncompressed texture format, and sit in ram in that format. This is catastrophic, as you’re seeing ram increases (on older machines primarily!) of like 16x. In both system ram and vram.
So as a compromise, you ship both things. For everything. Whatever your file size is for all the textures, we just doubled it, for the sake of older computers being able to run the game at all.
But it doesn’t stop there. If you want absolutely premium textures, we’re talking 8k per side, you just quadrupled the file size compared to a 4096 texture. And here’s the thing, most computers can’t load in a ton of textures at that size. They don’t have the ram or the vram.
So, now you need to have packages for the high res textures, and the medium res textures, and probably also some low res ones if you really want to support older machines. That original number that we doubled? We just quadrupled the thing we doubled, and also added another underlying 10% from the original.
So let’s say the game is only 8GB of original textures dealing with the compression formats; it’s now 16GB on disk. Your specific machine will only ever use half of that. Then when we add in the high res versions for this premium modern game, we are now quadrupling that, so we are at 64 GB of textures now. For the added low-res textures, add in another 8GB, so we’re at 72GB now.
This is before we get into any audio, and if there are any videos with localized audio, it’s before those, too. Code is always tiny, that’s a rounding error in all the rest of this.
There are some things that can be done better, like taking grayscale images and packing those into different channels. So that might mean that your specularity or metalness map, your AO map, and maybe your heightmap get combined into one texture, cutting things down substantially in disk size and vram usage. Except that’s a bit of a lie, because while it’s a bit of an improvement, it’s marginal since the extra channels are just skipped in some of the better (and thus newer and larger) formats.
There are some things I oversimplified, like you wouldn’t bother having 8k textures for hardware without BC7 support because they wouldn’t have the vram available anyhow. So my math doesn’t entirely check out, beyond being napkin math. But it’s not too far off.
—
This myth of the fully uncompressed texture needs to die.
If someone had 8k textures that were fully uncompressed, that would be 256MB per texture. That would mean that for a single basic shield, you have a diffuse map, height map, metalness map, ao, and normal map. If it has any glowy bits, then also an emission map. This would mean that this single stupid shield would take up 1.2 to 1.5 GB on disk and in ram and in vram.
This is patently absurd. You’d exhaust most vram on any given two characters if this is how a game was made. The textures are compressed.
What is causing all the file size bloat are the redundant copies of things to support older hardware, and the ultra high def stuff that’s only usable by people who can run ultra.
As textures get larger, they go up by squares. That didn’t used to be that big a deal, when 1k texture were the norm. But moving from 2k to 4k is a shift from 16 to 64 mb. And going to 8k is 256mb.
So if a game size now is like 4x the size it used to be… yeah, that’s just texture alone, in one hardware generation leap. I don’t have any experience with Oblivion directly, but I expect based on when it came out that its textures were originally 1k at most, and for lesser maps probably 0.5 or even 0.25k. Also, this was before the PBR pipeline, so they had fewer maps in general. No ao for sure, and probably not being map. So realistically, napkin map again, I would expect an average texture to increase by 16x to 32x in size, plus having about 33% more textures. Since this is a high def remaster, more towards 32x. 5 GB x 32x is already 160GB, and that’s before we get to the extra maps and other redundancy.
So that tells me they aren’t shipping every texture at 8k (good. That’s a silly thing that only mods do, usually. Nobody is going to notice an ao map on a small object that is 4k vs 8k). And they’re using good compression, and have possibly limited or effective redundancy.
TLDR, the load times are faster because we are not TRANSCODING compression. It’s not stored as a jpg on your disk and then turned to bc7. One, that would look like ass, and two, it would make game load times insane. Like 5 minute startups insane, on an SSD. Converting a full project of pngs to BC7 can take 5-8 hours on first run on a new dev machine. There are caching servers used to cut down on this. Nothing close to this would be feasible on a large modern game. And I say this as someone who used to do exactly this in my older games. Because things are squared, it’s just not possible anymore. And even my older games load slower than my newer ones.
So I mean, all of these file sizes sound pretty reasonable to me. Is it annoying? Yeah. But all of those squared numbers add up. If you want a next gen visual experience, this is the size of the compressed version of that data.
Exponents never seem intuitive, so people assume stuff is not compressed. Hope this is useful to someone who is curious.