Blender is NOT an API – let alone its addons!

So… The other day, a guy spent hours on IRC insulting everyone about “Blender always breaking its API for mere renames”. Today, I got this comment below:

Castano

By breaking the existing script interface and changing the way curves work you have done a tremendous disservice to the people that need FBX export the most.

The fact that you got the funds to do this development in part from Unity Tech, but couldn’t be bothered to keep the old interface intact tells me you are not competent for this kind of work. You don’t understand the priorities, at all.

All you would’ve needed to do is to keep this path to the ASCII code intact:
“io_scene_fbx.export_fbx.save”

You could’ve had named the new export “save_bin” or “save_new”, or something like that, instead of keeping the name but breaking the interface nonetheless. Instead, you expect Unity (and everyone else) to clean up after you. The idea that you couldn’t just easily support this is nonsense.

Secondly, you don’t understand that people absolutely *need* the classic FCurve workflow. The new “baking” workflow is a nice feature, but only if it is optional. It can’t just replace the old workflow, and you shouldn’t be wasting everyone’s time by just changing this without being explicit about it.

I sincerely hope you can be bothered to keep the old ASCII export around, as long as you have these regressions in the binary exporter.

So, to that specific case first. I did not remove nor renamed io_scene_fbx.export_fbx.save, as everyone can see in that history page. So people could first stop talking about things they do not know about. Actually, I added new “bin” exporter in a new py file, with a new name.

Oh, and by the way, FBX export to Unity itself is not  broken at all, the only thing that is broken is a helper script in Unity itself that “hides” FBX exporting, making it looks as if Unity could directly open .blend files…

Nevertheless, it somehow broke that Unity’s script… What the heck? Seriously!

Let’s summarize:

  • Blender is free and open source;
  • Blender is an application, not a library;
  • Blender features several extensions (“addons”);
  • A third party society reuses an addon’s code (free and open source, if I may remind) to provide a feature in its own, closed and (at least for the full version) charged application;
  • Some changes are made in the free, open source addon, which somehow break that third party society’s product;
  • And some guys go reproaching the new, enhanced addon, yelling about breakings, raging over IRC (and, I guess, forums etc.), insulting, …

That does not make me happy. Not at all.

I’ve spent let’s say about three months of full-time work (probably more, actually) on the mess that’s called FBX. I would not wish that to my worst enemy. I’m already really sick of it, I’m pushing myself to complete the last pieces of needed features in new exporter (and importer) for 2.72… All those guys might gain is me dropping completely and definitively this task. They are free to take it over, since they are so wise ans full of knowledge and competent and super heroes and all that, I’d wish them good luck.

Now, back to the general case. Again, Blender is not a library. Let alone its addons!!!

We do have a few pieces of library inside Blender – some helper modules in python, PY RNA interface itself (how properties are defined, how operators are called, that kind of stuff). But! Operators themselves, data access themselves, RNA types themselves are not an API, in the sense they offer a direct acces to Blender’s internals, and Blender’s internals are not, were never meant to be, and will (probably) never be a library. Which means we do not have to twist and tweak to keep compatibility. We do try to do it, to some reasonable level, of course. We rarely do mere renames, and when we do, we keep old names (as deprecated) available at least for one or two releases. When we add a new parameter to a function, we try to make it optional as much as possible. But when we change how an operator works, or remove one, because it’s no more needed inside Blender or was doing bad work, we won’t keep it as a stupid “proxy” just for our py interface. Nor do we when we change data structures inside Blender.

As a side note, let me say you how much a mess can come from trying to keep compatibility – I had to experience it while working on (yes, again!) FBX format, and this does not give a nice result. At all.

So, as a final word: we do not need people which are just yelling, without actually doing anything, not even being constructive, which do not simply know how to talk with others! To those: STOP WAISTING OUR TIME!

Advertisements

10 thoughts on “Blender is NOT an API – let alone its addons!

  1. My deep apologies, you are correct, I’ve drawn a wrong conclusion from reading the export_fbx_bin interface, which indeed is separate. That was a tremendously stupid thing to do. From this I cannot see how you could’ve possibly broken the Unity interface.

    However, even if you didn’t break the interface, you still insist that you should be able to do it at your leisure, which shows a clear disregard to what users (and companies that support you) expect. You’d think a basic amount of diligence is in order, when really important parts of the user base are at risk of having their workflows broken.

    All the points regarding regressions and the instability of the API are still valid. I don’t understand how you can claim operators or types are not API, when it part of what is literally referred to as the Blender Python API:
    http://www.blender.org/documentation/blender_python_api_2_71_0/

    If your point is that this API is really what should be called a “private API”, then you should be clear about it and not claim that Blender has an API at all. Otherwise, people *will* be wasting their time and will eventually stop supporting you.

    • Apologies accepted. But still, I do not say we have the right to change API at our leisure. I do say we have the right to do it when it’s needed, and we can’t keep compatibility without making horrible tweaks. Note we are pretty good at this play, if you consider the amount of changes in Blender between each versions, and the amount of breaking changes among those… It’s not that high, really.

      And it’s also a matter of versioning: if you really want full stability, then you stick to a version (or set of versions) that match your needs.

      But imho, you can’t ask for evolution (new features, better performances, bug fixing, …) and a stable API altogether, this does not makes much sense to me. PY RNA is part of Blender, it evolves with it.

  2. Hello Bastien Montagne,

    First off I would like to thank you for all your hard work. I believe if it wasn’t for your efforts whether anyone invested money into or not we would not even have fbx today because of the Autodesk situation… So thank you despite the negativity of some.

    Second I wanted to apologize how I named my thread yesterday. But I repeatedly said it was unity’s internal conversion the problem:
    http://forum.unity3d.com/threads/blender-2-71-blend-to-unity-broken.254632/

    I specified that it was Unity’s own internal conversion scripts the problem. Somehow people always seem to blame Blender and it’s developers first.. I don’t understand why.

    One way or another I apologize with all my heart if this somehow helped feed the negativity. Since its easy for some to jump to conclusions..

    I am extremely grateful for your contributions and hope you keep on fighting making amazing efforts to make this possible for us who don’t even know programming to keep bringing our art into games with Blender. Thank you.

    Steve

    • Hi Steve, and thanks for that comment. I would never think reporting a problem is bad.

      To be honest, if I had been aware of that Unity script issue sooner, I might have try to fix it somehow (though since API itself did not change for 6.1, I do not really understand why it broke in the first place).

      But yes, things often go out of control, we can’t do much about it. In this case, it actually went rather off-topic (since an addon can for sure never be considered as an API, really). 😉

      As a side note, we also see one of our recurring issues here – we lack early testing users. I do not use Unity (not even Windows, have to start a VM each time I have to check something with Unity, so, eh…), and in general, coders do not have time (nor even knowledge) to make extensive tests of their work. We only have a few ‘test cases’ we consider to cover a fair amount of the subject, and that’s all. This can’t beat real-life daily usage of a tool!

      I did have some real-case users (gamedevs, etc.) early testing that new exporter, but none of them was using the ‘open .blend files’ feature of Unity I guess… :/

      • Next time I will still let you know first.

        I will get used to using and reporting in the bug tracker.

    • As it turns out, neither Unity nor Blender are to blame for the breakage, but rather our beloved Microsoft® Corporation:

      https://developer.blender.org/T40907

      It is truly sad that, in this day and age, when we jump to conclusions, we often don’t even stop to think about blaming Microsoft®. I believe we all learned something valuable today!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s