Autogenerated glTFs contain many errors

We’re leveraging using glTF files from sketchfab, but so far, the experience is not good.

We’re encountering that many glTF files autoconverted by Sketchfab contain errors.

For example, we’ve found that many animations contain invalid time keys (typically, where two keys with the same time value are created on a given curve)

And also lots of errors with accessors.

We’re using a strict glTF validation preprocessing step to ensure the model is good down our processing pipeline, and so far, we have not been able to use roughly 50% of the models downloaded from sketchfab.

Please, make sure you generate correct glTF files, by validating them against the official glTF validator.

Do you have a link to an example of a model that produces a particularly bad gITF file?
I’m sure it will be helpful to @james or whoever else in the team looks into this.

Sure, here’s a list of models I’ve just checked:

All these files throw errors in glTF validator, and it’s been from a fast sampling of models from sketchfab… but if I keep going, I could easily find a lot more.

1 Like

Hi, and thanks for reporting those issues :+1:

We are currently working on those problems and should incorporate them in our processing pipeline soon, but as you have pointed out there are indeed some models which don’t pass the validation phase, for multiple kind of reasons.

Although the animations (DUPLICATE_CHANNELS and NON_INCREASING errors) can indeed be problematic in a pipeline (but will be fixed soon), most of the ACCESSOR_NON_UNIT validation errors appear in buffers associated with tangents, and often on degenerate geometries (which are not necessarily cleaned in every file).
As your pipeline is automated, you can therefore safely override the severity level of those in a config.yml file, as explained here for now, or recompute the primitives’ tangent spaces on your own if needed to pass the validation test.

Some, if not most, of the “INVALID_FLOAT” error messages are also due to bad tangents linked to the previous error, and should therefore be treated accordingly if the “accessor_non_unit” error is detected.

Two points I’d like to emphasize:

  • Although the models uploaded after those changes should in theory comply with a “strict” glTF validator, we can not guarantee that oldest ones will be reprocessed soon, and some of them might still fail some of the validation steps as we have not always been 100% strict with the glTF validation (mostly due to the diversity of files and software that we support).
  • If you encounter some recurrent glTF errors other than the ones mentioned above and that you think are truly corrupting the glTF, do not hesitate to share them with us as you just did in this thread (error with some of the models impacted). Such feedbacks are of course welcome, and can help us detect some behaviors we would have otherwise missed !

Thanks again for the report :slight_smile: !

1 Like

It’s great to know that some of these issues are in the process of being fixed.

But I believe you should also remove degenerated triangles and fix unit lengths for normals and tangents; The point of glTF is that exporters should do a best effort to export glTF files that can be “trusted”, so thin clients that cannot afford running a full validation check can simply load the models and run them down the pipeline.

We’re still running validation checks because we’re still at a point in which glTFs from many sources cannot be trusted.

My suggestion to normals and tangents is: first, remove degenerated geometry, and if after processing normals and tangents you still get an invalid floating point value, replace it by a (0,0,1) to ensure the validation passes.