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.
With this, we are able to get rid of all the increasingly broken file
system utility code, and trust boost::filesystem to handle all the
cross-platform complexity.
The first version of this PR centred around C++17 & std::filesystem,
but support remains too elusive; it seems works out of the box in
Visual Studio (especially 2019), but is entirely missing from the Mac
dclang, and even with GCC 8.0 it requires an explicit '-l c++fs'.
Luckily the std:: version is almost exactly the boost:: version (not
surprising) so when the world's caught up, we can ditch Boost and go
all stdlib.
Setting up Conan requires a bit of work; we'll want to document the
details in the README.
Alright, less haphazardly now after the two previous botched commits,
this fixes mistakes and bugs made a year or more in the past:
- We now always pass the metallic and roughness factors through all
the way to the glTF layer. They should not be multiplied into the
generated textures, and so they should be present as-is in glTF
output.
- We only generate the AO/Rough/Net combined texture if at least two
of the constituent textures are present.
- We only reference the generated texture as an occlusionTexture if
there really was an occlusion map present (and it had non-trivial
pixels).
It's also now ridiculously clear that:
- The material conversion section is long and tortured and it's very
easy to screw up. It should be broken into functions and classes.
- We urgely need a real regression suite, and we need to model some
artificial FBX files that test both realistic scenarios and edge-
case permutations.
At the end of the various material/mesh transformations we do, we were still using a ridiculously simplistic method of mapping RawMaterial to glTF MaterialData.
This switches to using FBX's GetUniqueID(), which should be the law of the land in general. Other model entities may need further investigation as well.
This moves ./npm to ./npm/fbx2gltf, and introduces a Mocha / TypeScript based testing harness.
We're also adding a GIT LFS dependency, but only for people who want to run tests. We're using LFS to store the many FBX models we want to convert to GLB as part of the integration test suite.
There's still work to be done here, mainly:
- Convert BUMP to NORMAL
- Apply "roughness inversion" to roughness map
But it now informs the user of unsupported properties their model uses,
and generally works correctly!
We don't want to use the logical texture name from the FBX to distinguish separate textures. It seems entirely valid for distinct textures to have the same name. It's not completely clear what's best to use instead, but adding fileLocation seems reasonable. It can be blank, for textures that don't exist on the filesystem –– but that's a pretty weird edge case, and even then we have both 'usage' and 'name' to distinguish.
Looks like I never did the required cleanup after my accidental commit back in August.
This deletes the materials classes that were obsoleted back then, and comments out the
large swathes of PhysicalMaterial code that's not currently doing anything (i.e. all the
materials properties that glTF can't currently represent.)
We want to move to auto-formatting all our code, and it just seemed impossible
to make cxxopts usage tidy under clang-format's dominion. While trying to work
out its quirks, I realised that CLI11 did everything I wanted much better, and
so we've switched.
We're also going to chuck the usage of ExternalProject_Add(), at least for the
simplest use cases such as single-header include files. We'll just commit them
directly; that's kind of the whole point.
The one discipline we'll maintain is that commits that involve third_party/
should be as self-contained as possible (without breaking the app).
Par Winzell
Par Winzell
Simon
hhalen
Michael Tostenson
abbaswasim