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

Ton Roosendaal ton at blender.org
Thu Feb 11 13:13:16 CET 2016

Hi Juan,

I think we mix up different use cases.

- COLLADA was meant to be a cross platform 3d exchange format. Even Khronos recognizes that this goal has issues. COLLADA has design flaws, it is disputed, very hard to get to work.

- Many Blender developers have put time on getting COLLADA exchange to work. With Python, with OpenCollada, with own C++ code. We tried a lot, discussions go back to 2004 already. In days of work, it had similar (or more) attention as developers gave to FBX.

- You made a COLLADA exporter to work as native format for Godot. That is cool, COLLADA works fine that way.

What we tried is something else, it is 3D exchange: a format to work in a mixed tools pipeline. That means Maya to Blender and back. And that is what FBX currently offers to the industry. COLLADA could have offered it too, but after 12 years we better conclude it won't work for this.

Conclusion: Blender can just get multiple COLLADA exporters to "save as Godot" or "save as 2ndlife" or "save as Maya", for as much developers wish to support that.



Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands

> On 10 Feb, 2016, at 21:41, Juan Linietsky <reduzio at gmail.com> wrote:
> Guys I'm sorry. I've seen this situation happening over and over to no end
> for more than a decade.
> How about some self-criticism from Blender instead of blaming Autodesk?
> If you guys really had cared about open standards and getting along well
> with game engines, you would have done the following:
> 1) Make sure you export proper Collada. The specification is pretty clear.
> 2) Push game engines to fix their importers.
> Blender support for Collada has always been a disaster. There was never any
> will to fix it.
> -I originally insisted against using OpenCollada due to the huge binary
> bloat, and the fact the spec is pretty simple.  You guys wanted to go with
> it.
> -The exporter was huge and full of bugs. I insisted that a lot of features
> missing in the spec needed to be implemented, was ignored.
> -Meanwhile, all the missing Collada features were implemented in FBX, such
> as blend shapes, proper keyframe baking. constraint baking, exporting all
> actions, etc.
> -I wrote for you guys a proper Collada exporter in a few lines of Code that
> supported the full spec, you guys refused it to add it to mainline Blender.
> -I insisted, the answer was "Yeah we can put it at some development repo
> and if anyone cares about it we move it to mainline". Of course, everyone
> was using FBX , so who would care about Collada?
> Now you cry that FBX is evil and blame Unreal, Unity and Autodesk.
> Now you complain that there are not any open standards being pushed.
> You know what guys? cry me a river..
> On Wed, Feb 10, 2016 at 2:45 PM, Daniel Stokes <kupomail at gmail.com> wrote:
>> With regards to glTF exporting, we have a glTF exporter as part of the Real
>> Time Engine addon project [1]. The exporter[2] output passes validation[3]
>> for the glTF 1.0 (not sure if draft or final) specification. It is
>> currently missing animation support, and could have better support for
>> materials and textures. This weekend I will move this exporter out of the
>> project it is currently in and in to its own repo so it can more easily be
>> used for creating a simple glTF export addon.
>> [1] https://github.com/Kupoman/BlenderRealtimeEngineAddon/
>> [2]
>> https://github.com/Kupoman/BlenderRealtimeEngineAddon/blob/develop/brte/converters/blendergltf.py
>> [3]
>> https://github.com/KhronosGroup/glTF/tree/1.0-final/specification/schema
>> Regards,
>> Daniel Stokes
>> On Wed, Feb 10, 2016 at 8:20 AM, Fabio Pesari <fabio at pesari.eu> wrote:
>>> On 02/10/2016 04:44 PM, Ton Roosendaal wrote:
>>>> A crowd-funder for 1 feature only is very risky. What precisely do we
>>> define to fund? Who would crowdfund a developer to just fix bugs and
>>> maintenance for 2 years? I doubt people would pay for that. I wouldn't
>> even
>>> know where to find such a coder...
>>>> For 2.8 we can do a big fund raiser, and include this on the work
>>> planning. I think professionals rather see us to keep working on the
>> whole
>>> pipeline, starting with good PBR shader editing in viewports.
>>> Why don't you do a fundraiser organized like this:
>>> Feature X   [---]
>>> Feature Y   [---------]
>>> Feature Z   [------]
>>> Maintenance [-----]
>>> Marketing   [--]
>>> =========================================
>>> Total       [---------------------------]
>>> When people donate, they can choose where to put their money and if they
>>> don't, it goes to "Maintenance" by default, so most donors will fund
>>> that. Also, any excess money from the implementation of other features
>>> also goes to "Maintenance".
>>> It'd be even better if there were set goals for each feature (for
>>> example, $40k for Feature X, and of course no limit on "Maintenance"),
>>> so people would know how much they have to donate in order to make sure
>>> the feature they need is implemented (with a disclaimer, of course).
>>> I think a lot more people are willing to donate if they know exactly
>>> where their money is going.
>>> I think generic fundraisers often fail because there aren't set
>>> objectives. The FSF recently managed to reach their goal because they
>>> set a reasonable one ($450k), and they aren't nearly as popular as
>>> Blender (you could say the industry hates them).
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> 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