Support for glTF+KTX2/Basis textures ("KHR_texture_basisu")

[donmccurdy]

The KTX2 (".ktx2") texture format uses Basis Universal compression to provide several benefits:

1. Much lower in-memory size for textures.
2. Much faster GPU upload for textures.
3. (Sometimes) Lower file/transmission size for textures.

In combination these make it possible to use more texture detail at lower performance cost in a scene, and these textures can also be embedded in glTF files.

Adding support in A-Frame would be straightforward (similar to #4910) except for one issue —  KTX2Loader.js is in examples/jsm and there's no examples/js equivalent. Does A-Frame's three.js fork have an existing way of pulling in examples/jsm files? Or should we ask to have the examples/js version created on the three.js repository?

[dmarcos]

Thanks so much. Not sure what's the best way to handle. An examples/js version would be great is possible. Would that be something reasonable for the THREE folks?

[donmccurdy]

Let's give it a try! Opened mrdoob/three.js#22485. If that gets merged we'll need to import THREE.KTX2Loader and its dependency, THREE.WorkerPool.

[dmarcos]

Let's give it a try! Opened mrdoob/three.js#22485. If that gets merged we'll need to import THREE.KTX2Loader and its dependency, THREE.WorkerPool.

It seems it got merged. Yeeeeah! Thanks so much

[XrayBravoGolf]

Let's give it a try! Opened mrdoob/three.js#22485. If that gets merged we'll need to import THREE.KTX2Loader and its dependency, THREE.WorkerPool.

@dmarcos @donmccurdy
Were there any work-in-progress of the KTX2Loader being put into A-Frame right now? As of today my build out of the master branch (latest commit 9e0cea) still gives this warning:

components:gltf-model:warn THREE.GLTFLoader: setKTX2Loader must be called before loading KTX2 textures

, thus I assume it has not been made part of this project yet.

[XrayBravoGolf]

By the way, is the fact that A-Frame is using the super-three instead of the THREE directly from mrdoob/three.js going to affect this KTX2 loader issue?

[dmarcos]

@XrayBravoGolf No, the super-three fork doesn't have any changes concerning KHR_texture_basisu. Functionality should be identical to THREE

[jameskane05]

@donmccurdy @dmarcos I'm working on a PR attempting to add KTX2 texture compression support to A-Frame gltf-model using the same pattern used for Draco compression support:

https://github.com/jameskane05/aframe/pull/1/files jameskane05#1

Trying to edit examples/js/test/model.html as an example in the above PR, but still getting an error about THREE.WorkerPool() while trying to load the transcoder files from a CDN folder like so:

<a-scene gltf-model="basisTranscoderPath:https://cdn.jsdelivr.net/npm/super-three@0.141.0/examples/js/libs/basis/;">

Again, this is how it's handled for Draco, I was assuming it's the same, but usually the Basis/KTX2 transcoders are loaded as a module, not remotely. The three.js KTX2 example sets a relative path in the same way:

https://github.com/mrdoob/three.js/blob/master/examples/webgl_loader_texture_ktx2.html#L79

Seems close unless I'm missing something! Here's where I'm leaving it for tonight:

[jameskane05]

@donmccurdy rereading your comment more closely from: mrdoob/three.js#24398

"I think it may be easier just to make a custom KTX2Loader build for A-Frame if necessary."

Is that to say that the super-three version of the KTX2Loader is problematic w/ A-Frame for some reason? You mentioned WorkerPool specifically, which I'm already running into. That's here:

https://github.com/supermedium/three.js/blob/super-r141/examples/js/loaders/KTX2Loader.js

[donmccurdy]

The super-three version of the KTX2Loader UMD module is OK I think, we've just stopped releasing new UMD (examples/js) versions of this loader, and future releases will just have the ESM (examples/jsm) versions. WorkerPool would need to be included in the A-Frame builds alongside KTX2Loader.

[donmccurdy]

I think you'll need to import the examples/js (UMD) version rather than the examples/jsm (ESM) version, since A-Frame doesn't support ES Modules in the build process. The UMD option just ensures that whatever you import gets attached to the global window.THREE object.

[jameskane05]

Got it working! Going to format the example a bit better and create a PR shortly 👍