[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