Clarify texture filesystem lookup

[zellski]

• Improve and validate the tricks we already use to match a texture file as listed in the FBX with what exists in the local filesystem.
• If inferring the local file fails, warn explicitly and don't try to read anything later on.
• Extend RawTexture with another field; it should have name (logical texture name), fbxFilename (the original filename, usually an absolute path on the model author's machine), and localFilename, a path that's guaranteed to exist on the local file system.
• In non-binary mode, we bizarrely just add '.ktx' to the texture name, which is certainly guaranteed to be forever wrong. As @robertlong says in the comments, we should copy source files into the output directory and reference them by basename, i.e. as relative path.

[robertlong]

@zellski are you currently working on this? I'd be interested in contributing to this as it would allow us to export valid .gltf files with external images. The AFrame community is in need of a better way of exporting from Maya and this project is fairly close.

[zellski]

@robertlong I'm planning on doing some cleanup here for sure, sooner rather than later. Can you clarify what exactly you want to do? By external images do you mean, "not literally embedded in the FBX" or do you mean URIs, for something like WebGL deployment?

We have no way of mapping filenames to URIs right now, although that'd be interesting. You could imagine something like FBX2glTF --resource-prefix https://foo.com/assets/textures/

If it's just a bunch of texture files and they're referenced in the FBX, chances are it already works. The current strategy is to take the basename of each texture's filename, and then look for a file with that same basename in the directory where the FBX file is. Thus if the FBX references C:\Work\Birds\Sparrow_diffuse.png, you're doing the conversion on a Mac, and you put a Sparrow_diffuse.png next to the FBX, which can exist anywhere in the filesystem, that should already work right. (In fact, it should match even if you change the suffix to a .jpg).

We handle textures very poorly in non-binary mode at the moment. That's part of what I want to fix.

[robertlong]

The non-binary support would be nice. Currently it just outputs a uri with textureName.ktx. Instead what is needed is copying the image file into the output directory and setting the proper uri. That would enable .gltf export that references images via uri.

[zellski]

Oh, yes -- that .ktx line is a bizarre holdover from a very early version. I think we agree that leaning on relative paths by simply outputting the basename of the texture's FBX-internal filename should do what you're looking for. We could possibly copy the texture files too.

I'll take a pass at the cleanup in the next day or two, then we can see where we're at; if there is further work you'd like to see at that point, contributions are more than welcome!

[robertlong]

That would be great, thanks!

[zellski]

@robertlong Take a look at #16 and see what you think.