Many validation errors occur in LittlestTokyo glTF Model


(Cx20) #1

I tried to display glTF file downloaded from sketchfab with glTF Viewer.

However, it seems that many validation errors occur.

It seems that there is probably a problem when Sketchfab performs automatic conversion to glTF file.


@waleguene ?

(Waleguene) #3

Hi @cx20

Thanks for the report. We are aware that there are still some errors/warnings with glTF exported file that need to be fixed, even if they should not cause any issue in external engines.
We will take a closer look and provide a fix for this, but the timeline is kind of blurry since we will also need to regenerate the archives.


(Donmccurdy) #4

Related thread here for numerical tolerance thresholds: I do think there is some chance that non-increasing animation inputs could cause issues for external engines, but if this doesn’t sound right please let us know. :slight_smile:

(Waleguene) #5

@donmccurdy I would also think that it could cause issues for external engines, depending on the assumptions made when the animation support has been implemented in the engine and I’m not sure it’s mentionned in glTF specification.

It could break an interpolator and it could be worse if there are two different values for the same time. This last case could be caused by a precision when exporting two keyframes very close to each other, which could be one of the cause for Sketchfab models raising the error during validation (along with duplicated keyframes due to old issues in our processing).
(my should not was more a “let’s hope it works” than a “don’t worry, no issue”).

Also, @nehon had issues when implementing animation support in JME.

Anyway, this is something that we need to adress since it’s unhealthy to carry such data, either for Sketchfab or anybody using glTF assets from the platform. We will need to spend time on this to find the root cause and provide fixes on each step (model processing and glTF export).
Also, the validator we are using is outdated and updating it will allow us to fix a bunch of issues like this one.

Thanks for following up!

(Donmccurdy) #7

One other issue I noticed on this skybox model —

The model is assigned both a KHR_materials_unlit extension and an emissive texture+color. When the unlit extension is present, only base color and vertex colors are applied — emissive is ignored, and the result (because there is no baseColorTexture on this model) is just a grey mesh. So when a shadeless model is the intention, the texture should be assigned as baseColor.