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.
Par Winzell
Graham Wihlidal
Par Winzell
Michael Ranieri
Michael Ranieri
Michael Ranieri
Artem Titoulenko
Matt Brown
Darío Hereñú
PLAINCONCEPTS\davila