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.)
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.
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).
This is a recreation of the PR @robertlong submitted long ago here:
https://github.com/facebookincubator/FBX2glTF/pull/97
Refactors and whitespace conflicts made this easier.
There is still a substantial rewrite of the texture-loading and
file-path handling pending, for sometime soon.
Depending on platform, multiple versions of isnan() can easily be floating around, causing compilation headaches. Luckily we can always rely on the standard library implementation.
This finishes the first phase of the FBX2glTF refactor, breaking utility classes out where things were getting too monolithic.
There is an equally important cleanup phase coming where we wrench all the various parts of this code, including the historical ones that we've rarely touched as yet, into a single C++ style paradigm, and modernise everything to C++11 at least.
But for now, we're just picking the pieces back on the floor so we can push 0.9.6 out. It's been far too long since a release.
Did not mean to commit/push the current state of master. But rather than
mess up source control history with a force push, I'll just try to hurry
to a stable point.
Hopefully without unintentional changes to functionality. This renames header
files to .hpp, imposes a gltf/raw/fbx directory structure, extracts standalone
chunks of Fbx2Raw into distinct files, and undoes some particularly egregious
mistakes from when I knew even less C++ than I do now.
This is in anticipation of implementing 3ds Max's "Physical Material".
The condense operation recreates the vectors of surfaces, materials,
textures and vertices so as to exclude anything that isn't referenced
explicitly by a triangle. In the process, we must take care that
references from other properties are cleared out.
This fixes the case when a node references a mesh by id, and then the
mesh is deleted because no triangle references. TODO: go through other
properties and make sure the same problem doesn't exist there.
It is also possible that these vectors should be replaced by maps, at
least for the elements that (now) have unique IDs.
A mesh with a single (skinning) deformer which had zero clusters would
erroneously register as skinned, leading GetRoodNode() to an assertion
failure. Fixed.
We're still gunshy from our previous attempts at coming up with metalilc
and roughness values from diffuse/specular/shininess, but this should be
safe: a high shininess means a low roughness, and vice versa.
The FBX SDK looks for our textures and often finds them. It helpfully
tells us exactly where they are. Let's not throw that information away
and demand that the textures only exist in precisely the folders we are
aware of.
Because we make a best-effort attempt to convert materials on the old
form -- like :ambert and Phong -- to PBR materials, it can be beneficial
to the consumer of the asset to know if the asset was intentionally
authored as PBR, or if it was a conversion.
The precise details of this information is specific to the intersection
of FBX and glTF, so we're not going to bother proposing extensions; we
just drop something into the extras field, e.g.
"materials": [
{
"name": "Troll_Water",
"alphaMode": "OPAQUE",
"extras": {
"fromFBX": {
"shadingModel": "Metallic/Roughness",
"isTruePBR": true
}
},
// ... and so on.
The possible values for shadingModel are:
"<unknown>"
"Constant"
"Lambert"
"Blinn"
"Phong"
"Metallic/Roughness"
Currently isTruePBR is true for the final entry, false for the other.
However, we may well add more PBR shading models in the future, so if
you intend to use this feature to look for true PBR, use the derived
property.
Now that we're writing both 16-bit and 32-bit integers, it's starting to
matter a little more how we slam even scalars into memory. This is maybe
not the fastest way to accomplish this, and I'm not crazy about the way
GLType works in general, but it does have the virtues of clarity and
expediency.
By oversight we had not included occlusionTexture in the core
MaterialData. While we're at it, bake occlusion into the red channel of
the merged metallic/roughness texture.
There seem to be few constraints on what values FBX properties can take. By contrast, glTF constrains e.g. common material factors to lie in [0, 1]. We take a simple approach and just clamp.
Previous to this, a PNG that was on RGBA format would cause its
corresponding texture to be flagged as transparent. This is very
silly. We now iterate over the bytes, and if any is not 255, THEN
there's alpha.
This was way overdue. Breaking up large meshes into many 65535-vertex
primitives can save a few bytes, but it's really a lot of complication
for minor benefit.
With this change the user can force short or long indices, and the
default is to use shorts for smaller meshes and longs for longer.
- KHR_materials_common never had a real life in the glTF 2.0 world. One
day we may see a new extension for Phong/Blinn/Lambert.
- PBR_specular_glossiness is a poor fit for PBS StingRay (the only real
source of PBR we have) and has no advantage over PBR_metallic_roughness.
- The conversion we were doing for traditional materials to PBR made no
sense. Revert to a very simple formula: diffuse -> baseColor, simple
reasonable constants for metallic & roughness.
The user can now ask for normals to be computed NEVER (can easily cause
broken glTF if the source isn't perfect), MISSING (when the mesh simply
lacks normals), BROKEN (only emptuy normals are replaced), or
ALWAYS (perhaps if the normals in the source are junk).
I stole expressions from Gary Hsu's PBR conversion routines here:
3606e79717/extensions/Khronos/KHR_materials_pbrSpecularGlossiness/examples/convert-between-workflows/js/three.pbrUtilities.js
which is experimental enough as it is, but I had gone further into the
domain of madness and uses this with *old* diffuse/specular values, not
PBR specular/glossness.
As a result a lot of old content was coming up with 100% metal values
quite often, which in turn means completely ignoring diffuse when
assembling a new base colour...
I should rip out this whole conversion. But not just now...
It's technically valid for e.g. scale to have a zero dimension, which in
turn wreaks havoc on the rotation quaternion we get from the FBX SDK.
The simplest solution is to just leave any T/R/S vector out of the glTF
if it has any NaN component.
K. S. Ernest (iFire) Lee
Henrik Halen
Jordy van Dortmont
vfxgordon
Pär Winzell
Jesse Vander Does
Leslie Leigh
“Brandon
Par Winzell
Simon
hhalen
Michael Tostenson
abbaswasim
Graham Wihlidal
Michael Ranieri
Michael Ranieri
Michael Ranieri
Artem Titoulenko
Matt Brown
PLAINCONCEPTS\davila
Josh Faust
Robert Long