UASTC option returning error

Hey, Don! In the past I’ve used gltf-pipeline for draco compression and the basisu command line to create basis textures, then programmatically applied the basis textures. I recently found gltf-transform and I’m a huge fan! Thanks for building an awesome tool.

I’ve been experimenting with gltf-transform this morning and have a few questions and 1 issue. Here’s the model for reference:

Skateboard.zip

Issue:

gltf-transform uastc Skateboard.glb gltf-transform/Skateboard.glb This command is not working for me and returns Texture compression failed.. The etc1s option works. For reference, the uastc command works for me with the toktx cli. I used it on the 3D-B.jpg and successfully received a ktx2 file. However, something is wrong because it doesn’t work in your gltf-viewer (the texture showed up black) and it also doesn’t work in PVRTexTool. Unfortunately the etc1s version of 3D-B texture has horrible quality, even with highest quality settings, so I was wanting to try uastc. Any guidance? Probably not the case but could this issue be something to do with this texture not being square?

Questions:

Could you provide any suggestions about converting normal maps to ktx2 and maintaining quality? I read about the -separate_rg_to_color_alpha option on the basisu github page but seems like I’d have to stick with programmatically applying .basis textures instead of embedding the ktx2 texture? “For tangent space normal maps, you should separate X into RGB and Y into Alpha, and provide the compressor with 32-bit/pixel input images. Or use the “-separate_rg_to_color_alpha” command line option which does this for you. The internal texture format that Basis Universal uses (ETC1S) doesn’t handle tangent space normal maps encoded into RGB well. You need to separate the channels and recover Z in the pixel shader using z=sqrt(1-x^2-y^2).” Maybe It’s an issue with the encoding, does gltf-transform auto set the texture encoding to linear on normal maps?

When exporting a model from blender to be used in three.js, what is your normal pipeline of optimizations? I’m guessing you run a sequence of gltf-transform commands and then maybe others? Do you also use gltfpack? I just learned about it and am interested in testing it out but it seems more intense than gltf-transform and like it may cause some issues with three.js?

[hayden2114]

Wonderful, thanks for all the explanations. I learn so much from you. You’re truly the man @donmccurdy! Thanks again

[donmccurdy]

Is there any runtime advantage to gltpack’s Meshopt compression vs draco besides potentially smaller file size?

I think Draco tends to compress geometry a bit further, but it only compresses geometry. MeshOpt will also compress animations and morph targets, and decompresses faster during loading (or did, the last time I checked). In either case you’ll need to register the right decoder with THREE.GLTFLoader. For small files you might not notice much difference between the two.

My viewer doesn’t support Meshopt compression just yet.

Also, I’ve gzipped the glb file but I’m not able to correctly load it in three.js.

With gzip you usually don’t directly load the .glb.gz URL — you go ahead and request the .glb version, and then many (but not all) web servers are configured to automatically serve the .glb.gz version instead. The browser will automatically decompress the gzipped data for you, so nothing is done differently in GLTFLoader.