<div dir="ltr">I like Campbell's idea of focusing on good support of essential FBX features with certain versions of the format. By having a test set for those feats like described in his mail.<div><br></div><div>In the long run it would be great to get some open & specified format to use. Would it be possible for you to talk with Unreal Engine, Unity and other relevant game engine dev folks to check if they would be willing to work on that too? Do they already know e.g. glTF and do they think it would be feasible or not?</div><div><br></div><div>Also I wonder: is it completely out of the question to use an external converter? For example to export to glTF from Blender and then use an external glTF-to-FBX tool that can use Autodesk's SDK and thus not be quite as painful to dev .. Autodesk already made that FBX-to-glTF tool, perhaps support for the reverse dir could be added there too. I realize that the current solution is much more user friendly and works nicely e.g. for Unity's .blend support but still. There could still be an addon that makes using the external converter easy from Blender GUI .. it could even download & install the converter automatically.</div><div><br></div><div>~Toni</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 10, 2016 at 6:26 AM, Campbell Barton <span dir="ltr"><<a href="mailto:ideasman42@gmail.com" target="_blank">ideasman42@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Feb 10, 2016 at 3:42 AM, Bastien Montagne <<a href="mailto:montagne29@wanadoo.fr">montagne29@wanadoo.fr</a>> wrote:<br>
> Hi,<br>
><br>
> So, lately there's been a lot of FBX-related issues reported to our<br>
> tracker. Most of those are either:<br>
> - Known (half-)broken things (like cameras/lights orientation issues),<br>
> over which I do not intend to spend more time, since those are not<br>
> critical features to support imho.<br>
> - Broken corner-cases in an area that globally works rather well<br>
> (thinking about skeletons here).<br>
> - Mysterious third-party applications-related issues (scaling, skeletons<br>
> again, etc.), that is, bugs that show with one app but not another.<br>
><br>
> I think later point is a good demonstration that FBX itself is a failure<br>
> and a dead horse - if even rather big and serious companies like Unreal<br>
> or Unity cannot get a reliable FBX importer working using official FBX<br>
> SDK, then how are we supposed to do it without even that SDK?<br>
><br>
> Further more:<br>
> - In past two years a lot of time and energy was invested (lost) in FBX.<br>
> - </rant> I’m just dead sick of that format, of hitting any possible<br>
> table corner when trying to walk my way in that non-sensible pitch black<br>
> box, etc. </rant><br>
> - Knowledge I gained of this format and its evolution is **not**<br>
> encouraging at all (stupid things like supporting two different and<br>
> complex transform systems [3DS max and Maya ones, btw ;) ], a very weird<br>
> inconsistency at binary level, etc.). I do not have any feeling this is<br>
> a sane format, nor that it is evolving in a sane direction. It seems to<br>
> be defined a bit as needs arise, piling up new stuff over old ones, etc.<br>
> To summarize: no clear design behind it, and a very dirty way of<br>
> handling new versions of it.<br>
><br>
> So I would claim to stop relying on and developing it. It would not mean<br>
> we just remove it from Blender, but think it’s time to switch to<br>
> something more modern and open - am aware of at least to possible<br>
> alternatives, which could even be quite complementary.<br>
><br>
> I) glTF<br>
> Promoted by Khronos group (<a href="https://www.khronos.org/gltf" rel="noreferrer" target="_blank">https://www.khronos.org/gltf</a>), it aims at<br>
> being the open exchange format for games (from simple asset to complete<br>
> scene description).<br>
> Think it’s still very new stuff, not much widely used yet, but it seems<br>
> to have some support from several major companies (including Microsoft<br>
> and even - rofl - Autodesk, see <a href="http://gltf.autodesk.io/" rel="noreferrer" target="_blank">http://gltf.autodesk.io/</a>).<br>
><br>
> II) USD<br>
> Promoted by Pixar (<a href="http://graphics.pixar.com/usd/" rel="noreferrer" target="_blank">http://graphics.pixar.com/usd/</a>), it aims at being<br>
> some kind of generic pipeline format for CG studios (it also has<br>
> integration of Alembic e.g.).<br>
> I have no idea of its acceptance currently, but sounds like it could be<br>
> a valuable option for our 2.8 'pipeline/inter-application exchange' goal?<br>
><br>
> (as a side note, interesting to see that those two have a similar<br>
> approach, they are not monolithic files but rather a combination of<br>
> binary data and textual descriptions…)<br>
><br>
> Anyway, those are very early reflections, would like to get your<br>
> feelings about those two formats/projects (or others you may have in<br>
> mind! ;) ), but I’m feeling much more enthusiast at the idea of spending<br>
> time on modern, open-designed (or at least, open-specified) formats,<br>
> than on piece of proprietary crap!<br>
><br>
> Again, even if we end up deciding we stop trying to fully support FBX as<br>
> our main exchange format, it would keep being supported in its current<br>
> status at least for one or two years - just I would not try to add<br>
> support for new versions (2016 one seems to have some incompatibilities<br>
> with our code already), nor would try to understand and fix more stuff<br>
> in that format.<br>
><br>
> And that’s a long enough mail, thanks for reading it!<br>
> Bastien<br>
<br>
</div></div>Think its fine to keep FBX maintained (similar to Collada),<br>
and investigate supporting other formats.<br>
<br>
Comments on more detailed points below.<br>
<br>
----<br>
<br>
One of the big problem If found when working on FBX is handling reports,<br>
we get reports with complex files and are expected to spend time (can be hours),<br>
to dig down into the root cause... it can involve having to install<br>
other applications to redo the bug too.<br>
... over time many bugs are fixed and new issues end up being strange<br>
compatibility problems with no clear outcome (or the conclusion is the<br>
other application had some quirk with its FBX support) -<br>
not errors in the code that can be fixed once understood.<br>
<br>
Rather then define FBX as a failed dead end, I think we could be more<br>
strict with whats supported, and considered a bug,<br>
to cut down on the time to investigate obscure errors.<br>
<br>
For example:<br>
<br>
- Export mesh data, basic object types, animation.<br>
- Import mesh data, basic object types.<br>
(animation is experimental, with limited support).<br>
<br>
- For application support we can pick a handful of popular 3d<br>
applications and game engines known to have good FBX support.<br>
<br>
Anything outside this we don't have to accept as a bug (or can<br>
document as unsupported for example).<br>
of course we don't prevent others from investigating and fixing issues<br>
they find.<br>
<br>
----<br>
<br>
For users who want to keep good FBX support.<br>
<br>
We could really use some help testing the current state of FBX:<br>
<br>
Make a small test suite of blend files, demonstrating different<br>
features, (armature animation, ik, custom normals, object animation).<br>
Find out which applications load FBX's from these files correctly...<br>
ask the community to test and document the results (similar steps for<br>
FBX import).<br>
Then we can make some effort to host these centrally maintain<br>
compatibility list.<br>
<br>
Early on with FBX development we did this with a simple animated character.<br>
<a href="http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Autodesk_FBX#Interoperability" rel="noreferrer" target="_blank">http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Autodesk_FBX#Interoperability</a><br>
<br>
However this list didn't have significant edits since ~2011, so not<br>
sure its even valid anymore.<br>
<br>
Of course developers can do some of the work here, just noting this is<br>
an area others can help with.<br>
_______________________________________________<br>
Bf-committers mailing list<br>
<a href="mailto:Bf-committers@blender.org">Bf-committers@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-committers" rel="noreferrer" target="_blank">http://lists.blender.org/mailman/listinfo/bf-committers</a><br>
</blockquote></div><br></div>