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

Ton Roosendaal ton at blender.org
Thu Feb 11 14:38:37 CET 2016


Hi,

That's a very impressive claim. I will be happily awaiting reports from testers on this. 

I suggest to further close this thread and move to the code review for the technical feedback and testing.

-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 14:21, 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



More information about the Bf-committers mailing list