[Feature] Adding KTX2

[miruji]

Problem / Motivation

I think this issue will be very useful when working with: textures, shaders, materials, and the model system.

Right now, regular raster images are used — which in the future will lead to high memory consumption.

The point is that Freven-vanilla and other games with large spaces — even with good optimization — will require a lot of memory for textures.

A simple example. I mentioned it a long time ago.

KTX2 (+Basis Universal), in turn:

1. Is supported on most (if not all) required platforms
2. Can automatically adapt the image to the platform
3. Supports dynamic work with images (for example, changing a texture in real time or something else)
4. Can support dynamic format changes (there are many formats, plus you can use heavy compression or best quality)
5. Supports mipmaps (including dynamic work with them and modification)
6. Supports working with models
7. GPU-friendly storage (stores the image in compressed form)
8. Supercompression (Zstd, etc.)
9. Metadata (very useful for storing additional data)
10. Cubemaps and texture arrays
11. Streaming-friendly (streaming and gradual loading)
12. Standardized by Khronos (excellent support for glTF)

Proposed solution

I propose using the ktx2-rw library. I personally tried it, and an almost complete pipeline for CaveVox took me about 1500 lines. Considering Freven as a whole, I think the entire API will take around 3–4 thousand lines of code.

But this is a very powerful architecture. If we also design a proper API between the implementation of textures, materials, models, and shaders — it will turn out very well.

That is, this will completely solve the texture problem for Freven.

Alternatives considered

There are alternatives, but they will be much more complex, and I don’t see the point in that.

[ogyrec-o]

Yeah, I think this is worth doing, but I'd scope it more narrowly.

KTX2/Basis looks like a strong fit for Freven as the rendering, material, and model pipeline grows. At the same time, I would treat it as part of the engine asset pipeline, not as a complete "texture solution" by itself

For this issue, I think the useful goal is to define a realistic v1 target:

• what KTX2 support actually means in Freven,
• where transcoding/conversion happens,
• what the fallback story is,
• and how it integrates with textures/materials/model loading.

I would also avoid locking this issue to one specific library too early. ktx2-rw may be a good candidate, but that should stay an implementation choice until the pipeline boundary is clearer.

Also, I wouldn't make this a blocker for basic model-system work. It's an important rendering/asset-pipeline feature, but it should stay scoped and explicit.