ETC2 KTX compression compatibility, and difference between etc1s compression for glbs and textures

[johntdaly7]

Hello,

My team and I are trying to figure out what compression method works best for our glbs across browsers and hardware platforms. The engine we are using is BabylonJS. I posted a forum post there (forum post url extension is ‘etc2-ktx-compression-not-compatible-with-macos/22246’), but they directed me here.

With some testing via Browserstack and a few hardware devices, we discovered the results outlined in this chart:

I’m a bit confused as to why etc1s works for glb compression across all these platforms, and yet when we try to compress a cubemap-formatted skybox texture, that is not the case. The folks at Babylon put together a doc regarding compression methods for individual textures, but I am confused why this is different for glbs (which have textures in them). We would like to use the least amount of compression methods as possible.

ETC2 KTX compression seems like an almost-viable candidate. I’m a bit surprised that it did not work on macOS. I would think that if it is compatible on iOS, Apple would build out compatibility for macOS as well. Can someone confirm that the compatibility in the chart, especially regarding etc2 on macOS is correct?

Lastly, we tested etc1s glb compression (created using @donmccurdy’s gltf-transform) on Edge Browser on a windows machine. We received an out-of-memory error from the browser. This was only the case for the compressed model, not the uncompressed model. Due to that, we believe that this was a GPU memory issue. The version of Edge that this issue was reproduced on was 91.0.864.71, 91.0.864.70, and 91.0.864.37. This seemed to only be an issue on Windows machines. This may be a bug with the compression, but we would like to confirm that this is the case.

Thanks in advance for the help!

[donmccurdy]

I think there’s at least one misunderstanding here. KTX2 textures using Basis Universal compression (either ETC1S or UASTC) are compatible with all browsers, operating systems, and GPUs. In the worst case — a very old browser or GPU — these textures can still be decoded to RGBA pixels in the browser and uploaded to the GPU uncompressed. In modern GPUs and browsers, the texture data does not need to be decompressed and may be quickly transcoded to one of many compressed texture targets. For more technical detail on this, see the KTX Developer Guide.

The web browser and the GPU are more important than the operating system here — it is unlikely that there is a bug specifically on Windows or macOS machines — and in the case of Browserstack it may be difficult to know what GPU is being used. It is possible that a particular engine (e.g. babylon.js or three.js) may have a bug on a particular platform, but this is easier to isolate by testing multiple engines.

Also note that there are important constraints with respect to texture sizes, dimensions, and mipmap filter settings when using any compressed texture format, particularly with WebGL 1. For best results I would suggest testing a 1024x1024 texture with a full mipmap chain (or some other power of two dimensions <= 2048) .

If this doesn’t clear things up, would you be able to share an example of a texture you’re trying to compress, the steps used to compress it, and the steps used to view it on these browsers? gltf-transform is not doing anything particularly fancy here, but does resize textures when necessary and generate a full mipmap chain.