gltfpack reports invalid GLB, while gltf validator says glb is fine

[hypnosnhendricks]

I downloaded gltfpack today to test it out against some of the GLBs I'm generating.
However, gltfpack compains the GLB is invalid.
I tested the GLB using https://github.khronos.org/glTF-Validator/ & the GLB passes as valid.

Is there any way to get the validation error report from gltfpack so I can better understand what aspect of the GLB it doesn't like?

[zeux]

Can you attach the glb in question?

[hypnosnhendricks]

The source GLB that comes out of fbx2gltf though works with it and I'm seeing a savings of 50MB (original size) to 31MB (optimized), which is great! My pipeline takes the source GLBS and processes them into an intermediate GLB, which I wanted to test with GLTFPACK. So the source GLBs work ok, the processed GLBs are complained about as being invalid, but they work with babylon/gltf validation viewers.

Also, is there a way to get the quantization info? The report generated doesn't seem to contain any info about how the meshes were quantized.

[zeux]

This might indicate a bug in the processor - or a bug in cgltf/gltfpack. I would recommend trying the same process on glb files you can share I guess.

Right now report doesn’t contain quantization info; the quantization parameters are part of the command line input (see -h output for defaults), is that what you’re looking for?

[hypnosnhendricks]

Yeah. I didn't specify any quantization params, just -i -o -r. I thought the report would contain that information is all.
I'll download the source and run it through the debugger, see what the validation is complaining about.

[hypnosnhendricks]

tracked down the issue. in the GLB, there is a mesh with "targetNames": null, in the JSON. We use TinyGltf & it must be writing this out when we tag up our meshes with target Names. Some meshes have targets, some don't. But we always write out this extra. cgltf expects an array here & instead it is getting a primitive. Interesting that gltf-validation doesn't complain about the null value for targetNames.

[zeux]

targetNames isn't normative (that is, there's a convention for storing targetNames in JSON extras, but it's not part of the official specification) so this actually makes sense; maybe cgltf handling of this should admit null and treat this as 0 name array at least.

[zeux]

I've submitted a PR to fix parsing files with null targetNames: jkuhlmann/cgltf#130