Lean on the excellent pre-existing support for creating multiple glTF
meshes from a single FBX mesh based on material type. All the triangles
with (at least one) non-opaque vertex get flagged as transparent
material. They will all go separately in their own mesh after the
CreateMaterialModels() gauntlet.
Fixes#25.
Everything's in place to drop the progressive morph calculations into
readAnimations(). Shouldn't be hard.
Normals are proving trickier. I'm not convinced they make it into the
FBX at all. The SDK reports the existence of normals in the primary
layer, but they seems to consist exclusively of zeroes.
We may have to compute them.
- This does not support progressive morphs. Still evaluating whether
that's required functionality. It's really just a little bit of more
work. An example implementation is available in the SDK samples.
- We're blithely ignoring NORMALs and TANGENTs. This almost certainly
has to change.
We were warnings against eInheritRSrs, which is actually the one type of
ineritance we're good with. It's eInheritRrSs we should freak out about.
That said, no need to do it for the root node -- at that point there is
no global transform to worry about.
Some FBX files have index arrays that contain -1 (indeed, that are
nothing but negative ones). Presumably the intention is to specify "no
material". In any case, let's not segfault.
* Further improvemens to texture resolution.
- Move towards std::string over char * and FbxString where convenient,
- Make a clear distinction between textures whose image files have been
located and those who haven't; warn early in the latter case.
- Extend RawTexture so we always know logical name in FBX, original file
name in FBX, and inferred location in local filesystem.
- In non-binary mode, simply output the inferred local file basename as
the URI; this will be the correct relative path as long as the texture
files are located next to the .gltf and .bin files.
Primary remaining urge for a follow-up PR:
- We should be copying texture image files into the .gltf output folder,
but before that we should switch to an off-the-shelf cross-platform
file manipulation library like https://github.com/cginternals/cppfs.
When we make that transition, all this texture resolution code will
undergo another refactoring.
- alphaMode is only BLEND for transparent materials.
- We use RawMaterial.type to figure out what's transparent.
- FBX TransparencyFactor is not opacity, but 1.0-opacity.
- Treat vertex coloured materials as transparent
- We should at least iterate over vertices here and see if any of them
actually are transparent
- Sort triangles properly: transparent ones render last!
- Nix GetFileFolder(). It was not helping. Always search for textures
- near the FBX file.
- Use RawTexture::name for the texture name and ::fileName for the
inferred local filename path.
Digging the property values and texture shadows thereof, associated with
a certain FbxSurfaceTexture, should clearly happen once per material,
not per polygon. Furthermore there is a pre-existing pattern of
Fbx-specific accessclasses in Fbx2Raw that we should follow.
Soon we'll be extracting more than Phong/Lambert properties here, and
then we'll need to do further refactoring.
Par Winzell
Pär Winzell