Hey,
I have lost houuuurs on this issue 
but finally I could find out it came from node naming issue
Following the documentation, a TransformNode should be given a string as name :
https://doc.babylonjs.com/typedoc/classes/BABYLON.TransformNode#constructor
Nevertheless, it will accept a number without any warning, and without conversion (originaly came from a Revit export unique ID on my sideā¦ 
)
In that case, the exported GLB will be broken playground repro here.
Eventhough, the sandbox is able to open it, Blender is not able to open it (crashes), and also the official khronos group glTF Validator claims itās broken.
Maybe forcing the TransformNode name to convert to string would be an issue (retrocompatibility) but at least I think it should be forced on GLB export
1 Like
I think this is ādelegatedā to TypeScript. There, it correctly complains:
This is basically true for all function parameters (and whatnot) if you decide to handle type checking via Typescritp rather than actual Javascript code. 
1 Like
Yeah I know that the type could be checked, but I think anyway the exporter should never export some broken file without any warningā¦ It should either convert to string, or skip these nodes with a warning 
1 Like
cc @alexchuber as we may want to add a check here
2 Likes
GG for finding that one !!!
This makes sense, but my first reaction was: āOh wowā¦ how many other fields are going to need this same treatment?ā 
Weāll probably uncover them as we go, but it might also be worth adding a broader schemaāvalidation pass using something like zod to catch all these issues. Iām not sure whether that would be overkill, nor if it should run by default.
Do you all have a preference? Manual checks vs. using zod? Fix the issue vs. warn? Optāin vs. default?
