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

Ton Roosendaal ton at blender.org
Fri Feb 12 10:51:29 CET 2016 

Hi William,

Your message arrived loud and clear! 
Of course we stick to keeping FBX IO to work, the discussion is mostly about:

- How to keep it maintained well, should we limit the scope a bit (design issue)
- Who could be found to work on it (we have a dev fund to support that)

What you (and other FBX users) can do to help is to join forces and create a reference test suite of files you want to keep working (import of fbx in Blender, export to fbx from Blender).

Not a wishlist, but a maintenance list! Files that work already (and documented how), which we can use to test before releases and after code changes.

-Ton-

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



> On 11 Feb, 2016, at 15:29, William Culver <wculver at cedeon.co.uk> wrote:
> 
> I love you guys.  I've spent 8 years invested in Blender with my company.
> I fight so hard as an advocate, all interns come to me with Maya/Max
> training and I make them learn Blender.  I'm constantly on job sites and
> 99% of the time there I'm the only employer in the whole of the UK looking
> for people with blender skills.
> 
> Point being, us Blenderers are massive outsiders in the industry already..
> and despite all the technological agreement, and sound argument from
> Bastien RE the FBX issue, I'm really dismayed with Blender right now.
> 
> I feel like Autodesk is laughing at you guys giving up with FBX... You're
> playing right into their hands and have just given them another small
> victory by validating all of their efforts to make the spec hard to access
> in the first place.  Please blender devs, I know FBX sucks and i know we
> should be pushing for better and more open file formats but *please *don't
> alienate us further by having bit rot take away FBX.  Its too soon to stop
> dev when there's little momentum for industry change and so much weight
> behind FBX.  I know you are going to argue that stopping dev on FBX *is*
> the momentum for change but come on guys we are tiny compared to Autodesk..
> FBX is a juggernaut and every single one of the MANY wanna-be game devs is
> going to spend 5 minutes with blender and then hop straight over to Maya LT
> unless FBX continues to work.  You're going to indirectly make Autodesk
> MORE money with this decision and i can't think anything worse than that.
> IMHO.
> 
> I know the format sucks and we have to reverse it to the point it could
> break tomorrow anyway.  I think you greatly underestimate its necessity.. I
> can point straight to more than 5 teenagers I know that downloaded blender
> to make a game asset for UE4 and that's just my first hand knowledge.   I
> think FBX export is one of the earliest things one does when dabbling in
> blender and first impressions count.
> 
> Of course no one can blame Bastien for having enough and I thank you for
> your hard work to date.  Please *please *put *some* continued resources
> into FBX though Ton, we desperately need something equivalent in its place
> before the bit rot starts to take hold.
> 
> TL;DR.. I agree with this at a development/technical level... on a
> political level you guys have scared the bajeezus out of me.
> 
> 
> Thanks Blender, you're the best.
> 
> Regards,
> 
> William Culver
> 
> 
> 
> 
> On Thu, Feb 11, 2016 at 1:21 PM, Juan Linietsky <reduzio at gmail.com> wrote:
> 
>> Ton,
>> 
>> Here's some facts you are missing:
>> 
>> -My Collada exporter works with Unity, Cryengine and imports correctly in
>> Maya/Max too via OpenCollada plugin.
>> -My Collada importer opens perfectly any scenes exported from Maya and Max
>> (Using OpenCollada plugin), XSI and Lightwave. Of course it also opens
>> scenes from my Collada exporter.
>> 
>> You are free to test this yourself.
>> 
>> The reason this failed consistently in Blender is because you guys didn't
>> care about having experienced developers spend time making it work.
>> Had Campbell Barton worked on it as he did on FBX, Collada would work
>> wonderfully. I just used his same approach to make my Collada exporter,
>> using OpenCollada library was a huge mistake.
>> 
>>  Still, I understand your concern and it is true that Collada was
>> originally devised as an exchange format. But if you read the specification
>> you will realize that, with each version,  it quickly migrated to a format
>> used to export assets for game engines. As an exchange format between 3D
>> DCCs it's severely limited.
>> 
>>  So my proposal is the following:
>> 
>> -Deprecate current Collada export support in Blender and replace it for
>> mine. Change the focus so it works well with game engines as a priority.
>> Having an alternative to FBX for this is a lot more important, both for
>> commercial game engines and (most vitally) for OSS game engines.
>>  If the focus is for DCC exchange, we know it will never work properly for
>> any use case and it sucks as a format for that anyway.
>> 
>> -Deprecate current Collada import suppot in Blender and work together with
>> me to implement my library, which has extremely high compatibility.
>> 
>> -Find a more useful long-term solution for asset exchange between Blender
>> and other 3D DCCs. I don't think even FBX is up to this task. If it was up
>> to me to decide, I think the best solution would be to implement a
>> dedicated .blend importer/exporter plugin for Maya, and make sure every
>> single use case works. From there, you can go to any other Autodesk
>> software using Maya Import/Export.
>> 
>> What do you think?
>> 
>> 
>> 
>> On Thu, Feb 11, 2016 at 9:13 AM, Ton Roosendaal <ton at blender.org> wrote:
>> 
>>> 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.
>>> 
>>> Laters,
>>> 
>>> -Ton-
>>> 
>>> --------------------------------------------------------
>>> 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
>>> 
>>> _______________________________________________
>>> 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