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.

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.

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).

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?

What did bevy end up using?

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.

Oh cool I used bevy for something. Really good shit

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.

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.

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.

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.

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.

Is there some open equivalent of alpha in videos?

You have a patent for alpha in videos? Curious to hear more about this - the application you describe sounds eerily familiar to me.

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.

GPU texture compression needs fixed bitrate for random access, usually 2 bits per pixel (128b for 8x8 block) with modern formats.

Jpeg or other variable bitrate compression schemes are not applicable.