Hacker News Reader

Comment by laserbeam | Hacker News Reader

Textures are big... bigbly big! And to be fair, game devs even have middleware solely dedicated to compression (such as Oodle http://www.radgametools.com/oodle.htm). I am sure that some % of that space can still be recovered, but it's definitely not significant. I'm sure you can't drop to half and maintain the ultra settings.

View on HN

You would be surprised, actually. This [0] shows an example of some excellent space savings. I used to work for Epic and the results we got on other projects were in this ballpark too.

[0] https://dev.epicgames.com/community/learning/tutorials/ry2D/...

My assumption was that you get down to 70gb packages after using tools like oodle. But hell, I may be wrong there and may be giving most AAA devs too much credit.

> But hell, I may be wrong there and may be giving most AAA devs too much credit.

I don't think this is a fair comment. Theres an enormous tradeoff to make when compressing game assets, and uncompressed game assets are _absolutely enormous_. My current project has about 30 people at the moment. The game content is ~50GB, the client itself is ~4GB but the source substance files/fbx files/photogrammetry assets are tipping on 500GB. We're a _small_ AAA game. My previous project was closer to 500GB for the game content, and the source assets were multiple TB.

Tools like Oodle are third party licenses that need to be considered. Most games are compressing but switching to better compression methods can make the differences shown. Theres still huge tradeoffs to be made though. Most GPU formats for consoles require platform specific texture formats, and some of them don't compress well (hello dxt). You might have to trade a 20% file size reduction for a 30 second increase load time. Is that worth it? Maybe.

Either way, it's not just "dumb Devs". We care, we work hard on this.

> it's not just dumb devs

I may have come too rough in my comments and lost the original intent. I was hoping to defend that devs _already have_ access to good compression tools and that they already use them, and 70gb games are that big after compression is applied. That's where my assumption started.

I understand well that there are custom formats for different platforms, and that the whole reason these tools exist is not to squeeze an extra 10% smaller files, but to get fast load times while maintaining small file sizes.

> My previous project was 500gb

That wouldn't surprise me to be honest. It makes perfect sense.

Question: why can you not separate the different graphics tiers as optional addons? That way, I only have to download high resolution textures if my PC can actually handle them.

Edit: never mind. Saw this being discussed elsewhere in this thread.

But that's kinda the point, when you are on a low to mid tier setup you now have to download 50GB of 4k textures you're never gonna see.

Just get up close to a model, and you can still see the difference.

And there are YT videos that call developers out for mushy textures on every new game release.

For the steam deck valve added support for games to only include the relevant texture quality tier to save space. Hopefully that expands and rolls out more broadly, but it's also a bit awkward to specify your game quality settings before launching the game.

Both the current Xbox and PS generations support this in a way as well. The developers need to do some work to make use of the features, but they are available.

I looked through the generated binaries from unreal engine, and they inline sort algorithms almost everywhere in their code, so even their binaries becomes huge not just the assets. Inlining sort algorithms is in my experience a very common cause to binary bloat, and not at all helpful for performance, forcing the cpu to load that much code everywhere hurts performance. It will look good in local benchmarks though since then the CPU can keep all the code in its cache.

Reply on news.ycombinator.com