glTF basisu extension platform support

glTF glTF: Support
1

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 ?

2

In practice, glTF files rarely include these “fallback” copies of images. It is likely enough that users will have a separate ‘source’ copy of the glTF with traditional image formats instead. Not sure if that’s good enough for your use case.

Can ETC1S be transcoded to ASTC? I was under the impression that UASTC → ASTC was possible but ETC1S → ASTC was not, though I haven’t tried. Going on the diagrams in the KTX Developer Guide.

I think ETC1/2 + ASTC might be a reasonable minimum, with RGBA8 fallback.

3

Thanks for the helpful info.

I think the extension intentionally is designed for and starts with the assumption of a fallback texture source:

before it explains the use case without fallback.

But for .glb use I can see that including a fallback jpp/png does not make a lot of sense, and supporting a RGBA8 target format may not add (much) to the wasm code.

I asked and ETC1S → ASTC transcoding apparently is supported:

But even with much reduced transcoding functionality the transcoder code remains rather heavy.

4

Designed for, yes – but very rarely used. The same is true for Draco and Meshopt compression, it is possible to create glTF files that include compressed binary payloads in one .bin, with uncompressed fallback data in a second .bin.

It’s a nice feature of the design. But in practice, people don’t create files that way – in most cases it’d just be unwanted extra data. They have unoptimized source files, and (separate) optimized distribution files for their target platforms. If your viewer assumes that KTX2 textures will have PNG/JPEG fallbacks embedded, I don’t think you’ll find many assets using that fallback path.

5

Ok, makes sense. It would not be the ktx2 container which has the PNG/JPEG embedded (although I think that is possible as well) but the fallback would be outside the ktx2 container in an extra file.

Well, in this case it may be ok to only support ASTC capable platforms, especially if a dedicated, light transcoder becomes available.