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.
Why not just use BC7 (BC6H for HDR) textures on desktop and ASTC on mobile? There's no need to ship an format like basisu that converts to both. There are rust bindings for both the Intel ispc BC(n) compressor and ASTCenc.
Basis Universal also gives you much smaller size over the wire than hardware compressed formats (closer to jpg), which is important at least for web games (or any game that streams asset data over the net).
I don't think you'll find anything much better than basis universal, assuming you want textures compressed on the GPU and the simplicity of shipping one file that decodes quickly enough. I've followed development of the encoder, and its authors know what they're doing.
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).
> 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.
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.
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?
I assume parent means "import" as in "asset pipeline import", not importing at game start. Using hardware-compressed texture formats will actually speed up loading time since you can dump them directly into a 3D API texture without decoding.
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.
If you’re compressing at load-time it can be a lot. You can do a quick and dirty compress to BC1-3 (assuming you are on PC) in a few tens of milliseconds but quality will be suboptimal, higher quality will likely take a few seconds per texture and going to BC6 takes even longer but will look much better.
It's an open ended optimization problem. You can get bad results very quickly but on high quality settings it can take minutes or hours to compress large textures.
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).
It’s not entirely trivial (if you care about texture quality) you’re choosing 2 endpoints in 3d space that can be linearly interpolated to values that best fit 16 points in 3d space.
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.
I have no idea how things are done today but in the opengl 1.x era multiple textures would sometimes be stored in a single image, so to get a different texture you would pick different texture coords.
I’ve been using bc7 since 2012, and even have a video codec using bc7 keyframes (we needed alpha videos, even have a patent for it). Our emphasis is not file size, but playback speed. Bc7 renders 20-40% faster than raw rgba32, and we overlay 5-7 videos on screen simultanously, so every boost helps.
We also have custom encoders for the custom video format.
HAP is a family of codecs for GPU accelerated decoding. HAP R uses BC7 frames.
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.
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.
Not for multi-channel SDF at least. Texture compression works terribly badly with "uncorrelated" RGB values as they work in chroma/luminance rather than RGB. For uncorrelated values like normal maps, there are texture compression formats specifically for that (RGTC).
However, your typical MSDF font texture has three uncorrelated color channels and afaik there isn't a texture compression format with three uncorrelated channels.
Good question. I don’t have any authored SDF content right now so take this with a grain of salt, but my thoughts are:
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.
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.
A single channel SDF can be encoded to BC4 with fairly good quality, and it can actually represent a wider range of values than a u8 texture... but with the downside of only having 8 values per 4x4 block.
So if the texture is small I'd use u8, for a very large texture BC4 isn't a bad idea.
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.
It will be interesting to see whether this 'prefers' some types of textures over others. Also how well it works for non-image textures like normal maps or other material system parameters.
The more efficient versions compress the entire material stack in one, to exploit inherent redundancies, including albedo, normals, roughness etc. The main problem, as far as I can tell, is the increased GPU performance cost compared to block compression. Though recent research shows some versions are already pretty manageable on modern GPUs with ML acceleration: https://arxiv.org/abs/2506.06040
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.
Developers should revisit using indexed color formats so they only map the colors that they are using within the texture rather than an entire 32bit color space. This coupled with compression would greatly reduce the amount of ram and disk space that each texture consumes.
BC1 uses 4 bits per pixel without being limited to 16 colors though.
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).
Indexed color formats stopped being supported on GPUs past roughly the GeForce 3, partly due to the CLUTs being a bottleneck. This discourages their use because indexed textures have to be expanded on load to 16bpp or 32bpp vs. much more compact ~4 or 8bpp block compressed formats that can be directly consumed by the GPU. Shader-based palette expansion is unfavorable because it is incompatible with hardware bilinear/anisotropic filtering and sRGB to linear conversion.
Tbf, you wouldn't want any linear filtering for pixel art textures anyway, and you can always implement some sort of custom filter in the pixel shader (at a cost of course, but still much cheaper than a photorealistic rendering pipeline).
Definitely might make sense IMHO since block compression artefacts usually prohibit using BCx for pixel art textures.
> 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.
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.
We used to learn all this stuff by word of mouth back in the day, and it's been interesting watching young developers "rediscover" these things on YouTube, etc. Its great because now these techniques are part of public discourse rather than known only by a few.
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.
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).
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.
Mostly web games I'd think, it's not uncommon to ship with png or jpg textures for small download size (but then you pay with in-memory size and texture sampling bandwidth - thus Basis Universal).
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!
I don't think any current games use megatextures-- it takes too much memory, and you can compose tiling textures at runtime for good results, that additionally supports dynamic modifications.
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.
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.
This can be solved with a few lines of python and a naming convention for texture file names (or alternatively a small json file per texture with metadata).
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.
> 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"
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.
Note that KTX2 is a container format. It can contain uncompressed or compressed texture data. Some of the tools you mention might support "KTX2" but they won't compress textures for you, they just put the uncompressed data in a KTX2 container.
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.
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.
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.
We do have the existing bindings to a 2-year old version of basis universal, but I've been looking to replace it.
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).
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.
It takes that long to do a good compression on the format that interpolates 2 colors for each 4x4 block? Huh.
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).
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-...
We also have custom encoders for the custom video format.
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.
https://pomf2.lain.la/f/kg9r139e.webm needs non-black background, change the <html> element's background-color in developer tools if necessary
However, your typical MSDF font texture has three uncorrelated color channels and afaik there isn't a texture compression format with three uncorrelated channels.
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.
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.
So if the texture is small I'd use u8, for a very large texture BC4 isn't a bad idea.
Jpeg or other variable bitrate compression schemes are not applicable.
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.
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).
Definitely might make sense IMHO since block compression artefacts usually prohibit using BCx for pixel art textures.
https://github.com/KhronosGroup/KTX-Software
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.
Mostly web games I'd think, it's not uncommon to ship with png or jpg textures for small download size (but then you pay with in-memory size and texture sampling bandwidth - thus Basis Universal).
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"
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.