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

Thu Feb 11 14:21:24 CET 2016

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
>