Re: [Bf-committers] Next dev meeting in about 13h from now

[Francesco Siddi]

Hi Piotr,
no config options available at the moment. Sources are available here 
https://github.com/armadillica/blender-coders in case anyone would like to 
propose tweaks or fixes.

Francesco

On 9 February 2016 at 19:13:10, Piotr Arlukowicz (pio...@polskikursblendera.pl) 
wrote:

Works like a charm. Any configuration options? A l11n maybe?

here it is: http://polskikursblendera.pl/
Thank you!

pio

​Piotr
​ Arlukowicz, BFCT​

​*YT: /user/piotao?feature=guide*
*FB:* */polskikursblendera* *TW:*
*/piotao*
*Blender Network:* *https://www.blendernetwork.org/piotr-arlukowicz
*
*Polski Kurs Blendera:* http://polskikursblendera.pl




2016-02-09 12:22 GMT-05:00 Francesco Siddi :

> Hi,
> the website is back online and should be working fine
> https://blendercoders.xyz/
>
> Regards,
> Francesco
>
> On 26 January 2016 at 18:02:41, Aaron Carlisle (carlisle.aaro...@gmail.com)
> wrote:
>
> Correct I mentioned it to Francesco and he took the website down until he
> fixed it.
>
> On Tue, Jan 26, 2016 at 11:57 AM, Mike Erwin 
> wrote:
>
> > Thanks, Aaron! But that clock says the meeting is 6 PM 27th Jan Wednesday
> > when it's actually 6pm today the 26th. (EST time zone). Unless I'm crazy,
> > which I could possibly be.
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> >
> > On Tue, Jan 26, 2016 at 10:56 AM, Aaron Carlisle <
> > carlisle.aaro...@gmail.com
> > > wrote:
> >
> > > The easiest way to see what time the meeting,
> > > is by going to https://blendercoders.xyz/
> > >
> > > On Tue, Jan 26, 2016 at 4:44 AM, Ton Roosendaal 
> wrote:
> > >
> > > > Hi all,
> > > >
> > > > Check your clocks! In roughly 13 hours it is 10 AM in Sydney, and
> 27th
> > of
> > > > January.
> > > > That means afternoon for the Americans on the 26th of January.
> > > >
> > > > Just ask google (if logged in) "What time is 10 AM Sydney here"
> > > >
> > > > Thanks,
> > > >
> > > > -Ton-
> > > >
> > > > 
> > > > Ton Roosendaal - t...@blender.org - www.blender.org
> > > > Chairman Blender Foundation - Producer Blender Institute
> > > > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands
> > > >
> > > >
> > > >
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Multiple .desktop files for different modes

[Fabio Pesari]

On 02/08/2016 03:48 PM, Todor Imreorov wrote:
> Then its very easy to make a bunch of desktop entries for the installer. It
> would however add the task to create an icon for each layout

How about using the Blender icon and a smaller icon released under a
free license on the bottom right? For example, a "play" button for
"Video Editing", a joystick for "Game Logic", etc.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Multiple .desktop files for different modes

[Todor Imreorov]

These layout presets are just a click away anyways. I would be ok if
blender had numerous icons in the start menu - kind of like an office suit,
but it might be a bit annoying to have many launchers in its build zip.
On 10 Feb 2016 09:40, "Fabio Pesari"  wrote:

> On 02/08/2016 03:48 PM, Todor Imreorov wrote:
> > Then its very easy to make a bunch of desktop entries for the installer.
> It
> > would however add the task to create an icon for each layout
>
> How about using the Blender icon and a smaller icon released under a
> free license on the bottom right? For example, a "play" button for
> "Video Editing", a joystick for "Game Logic", etc.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Multiple .desktop files for different modes

[Fabio Pesari]

On 02/10/2016 11:52 AM, Todor Imreorov wrote:
> These layout presets are just a click away anyways. I would be ok if
> blender had numerous icons in the start menu - kind of like an office suit,
> but it might be a bit annoying to have many launchers in its build zip.

I was thinking more about Freedesktop categories.

On lxpanel on my system (Parabola GNU/Linux), right now Blender shows up
under "Graphics", while Kdenlive is under "Sound & Video". Blender also
belongs to the same category as Kdenlive, so it's inaccurate (and
unfair) to put it only under "Graphics", but at the same time using the
normal Blender icon and description would be misleading, so a separate
.desktop file would be a cleaner solution. Likewise, Blender could also
belong in the "Programming" category when launched in "Game Logic" mode.

For these reasons, the current .desktop file:

https://git.blender.org/gitweb/gitweb.cgi/blender.git/blob_plain/HEAD:/release/freedesktop/blender.desktop

has the right "Keywords", but the "Categories":

> Categories=Graphics;3DGraphics;

are not as accurate as they could be, in my opinion.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Built-in support for free formats (OpenGEX and glTF)

[Fabio Pesari]

After reading the thread about FBX, I realized that since Blender is
free software, it would be good if it encouraged using free formats
instead of proprietary ones like FBX, which are always going to require
time-consuming reverse engineering efforts.

I know at least two engine-independent formats which have fully
available specifications: glTF ([0]) and OpenGEX ([1]).

I think both were designed to fix the various issues COLLADA had; glTF
is JSON-based and OpenGEX uses its own typed free format called
"OpenDDL" (example at [2]).

OpenGEX already has a Blender exporter which is licensed under the CC
BY-SA 3.0 ([3]), while I couldn't find anything Blender-related for glTF
(but being JSON-based, writing a Python plugin for it should be trivial).

I think including built-in support for them in Blender would be a good
way to encourage users to adopt something else than both proprietary
formats and free (but crappy) COLLADA, and for the Blenders devs to have
less headaches (since they would just have to follow the specs rather
than reverse-engineer obscure formats).

[0]:
https://github.com/KhronosGroup/glTF/blob/master/specification/README.md
[1]: http://opengex.org/OpenGEX.1.1.2.pdf
[2]: https://en.wikipedia.org/wiki/Open_Game_Engine_Exchange#Example
[3]: http://opengex.org/OpenGex-Blender-Script.zip
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Keith Boshoff]

Hi!

As much as using a proper, open interchange format would be fantastic, it's
just about useless if no other apps actually use the format.

I'm speaking from a Unity perspective and the chances of them including
other mesh formats in the near future are slim to none (Though I'm still
going to nag them about it). I'm pretty sure the same is true for Unreal,
Crytek, Lumberyard and definitely Stingray.

The other problem with open standards is that they are usually interpreted
as a free-for-all as far as features are concerned (see Collada), having
never looked at either of the proposed formats this may be a moot point,
but still something to consider moving forward..

In short having a stable, open standard for interchange would be the ideal,
but realistically FBX support is sadly still **very** important if any
interchange with current game engines is required.

Aside:
Blender's current FBX implementation is actually very good (as far as Unity
is concerned). The only missing feature is not even directly related to the
FBX format, ie. the correct translation from +Z Up to +Y Up, and rotating
everything along the Up Axis 180 degrees (due to the fact that the Front
camera actually looks along the +Y axis which creates the tendency to model
and animate everything rotated 180 degrees along the Up axis, but that's
another conversation).

Thanks,
Keith

On Wed, Feb 10, 2016 at 6:26 AM, Campbell Barton 
wrote:

> On Wed, Feb 10, 2016 at 3:42 AM, Bastien Montagne 
> wrote:
> > Hi,
> >
> > So, lately there's been a lot of FBX-related issues reported to our
> > tracker. Most of those are either:
> > - Known (half-)broken things (like cameras/lights orientation issues),
> > over which I do not intend to spend more time, since those are not
> > critical features to support imho.
> > - Broken corner-cases in an area that globally works rather well
> > (thinking about skeletons here).
> > - Mysterious third-party applications-related issues (scaling, skeletons
> > again, etc.), that is, bugs that show with one app but not another.
> >
> > I think later point is a good demonstration that FBX itself is a failure
> > and a dead horse - if even rather big and serious companies like Unreal
> > or Unity cannot get a reliable FBX importer working using official FBX
> > SDK, then how are we supposed to do it without even that SDK?
> >
> > Further more:
> > - In past two years a lot of time and energy was invested (lost) in FBX.
> > -  I’m just dead sick of that format, of hitting any possible
> > table corner when trying to walk my way in that non-sensible pitch black
> > box, etc. 
> > - Knowledge I gained of this format and its evolution is **not**
> > encouraging at all (stupid things like supporting two different and
> > complex transform systems [3DS max and Maya ones, btw ;) ], a very weird
> > inconsistency at binary level, etc.). I do not have any feeling this is
> > a sane format, nor that it is evolving in a sane direction. It seems to
> > be defined a bit as needs arise, piling up new stuff over old ones, etc.
> > To summarize: no clear design behind it, and a very dirty way of
> > handling new versions of it.
> >
> > So I would claim to stop relying on and developing it. It would not mean
> > we just remove it from Blender, but think it’s time to switch to
> > something more modern and open - am aware of at least to possible
> > alternatives, which could even be quite complementary.
> >
> > I) glTF
> > Promoted by Khronos group (https://www.khronos.org/gltf), it aims at
> > being the open exchange format for games (from simple asset to complete
> > scene description).
> > Think it’s still very new stuff, not much widely used yet, but it seems
> > to have some support from several major companies (including Microsoft
> > and even - rofl - Autodesk, see http://gltf.autodesk.io/).
> >
> > II) USD
> > Promoted by Pixar (http://graphics.pixar.com/usd/), it aims at being
> > some kind of generic pipeline format for CG studios (it also has
> > integration of Alembic e.g.).
> > I have no idea of its acceptance currently, but sounds like it could be
> > a valuable option for our 2.8 'pipeline/inter-application exchange' goal?
> >
> > (as a side note, interesting to see that those two have a similar
> > approach, they are not monolithic files but rather a combination of
> > binary data and textual descriptions…)
> >
> > Anyway, those are very early reflections, would like to get your
> > feelings about those two formats/projects (or others you may have in
> > mind! ;) ), but I’m feeling much more enthusiast at the idea of spending
> > time on modern, open-designed (or at least, open-specified) formats,
> > than on piece of proprietary crap!
> >
> > Again, even if we end up deciding we stop trying to fully support FBX as
> > our main exchange format, it would keep being supported in its current
> > status at least for one or two years - just I would not try to add
> > support for new versions (2016 one seems to have some inco

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

[Fabio Pesari]

On 02/10/2016 01:23 PM, Keith Boshoff wrote:
> I'm speaking from a Unity perspective and the chances of them including
> other mesh formats in the near future are slim to none (Though I'm still
> going to nag them about it). I'm pretty sure the same is true for Unreal,
> Crytek, Lumberyard and definitely Stingray.

A proprietary program decides to arbitrarily not implement some formats,
so Blender should follow suit, is that right?

If Unity wants to play the lock-in game, that's theirs to play. Nothing
prevents them from making deals with AutoDesk to make their formats the
default, for example.

I don't see how that should prevent Blender from making the right
choice, that is, to use formats that are fully documented, unencumbered
from patents and free, and do not require any reverse-engineering.

> The other problem with open standards is that they are usually interpreted
> as a free-for-all as far as features are concerned (see Collada), having
> never looked at either of the proposed formats this may be a moot point,
> but still something to consider moving forward..

This certainly happened in the past, however there is nothing inherent
to free formats that makes this easier, and the Blender team could
simply avoid doing that.

And proprietary formats which break every time a new "version" is
released are even worse, by the way.

> In short having a stable, open standard for interchange would be the ideal,
> but realistically FBX support is sadly still **very** important if any
> interchange with current game engines is required.

The two goals aren't incompatible: the Blender devs could both maintain
FBX support and implement new formats, although I would argue the latter
as higher priority (since it favors all users and not only those who
purposefully choose to rely on proprietary technologies which limit them).
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Owen Hogarth II]

This +1

On Wed, Feb 10, 2016, 20:47 Fabio Pesari  wrote:

> On 02/10/2016 01:23 PM, Keith Boshoff wrote:
> > I'm speaking from a Unity perspective and the chances of them including
> > other mesh formats in the near future are slim to none (Though I'm still
> > going to nag them about it). I'm pretty sure the same is true for Unreal,
> > Crytek, Lumberyard and definitely Stingray.
>
> A proprietary program decides to arbitrarily not implement some formats,
> so Blender should follow suit, is that right?
>
> If Unity wants to play the lock-in game, that's theirs to play. Nothing
> prevents them from making deals with AutoDesk to make their formats the
> default, for example.
>
> I don't see how that should prevent Blender from making the right
> choice, that is, to use formats that are fully documented, unencumbered
> from patents and free, and do not require any reverse-engineering.
>
> > The other problem with open standards is that they are usually
> interpreted
> > as a free-for-all as far as features are concerned (see Collada), having
> > never looked at either of the proposed formats this may be a moot point,
> > but still something to consider moving forward..
>
> This certainly happened in the past, however there is nothing inherent
> to free formats that makes this easier, and the Blender team could
> simply avoid doing that.
>
> And proprietary formats which break every time a new "version" is
> released are even worse, by the way.
>
> > In short having a stable, open standard for interchange would be the
> ideal,
> > but realistically FBX support is sadly still **very** important if any
> > interchange with current game engines is required.
>
> The two goals aren't incompatible: the Blender devs could both maintain
> FBX support and implement new formats, although I would argue the latter
> as higher priority (since it favors all users and not only those who
> purposefully choose to rely on proprietary technologies which limit them).
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Vicente Carro]

If Blender is really thinking about an industry/pipeline oriented release
then this discussion makes no sense. FBX is shit but we need it.

Vicente

On 10 February 2016 at 12:53, Owen Hogarth II  wrote:

> This +1
>
> On Wed, Feb 10, 2016, 20:47 Fabio Pesari  wrote:
>
> > On 02/10/2016 01:23 PM, Keith Boshoff wrote:
> > > I'm speaking from a Unity perspective and the chances of them including
> > > other mesh formats in the near future are slim to none (Though I'm
> still
> > > going to nag them about it). I'm pretty sure the same is true for
> Unreal,
> > > Crytek, Lumberyard and definitely Stingray.
> >
> > A proprietary program decides to arbitrarily not implement some formats,
> > so Blender should follow suit, is that right?
> >
> > If Unity wants to play the lock-in game, that's theirs to play. Nothing
> > prevents them from making deals with AutoDesk to make their formats the
> > default, for example.
> >
> > I don't see how that should prevent Blender from making the right
> > choice, that is, to use formats that are fully documented, unencumbered
> > from patents and free, and do not require any reverse-engineering.
> >
> > > The other problem with open standards is that they are usually
> > interpreted
> > > as a free-for-all as far as features are concerned (see Collada),
> having
> > > never looked at either of the proposed formats this may be a moot
> point,
> > > but still something to consider moving forward..
> >
> > This certainly happened in the past, however there is nothing inherent
> > to free formats that makes this easier, and the Blender team could
> > simply avoid doing that.
> >
> > And proprietary formats which break every time a new "version" is
> > released are even worse, by the way.
> >
> > > In short having a stable, open standard for interchange would be the
> > ideal,
> > > but realistically FBX support is sadly still **very** important if any
> > > interchange with current game engines is required.
> >
> > The two goals aren't incompatible: the Blender devs could both maintain
> > FBX support and implement new formats, although I would argue the latter
> > as higher priority (since it favors all users and not only those who
> > purposefully choose to rely on proprietary technologies which limit
> them).
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Fabio Pesari]

On 02/10/2016 02:00 PM, Vicente Carro wrote:
> If Blender is really thinking about an industry/pipeline oriented release
> then this discussion makes no sense. FBX is shit but we need it.
> 
> Vicente

https://www.khronos.org/gltf

Under "Industry Support for glTF". It seems like the industry cares
about glTF as well.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Vicente Carro]

>
> > If Blender is really thinking about an industry/pipeline oriented release
> > then this discussion makes no sense. FBX is shit but we need it.
> >
> > Vicente
>
> https://www.khronos.org/gltf
>
> Under "Industry Support for glTF". It seems like the industry cares
> about glTF as well.
>

They are talking about the future. Most of the comments are in future
tense, mentioning "the future" or that they are collaborating with the
"development". And please don't get me wrong, I completely agree that
Blender should support at least one of these new formats. But not instead
of FBX.

When you see glTF(or the others) in this list ( http://www.vfxplatform.com/
), then we talk. Meanwhile is a very promising thing that is not there yet.
(note: Those guys are the ones that in fact set the standard in the VFX
industry. And FBX is in the list.)

Even if I cannot disclosure the details I can tell you that a recent AAA
movie (punctually) used Blender precisely because it was importing FBX
better than Maya. And guess what, the team started to think about using
Blender more seriously in the next film. So, IMHO, having a good FBX
support is good for Blender and should stay until the industry actually
changes to another format.

On 10 February 2016 at 13:17, Fabio Pesari  wrote:

> On 02/10/2016 02:00 PM, Vicente Carro wrote:
> > If Blender is really thinking about an industry/pipeline oriented release
> > then this discussion makes no sense. FBX is shit but we need it.
> >
> > Vicente
>
> https://www.khronos.org/gltf
>
> Under "Industry Support for glTF". It seems like the industry cares
> about glTF as well.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[David Fenner]

On 02/10/2016 01:23 PM, Keith Boshoff wrote:
> I'm speaking from a Unity perspective and the chances of them including
> other mesh formats in the near future are slim to none (Though I'm still
> going to nag them about it). I'm pretty sure the same is true for Unreal,
> Crytek, Lumberyard and definitely Stingray.


*A proprietary program decides to arbitrarily not implement some formats,so
Blender should follow suit, is that right?*

I think this is unfare. Blender lives because of it's users. Think about
how many studio pipelines depend on blender fbx export to unity. If
suddenly this is dead, then thousands (literally) would have to switch to
other animation software to work with unity. I really don't want this to
happen, one because I love blender, second because I'd have to pay for
other software just because of fbx, and third because all of us wouldn't be
able to support blender like a user and as donator (too much money on fbx
program).

2016-02-10 10:46 GMT-03:00 Vicente Carro :

> >
> > > If Blender is really thinking about an industry/pipeline oriented
> release
> > > then this discussion makes no sense. FBX is shit but we need it.
> > >
> > > Vicente
> >
> > https://www.khronos.org/gltf
> >
> > Under "Industry Support for glTF". It seems like the industry cares
> > about glTF as well.
> >
>
> They are talking about the future. Most of the comments are in future
> tense, mentioning "the future" or that they are collaborating with the
> "development". And please don't get me wrong, I completely agree that
> Blender should support at least one of these new formats. But not instead
> of FBX.
>
> When you see glTF(or the others) in this list (
> http://www.vfxplatform.com/
> ), then we talk. Meanwhile is a very promising thing that is not there yet.
> (note: Those guys are the ones that in fact set the standard in the VFX
> industry. And FBX is in the list.)
>
> Even if I cannot disclosure the details I can tell you that a recent AAA
> movie (punctually) used Blender precisely because it was importing FBX
> better than Maya. And guess what, the team started to think about using
> Blender more seriously in the next film. So, IMHO, having a good FBX
> support is good for Blender and should stay until the industry actually
> changes to another format.
>
> On 10 February 2016 at 13:17, Fabio Pesari  wrote:
>
> > On 02/10/2016 02:00 PM, Vicente Carro wrote:
> > > If Blender is really thinking about an industry/pipeline oriented
> release
> > > then this discussion makes no sense. FBX is shit but we need it.
> > >
> > > Vicente
> >
> > https://www.khronos.org/gltf
> >
> > Under "Industry Support for glTF". It seems like the industry cares
> > about glTF as well.
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Fabio Pesari]

On 02/10/2016 02:46 PM, Vicente Carro wrote:
> They are talking about the future. Most of the comments are in future
> tense, mentioning "the future" or that they are collaborating with the
> "development". And please don't get me wrong, I completely agree that
> Blender should support at least one of these new formats. But not instead
> of FBX.

Oh sure, as I said the two things are not incompatible.

But perhaps all those people who need FBX support should either donate
money to Blender or hire a developer to work on that specific feature
full-time, given that reverse-engineering is a time-consuming and hard
task and it wouldn't be fair to take time away from features from which
the whole community might benefit (as opposed to a subset of users who
explicitly need compatibility with proprietary technologies).

> When you see glTF(or the others) in this list ( http://www.vfxplatform.com/
> ), then we talk. Meanwhile is a very promising thing that is not there yet.
> (note: Those guys are the ones that in fact set the standard in the VFX
> industry. And FBX is in the list.)

I'm glad that most of those things are not proprietary, except these
three: Intel TBB, Intel MKL and FBX (and probably ACES as well, I'm not
sure about this license [0]).

My question is - what makes FBX so special compared to other formats
that an exception should be made for it in a list of standardized/free
technologies, other than the fact that many people use it?

[0]: https://github.com/ampas/aces-dev/blob/v1.0.1/LICENSE.md
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[David Fenner]

Crowdfund FBX then. Money donated will decide how much it is needed. I know
this isn't ideal from an open source perspective, but honestly, fbx is a
business/market matter, and maybe should be put aside from the blender open
source ideal.

2016-02-10 11:05 GMT-03:00 Fabio Pesari :

> On 02/10/2016 02:46 PM, Vicente Carro wrote:
> > They are talking about the future. Most of the comments are in future
> > tense, mentioning "the future" or that they are collaborating with the
> > "development". And please don't get me wrong, I completely agree that
> > Blender should support at least one of these new formats. But not instead
> > of FBX.
>
> Oh sure, as I said the two things are not incompatible.
>
> But perhaps all those people who need FBX support should either donate
> money to Blender or hire a developer to work on that specific feature
> full-time, given that reverse-engineering is a time-consuming and hard
> task and it wouldn't be fair to take time away from features from which
> the whole community might benefit (as opposed to a subset of users who
> explicitly need compatibility with proprietary technologies).
>
> > When you see glTF(or the others) in this list (
> http://www.vfxplatform.com/
> > ), then we talk. Meanwhile is a very promising thing that is not there
> yet.
> > (note: Those guys are the ones that in fact set the standard in the VFX
> > industry. And FBX is in the list.)
>
> I'm glad that most of those things are not proprietary, except these
> three: Intel TBB, Intel MKL and FBX (and probably ACES as well, I'm not
> sure about this license [0]).
>
> My question is - what makes FBX so special compared to other formats
> that an exception should be made for it in a list of standardized/free
> technologies, other than the fact that many people use it?
>
> [0]: https://github.com/ampas/aces-dev/blob/v1.0.1/LICENSE.md
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Fabio Pesari]

On 02/10/2016 03:00 PM, David Fenner wrote:
> I think this is unfare. Blender lives because of it's users. Think about
> how many studio pipelines depend on blender fbx export to unity. 

It seems like Blender is very important for both studios and Unity. How
much money did studios donate to Blender? How much money did Unity
donate to Blender?

I am honestly curious, these are not rhetoric questions.

> If suddenly this is dead, then thousands (literally) would have to switch to
> other animation software to work with unity. I really don't want this to
> happen, one because I love blender, second because I'd have to pay for
> other software just because of fbx, and third because all of us wouldn't be
> able to support blender like a user and as donator (too much money on fbx
> program).

Blender cannot ever die because it's free software, but if it "dies" in
terms of fewer contributions due to poor funding, it will be exactly
because of people who would rather buy* expensive proprietary programs
than donate at least 1/3 of that money to Blender. Why the double standard?
* = in some cases, rent, because many of those other programs use DRM
and are subscription-based.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Campbell Barton]

On Thu, Feb 11, 2016 at 1:28 AM, Fabio Pesari  wrote:
> On 02/10/2016 03:00 PM, David Fenner wrote:
>> I think this is unfare. Blender lives because of it's users. Think about
>> how many studio pipelines depend on blender fbx export to unity.
>
> It seems like Blender is very important for both studios and Unity. How
> much money did studios donate to Blender? How much money did Unity
> donate to Blender?
>
> I am honestly curious, these are not rhetoric questions.

Unity3D funded the original FBX exporter,
see: https://www.blender.org/about/credits/

>> If suddenly this is dead, then thousands (literally) would have to switch to
>> other animation software to work with unity. I really don't want this to
>> happen, one because I love blender, second because I'd have to pay for
>> other software just because of fbx, and third because all of us wouldn't be
>> able to support blender like a user and as donator (too much money on fbx
>> program).
>
> Blender cannot ever die because it's free software, but if it "dies" in
> terms of fewer contributions due to poor funding, it will be exactly
> because of people who would rather buy* expensive proprietary programs
> than donate at least 1/3 of that money to Blender. Why the double standard?
> * = in some cases, rent, because many of those other programs use DRM
> and are subscription-based.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Fabio Pesari]

On 02/10/2016 03:35 PM, Campbell Barton wrote:
> Unity3D funded the original FBX exporter,
> see: https://www.blender.org/about/credits/

That's good to know, and I can appreciate that.
Have they been contributing to it since then? I think it would be in
their interest to hire someone to work specifically on FBX support.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[David Fenner]

2016-02-10 11:28 GMT-03:00 Fabio Pesari :

> , but if it "dies" in
> terms of fewer contributions due to poor funding, it will be exactly
> because of people who would rather buy* expensive proprietary programs
> than donate at least 1/3 of that money to Blender. Why the double standard?
> * = in some cases, rent, because many of those other programs use DRM
> and are subscription-based.


Talking about double standard here is waaay too idealistic. Users buy
software when they need to, and when open source software meets all their
needs, they donate when they can or want. Still, having thousands of users
using blender is still better for the software, since studios do develop
for blender for time to time, they also contribute bug reports, ideas,
sometimes money, and they spread the use of the software, which makes big
studios start to develop also for blender. Is an ecosystem based on users.
Sadly, people don't appreciate what they have until they can lose it, and
that's what I'm saying that maybe fbx export should be crowdfunded.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Vicente Carro]

Well, instead of crowdfunding, that I think it's not going to work, I would
suggest to officially (Ton) talk with Unreal, Unity, Valve and maybe some
of the blender partners and expose the problem to them. If possible make
them talk all together. Since all of them have some interest in FBX working
in Blender probably they can agree to have a guy maintaining FBX for
Blender or to give us other solution.

Vicente

On 10 February 2016 at 14:48, David Fenner  wrote:

> 2016-02-10 11:28 GMT-03:00 Fabio Pesari :
>
> > , but if it "dies" in
> > terms of fewer contributions due to poor funding, it will be exactly
> > because of people who would rather buy* expensive proprietary programs
> > than donate at least 1/3 of that money to Blender. Why the double
> standard?
> > * = in some cases, rent, because many of those other programs use DRM
> > and are subscription-based.
>
>
> Talking about double standard here is waaay too idealistic. Users buy
> software when they need to, and when open source software meets all their
> needs, they donate when they can or want. Still, having thousands of users
> using blender is still better for the software, since studios do develop
> for blender for time to time, they also contribute bug reports, ideas,
> sometimes money, and they spread the use of the software, which makes big
> studios start to develop also for blender. Is an ecosystem based on users.
> Sadly, people don't appreciate what they have until they can lose it, and
> that's what I'm saying that maybe fbx export should be crowdfunded.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Built-in support for free formats (OpenGEX and glTF)

[Todor Imreorov]

It would be great to have gitf support. Some open source game engines use
it for importing 3d animated assets. It is said to perfprm better that the
other formats on webg games.
On 10 Feb 2016 11:42, "Fabio Pesari"  wrote:

> After reading the thread about FBX, I realized that since Blender is
> free software, it would be good if it encouraged using free formats
> instead of proprietary ones like FBX, which are always going to require
> time-consuming reverse engineering efforts.
>
> I know at least two engine-independent formats which have fully
> available specifications: glTF ([0]) and OpenGEX ([1]).
>
> I think both were designed to fix the various issues COLLADA had; glTF
> is JSON-based and OpenGEX uses its own typed free format called
> "OpenDDL" (example at [2]).
>
> OpenGEX already has a Blender exporter which is licensed under the CC
> BY-SA 3.0 ([3]), while I couldn't find anything Blender-related for glTF
> (but being JSON-based, writing a Python plugin for it should be trivial).
>
> I think including built-in support for them in Blender would be a good
> way to encourage users to adopt something else than both proprietary
> formats and free (but crappy) COLLADA, and for the Blenders devs to have
> less headaches (since they would just have to follow the specs rather
> than reverse-engineer obscure formats).
>
> [0]:
> https://github.com/KhronosGroup/glTF/blob/master/specification/README.md
> [1]: http://opengex.org/OpenGEX.1.1.2.pdf
> [2]: https://en.wikipedia.org/wiki/Open_Game_Engine_Exchange#Example
> [3]: http://opengex.org/OpenGex-Blender-Script.zip
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Fergal Gribben]

I agree with Fabio and David - if industry users are so reliant on FBX
support within Blender, then crowdfunding/hiring a developer to work
specifically on FBX support is probably worth investigating. From what
Bastien has said, keeping up with the latest FBX format sounds like a major
pain, and from what I can tell, focusing efforts on supporting glTF or USD
would be time better spent.

A professional Unity license costs $75 a month, a 3DS Max subscription with
basic support costs €238 a month, and a Maya LT subscription with basic
support costs €35.70 a month

If lacking FBX support in Blender would cause people to switch to
expensive, proprietary software, is it too much to ask that they instead
donate to FBX development within Blender? If industry users were to donate
a fraction of the aforementioned licensing costs on a monthly basis,
perhaps that would be enough support for a dedicated FBX developer?

I believe EpicGames donated €10k to the development fund for better FBX
support in the past (
https://twitter.com/tonroosendaal/status/485431565447868416) - is that too
ambitious a goal for crowdfunding?

And just to weigh in with my own personal experiences as a hobbyist game
dev: the FBX format terrifies me! :) Personally, I couldn't make sense of
the file format, especially when it came to animations, so I instead
decided to create my own file format for my game engine. At least that way
I know exactly what information is available to me, and I know that any
bugs I encounter are related to my game engine's implementation, and not
due to how Blender has exported the scene. The same applies to a lot of
other hobbyist/home users I know, either they get by with the .obj format,
or they roll their own. Furthermore, any inconsistencies with my own file
format are easily identified and fixed, whereas FBX to me was a bit of a
black box.

I guess what I'm trying to say is, the FBX format seems much more important
to users who work in the industry, rather than home/hobbyist users, and I
think if the demand was there as much as industry users have conveyed, a
push for donations/crowdfunding would be enough to achieve better FBX
support.

On 10 February 2016 at 14:57, Vicente Carro  wrote:

> Well, instead of crowdfunding, that I think it's not going to work, I would
> suggest to officially (Ton) talk with Unreal, Unity, Valve and maybe some
> of the blender partners and expose the problem to them. If possible make
> them talk all together. Since all of them have some interest in FBX working
> in Blender probably they can agree to have a guy maintaining FBX for
> Blender or to give us other solution.
>
> Vicente
>
> On 10 February 2016 at 14:48, David Fenner  wrote:
>
> > 2016-02-10 11:28 GMT-03:00 Fabio Pesari :
> >
> > > , but if it "dies" in
> > > terms of fewer contributions due to poor funding, it will be exactly
> > > because of people who would rather buy* expensive proprietary programs
> > > than donate at least 1/3 of that money to Blender. Why the double
> > standard?
> > > * = in some cases, rent, because many of those other programs use DRM
> > > and are subscription-based.
> >
> >
> > Talking about double standard here is waaay too idealistic. Users buy
> > software when they need to, and when open source software meets all their
> > needs, they donate when they can or want. Still, having thousands of
> users
> > using blender is still better for the software, since studios do develop
> > for blender for time to time, they also contribute bug reports, ideas,
> > sometimes money, and they spread the use of the software, which makes big
> > studios start to develop also for blender. Is an ecosystem based on
> users.
> > Sadly, people don't appreciate what they have until they can lose it, and
> > that's what I'm saying that maybe fbx export should be crowdfunded.
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Ton Roosendaal]

Hi Bastien,

Thanks for the notes, I know how much you've been suffering *and* contributing 
in this area!

Let me share a bit of background info, and provide a translation of Bastien's 
rant :)

Bastien is already involved since September 2013 to work on FBX. He did a truly 
amazing job in getting IO on a reasonable working level already. I hear a lot 
of professionals and studios who are happy with Blender's fbx support.

After over two years of FBX work, Bastien is now our #1 expert in that area. He 
made a well informed (albeit a bit frustrated) decision that he doesn't further 
want to develop on it.

His suggestion is just to freeze the support level for FBX (or limit it, like 
Campbell suggests) and move energy to another and truly open format.

Of course we keep FBX, and if a developer comes by who likes to maintain it or 
who can bring it up to an even higher support level, then the person is more 
than welcome (possibly with a development fund grant). Knowing the quality of 
Bastien's work, then this is not going to be a simple job for anyone. But it 
could be tried!

(BTW don't forget, Autodesk is not giving out docs or specs, and they change 
the format at will randomly. We need to reverse engineer the format).

And that is the real main reason for this frustrated situation:
--> Autodesk's persistent refusal to open up FBX as an exchange format <--

It's how Autodesk frustrates and dominates the market. Good for their share 
holders. 

And secondary: why are parties like Epic Games, Valve or Unity not solving it 
then?
Together they are a 100x more powerful than Blender Foundation. They can start 
to make nice plugins for Maya and Max for an open format tomorrow. Heck, they 
could use the .blend format even!

Laters,

-Ton-


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



> On 9 Feb, 2016, at 17:42, Bastien Montagne  wrote:
> 
> Hi,
> 
> So, lately there's been a lot of FBX-related issues reported to our 
> tracker. Most of those are either:
> - Known (half-)broken things (like cameras/lights orientation issues), 
> over which I do not intend to spend more time, since those are not 
> critical features to support imho.
> - Broken corner-cases in an area that globally works rather well 
> (thinking about skeletons here).
> - Mysterious third-party applications-related issues (scaling, skeletons 
> again, etc.), that is, bugs that show with one app but not another.
> 
> I think later point is a good demonstration that FBX itself is a failure 
> and a dead horse - if even rather big and serious companies like Unreal 
> or Unity cannot get a reliable FBX importer working using official FBX 
> SDK, then how are we supposed to do it without even that SDK?
> 
> Further more:
> - In past two years a lot of time and energy was invested (lost) in FBX.
> -  I’m just dead sick of that format, of hitting any possible 
> table corner when trying to walk my way in that non-sensible pitch black 
> box, etc. 
> - Knowledge I gained of this format and its evolution is **not** 
> encouraging at all (stupid things like supporting two different and 
> complex transform systems [3DS max and Maya ones, btw ;) ], a very weird 
> inconsistency at binary level, etc.). I do not have any feeling this is 
> a sane format, nor that it is evolving in a sane direction. It seems to 
> be defined a bit as needs arise, piling up new stuff over old ones, etc. 
> To summarize: no clear design behind it, and a very dirty way of 
> handling new versions of it.
> 
> So I would claim to stop relying on and developing it. It would not mean 
> we just remove it from Blender, but think it’s time to switch to 
> something more modern and open - am aware of at least to possible 
> alternatives, which could even be quite complementary.
> 
> I) glTF
> Promoted by Khronos group (https://www.khronos.org/gltf), it aims at 
> being the open exchange format for games (from simple asset to complete 
> scene description).
> Think it’s still very new stuff, not much widely used yet, but it seems 
> to have some support from several major companies (including Microsoft 
> and even - rofl - Autodesk, see http://gltf.autodesk.io/).
> 
> II) USD
> Promoted by Pixar (http://graphics.pixar.com/usd/), it aims at being 
> some kind of generic pipeline format for CG studios (it also has 
> integration of Alembic e.g.).
> I have no idea of its acceptance currently, but sounds like it could be 
> a valuable option for our 2.8 'pipeline/inter-application exchange' goal?
> 
> (as a side note, interesting to see that those two have a similar 
> approach, they are not monolithic files but rather a combination of 
> binary data and textual descriptions…)
> 
> Anyway, those are very early reflections, would like to get your 
> feelings about those two formats/projects (or others you ma

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

[Ton Roosendaal]

Hi,

Money is very welcome. Industry users can do two things:

1) Let their company sign up for the development fund:
https://www.blender.org/foundation/development-fund/

(We get about 100 grand per year, which is 1% of what C4D users give to Maxon 
annually).

2) Hire developers yourself! Or assign your own developers part time on IO for 
Blender.

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. 

-Ton-


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



> On 10 Feb, 2016, at 16:13, Fergal Gribben  wrote:
> 
> I agree with Fabio and David - if industry users are so reliant on FBX
> support within Blender, then crowdfunding/hiring a developer to work
> specifically on FBX support is probably worth investigating. From what
> Bastien has said, keeping up with the latest FBX format sounds like a major
> pain, and from what I can tell, focusing efforts on supporting glTF or USD
> would be time better spent.
> 
> A professional Unity license costs $75 a month, a 3DS Max subscription with
> basic support costs €238 a month, and a Maya LT subscription with basic
> support costs €35.70 a month
> 
> If lacking FBX support in Blender would cause people to switch to
> expensive, proprietary software, is it too much to ask that they instead
> donate to FBX development within Blender? If industry users were to donate
> a fraction of the aforementioned licensing costs on a monthly basis,
> perhaps that would be enough support for a dedicated FBX developer?
> 
> I believe EpicGames donated €10k to the development fund for better FBX
> support in the past (
> https://twitter.com/tonroosendaal/status/485431565447868416) - is that too
> ambitious a goal for crowdfunding?
> 
> And just to weigh in with my own personal experiences as a hobbyist game
> dev: the FBX format terrifies me! :) Personally, I couldn't make sense of
> the file format, especially when it came to animations, so I instead
> decided to create my own file format for my game engine. At least that way
> I know exactly what information is available to me, and I know that any
> bugs I encounter are related to my game engine's implementation, and not
> due to how Blender has exported the scene. The same applies to a lot of
> other hobbyist/home users I know, either they get by with the .obj format,
> or they roll their own. Furthermore, any inconsistencies with my own file
> format are easily identified and fixed, whereas FBX to me was a bit of a
> black box.
> 
> I guess what I'm trying to say is, the FBX format seems much more important
> to users who work in the industry, rather than home/hobbyist users, and I
> think if the demand was there as much as industry users have conveyed, a
> push for donations/crowdfunding would be enough to achieve better FBX
> support.
> 
> On 10 February 2016 at 14:57, Vicente Carro  wrote:
> 
>> Well, instead of crowdfunding, that I think it's not going to work, I would
>> suggest to officially (Ton) talk with Unreal, Unity, Valve and maybe some
>> of the blender partners and expose the problem to them. If possible make
>> them talk all together. Since all of them have some interest in FBX working
>> in Blender probably they can agree to have a guy maintaining FBX for
>> Blender or to give us other solution.
>> 
>> Vicente
>> 
>> On 10 February 2016 at 14:48, David Fenner  wrote:
>> 
>>> 2016-02-10 11:28 GMT-03:00 Fabio Pesari :
>>> 
 , but if it "dies" in
 terms of fewer contributions due to poor funding, it will be exactly
 because of people who would rather buy* expensive proprietary programs
 than donate at least 1/3 of that money to Blender. Why the double
>>> standard?
 * = in some cases, rent, because many of those other programs use DRM
and are subscription-based.
>>> 
>>> 
>>> Talking about double standard here is waaay too idealistic. Users buy
>>> software when they need to, and when open source software meets all their
>>> needs, they donate when they can or want. Still, having thousands of
>> users
>>> using blender is still better for the software, since studios do develop
>>> for blender for time to time, they also contribute bug reports, ideas,
>>> sometimes money, and they spread the use of the software, which makes big
>>> studios start to develop also for blender. Is an ecosystem based on
>> users.
>>> Sadly, people don't appreciate what they have until they can lose it, and
>>> that's what I'm sayi

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

[Doeke Wartena]

The best way to let FBX die is to support other formats!
I hate autodesk more then Ton hates installers and progress bars.

2016-02-10 16:44 GMT+01:00 Ton Roosendaal :

> Hi,
>
> Money is very welcome. Industry users can do two things:
>
> 1) Let their company sign up for the development fund:
> https://www.blender.org/foundation/development-fund/
>
> (We get about 100 grand per year, which is 1% of what C4D users give to
> Maxon annually).
>
> 2) Hire developers yourself! Or assign your own developers part time on IO
> for Blender.
>
> 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.
>
> -Ton-
>
> 
> Ton Roosendaal  -  t...@blender.org   -   www.blender.org
> Chairman Blender Foundation - Producer Blender Institute
> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>
>
>
> > On 10 Feb, 2016, at 16:13, Fergal Gribben  wrote:
> >
> > I agree with Fabio and David - if industry users are so reliant on FBX
> > support within Blender, then crowdfunding/hiring a developer to work
> > specifically on FBX support is probably worth investigating. From what
> > Bastien has said, keeping up with the latest FBX format sounds like a
> major
> > pain, and from what I can tell, focusing efforts on supporting glTF or
> USD
> > would be time better spent.
> >
> > A professional Unity license costs $75 a month, a 3DS Max subscription
> with
> > basic support costs €238 a month, and a Maya LT subscription with basic
> > support costs €35.70 a month
> >
> > If lacking FBX support in Blender would cause people to switch to
> > expensive, proprietary software, is it too much to ask that they instead
> > donate to FBX development within Blender? If industry users were to
> donate
> > a fraction of the aforementioned licensing costs on a monthly basis,
> > perhaps that would be enough support for a dedicated FBX developer?
> >
> > I believe EpicGames donated €10k to the development fund for better FBX
> > support in the past (
> > https://twitter.com/tonroosendaal/status/485431565447868416) - is that
> too
> > ambitious a goal for crowdfunding?
> >
> > And just to weigh in with my own personal experiences as a hobbyist game
> > dev: the FBX format terrifies me! :) Personally, I couldn't make sense of
> > the file format, especially when it came to animations, so I instead
> > decided to create my own file format for my game engine. At least that
> way
> > I know exactly what information is available to me, and I know that any
> > bugs I encounter are related to my game engine's implementation, and not
> > due to how Blender has exported the scene. The same applies to a lot of
> > other hobbyist/home users I know, either they get by with the .obj
> format,
> > or they roll their own. Furthermore, any inconsistencies with my own file
> > format are easily identified and fixed, whereas FBX to me was a bit of a
> > black box.
> >
> > I guess what I'm trying to say is, the FBX format seems much more
> important
> > to users who work in the industry, rather than home/hobbyist users, and I
> > think if the demand was there as much as industry users have conveyed, a
> > push for donations/crowdfunding would be enough to achieve better FBX
> > support.
> >
> > On 10 February 2016 at 14:57, Vicente Carro 
> wrote:
> >
> >> Well, instead of crowdfunding, that I think it's not going to work, I
> would
> >> suggest to officially (Ton) talk with Unreal, Unity, Valve and maybe
> some
> >> of the blender partners and expose the problem to them. If possible make
> >> them talk all together. Since all of them have some interest in FBX
> working
> >> in Blender probably they can agree to have a guy maintaining FBX for
> >> Blender or to give us other solution.
> >>
> >> Vicente
> >>
> >> On 10 February 2016 at 14:48, David Fenner 
> wrote:
> >>
> >>> 2016-02-10 11:28 GMT-03:00 Fabio Pesari :
> >>>
>  , but if it "dies" in
>  terms of fewer contributions due to poor funding, it will be exactly
>  because of people who would rather buy* expensive proprietary programs
>  than donate at least 1/3 of that money to Blender. Why the double
> >>> standard?
>  * = in some cases, rent, because many of those other programs use DRM
> and are subscription-based.
> >>>
> >>>
> >>> Talking about double standard here is waaay too idealistic. Users buy
> >>> software when they need to, and when open source software meets all
> their
> >>> needs, they donate when they can or want. Still, having thousands of
> >> users
> >>> using blender is still better for the soft

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

[Fabio Pesari]

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@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Daniel Stokes]

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  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@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Built-in support for free formats (OpenGEX and glTF)

[Juan Linietsky]

glTF is raw OpenGL state data, it's useless for game engines other than
basic HTML5 frameworks.

On Wed, Feb 10, 2016 at 12:05 PM, Todor Imreorov 
wrote:

> It would be great to have gitf support. Some open source game engines use
> it for importing 3d animated assets. It is said to perfprm better that the
> other formats on webg games.
> On 10 Feb 2016 11:42, "Fabio Pesari"  wrote:
>
> > After reading the thread about FBX, I realized that since Blender is
> > free software, it would be good if it encouraged using free formats
> > instead of proprietary ones like FBX, which are always going to require
> > time-consuming reverse engineering efforts.
> >
> > I know at least two engine-independent formats which have fully
> > available specifications: glTF ([0]) and OpenGEX ([1]).
> >
> > I think both were designed to fix the various issues COLLADA had; glTF
> > is JSON-based and OpenGEX uses its own typed free format called
> > "OpenDDL" (example at [2]).
> >
> > OpenGEX already has a Blender exporter which is licensed under the CC
> > BY-SA 3.0 ([3]), while I couldn't find anything Blender-related for glTF
> > (but being JSON-based, writing a Python plugin for it should be trivial).
> >
> > I think including built-in support for them in Blender would be a good
> > way to encourage users to adopt something else than both proprietary
> > formats and free (but crappy) COLLADA, and for the Blenders devs to have
> > less headaches (since they would just have to follow the specs rather
> > than reverse-engineer obscure formats).
> >
> > [0]:
> > https://github.com/KhronosGroup/glTF/blob/master/specification/README.md
> > [1]: http://opengex.org/OpenGEX.1.1.2.pdf
> > [2]: https://en.wikipedia.org/wiki/Open_Game_Engine_Exchange#Example
> > [3]: http://opengex.org/OpenGex-Blender-Script.zip
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Built-in support for free formats (OpenGEX and glTF)

[Juan Linietsky]

Blender support for Collada is bad because no one wants to work on it. The
format itself is not at fault.

On Wed, Feb 10, 2016 at 5:14 PM, Juan Linietsky  wrote:

> glTF is raw OpenGL state data, it's useless for game engines other than
> basic HTML5 frameworks.
>
> On Wed, Feb 10, 2016 at 12:05 PM, Todor Imreorov 
> wrote:
>
>> It would be great to have gitf support. Some open source game engines use
>> it for importing 3d animated assets. It is said to perfprm better that the
>> other formats on webg games.
>> On 10 Feb 2016 11:42, "Fabio Pesari"  wrote:
>>
>> > After reading the thread about FBX, I realized that since Blender is
>> > free software, it would be good if it encouraged using free formats
>> > instead of proprietary ones like FBX, which are always going to require
>> > time-consuming reverse engineering efforts.
>> >
>> > I know at least two engine-independent formats which have fully
>> > available specifications: glTF ([0]) and OpenGEX ([1]).
>> >
>> > I think both were designed to fix the various issues COLLADA had; glTF
>> > is JSON-based and OpenGEX uses its own typed free format called
>> > "OpenDDL" (example at [2]).
>> >
>> > OpenGEX already has a Blender exporter which is licensed under the CC
>> > BY-SA 3.0 ([3]), while I couldn't find anything Blender-related for glTF
>> > (but being JSON-based, writing a Python plugin for it should be
>> trivial).
>> >
>> > I think including built-in support for them in Blender would be a good
>> > way to encourage users to adopt something else than both proprietary
>> > formats and free (but crappy) COLLADA, and for the Blenders devs to have
>> > less headaches (since they would just have to follow the specs rather
>> > than reverse-engineer obscure formats).
>> >
>> > [0]:
>> >
>> https://github.com/KhronosGroup/glTF/blob/master/specification/README.md
>> > [1]: http://opengex.org/OpenGEX.1.1.2.pdf
>> > [2]: https://en.wikipedia.org/wiki/Open_Game_Engine_Exchange#Example
>> > [3]: http://opengex.org/OpenGex-Blender-Script.zip
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Juan Linietsky]

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  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  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@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Mike Erwin]

Timur Ariman  wrote:
>
> After or if possible during integration of the fileformat into Blender,
> adding big game engine developers for implementing the same interchange
> format
> should be a given!
>

Keith Boshoff  wrote:

> As much as using a proper, open interchange format would be fantastic, it's
> just about useless if no other apps actually use the format.
>
> I'm speaking from a Unity perspective and the chances of them including
> other mesh formats in the near future are slim to none (Though I'm still
> going to nag them about it). I'm pretty sure the same is true for Unreal,
> Crytek, Lumberyard and definitely Stingray.
>

Why assume that other project's developers have no interest in open
formats? I'll talk to some Epic folks tomorrow and see how interested they
are in accepting glTF data (alongside FBX). Maybe start simple with
StaticMesh import and build from there.

To get other people on board, what are the benefits? I'll focus on glTF
since I know nothing about the other formats mentioned:
- not controlled by a 3rd party
- simpler format / easier to implement correctly
- robust export from Blender (in the near future)
- what else?

Also keep in mind glTF is an export format, not an interchange format like
Collada & FBX. It's ideal for moving *finished* 3D work from Blender to a
game engine. It will be a good alternative to FBX for many tasks.

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[spatial]

> - Known (half-)broken things (like cameras/lights orientation issues),
> over which I do not intend to spend more time, since those are not
> critical features to support imho.
The way I solved this issue was to copy the motion (scale translate 
rotation) to a empty object, and parent the non moving camera/ lights to 
this empty (So I can do an easy roate it by 90 degrees etc in the 
application of choice). Maybe this process can be optional / automated ?

> - Mysterious third-party applications-related issues (scaling, skeletons
> again, etc.), that is, bugs that show with one app but not another.

This is the point wich hits my nerve, because you will _allways_ run 
into problems, even if you try to natively support an application of 
choice. If you are lucky you do have an open format (lw modo) wich you
can _export_ to, wich is (imho) the beter solution than writing an importer:
If you are using a more or less closed format (blender / max) you are
not only bound to the problems reinventing the wheel (like text 
objects), but also with the restrictions the api provide.

Point is, you will allways run into problems and things don't get better 
with collada, fbx or what I've read about USD wich all try to be as less 
restrictive as possible, wich opens the can of worms for 
misinterpretation and half supported features.

I really hoped USD would make it right, and come up at the start with a 
very limited and restricted format with one or two reference 
implementions, so people could test their importers/exporters on them. 
But as far as I see this isn't the case. In fact I've got some deja vue 
feeling (collada). But maybe its just to soon to judge it.

This shouldn't sound like a defendance to the current situation wich 
undoubtly does suck, but I still does not encounter any scene 
description format wich is as simple and foolproof as obj is for 
objects... Maybe USD will proove me wrong, maybe glTF (wich I heard the 
first tme) might be the solution, but wouldn't it be wiser to wait
until we do know that these formats do work / are widely supported ?

just my 2 cents on this
chris


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Gaia Clary]

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  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  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@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>

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

[Juan Linietsky]

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 
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 
> 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  wrote:
> >>
> >>> On 02/10/2016 04:44 PM, Ton Roosendaal wrote:
>  A crowd-funder for 1 feature only is very risky. What precisely d

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

[Thomas Dinges]

Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> -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.

"Refused to add it"?

https://developer.blender.org/T41071
Reading that ticket^^ tells a whole different story.
Reasonable code review comments were made, but then we got no further 
response.

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Julian Eisel]

Suggest we don't pollute this mailing list with discussions about
who's capable of writing the better Collada Importer/Exporter? This
isn't helpful at all.

Cheers,
- Julian -

On 10 February 2016 at 23:21, Thomas Dinges  wrote:
> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
>> -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.
>
> "Refused to add it"?
>
> https://developer.blender.org/T41071
> Reading that ticket^^ tells a whole different story.
> Reasonable code review comments were made, but then we got no further
> response.
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Juan Linietsky]

Julian, I'm only proposing a way to solve the following problems:

1) Not having an alternative to FBX
2) Not having a fully working Collada exporter that supports the same as
the FBX. You can test mine any time, try exporting a complex scene from
Blender with skeletal animations, blend shapes, multiple actions, etc.
3) Not having a fully working Collada importer. You can test mine any time
and see how it imports Blender, OpenCollada, XSI, Lightwave, etc. with all
the above mentioned features.
4) Not having the huge bloat that represents using OpenCollada in Blender.

There is no argument here. I'm offering a working solution, I did all the
work already, developed both importer and importer. Hundreds of users
tested both working. You just have to take it or leave it.

But if you leave it, please don't follow with the hipocrisy of saying FBX
evil and we have no alternative. Collada is a fine format already, the only
problem is broken libraries (FCollada, OpenCollada).



On Wed, Feb 10, 2016 at 7:37 PM, Julian Eisel  wrote:

> Suggest we don't pollute this mailing list with discussions about
> who's capable of writing the better Collada Importer/Exporter? This
> isn't helpful at all.
>
> Cheers,
> - Julian -
>
> On 10 February 2016 at 23:21, Thomas Dinges  wrote:
> > Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> >> -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.
> >
> > "Refused to add it"?
> >
> > https://developer.blender.org/T41071
> > Reading that ticket^^ tells a whole different story.
> > Reasonable code review comments were made, but then we got no further
> > response.
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Juan Linietsky]

Yeah, I had hope for a bit, then been told current broken support for
Collada would be fixed. Finally, it was not fixed.

I've been trying to help Blender support Collada properly for 10 years, did
all the work, proposed it. Still maintain in on my own. It works
fantastically well, it's been tested in several games with very complex
rigs, with several exporters.

But there seems to be this overwhelming feeling Blender developers have to
keep the broken implementation and insist on defending it... while
complaining there is no alternative to FBX export. I wonder why..


"Refused to add it"?
>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Todor Imreorov]

Until the code clean up can this exporter at least be included as a
"testing" addon in trunk? That way you will make it easier for more people
to try it out and report bugs. It will also save time of the many who
already use it for godot. If the old one has code that no one wants to
touch with a stick and is too big, even if written in better style - it is
useless to the end users. The end user does not care about the style of
programming. They care if the exporter creates compatible files. Here you
have an actual game engine developer with huge community support not being
able to get it in trunk. Heck people are already using his collada exporter
more than the one with blender.
On 10 Feb 2016 22:37, "Julian Eisel"  wrote:

> Suggest we don't pollute this mailing list with discussions about
> who's capable of writing the better Collada Importer/Exporter? This
> isn't helpful at all.
>
> Cheers,
> - Julian -
>
> On 10 February 2016 at 23:21, Thomas Dinges  wrote:
> > Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> >> -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.
> >
> > "Refused to add it"?
> >
> > https://developer.blender.org/T41071
> > Reading that ticket^^ tells a whole different story.
> > Reasonable code review comments were made, but then we got no further
> > response.
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Request for Collada Importers/Exporters

[Gaia Clary]

Hi.

If you have a working Collada Importer and/or a corresponding Exporter
for Blender and if you think your solution works better than Blender's
own Collada Module, then please tell us where we can take
a look at your solution.

Please can you make it easy for us to find the code by providing
either reliable URL's (which point to the sources YOU mean)
or even better create a new Maniphest for that.

Or if just provide some answers to the
open questions in

https://developer.blender.org/T41071

I am sure you will get attention :)
thanks
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Gaia Clary]

Can the Collada Fans please move over to the other thread that i just 
opened?
I believe the FBX guys will be thankful for that :)

thanks

On 11.02.2016 00:30, Todor Imreorov wrote:
> Until the code clean up can this exporter at least be included as a
> "testing" addon in trunk? That way you will make it easier for more people
> to try it out and report bugs. It will also save time of the many who
> already use it for godot. If the old one has code that no one wants to
> touch with a stick and is too big, even if written in better style - it is
> useless to the end users. The end user does not care about the style of
> programming. They care if the exporter creates compatible files. Here you
> have an actual game engine developer with huge community support not being
> able to get it in trunk. Heck people are already using his collada exporter
> more than the one with blender.
> On 10 Feb 2016 22:37, "Julian Eisel"  wrote:
>
>> Suggest we don't pollute this mailing list with discussions about
>> who's capable of writing the better Collada Importer/Exporter? This
>> isn't helpful at all.
>>
>> Cheers,
>> - Julian -
>>
>> On 10 February 2016 at 23:21, Thomas Dinges  wrote:
>>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
 -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.
>>> "Refused to add it"?
>>>
>>> https://developer.blender.org/T41071
>>> Reading that ticket^^ tells a whole different story.
>>> Reasonable code review comments were made, but then we got no further
>>> response.
>>>
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Mike Erwin]

Juan Linietsky  wrote:

> Julian, I'm only proposing a way to solve the following problems:
>
> 1) Not having an alternative to FBX
> 2) Not having a fully working Collada exporter that supports the same as
> the FBX. You can test mine any time, try exporting a complex scene from
> Blender with skeletal animations, blend shapes, multiple actions, etc.
> 3) Not having a fully working Collada importer. You can test mine any time
> and see how it imports Blender, OpenCollada, XSI, Lightwave, etc. with all
> the above mentioned features.
> 4) Not having the huge bloat that represents using OpenCollada in Blender.
>
>
I no longer use Collada but am very excited about solutions to 1 and 4
above. They benefit all Blenderheads. For those who *do* use Collada, we
might as well get it right (the 2 & 3 part).

Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Jacob Merrill]

I am neutral here, and I just want to say, that if we are having disputes
over how to move forward, someone on each side should write out a document,
and point at code etc, and make this less a argument, and more of a
checklist.

>From what I gather, collada and fbx are both valid to import/export.
On Feb 10, 2016 3:39 PM, "Gaia Clary"  wrote:

> Can the Collada Fans please move over to the other thread that i just
> opened?
> I believe the FBX guys will be thankful for that :)
>
> thanks
>
> On 11.02.2016 00:30, Todor Imreorov wrote:
> > Until the code clean up can this exporter at least be included as a
> > "testing" addon in trunk? That way you will make it easier for more
> people
> > to try it out and report bugs. It will also save time of the many who
> > already use it for godot. If the old one has code that no one wants to
> > touch with a stick and is too big, even if written in better style - it
> is
> > useless to the end users. The end user does not care about the style of
> > programming. They care if the exporter creates compatible files. Here you
> > have an actual game engine developer with huge community support not
> being
> > able to get it in trunk. Heck people are already using his collada
> exporter
> > more than the one with blender.
> > On 10 Feb 2016 22:37, "Julian Eisel"  wrote:
> >
> >> Suggest we don't pollute this mailing list with discussions about
> >> who's capable of writing the better Collada Importer/Exporter? This
> >> isn't helpful at all.
> >>
> >> Cheers,
> >> - Julian -
> >>
> >> On 10 February 2016 at 23:21, Thomas Dinges  wrote:
> >>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
>  -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.
> >>> "Refused to add it"?
> >>>
> >>> https://developer.blender.org/T41071
> >>> Reading that ticket^^ tells a whole different story.
> >>> Reasonable code review comments were made, but then we got no further
> >>> response.
> >>>
> >>> ___
> >>> Bf-committers mailing list
> >>> Bf-committers@blender.org
> >>> http://lists.blender.org/mailman/listinfo/bf-committers
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Todor Imreorov]

Fbx is broken. Exporting baked animation armature from maya works in unity.
Importing to blender it is a mess. I can share a few fbx files if you are
interested
On 10 Feb 2016 23:53, "Jacob Merrill"  wrote:

> I am neutral here, and I just want to say, that if we are having disputes
> over how to move forward, someone on each side should write out a document,
> and point at code etc, and make this less a argument, and more of a
> checklist.
>
> >From what I gather, collada and fbx are both valid to import/export.
> On Feb 10, 2016 3:39 PM, "Gaia Clary" 
> wrote:
>
> > Can the Collada Fans please move over to the other thread that i just
> > opened?
> > I believe the FBX guys will be thankful for that :)
> >
> > thanks
> >
> > On 11.02.2016 00:30, Todor Imreorov wrote:
> > > Until the code clean up can this exporter at least be included as a
> > > "testing" addon in trunk? That way you will make it easier for more
> > people
> > > to try it out and report bugs. It will also save time of the many who
> > > already use it for godot. If the old one has code that no one wants to
> > > touch with a stick and is too big, even if written in better style - it
> > is
> > > useless to the end users. The end user does not care about the style of
> > > programming. They care if the exporter creates compatible files. Here
> you
> > > have an actual game engine developer with huge community support not
> > being
> > > able to get it in trunk. Heck people are already using his collada
> > exporter
> > > more than the one with blender.
> > > On 10 Feb 2016 22:37, "Julian Eisel"  wrote:
> > >
> > >> Suggest we don't pollute this mailing list with discussions about
> > >> who's capable of writing the better Collada Importer/Exporter? This
> > >> isn't helpful at all.
> > >>
> > >> Cheers,
> > >> - Julian -
> > >>
> > >> On 10 February 2016 at 23:21, Thomas Dinges 
> wrote:
> > >>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> >  -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.
> > >>> "Refused to add it"?
> > >>>
> > >>> https://developer.blender.org/T41071
> > >>> Reading that ticket^^ tells a whole different story.
> > >>> Reasonable code review comments were made, but then we got no further
> > >>> response.
> > >>>
> > >>> ___
> > >>> Bf-committers mailing list
> > >>> Bf-committers@blender.org
> > >>> http://lists.blender.org/mailman/listinfo/bf-committers
> > >> ___
> > >> Bf-committers mailing list
> > >> Bf-committers@blender.org
> > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > >>
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Juan Linietsky]

Collada exporter is here:

https://github.com/godotengine/godot/tree/master/tools/export/blender25/io_scene_dae

The only limitation it has, which I believe could be fixed quite easily but
should not be a blocker, is that to export skeletons, you have to make the
mesh a child of the skeleton.
This is because, unlike Blender, game engines do skeletal transform locally
before transforming by world matrix so this makes it more compatible and
all the content more coherent. Collada importers have not much of a problem
with this. Please remember this exporter is meant for game engines, since
Collada is not very useful as exchange format between 3D DCCs.

Collada importer is here, and it's very compatible.. Godot uses it to load
full scenes from any existing DCC fine, with full skeletal animation, morph
targets, etc. I have found that some exporters have small inconsistencies
with the format, so this importer is custom made and very, very very
tolerant. Trust me, hundreds of Godot users use it and it hasn't failed in
a long time.

https://github.com/godotengine/godot/tree/master/tools/collada

However, it's written in C++ and I don't really have any knowledge about
Blender internals. Godot manages scenes in a very similar way to Blender so
adapting it should be easy, but I honestly don't have time to learn Blender
internals. Still, I offer help about understanding and adapting the
codebase to anyone willing to do it. If you guys could adapt OpenCollada to
Blender, this should be a lot easier.

Cheers! And sorry if I sounded offensive in previous threads, please
understand that the currently situation and having to create and maintain a
parallel exporter so Blender users could export to Godot did not make me
happy, specially when Ton cried today on twitter about how FBX was evil and
we have no open standards to export to game engines...

Juan





On Wed, Feb 10, 2016 at 8:35 PM, Gaia Clary 
wrote:

> Hi.
>
> If you have a working Collada Importer and/or a corresponding Exporter
> for Blender and if you think your solution works better than Blender's
> own Collada Module, then please tell us where we can take
> a look at your solution.
>
> Please can you make it easy for us to find the code by providing
> either reliable URL's (which point to the sources YOU mean)
> or even better create a new Maniphest for that.
>
> Or if just provide some answers to the
> open questions in
>
> https://developer.blender.org/T41071
>
> I am sure you will get attention :)
> thanks
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Todor Imreorov]

Lets make a table comparison of what works in the two exporters and what
doesnt. If the one with more green checks is being abandoned over bike
shedding arguments and lack of interest, then at least  the user can still
get it from godot developers. Alot who dont know about it will ofcourse use
blender's lacking implementation and continue to hold the belief that
blender or the format is broken
On 10 Feb 2016 23:53, "Mike Erwin"  wrote:

> Juan Linietsky  wrote:
>
> > Julian, I'm only proposing a way to solve the following problems:
> >
> > 1) Not having an alternative to FBX
> > 2) Not having a fully working Collada exporter that supports the same as
> > the FBX. You can test mine any time, try exporting a complex scene from
> > Blender with skeletal animations, blend shapes, multiple actions, etc.
> > 3) Not having a fully working Collada importer. You can test mine any
> time
> > and see how it imports Blender, OpenCollada, XSI, Lightwave, etc. with
> all
> > the above mentioned features.
> > 4) Not having the huge bloat that represents using OpenCollada in
> Blender.
> >
> >
> I no longer use Collada but am very excited about solutions to 1 and 4
> above. They benefit all Blenderheads. For those who *do* use Collada, we
> might as well get it right (the 2 & 3 part).
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Juan Linietsky]

> I no longer use Collada but am very excited about solutions to 1 and 4
> above. They benefit all Blenderheads. For those who *do* use Collada, we
> might as well get it right (the 2 & 3 part).
>
>

Game engines such as Unity or Unreal would happily support Collada if
Blender exports it properly. They already do in a limited way so helping
them out should not be a problem.
Worst case, I can give them a hand with that, otherwise we run into the
horrible situation where open source game engines can't use FBX due to
license restrictions.
As I develop Godot, i don't want this situation to get worse.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Jim Cantley]

All due respect guys, can this go to a thread somewhere? I have some four or so 
pages of emails about FBX/collada currently, it's drowning everything else in 
my email out. 

Not meaning to single anyone out, I just want to jump in and kindly request 
that this be taken somewhere more suitable for detailed discussion rather than 
having it continue through what seems like a format for broader discussion. 



From: bf-committers-boun...@blender.org  on 
behalf of Todor Imreorov 
Sent: Wednesday, February 10, 2016 7:06 PM
To: bf-blender developers
Subject: Re: [Bf-committers] Request for Collada Importers/Exporters

Lets make a table comparison of what works in the two exporters and what
doesnt. If the one with more green checks is being abandoned over bike
shedding arguments and lack of interest, then at least  the user can still
get it from godot developers. Alot who dont know about it will ofcourse use
blender's lacking implementation and continue to hold the belief that
blender or the format is broken
On 10 Feb 2016 23:53, "Mike Erwin"  wrote:

> Juan Linietsky  wrote:
>
> > Julian, I'm only proposing a way to solve the following problems:
> >
> > 1) Not having an alternative to FBX
> > 2) Not having a fully working Collada exporter that supports the same as
> > the FBX. You can test mine any time, try exporting a complex scene from
> > Blender with skeletal animations, blend shapes, multiple actions, etc.
> > 3) Not having a fully working Collada importer. You can test mine any
> time
> > and see how it imports Blender, OpenCollada, XSI, Lightwave, etc. with
> all
> > the above mentioned features.
> > 4) Not having the huge bloat that represents using OpenCollada in
> Blender.
> >
> >
> I no longer use Collada but am very excited about solutions to 1 and 4
> above. They benefit all Blenderheads. For those who *do* use Collada, we
> might as well get it right (the 2 & 3 part).
>
> Mike Erwin
> musician, naturalist, pixel pusher, hacker extraordinaire
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Juan Linietsky]

Jim,

   With all due respect, feel free to add a filter to your inbox to avoid
this mailing list from filling it.


On Wed, Feb 10, 2016 at 9:12 PM, Jim Cantley 
wrote:

> All due respect guys, can this go to a thread somewhere? I have some four
> or so pages of emails about FBX/collada currently, it's drowning everything
> else in my email out.
>
> Not meaning to single anyone out, I just want to jump in and kindly
> request that this be taken somewhere more suitable for detailed discussion
> rather than having it continue through what seems like a format for broader
> discussion.
>
>
> 
> From: bf-committers-boun...@blender.org 
> on behalf of Todor Imreorov 
> Sent: Wednesday, February 10, 2016 7:06 PM
> To: bf-blender developers
> Subject: Re: [Bf-committers] Request for Collada Importers/Exporters
>
> Lets make a table comparison of what works in the two exporters and what
> doesnt. If the one with more green checks is being abandoned over bike
> shedding arguments and lack of interest, then at least  the user can still
> get it from godot developers. Alot who dont know about it will ofcourse use
> blender's lacking implementation and continue to hold the belief that
> blender or the format is broken
> On 10 Feb 2016 23:53, "Mike Erwin"  wrote:
>
> > Juan Linietsky  wrote:
> >
> > > Julian, I'm only proposing a way to solve the following problems:
> > >
> > > 1) Not having an alternative to FBX
> > > 2) Not having a fully working Collada exporter that supports the same
> as
> > > the FBX. You can test mine any time, try exporting a complex scene from
> > > Blender with skeletal animations, blend shapes, multiple actions, etc.
> > > 3) Not having a fully working Collada importer. You can test mine any
> > time
> > > and see how it imports Blender, OpenCollada, XSI, Lightwave, etc. with
> > all
> > > the above mentioned features.
> > > 4) Not having the huge bloat that represents using OpenCollada in
> > Blender.
> > >
> > >
> > I no longer use Collada but am very excited about solutions to 1 and 4
> > above. They benefit all Blenderheads. For those who *do* use Collada, we
> > might as well get it right (the 2 & 3 part).
> >
> > Mike Erwin
> > musician, naturalist, pixel pusher, hacker extraordinaire
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Juan Linietsky]

Todor, did you try importing in Godot the same armature exported from Maya
using OpenCollada plugin?


On Wed, Feb 10, 2016 at 8:58 PM, Todor Imreorov  wrote:

> Fbx is broken. Exporting baked animation armature from maya works in unity.
> Importing to blender it is a mess. I can share a few fbx files if you are
> interested
> On 10 Feb 2016 23:53, "Jacob Merrill"  wrote:
>
> > I am neutral here, and I just want to say, that if we are having disputes
> > over how to move forward, someone on each side should write out a
> document,
> > and point at code etc, and make this less a argument, and more of a
> > checklist.
> >
> > >From what I gather, collada and fbx are both valid to import/export.
> > On Feb 10, 2016 3:39 PM, "Gaia Clary" 
> > wrote:
> >
> > > Can the Collada Fans please move over to the other thread that i just
> > > opened?
> > > I believe the FBX guys will be thankful for that :)
> > >
> > > thanks
> > >
> > > On 11.02.2016 00:30, Todor Imreorov wrote:
> > > > Until the code clean up can this exporter at least be included as a
> > > > "testing" addon in trunk? That way you will make it easier for more
> > > people
> > > > to try it out and report bugs. It will also save time of the many who
> > > > already use it for godot. If the old one has code that no one wants
> to
> > > > touch with a stick and is too big, even if written in better style -
> it
> > > is
> > > > useless to the end users. The end user does not care about the style
> of
> > > > programming. They care if the exporter creates compatible files. Here
> > you
> > > > have an actual game engine developer with huge community support not
> > > being
> > > > able to get it in trunk. Heck people are already using his collada
> > > exporter
> > > > more than the one with blender.
> > > > On 10 Feb 2016 22:37, "Julian Eisel"  wrote:
> > > >
> > > >> Suggest we don't pollute this mailing list with discussions about
> > > >> who's capable of writing the better Collada Importer/Exporter? This
> > > >> isn't helpful at all.
> > > >>
> > > >> Cheers,
> > > >> - Julian -
> > > >>
> > > >> On 10 February 2016 at 23:21, Thomas Dinges 
> > wrote:
> > > >>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> > >  -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.
> > > >>> "Refused to add it"?
> > > >>>
> > > >>> https://developer.blender.org/T41071
> > > >>> Reading that ticket^^ tells a whole different story.
> > > >>> Reasonable code review comments were made, but then we got no
> further
> > > >>> response.
> > > >>>
> > > >>> ___
> > > >>> Bf-committers mailing list
> > > >>> Bf-committers@blender.org
> > > >>> http://lists.blender.org/mailman/listinfo/bf-committers
> > > >> ___
> > > >> Bf-committers mailing list
> > > >> Bf-committers@blender.org
> > > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > > >>
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Todor Imreorov]

Juan - i havent tried maya's collada exporter yet, but i will tomorrow.
Why, is it broken on purpose? My point was that blender fails miserably at
importing fbx animation even when baked on a deform armature
On 11 Feb 2016 00:19, "Juan Linietsky"  wrote:

> Todor, did you try importing in Godot the same armature exported from Maya
> using OpenCollada plugin?
>
>
> On Wed, Feb 10, 2016 at 8:58 PM, Todor Imreorov 
> wrote:
>
> > Fbx is broken. Exporting baked animation armature from maya works in
> unity.
> > Importing to blender it is a mess. I can share a few fbx files if you are
> > interested
> > On 10 Feb 2016 23:53, "Jacob Merrill" 
> wrote:
> >
> > > I am neutral here, and I just want to say, that if we are having
> disputes
> > > over how to move forward, someone on each side should write out a
> > document,
> > > and point at code etc, and make this less a argument, and more of a
> > > checklist.
> > >
> > > >From what I gather, collada and fbx are both valid to import/export.
> > > On Feb 10, 2016 3:39 PM, "Gaia Clary" 
> > > wrote:
> > >
> > > > Can the Collada Fans please move over to the other thread that i just
> > > > opened?
> > > > I believe the FBX guys will be thankful for that :)
> > > >
> > > > thanks
> > > >
> > > > On 11.02.2016 00:30, Todor Imreorov wrote:
> > > > > Until the code clean up can this exporter at least be included as a
> > > > > "testing" addon in trunk? That way you will make it easier for more
> > > > people
> > > > > to try it out and report bugs. It will also save time of the many
> who
> > > > > already use it for godot. If the old one has code that no one wants
> > to
> > > > > touch with a stick and is too big, even if written in better style
> -
> > it
> > > > is
> > > > > useless to the end users. The end user does not care about the
> style
> > of
> > > > > programming. They care if the exporter creates compatible files.
> Here
> > > you
> > > > > have an actual game engine developer with huge community support
> not
> > > > being
> > > > > able to get it in trunk. Heck people are already using his collada
> > > > exporter
> > > > > more than the one with blender.
> > > > > On 10 Feb 2016 22:37, "Julian Eisel" 
> wrote:
> > > > >
> > > > >> Suggest we don't pollute this mailing list with discussions about
> > > > >> who's capable of writing the better Collada Importer/Exporter?
> This
> > > > >> isn't helpful at all.
> > > > >>
> > > > >> Cheers,
> > > > >> - Julian -
> > > > >>
> > > > >> On 10 February 2016 at 23:21, Thomas Dinges 
> > > wrote:
> > > > >>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> > > >  -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.
> > > > >>> "Refused to add it"?
> > > > >>>
> > > > >>> https://developer.blender.org/T41071
> > > > >>> Reading that ticket^^ tells a whole different story.
> > > > >>> Reasonable code review comments were made, but then we got no
> > further
> > > > >>> response.
> > > > >>>
> > > > >>> ___
> > > > >>> Bf-committers mailing list
> > > > >>> Bf-committers@blender.org
> > > > >>> http://lists.blender.org/mailman/listinfo/bf-committers
> > > > >> ___
> > > > >> Bf-committers mailing list
> > > > >> Bf-committers@blender.org
> > > > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > > > >>
> > > > > ___
> > > > > Bf-committers mailing list
> > > > > Bf-committers@blender.org
> > > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Juan Linietsky]

Maya's default Collada exporter is broken on purpose too. You have to use
the OpenCollada plugin

On Wed, Feb 10, 2016 at 9:27 PM, Todor Imreorov  wrote:

> Juan - i havent tried maya's collada exporter yet, but i will tomorrow.
> Why, is it broken on purpose? My point was that blender fails miserably at
> importing fbx animation even when baked on a deform armature
> On 11 Feb 2016 00:19, "Juan Linietsky"  wrote:
>
> > Todor, did you try importing in Godot the same armature exported from
> Maya
> > using OpenCollada plugin?
> >
> >
> > On Wed, Feb 10, 2016 at 8:58 PM, Todor Imreorov 
> > wrote:
> >
> > > Fbx is broken. Exporting baked animation armature from maya works in
> > unity.
> > > Importing to blender it is a mess. I can share a few fbx files if you
> are
> > > interested
> > > On 10 Feb 2016 23:53, "Jacob Merrill" 
> > wrote:
> > >
> > > > I am neutral here, and I just want to say, that if we are having
> > disputes
> > > > over how to move forward, someone on each side should write out a
> > > document,
> > > > and point at code etc, and make this less a argument, and more of a
> > > > checklist.
> > > >
> > > > >From what I gather, collada and fbx are both valid to import/export.
> > > > On Feb 10, 2016 3:39 PM, "Gaia Clary" 
> > > > wrote:
> > > >
> > > > > Can the Collada Fans please move over to the other thread that i
> just
> > > > > opened?
> > > > > I believe the FBX guys will be thankful for that :)
> > > > >
> > > > > thanks
> > > > >
> > > > > On 11.02.2016 00:30, Todor Imreorov wrote:
> > > > > > Until the code clean up can this exporter at least be included
> as a
> > > > > > "testing" addon in trunk? That way you will make it easier for
> more
> > > > > people
> > > > > > to try it out and report bugs. It will also save time of the many
> > who
> > > > > > already use it for godot. If the old one has code that no one
> wants
> > > to
> > > > > > touch with a stick and is too big, even if written in better
> style
> > -
> > > it
> > > > > is
> > > > > > useless to the end users. The end user does not care about the
> > style
> > > of
> > > > > > programming. They care if the exporter creates compatible files.
> > Here
> > > > you
> > > > > > have an actual game engine developer with huge community support
> > not
> > > > > being
> > > > > > able to get it in trunk. Heck people are already using his
> collada
> > > > > exporter
> > > > > > more than the one with blender.
> > > > > > On 10 Feb 2016 22:37, "Julian Eisel" 
> > wrote:
> > > > > >
> > > > > >> Suggest we don't pollute this mailing list with discussions
> about
> > > > > >> who's capable of writing the better Collada Importer/Exporter?
> > This
> > > > > >> isn't helpful at all.
> > > > > >>
> > > > > >> Cheers,
> > > > > >> - Julian -
> > > > > >>
> > > > > >> On 10 February 2016 at 23:21, Thomas Dinges  >
> > > > wrote:
> > > > > >>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> > > > >  -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.
> > > > > >>> "Refused to add it"?
> > > > > >>>
> > > > > >>> https://developer.blender.org/T41071
> > > > > >>> Reading that ticket^^ tells a whole different story.
> > > > > >>> Reasonable code review comments were made, but then we got no
> > > further
> > > > > >>> response.
> > > > > >>>
> > > > > >>> ___
> > > > > >>> Bf-committers mailing list
> > > > > >>> Bf-committers@blender.org
> > > > > >>> http://lists.blender.org/mailman/listinfo/bf-committers
> > > > > >> ___
> > > > > >> Bf-committers mailing list
> > > > > >> Bf-committers@blender.org
> > > > > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > > > > >>
> > > > > > ___
> > > > > > Bf-committers mailing list
> > > > > > Bf-committers@blender.org
> > > > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > > >
> > > > > ___
> > > > > Bf-committers mailing list
> > > > > Bf-committers@blender.org
> > > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > > >
> > > > ___
> > > > Bf-committers mailing list
> > > > Bf-committers@blender.org
> > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > >
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/li

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

[Todor Imreorov]

So autodesk is quite happy when people think collada is broken so they
should use fbx. Blender devs are kind of helping things stay that way when
working on fbx over collada. Why not rerelease the format with another name
when importers and exporters are fixed? Call it fbx2 and people will think
its better hahah
On 11 Feb 2016 00:31, "Juan Linietsky"  wrote:

> Maya's default Collada exporter is broken on purpose too. You have to use
> the OpenCollada plugin
>
> On Wed, Feb 10, 2016 at 9:27 PM, Todor Imreorov 
> wrote:
>
> > Juan - i havent tried maya's collada exporter yet, but i will tomorrow.
> > Why, is it broken on purpose? My point was that blender fails miserably
> at
> > importing fbx animation even when baked on a deform armature
> > On 11 Feb 2016 00:19, "Juan Linietsky"  wrote:
> >
> > > Todor, did you try importing in Godot the same armature exported from
> > Maya
> > > using OpenCollada plugin?
> > >
> > >
> > > On Wed, Feb 10, 2016 at 8:58 PM, Todor Imreorov 
> > > wrote:
> > >
> > > > Fbx is broken. Exporting baked animation armature from maya works in
> > > unity.
> > > > Importing to blender it is a mess. I can share a few fbx files if you
> > are
> > > > interested
> > > > On 10 Feb 2016 23:53, "Jacob Merrill" 
> > > wrote:
> > > >
> > > > > I am neutral here, and I just want to say, that if we are having
> > > disputes
> > > > > over how to move forward, someone on each side should write out a
> > > > document,
> > > > > and point at code etc, and make this less a argument, and more of a
> > > > > checklist.
> > > > >
> > > > > >From what I gather, collada and fbx are both valid to
> import/export.
> > > > > On Feb 10, 2016 3:39 PM, "Gaia Clary" <
> gaia.cl...@machinimatrix.org>
> > > > > wrote:
> > > > >
> > > > > > Can the Collada Fans please move over to the other thread that i
> > just
> > > > > > opened?
> > > > > > I believe the FBX guys will be thankful for that :)
> > > > > >
> > > > > > thanks
> > > > > >
> > > > > > On 11.02.2016 00:30, Todor Imreorov wrote:
> > > > > > > Until the code clean up can this exporter at least be included
> > as a
> > > > > > > "testing" addon in trunk? That way you will make it easier for
> > more
> > > > > > people
> > > > > > > to try it out and report bugs. It will also save time of the
> many
> > > who
> > > > > > > already use it for godot. If the old one has code that no one
> > wants
> > > > to
> > > > > > > touch with a stick and is too big, even if written in better
> > style
> > > -
> > > > it
> > > > > > is
> > > > > > > useless to the end users. The end user does not care about the
> > > style
> > > > of
> > > > > > > programming. They care if the exporter creates compatible
> files.
> > > Here
> > > > > you
> > > > > > > have an actual game engine developer with huge community
> support
> > > not
> > > > > > being
> > > > > > > able to get it in trunk. Heck people are already using his
> > collada
> > > > > > exporter
> > > > > > > more than the one with blender.
> > > > > > > On 10 Feb 2016 22:37, "Julian Eisel" 
> > > wrote:
> > > > > > >
> > > > > > >> Suggest we don't pollute this mailing list with discussions
> > about
> > > > > > >> who's capable of writing the better Collada Importer/Exporter?
> > > This
> > > > > > >> isn't helpful at all.
> > > > > > >>
> > > > > > >> Cheers,
> > > > > > >> - Julian -
> > > > > > >>
> > > > > > >> On 10 February 2016 at 23:21, Thomas Dinges <
> blen...@dingto.org
> > >
> > > > > wrote:
> > > > > > >>> Am 10.02.2016 um 21:41 schrieb Juan Linietsky:
> > > > > >  -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.
> > > > > > >>> "Refused to add it"?
> > > > > > >>>
> > > > > > >>> https://developer.blender.org/T41071
> > > > > > >>> Reading that ticket^^ tells a whole different story.
> > > > > > >>> Reasonable code review comments were made, but then we got no
> > > > further
> > > > > > >>> response.
> > > > > > >>>
> > > > > > >>> ___
> > > > > > >>> Bf-committers mailing list
> > > > > > >>> Bf-committers@blender.org
> > > > > > >>> http://lists.blender.org/mailman/listinfo/bf-committers
> > > > > > >> ___
> > > > > > >> Bf-committers mailing list
> > > > > > >> Bf-committers@blender.org
> > > > > > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > > > > > >>
> > > > > > > ___
> > > > > > > Bf-committers mailing list
> > > > > > > Bf-committers@blender.org
> > > > > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > > > >
> > > > > > ___
> > > > > > Bf-committers mailing list
> > > > > > Bf-committers@blender.org
> > > > > > http://lists.blender.org/mailman/listinfo/bf-committers
> > > > > >
> > > > > __

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

[Campbell Barton]

> -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?

There are problems in the code that were requested to be resolved and
you didn't respond or make any effort to fix.

If you provide code "as-is" for someone else to fix, that OK too - but
let us know this is work you no longer maintain and provide as a
starting point for others.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Campbell Barton]

On Thu, Feb 11, 2016 at 11:04 AM, Juan Linietsky  wrote:
> Collada exporter is here:
>
> https://github.com/godotengine/godot/tree/master/tools/export/blender25/io_scene_dae

Reading over this code I've found some bugs... one I mentioned in
review already,
others are potential issues or just misunderstandings of the API.

If you're interested to submit this we can do code-review for
inclusion in Blender,
however I made the offer before to do initial review + inclusion and
you didn't respond,
so I assumed you had no interest to work on the code.

That you ignore feedback and tell us its perfectly stable when there
is some very obvious mistake in the code I mention in initial review -
makes me unsure if this is worth the effort to persist with.
Unless we want to take over maintaining entirely.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

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

[Juan Linietsky]

Hi Campbell, it is still maintained, and the latest version is in the
github repo linked above.
Godot community often contributes improvements to it, but i don't think
having duplicated code is a good idea.
If Blender includes it officially in the stable release, I'll remove it
from Godot repo and do changes (and request contributions) in Blender's
repo I guess.

On Wed, Feb 10, 2016 at 11:04 PM, Campbell Barton 
wrote:

> > -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?
>
> There are problems in the code that were requested to be resolved and
> you didn't respond or make any effort to fix.
>
> If you provide code "as-is" for someone else to fix, that OK too - but
> let us know this is work you no longer maintain and provide as a
> starting point for others.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Juan Linietsky]

Sorry, shouldn't have ignored the feedback, but at the time I was told the
code would just be around and only included into blender if someone was
interested about using it.. and instead was asked for feedback into how to
improve the existing blender Collada exporter. As I thought the existing
exporter was going to be fixed I lost interest in pushing mine.


On Wed, Feb 10, 2016 at 11:26 PM, Campbell Barton 
wrote:

> On Thu, Feb 11, 2016 at 11:04 AM, Juan Linietsky 
> wrote:
> > Collada exporter is here:
> >
> >
> https://github.com/godotengine/godot/tree/master/tools/export/blender25/io_scene_dae
>
> Reading over this code I've found some bugs... one I mentioned in
> review already,
> others are potential issues or just misunderstandings of the API.
>
> If you're interested to submit this we can do code-review for
> inclusion in Blender,
> however I made the offer before to do initial review + inclusion and
> you didn't respond,
> so I assumed you had no interest to work on the code.
>
> That you ignore feedback and tell us its perfectly stable when there
> is some very obvious mistake in the code I mention in initial review -
> makes me unsure if this is worth the effort to persist with.
> Unless we want to take over maintaining entirely.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Request for Collada Importers/Exporters

[Campbell Barton]

On Thu, Feb 11, 2016 at 1:56 PM, Juan Linietsky  wrote:
> Sorry, shouldn't have ignored the feedback, but at the time I was told the
> code would just be around and only included into blender if someone was
> interested about using it.. and instead was asked for feedback into how to
> improve the existing blender Collada exporter. As I thought the existing
> exporter was going to be fixed I lost interest in pushing mine.

No worries, perhaps a misunderstanding - I didn't mean to be
dismissive here, I expected important (noisy) changes would be made in
the branch then we could have in `addons_contrib`
(which comes in daily builds).

Heres review of the latest Collada addon from your repo. noticed
blocking as well as some suggested changes.

https://developer.blender.org/D1787
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Proposal: include Python's distutils

[Alex Fraser]

Hi all,

Recently I wanted to install some packages with pip to use with Blender's
Python. I thought I should be able to do it like this:

 PYTHON=blender-2.76b-linux-glibc211-x86_64/2.76/python/bin/python3.4
 wget https://bootstrap.pypa.io/get-pip.py
 ${PYTHON} get-pip.py
 ${PYTHON} -m pip install -r requirements.txt

But get-pip.py fails with "ImportError: No module named 'distutils'" [1].
The suggested alternative is to remove Blender's Python so it falls back to
the system install [2]. But this doesn't work for me: it causes Blender to
stop working at all, crashing with "ImportError: No module named
'encodings'" [3]. I think this indicates a version incompatibility (3.4.2
vs 3.4.3).

Campbell says the inclusion of the Python executable is fairly recent.
Given that Python itself is now included, I think it makes sense to include
distutils. A quick test on my system suggests it would add about 160k to
the size of package.

Cheers,
Alex

-- 
Alex Fraser
Software Engineer
VPAC Innovations Pty. Ltd.

[1]: http://www.pasteall.org/64483/python
[2]:
https://www.blender.org/api/blender_python_api_2_61_0/info_tips_and_tricks.html#bundled-python-extensions
[3]: http://www.pasteall.org/64484
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers