This caused https://github.com/facebookincubator/FBX2glTF/issues/218
in ways that I honestly don't fully understand, and I believe only under
Windows, with Release-level optimisation turned on.
It's possible we should drop all these initializer lists, and replace
them with simple and explicit initialising constructors.
Fixes#218.
Merge code from @shrinktofit that allows control over where temporary files are created.
(Most commonly the .fbm directory where the SDK extracts embedded resources.)
The FBX SDK is compiled against a regular libiconv on Windows on Linux (with symbols libconv_open() etc) but on Mac, they compiled it against Apple's modified libiconv, which renames those functions. Annoyingly this means we need to explicitly decline the Conan libiconv package, for that platform only.
I've added the sdk directory to the docker ignore.
With the SDK ignored, we can install the SDK before
adding the project source. This allows the docker image
to preserve most of the layer caches when source code is
changed.
On a system with GCC 5.* Conan will conservatively choose 'libstdc++'
over 'libstdc++11' for compiler.libcxx, and then proceed to download
libraries compiled with the older ABI.
Meanwhile, though, our own CMake setup dictates the use of the modern
ABI, and the result is an application binary with ABI mismatches that
yield SIGSEGVs almost immediately.
Here, we guard against erronous invocations, and gently push the user
towards sending in the right explicit override for their system.
Lifted from comment in source:
Individual animations are often concatenated on the timeline, and the
only certain way to identify precisely what interval they occupy is to
depth-traverse the entire animation stack, and examine the actual keys.
There is a deprecated concept of an "animation take" which is meant to
provide precisely this time interval information, but the data is not
actually derived by the SDK from source-of-truth data structures, but
rather provided directly by the FBX exporter, and not sanity checked.
Some exporters calculate it correctly. Others do not. In any case, we
now ignore it completely.