Who is this for? Texture compression is already handled automatically by all the major game engines under the hood. If you’re building your own engine you probably already know what texture compression is.
raincole · 1h ago
> If you’re building your own engine you probably already know what texture compression is
Yes, because they learnt it somewhere, for example, this article.
I don't get the negativity. Unless you work on bleeding edge R&D, every technique you know has been documented somewhere by someone else. So only the bleeding edge R&D people should write tech blogs?
Anecdotally, even I had known what texture compression is, this article still taught me something: the existence of Tacant View. It looks like quite a neat app.
filchermcurr · 27m ago
Thank you for mentioning this. You often see comments like the OC that are dismissive of articles and seem to think people doing one thing know everything about that thing. I guess when people get to a certain level themselves, they forget that others have to learn things too and don't implicitly know all of the things that you know. I really do appreciate seeing your comment gently reminding people that learning is a thing that has to happen and should be encouraged.
furyofantares · 3h ago
People do ship games on frameworks, rather than on engines. That could be considered building your own engine although I'm not sure if that's what you meant by the phrase.
maplethorpe · 2h ago
Ktx2 can also be used on the web, and a lot of web developers who make games are using libraries like Three.js instead of engines like Unity (which can technically build to WebGL but does an awful job of it).
DetroitThrow · 1h ago
I keep saying this whenever I see books about quantum electrodynamics. Everyone in the room who does QCD already knows QCD and doesn't need to discover it from scratch, so why do we need to write about it? Such wasted energy, we could all be writing comments on HN instead!
LexiMax · 3h ago
Someone on this forum might be one of the lucky 10,000. They also made their own texture conversion tool, which might save someone some time and effort.
Of course, they might have written the blog post with the intention of drawing attention to themselves and being noticed. These days, I can't bring myself to be upset about that sort of thing - if the content is good, better self-promotion than AI slop or hyping up the next hot investment vehicle.
Stevvo · 3h ago
Any modern engine does this automatically on PNG import, or as part of material/shader setup. You want different formats for different things, e.g AO, normals, bcs different formats have different compression artifacts.
pimlottc · 2h ago
How much extra time does it add for startup? For a single texture it’s probably negotiable but for a modern game, we’re talking about thousands of textures, so maybe it adds up?
charlie90 · 1h ago
i did some casual testing before of a png vs a compressed texture and its like 20x faster, so yes a big difference. most of the speedup is from not needing to calculate mipmaps since they are already precalculated.
LexiMax · 3h ago
> Unfortunately, AFAICT most people end up rolling their own exporters.
Aside from the closed-source NVIDIA texture tool, I'm also aware of AMD's Compressonator, and Microsoft's DirectXTex implementation of texconv. Intel also used to maintain the ISPC texture compressor, but afaik it's also abandoned.
jms55 · 2h ago
I've been evaluating texture compression options for including in Bevy https://bevy.org, and there's just, not really any good options?
Requirements:
* Generate mipmaps
* Convert to BC and ASTC
* Convert to ktx2 with zstd super-compression
* Handle color, normal maps, alpha masks, HDR textures, etc
* Open source
* (Nice to have) runs on the GPU to be fast
I unfortunately haven't found any option that cover all of these points. Some tools only write DDS, or don't handle ASTC, or want to use basis universal, or don't generate mipmaps, etc.
drak0n1c · 3h ago
Similarly in mobile apps where install size is key, designed image assets are better exported as SVG or platform draw code. There are tools to do this conversion easily and the benefit of draw code is that it is crisp at all sizes and can be dynamically colored and animated. Whether or not an app does this is often the reason why some relatively basic apps are 1 mb while others are 100+ mb.
cubefox · 13m ago
Soon this will all be outdated again because neural texture compression is on its way to replace block compression, with substantially higher compression ratios both on disk and in VRAM.
declan_roberts · 2h ago
It sucks to get to the "better" option and there actually is no better option other than bespoke export tools.
gmueckl · 4h ago
This advice is only practical if you have proper import tooling that can transparently do this conversion for your engine and preserves import settings per asset. Otherwise, this just adds a ton of fragile manual steps to asset creation.
LexiMax · 3h ago
This sort of batch asset conversion can be pretty easily automated with some combination of scripting and/or makefile.
Taking the time to learn about these sorts of compression methods is well worth it, as once you start loading assets of any appreciable scale or number, the savings in asset loading times can add up to be significant, turning what might have been a noticable jarring pause or stutter into something much less noticable.
Think about it, with hardware texture formats, not only are you not having to decode the PNG on the CPU, but you're also literally uploading less data to the GPU overall, since it can be transferred in a compressed form.
gmueckl · 22m ago
It's not so much the upload time/bandwidth, but some of the lossy compression algos are really slow.
reactordev · 3h ago
BS, Blender exports KTX2, your engine supports KTX2, Gimp exports DDS/KTX2, Substance Painter exports DDS/KTX2, three.js has a KTX2 converter.
Using image formats for texture formats is amateur game development. PNG’s are fine for icons or UI or while you’re still trying to figure out what you’re doing. Once you know, you switch to a faster, no translation required, texture formats that load faster, support physical layers, compression, and are already in BGRA format.
socalgal2 · 3h ago
You should always start from source IMO.
> Blender exports KTX2, your engine supports KTX2, Gimp exports DDS/KTX2, Substance Painter exports DDS/KTX2, three.js has a KTX2 converter.
If you're manually doing this conversion from source images to shipping formats your wasting your artist's time, AND, you'll likely lose the source images since people will generally only give you what's needed to build. "Hey, could you tweak building-wall-12.ktx?" "No, It was made in Photoshop and I can't find the file with the 60 layers so no, I can't tweak. Sorry"
reactordev · 2h ago
In this case, the source are TIFF's, pulled from the company texture CDN... I agree you start with high resolution sources but you don't ship lower resolution PNGs unless you're on an indie game or making a browser game.
Yes, because they learnt it somewhere, for example, this article.
I don't get the negativity. Unless you work on bleeding edge R&D, every technique you know has been documented somewhere by someone else. So only the bleeding edge R&D people should write tech blogs?
Anecdotally, even I had known what texture compression is, this article still taught me something: the existence of Tacant View. It looks like quite a neat app.
Of course, they might have written the blog post with the intention of drawing attention to themselves and being noticed. These days, I can't bring myself to be upset about that sort of thing - if the content is good, better self-promotion than AI slop or hyping up the next hot investment vehicle.
Aside from the closed-source NVIDIA texture tool, I'm also aware of AMD's Compressonator, and Microsoft's DirectXTex implementation of texconv. Intel also used to maintain the ISPC texture compressor, but afaik it's also abandoned.
Requirements:
* Generate mipmaps
* Convert to BC and ASTC
* Convert to ktx2 with zstd super-compression
* Handle color, normal maps, alpha masks, HDR textures, etc
* Open source
* (Nice to have) runs on the GPU to be fast
I unfortunately haven't found any option that cover all of these points. Some tools only write DDS, or don't handle ASTC, or want to use basis universal, or don't generate mipmaps, etc.
Taking the time to learn about these sorts of compression methods is well worth it, as once you start loading assets of any appreciable scale or number, the savings in asset loading times can add up to be significant, turning what might have been a noticable jarring pause or stutter into something much less noticable.
Think about it, with hardware texture formats, not only are you not having to decode the PNG on the CPU, but you're also literally uploading less data to the GPU overall, since it can be transferred in a compressed form.
Using image formats for texture formats is amateur game development. PNG’s are fine for icons or UI or while you’re still trying to figure out what you’re doing. Once you know, you switch to a faster, no translation required, texture formats that load faster, support physical layers, compression, and are already in BGRA format.
> Blender exports KTX2, your engine supports KTX2, Gimp exports DDS/KTX2, Substance Painter exports DDS/KTX2, three.js has a KTX2 converter.
If you're manually doing this conversion from source images to shipping formats your wasting your artist's time, AND, you'll likely lose the source images since people will generally only give you what's needed to build. "Hey, could you tweak building-wall-12.ktx?" "No, It was made in Photoshop and I can't find the file with the 60 layers so no, I can't tweak. Sorry"