Shipping textures as PNGs is suboptimal
64 comments
·September 6, 2025jms55
xyzsparetimexyz
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.
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.
flohofwoe
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).
raincole
What did bevy end up using?
jms55
Nothing, I haven't found a good option yet.
We do have the existing bindings to a 2-year old version of basis universal, but I've been looking to replace it.
pornel
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).
raincole
Is basis universal that bad? I thought it's more or less invented for this purpose.
BriggyDwiggs42
Oh cool I used bevy for something. Really good shit
LexiMax
> 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.
Stevvo
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
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?
flohofwoe
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.
charlie90
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.
cout
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.
midnightclubbed
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.
Dylan16807
> higher quality will likely take a few seconds per texture
It takes that long to do a good compression on the format that interpolates 2 colors for each 4x4 block? Huh.
smallstepforman
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.
kookamamie
You have a patent for alpha in videos? Curious to hear more about this - the application you describe sounds eerily familiar to me.
chmod775
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.
_def
Is there some open equivalent of alpha in videos?
the8472
vp9 and avif have alpha, whether it's patented I don't know.
https://pomf2.lain.la/f/kg9r139e.webm needs non-black background, change the <html> element's background-color in developer tools if necessary
drak0n1c
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.
declan_roberts
It sucks to get to the "better" option and there actually is no better option other than bespoke export tools.
rudedogg
Do you still want to do this for SDF font textures? Or is the lossiness an issue?
exDM69
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.
masonremaley
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.
xeonmc
Tangential: where does pixel art textures fall under in this consideration for asset compression?
masonremaley
That’s also a good question.
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.
rudedogg
Makes sense, thanks for the insight.
TinkersW
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.
jam
Are there good texture generators that export in KTX2? I use iliad.ai mainly, but for PNGs.
pmarreck
JPEG-XL, your time has come? ;)
cubefox
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.
flohofwoe
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.
cubefox
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.
cshores
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.
flohofwoe
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).
ack_complete
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.
flohofwoe
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.
shmerl
Surprisingly I don't see ktx tools in Debian.
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.