KTX2 support for threejs.com/editor

[hybridherbst]

Is your feature request related to a problem? Please describe.

Threejs supports KTX2 when loading GLTF files, but the editor doesn't seem to support it yet (the KTX2 loader isn't registered according to the console).

Describe the solution you'd like

GLTF files that use KTX2 texture compression should open in threejs editor.

Additional context

[donmccurdy]

Would loading GLTF w/ KTX2 textures still be useful to you if the Editor can't export the scene after displaying it? Unfortunately that is a rather more complicated thing to fix, since the we can't reconstruct the original KTX2 texture from the transcoded data. Some discussion in #13911 (comment).

[hybridherbst]

Ah, I see. What I was actually trying is indeed to export to USDZ, as I was investigating google/model-viewer#2503 (besides other issues, model-viewer auto-export to USDZ not working when model has ktx2 textures). Seems that's kind of the same issue then – as the textures can't be read back to CPU they can't be converted.

I'm not sure I quite understand the issue though, couldn't the KTX-unpacked texture be blitted into an ARGB32 target and read back to the CPU for conversion to any other format? (that's what the flow would be in e.g. Unity)

[donmccurdy]

Ah, probably same issue with model-viewer then, yes.

Rendering to RGBA target would be a good fallback. Perhaps lossy depending on the device where it's running... e.g. if we've already transcoded to PVRTC on an iOS device, KTX2 -> PVRTC -> RGBA (for USDZ) will be lossy where KTX2 -> RGBA is not, I think. The proposal in #13911 was to add a new TranscodableTexture class that retains the pre-transcode data in some form.

[hybridherbst]

I might be mistaken but I think KTX2 (usually ETC1S or UASTC) is already lossy, so not sure if there's actually a noticeable quality difference between these paths. Should I keep this issue here open?

[donmccurdy]

Right, KTX2 is already lossy compression. Transcoding KTX (especially UASTC) to older formats like PVRTC will lose a bit more, and that's likely to be quite noticeable, similar to the differences between ETC1S and UASTC. But we are just talking about older iOS devices here. This isn't a blocker on the approach, just something to be aware of. The https://github.com/KhronosGroup/3D-Formats-Guidelines repository has more detailed documentation on device support and which transcoding targets are preferred.

I'm not sure what solution others would prefer (editor converts textures? add this feature to USDZExporter? other exporters?) so probably good to keep this open for discussion. Another option would be to provide some way of configuring KTX2Loader to output RGBA textures to begin with, and enable that in the editor ... loses the performance benefits, but much easier to export.

[Mugen87]

Since the editor should now display KTX2 textures (embedded in glTF assets as well as selected via the UI), this issue can be closed.

The missing serialization/deserialization support is tracked in #17974. #13911 also discusses a possible solution based on TranscodableTexture.