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

Wed Feb 10 23:14:43 CET 2016

Gaia:

  Well, it was never merged. How about merging it and then we fix potential
problems later? I think what is missing in the above link is the time when
we talked on Irc, you approached me to ask if there was any improvement
there could be done to existing Collada exporter, as the plan was to fix it
instead of merging mine. Years later, Collada was not fixed, and mine was
not merged.

  If you believe that the exporter is the easy part, why has there been
more than 10 years and Blender is still unable to export Collada properly?
I wrote for you an exporter that has been tested in dozens of games and
that exports every meaningful part of the spec as best as possible. Either
two actions must happen:

1) Just make the built-in exporter work as well as mine
2) Merge mine and deprecate the built-in exporter.

  Otherwise please don't state that the exporter is the easy part. I also
offered my Collada importer code, which is written in a single .h/.cpp line
of code that reads pretty much every single thing you throw at it, and it
was refused.

  I can't maintain a full Collada subsystem in Blender, I'm already too
busy working on Godot. I´m offering extremely well tested and fully
compliant code for both importer and exporter, both extremely tiny
(compared to OpenCollada). You only have to help me out merge both into
Blender, and all this discussion about open formats is over. We can even
work in a more modern version of the Collada spec together (I'm an advisor
at Khronos) supporting more modern features such as PBR, Shader Graphs, etc.

  But seriously, just work a little from your end too instead of
complaining about Autodesk being evil..

On Wed, Feb 10, 2016 at 6:57 PM, Gaia Clary <gaia.clary at machinimatrix.org>
wrote:

> Have our attempts to improve the Collada module really been such a
> desaster?
> I try to not take the personally. Anyways, i tried to contact you for
> testing your
> exporter:
>
>      https://developer.blender.org/T41071
>
> It seems like you overlooked that.
>
> And just one more note about an import/export module:
> The challenge is not the exporter but the Importer.
> And i am almost sure this is true for FBX and for Collada equally.
>
> cheers,
> Gaia
>
> On 10.02.2016 21:41, Juan Linietsky 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
>