zeux / meshoptimizer

Mesh optimization library that makes meshes smaller and faster to render
MIT License
5.6k stars 480 forks source link

-tu option will not load in THREE.JS #236

Closed br-matt closed 3 years ago

br-matt commented 3 years ago

Screen Shot 2021-01-29 at 1 14 35 PM

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

zeux commented 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.

zeux commented 3 years ago

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)

br-matt commented 3 years ago

Thank you I will do that now

zeux commented 3 years ago

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.

zeux commented 3 years ago

Related, this would have made debugging easier here https://github.com/mrdoob/three.js/pull/21177

br-matt commented 3 years ago

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