Closed br-matt closed 3 years ago
Thanks for the heads up, I'll take a look; three.js KTX loading implementation recently changed substantially, will see where the problem is.
Hmm - I don't think I can reproduce this. Any chance you can share an example asset with this problem? (feel free to do it privately via email arseny.kapoulkine at gmail.com)
Thank you I will do that now
Thanks, for visibility I'll share the results here.
The core problem here is the same as https://github.com/KhronosGroup/KTX-Software/issues/360. The input file contains a 16-bit PNG normal map; toktx can't encode that due to the linked bug.
gltfpack proceeds to emit the file that doesn't have the URI / bufferView for the texture since it wasn't encoded, like this:
"images":[
{
}
],
"textures":[
{
"extensions":{
"KHR_texture_basisu":{
"source":0
}
}
},
],
Before r125 I think the error was silently ignored, but now it's more prominently visible.
Related, this would have made debugging easier here https://github.com/mrdoob/three.js/pull/21177
Thank you for looking into that so quickly, using 8bit and it loads right up now. Will keep an eye on that toktx issue for when we can go back to 16
Hello when using the
-tu
option, the meshes no longer load in three.js with the above error. Using-tc
and they are loading just fine. We are seeing too many artifacts in the super compressed version's normals and would like the flexibility to have some assets with higher quality.Three.js r125 using the ktx2/basis loader