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

Keith Boshoff wahooney at gmail.com
Wed Feb 10 13:23:48 CET 2016


As much as using a proper, open interchange format would be fantastic, it's
just about useless if no other apps actually use the format.

I'm speaking from a Unity perspective and the chances of them including
other mesh formats in the near future are slim to none (Though I'm still
going to nag them about it). I'm pretty sure the same is true for Unreal,
Crytek, Lumberyard and definitely Stingray.

The other problem with open standards is that they are usually interpreted
as a free-for-all as far as features are concerned (see Collada), having
never looked at either of the proposed formats this may be a moot point,
but still something to consider moving forward..

In short having a stable, open standard for interchange would be the ideal,
but realistically FBX support is sadly still **very** important if any
interchange with current game engines is required.

Blender's current FBX implementation is actually very good (as far as Unity
is concerned). The only missing feature is not even directly related to the
FBX format, ie. the correct translation from +Z Up to +Y Up, and rotating
everything along the Up Axis 180 degrees (due to the fact that the Front
camera actually looks along the +Y axis which creates the tendency to model
and animate everything rotated 180 degrees along the Up axis, but that's
another conversation).


On Wed, Feb 10, 2016 at 6:26 AM, Campbell Barton <ideasman42 at gmail.com>

> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list