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.
This adds the first FBX PBR import path. Materials that have been
exported via the Stingray PBS preset should be picked up as native
metallic/roughness, and exported essentially 1:1 to the glTF output.
In more detail, this commit:
- (Re)introduces the STB header libraries as a dependency. We currently
use it for reading and writing images. In time we may need a more
dedicated PNG compression library.
- Generalizes FbxMaterialAccess to return different subclasses of
FbxMaterialInfo; currently FbxRoughMetMaterialInfo and
FbxTraditionalMaterialInfo.
- FbxTraditionalMaterialInfo is populated from the canonical
FbxSurfaceMaterial classes.
- FbxRoughMetMaterialInfo is currently populated through the Stingray
PBS set of properties, further documented in the code.
- RawMaterial was in turn generalized to feature a pluggable,
type-specific RawMatProps struct; current implementations are,
unsurprisingly, RawTraditionalMatProps and RawMetRoughMatProps. These
are basically just lists of per-surface constants, e.g. diffuseFactor or
roughness.
- In the third phase, glTF generation, the bulk of the changes are
concerned with creating packed textures of the type needed by e.g. the
metallic-roughness struct, where one colour channel holds roughness and
the other metallic. This is done with a somewhat pluggable "map source
pixels to destination pixel" mechanism. More work will likely be needed
here in the future to accomodate more demanding mappings.
There's also a lot of code to convert from one representation to
another. The most useful, but also the least well-supported conversion,
is from old workflow (diffuse, specular, shininess) to
metallic/roughness. Going from PBR spec/gloss to PBR met/rough is hard
enough, but we go one step sillier and treat shininess as if it were
glossiness, which it certainly isn't. More work is needed here! But it's
still a fun proof of concept of sorts, and perhaps for some people it's
useful to just get *something* into the PBR world.
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.
Par Winzell
Par Winzell