[Bf-committers] The future of FBX and/or other formats in Blender

[Campbell Barton]

On Wed, Feb 10, 2016 at 3:42 AM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
> Hi,
>
> So, lately there's been a lot of FBX-related issues reported to our
> tracker. Most of those are either:
> - Known (half-)broken things (like cameras/lights orientation issues),
> over which I do not intend to spend more time, since those are not
> critical features to support imho.
> - Broken corner-cases in an area that globally works rather well
> (thinking about skeletons here).
> - Mysterious third-party applications-related issues (scaling, skeletons
> again, etc.), that is, bugs that show with one app but not another.
>
> I think later point is a good demonstration that FBX itself is a failure
> and a dead horse - if even rather big and serious companies like Unreal
> or Unity cannot get a reliable FBX importer working using official FBX
> SDK, then how are we supposed to do it without even that SDK?
>
> Further more:
> - In past two years a lot of time and energy was invested (lost) in FBX.
> - </rant> I’m just dead sick of that format, of hitting any possible
> table corner when trying to walk my way in that non-sensible pitch black
> box, etc. </rant>
> - Knowledge I gained of this format and its evolution is **not**
> encouraging at all (stupid things like supporting two different and
> complex transform systems [3DS max and Maya ones, btw ;) ], a very weird
> inconsistency at binary level, etc.). I do not have any feeling this is
> a sane format, nor that it is evolving in a sane direction. It seems to
> be defined a bit as needs arise, piling up new stuff over old ones, etc.
> To summarize: no clear design behind it, and a very dirty way of
> handling new versions of it.
>
> So I would claim to stop relying on and developing it. It would not mean
> we just remove it from Blender, but think it’s time to switch to
> something more modern and open - am aware of at least to possible
> alternatives, which could even be quite complementary.
>
> I) glTF
> Promoted by Khronos group (https://www.khronos.org/gltf), it aims at
> being the open exchange format for games (from simple asset to complete
> scene description).
> Think it’s still very new stuff, not much widely used yet, but it seems
> to have some support from several major companies (including Microsoft
> and even - rofl - Autodesk, see http://gltf.autodesk.io/).
>
> II) USD
> Promoted by Pixar (http://graphics.pixar.com/usd/), it aims at being
> some kind of generic pipeline format for CG studios (it also has
> integration of Alembic e.g.).
> I have no idea of its acceptance currently, but sounds like it could be
> a valuable option for our 2.8 'pipeline/inter-application exchange' goal?
>
> (as a side note, interesting to see that those two have a similar
> approach, they are not monolithic files but rather a combination of
> binary data and textual descriptions…)
>
> Anyway, those are very early reflections, would like to get your
> feelings about those two formats/projects (or others you may have in
> mind! ;) ), but I’m feeling much more enthusiast at the idea of spending
> time on modern, open-designed (or at least, open-specified) formats,
> than on piece of proprietary crap!
>
> Again, even if we end up deciding we stop trying to fully support FBX as
> our main exchange format, it would keep being supported in its current
> status at least for one or two years - just I would not try to add
> support for new versions (2016 one seems to have some incompatibilities
> with our code already), nor would try to understand and fix more stuff
> in that format.
>
> And that’s a long enough mail, thanks for reading it!
> Bastien

Think its fine to keep FBX maintained (similar to Collada),
and investigate supporting other formats.

Comments on more detailed points below.

----

One of the big problem If found when working on FBX is handling reports,
we get reports with complex files and are expected to spend time (can be hours),
to dig down into the root cause... it can involve having to install
other applications to redo the bug too.
... over time many bugs are fixed and new issues end up being strange
compatibility problems with no clear outcome (or the conclusion is the
other application had some quirk with its FBX support) -
not errors in the code that can be fixed once understood.

Rather then define FBX as a failed dead end, I think we could be more
strict with whats supported, and considered a bug,
to cut down on the time to investigate obscure errors.

For example:

- Export mesh data, basic object types, animation.
- Import mesh data, basic object types.
  (animation is experimental, with limited support).

- For application support we can pick a handful of popular 3d
applications and game engines known to have good FBX support.

Anything outside this we don't have to accept as a bug (or can
document as unsupported for example).
of course we don't prevent others from investigating and fixing issues
they find.

----

For users who want to keep good FBX support.

We could really use some help testing the current state of FBX:

Make a small test suite of blend files, demonstrating different
features, (armature animation, ik, custom normals, object animation).
Find out which applications load FBX's from these files correctly...
ask the community to test and document the results (similar steps for
FBX import).
Then we can make some effort to host these centrally maintain
compatibility list.

Early on with FBX development we did this with a simple animated character.
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Autodesk_FBX#Interoperability

However this list didn't have significant edits since ~2011, so not
sure its even valid anymore.

Of course developers can do some of the work here, just noting this is
an area others can help with.