Yo @bghgary … Hey bro… I am trying to use custom image types .basis for my textures inside my gltf. I am making a an extension to support the .basis file offically so it wont show errors in GLTF Validation.
But… In babylon… aside from GLTF Validation warnings it still should be able to load .basis files…
But the Babylon.GLTFLoader is throwing an error when not using .png or .jpg images types…
I can tell where there error is being thrown… Is it because of the the value of image.mimeType that is being passed in _loadTextureAsync…
How can i let my custom GLTF image type of .basis work with BABYLON.GLTF.Parsing ???
I am already working on the implementations for Babylon, but they will take some time to finish as there are issues with the KTX2 libraries at the moment.
Seems to be making a compressed KTX2 with Basis Payload.
A couple questions:
1… Is there ANY viewer so i can view the output ktx2 file ???
2… Is there any support in babylon yet (maybe manually hacking) to load the ktx2 files ???
3… When making ktx2 compressed images… Should we ALSO keep the original .png for fallback or something… Or should re REPLACE the .png witht .ktx2… Or keep both .png and ktx2 ???
I’ve only ever built KTX-Software on a linux machine using WIndows Linux Subsystem. I think you might consider raising this issue (i.e. the instructions are not clear) on GitHub even though you got it working.
I have an local branch that can do it, but I haven’t update it in a long time, so it’s probably broken. The main issue for the web right now is that KTX-Software compiled to WASM is a huge 2MB file.
It depends. If the intent is to be a small payload, then it should be marked as required in the glTF and it will only load in clients that support the extension. It’s very similar to the Draco extension.
I talking about what extension do we put on the original GLTF texture asset… The .png or the .ktx2 ???
Will .ktx2 be specified in the KTX2_image_ext part. That way the original png loads UNLESS the gltf has the KTX2 extension… then it would be the GLTF Extension responsibility to load the alternative .ktx2 filename from its extension json and load the the .ktx2 file instead of the .png
…
Like the KTX extension in Babylon… You still specify the .png but you set the extension used… ie -dxt.ktx … And all calls to load that original .png are replaced by the -dxt.kxt
You can choose to make both png and ktx2 available such that a client will load ktx2 if it supports ktx2, but a client can fallback to png if it doesn’t support ktx2. In this scenario, the extension is not required. This scenario is useful if the asset is hosted on a server somewhere as loose files so that it has the maximum compatibility without compromising on size.
The other scenario is to mark the extension as required and only put ktx2 in the asset. This is good to minimize size but sacrifices compatibility. For closed systems, this is a good choice.
I’ll leave it to @bghgary for a definitive answer, but I’d assume that the ktx2 texture loading should be transparent to the user, Ideally that snippet should be all that’s needed to load it
Yo @bghgary … Where is the REPO you made for Babylon that has support for rendering these new basisu ktx2 files… I wanna see what they will look like in babylon.js
In the big picture … a 2mb size increase for the core engine to be able to use super compressed basis images that would ultimately save much more than 2mb in compressed images… heck file size are almost 10 percent on some images with qlevel set to 255
Anyways the 2mb is well worth all the mb you save in super compressed images
