I have a few GLTF files that seem like valid files; they open in Blender, and they also all open with this web utility with no issues: https://gltf-viewer.donmccurdy.com/
This is a skinned mesh with bones and animation. If I convert the file in blender to FBX it will open fine in touchdesigner, but none of the GLTF or GLB versions will open. Does GLTF support skinning and rigged animated meshes? If not, maybe this belongs in an RFE, but if so, these files should work? Error message in TD build 2025.33070 doesn’t tell much.
I see that it’s failing the validation stage of the file against the glTF spec, specifically the check that all rotations are between [-1.0, 1.0]. On inspection of the raw json in the file I see that there is indeed a rotation value of [0.0,0.0,0.0,1.0000001192092896] for bone_111, exceeding the glTF limits because of what looks to be a floating point error.
Where did you export it from? Are you able to clamp the values on export?
The takeaway here is we should probably not abort import in all cases of validation failure, which is presumably the case for Blender. On top of that, I think we should be passing up the validation errors to the node, otherwise it’s difficult to know why it’s failing.
For now, you can use this online glTF viewer to more easily see what validation errors your file has.
I’ll also just add that we do support all base features of the glTF spec including rigged animated meshes, but there are nonetheless many glTF extensions that we do not support. The extensions we do support can be found on glTF In COMP wiki page.
Those meshes came from the ComfyUI Sam3D AI model. Yeah, unfortunate about the unclamped rotation matrix. I don’t really want to run that through another manual cleanup process, as I am working with automation processes that would try to rely on as little human intervention as possible.
Interestingly enough, even though it’s invalid, those Online GLTF viewers all do load the models + animations just fine… IMO this might be a case of warn over reject failure. I’d rather have some data in the model than nothing, users could always check info for warning and self reject if invalid.
Yeah, I think the correct course of action is for the glTF In COMP to continue import on validation failure and display any validation warnings/errors with the file. In more severe validation failure cases the import itself will probably fail anyway, but that’s obviously not the case here as it’s a pretty benign floating point error.