We are at liberty to order our JSON any way we like (by spec) and we can
improve readability a lot by doing so. By default, this JSON library
uses an unordered map for objects, but it's relatively easy to switch in
a FiFo map that keeps track of the insertion order.
The FBX SDK absolutely claims that there is a normal layer to each
FbxShape, with non-trivial data, even when the corresponding FBX file,
upon visual inspection, explicitly contains nothing but zeroes. The only
conclusion I can draw is that the SDK is computing normals from
geometry, without being asked to, which seems kind of sketchy.
These computed normals are often not at all what the artist wanted, they
take up a lot of space -- often pointlessly, since if they're computed,
we could just as well compute them on the client -- and at least in the
case of three.js their inclusion uses up many of the precious 8 morph
target slots in the shader.
So, they are now opt-in, at least until we can solve the mystery of just
what goes on under the hood in the SDK.
When we've successfully located a referenced texture image on the local
filesystem and we're generating non-binary, non-embedded output, copy
the source folder wholesale into the destination directory.
This means the output folder is always a full, free-standing deployment,
one that can be dragged into e.g. https://gltf-viewer.donmccurdy.com/
Robert Long
Par Winzell
Pär Winzell