.basis texture compression in inspector

Questions
1

Hi together,

we have been playing around with compressed texture formats recently. And noticed that for .basis files. that the inspector always shows ‘RGBA & Uncompressed’ (.dxt-ktx works as intended).

For further understanding we debugged the code a bit and came to a conclusion. However, we are not super deep into the topic and would like to discuss our findings first.

Thesis
Basis textures are correctly loaded and passed to the GPU in a compressed format (if supported). However, we think the babylon texture object is not updated correctly. The inspector shows the format to be RGBA and uncompressed

What I’ve noticed on my PC:

  • basisTextureLoader.ts
    • loadData
      • line 100 (before TranscodeAsync is called)
        → supportedCompressionFormats → s3tc & bc7 = true
      • line 105 (inside the callback before LoadTextureFromTranscodeResult is called)
        → result.format = 6 (BASIS_FORMATS.cTFBC7)
  • basis.ts
    • LoadTextureFromTranscodeResult
      → else path is taken since format is not -1
      → the texture format is determined as TEXTUREFORMAT_COMPRESSED_RGBA_BPTC_UNORM with BasisTools.GetInternalFormatFromBasisFormat
      → gl.texture is created with the correct format (engine._uploadCompressedDataToTextureDirectly → gl.COMPRESSED_SRGB_ALPHA_BPTC_UNORM_EXT)
      → texture.format and texture.type is never set.

Conclusion / Discussion
With my limited knowledge about this topic, I would think that it is only a display error and that within the else section of the LoadTextureFromTranscodeResult function the texture.format and texture.type must also be determined and updated.

  • texture.format: should probably be the same as BasisTools.GetInternalFormatFromBasisFormat
  • texture.type: no idea how to define that…
2

cc @sebavan / @bghgary

3

It sounds weird indeed, I ll try to have a fix today.

1 Like
5

Thanks so much!

One additional thing I’ve noticed today, is that the fallback for devices, that don’t support texture compression, might not be working as intended. However, I don’t have such a device and therfore manualy set all settings within the supportedCompressionFormats to false right before basisTextureLoader.ts -> TranscodeAsync is called. The result was a completly black image.

By removing the else part in basis.ts -> GetSupportedTranscodeFormat. I was able to force the fallback option and get an image displayed. But this doesent seem to be a good way to me. First of all it always fallbacks to RGB even if the source image has a alpha channel. And more importantly as soon as I tried to inspect the texure in the babylon inspector it turned black again…

Please let me know if these are not related and if I should create a sperate forum entry for this.

6

Ok I have a fix for the format, will look into the second part ASAP and let you know. (THANKS A MEGATON for your thorough analysis)

7

Here is the PR: Fix issues with basis texture and inspector (display format, preview window and broken texture) by sebavan · Pull Request #12853 · BabylonJS/Babylon.js · GitHub

Thanks a lot again as it was actually 4 tiny issues related to each other :slight_smile:

1 Like
9

Awesome thank you! Looking at the PR is the fallback of a .basis file always a RGB texture without alpha information? Or would it be possible to fallback to a RGBA depending on the source file?

10

Currently only RGB looks supported with the 565 format but let s add @bghgary to know if Basis supports RGBA fallbacks as well

1 Like
11

Hi @bghgary where you able to have a look at this?

If a fallback to RGBA is not possible, what would be the best way to check, if the current device supports a .basis file? Should I just check if engine.texturesSupported is completely empty. However, I belief this function only returns the support for .ktx file compression, right?

12

@bghgary is in vacation until next week :slight_smile:

1 Like
13

Unfortunately, I don’t know this either off the top of my head. I didn’t write any of this code. We will have to look into the Basis decoder.

Is there any reason why you don’t use .ktx2? We have better support for KTX2 as it is a Khronos standard.

14

Thanks for the tip about .ktx2. We only looked at .ktx in the beginning but it doesn’t support BasisU compression. And in the end we didn’t want to generate / distribute multiple files for different compressions.

But great to know, that Babylon supports .ktx2 with BasisU😊. I’ve just tested it out and the support works great (including the fallback to RGBA).

For our case we probably will switch to .ktx2. But maybe I’ll also find some spare time to investigate the RGBA fallback for .basis as well.

1 Like