I am trying to understand how to reach/support most web browsers with a minimal glTF texture basisu extension implementation.
The extension requires support for three internal, basis universal (basisu) formats:
- ETC1S with BasisLZ (used for color-perceptual content)
- UASTC with optional Zstandard compression (used for data content)
This is already an attempt to limit the necessary effort for supporting ktx2 containers with highly compressed textures since there are many more combinations.
The idea is to use available, efficient transcoders to generate GPU supported texture formats from those internal formats. These are called transcoders, not decoders because they may not have to completely decode and then reencode between formats.
As a first simplification, let’s exclude uncompressed GPU formats with the assumption that the glTF source will provide fallback images in any case (since not all glTF viewers will support the extension).
This leaves these compressed GPU formats:
caniuse .com mdn-api_webgl_compressed_texture_s3tc
caniuse .com mdn-api_webgl_compressed_texture_etc1
caniuse .com mdn-api_webgl_compressed_texture_etc
caniuse .com mdn-api_webgl_compressed_texture_pvrtc
caniuse .com mdn-api_webgl_compressed_texture_astc
caniuse .com ?search=bptc
[sorry, links are not allowed for me].
What most implementations then do, is to determine the best available GPU format depending on the platform, and transcode to that format. However, let’s prefer simplicity over performance/quality and see if there is a single GPU format which can satisfy most use cases in a basic manner.
Looking at the caniuse stats, it turns out that only astc is supported by: desktop chrome/firefox/safari, and also mobile chrome/safari . This makes astc the preferred target format.
Does that sound correct ? Let’s assume modern phones (and pregenerated mipmaps).
How far would a glTF viewer with such limited basisu texture support go ?