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.
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"
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.
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.
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.
1. Fonts are a very small percent of most games’ storage and frame time, so there’s less motivation to compress them than other textures
2. Every pixel in a font is pretty intentional (unlike in, say, a brick texture) so I’d be hesitant to do anything lossy to it
I suspect that a single channel SDF for something like a UI shape would compress decently, but you could also just store it at a lower resolution instead since it’s a SDF. For SDF fonts I’d probably put them through the same asset pipeline but turn off the compression.
(Of course, if you try it out and find that in practice they look better compressed than downscaled, then you may as well go for it!)
[EDIT] a slightly higher level answer—you probably wouldn’t compress them, but you’d probably still use this workflow to go from my_font.ttf -> my_font_sdf.ktx2 or such.
It takes that long to do a good compression on the format that interpolates 2 colors for each 4x4 block? Huh.
We also have custom encoders for the custom video format.
In a way the hardware-compressed formats are paletted, they just use a different color palette for each 4x4 pixel block.
Having said that, for retro-style pixel art games traditional paletted textures might make sense, but when doing the color palette lookup in the pixel shader anyway you could also invent your own more flexible paletted encoding (like assigning a local color palette to each texture atlas tile).
I personally wouldn’t compress pixel art—the artist presumably placed each pixel pretty intentionally so I wouldn’t wanna do anything to mess with that. By pixel art’s nature it’s gonna be low resolution anyway, so storage and sample time are unlikely to be a concern.
Pixel art is also a special case in that it’s very unlikely you need to do a bake step where you downsize or generate mipmaps or such. As a result, using an interchange format here could actually be reasonable.
If I was shipping a pixel art title I’d probably decide based on load times. If the game loads instantly with whichever approach you implement first then it doesn’t matter. If it’s taking time to load the textures, then I’d check which approach loads faster. It’s not obvious a priori which that would be without measuring—it depends on whether the bottleneck is decoding or reading from the filesystem.
I may have been a little off with saying seconds per texture but it’s definitely non trivial amounts of time. And ects (mobile) and BC7 are certainly still not something you want to compress to at game load-time.
Some comparisons of texture compression speeds for various formats (from 2020 but on a 12core i9): https://www.aras-p.info/blog/2020/12/08/Texture-Compression-...
Oh but if you care about GPU support then I'm pretty sure https://github.com/GPUOpen-Tools/Compressonator has GPU support for BC(n) compression at least. Could rip those shaders out.
Definitely might make sense IMHO since block compression artefacts usually prohibit using BCx for pixel art textures.
You might beat basisu if you encode for one texture format at a time, and use perceptual RDO for albedo textures.
Another alternative would be to use JPEG XL for distribution and transcode to GPU texture formats on install, but you'd have to ship a decent GPU texture compressor (fast ones leave quality on the table, and it's really hard to make a good one that isn't exponentially slower).
https://pomf2.lain.la/f/kg9r139e.webm needs non-black background, change the <html> element's background-color in developer tools if necessary
They cite 0.55ms per frame at 1080p on a recent Intel GPU. The budget for one frame at 60 FPS is 16.7ms, so the performance cost would be 3.3% of that. Though higher resolutions would be more expensive. But they mention there is room for performance improvements of their method.
The other problem is probably that it isn't very practical to ship multiple versions of the game (the old block compressed textures for lower end hardware without ML acceleration), so adoption may take a while.
So if the texture is small I'd use u8, for a very large texture BC4 isn't a bad idea.
There's support for various HAP codecs in ffmpeg, VLC, etc, but I think support for HAP R is lacking. However HAP, HAP Alpha, HAP Q and HAP Q Alpha have wide support. They use DXT1/DXT3/DXT5/RGTC afaik.
Compared to your implementation, their addition of BC7 is quite recent, yet they did have support for alpha channels for probably a decade.
However, your typical MSDF font texture has three uncorrelated color channels and afaik there isn't a texture compression format with three uncorrelated channels.
And my out-of-the-box Gimp 3.0.4. doesn't have KTX export at all. Didn't check the other tools you mention.
And the newer compression formats have larger block sizes from 8x8 to even 12x12 pixels. ASTC and BC7 are a different beast to the early texture compression formats. You can get pretty awesome image quality at 2 bits per pixel (and slightly less awesome at less than a bit per pixel).