[Bf-committers] Some Ideas for a Blender Plugin System

Vicente Carro vicentecarro at gmail.com
Tue Nov 3 15:25:13 CET 2015


Hi,

>From a pipeline td point of view I would say keeping (and
extending/improving) the current python API is the best option.
When you need to do something during production usually you almost
have no time and for those situations python is the way to go. You
just do a prototype on the fly then you clean it a little bit and
ready to go. If you try to do that with C/C++ well, in the best case
scenario, is going to take way more time. And that if you are lucky.
For us is way more usable something that is fast to develop and slow
to execute than the reverse.

Regards

Vicente



On 3 November 2015 at 14:14, Sybren A. Stüvel <sybren at stuvel.eu> wrote:
> Hi all,
>
> On Sun, Nov 01, 2015 at 04:11:54PM +0100, Martin Felke wrote:
>> Hi, today i was thinking a bit about possible approaches on how to
>> add a C / C++ Plugin system to blender.
>
> There seems to be a thing missing: a good overview of the pros and
> cons of having a C/C++ plugin system at all.
>
>> - dynamic compilation of module sources via Python / CFFI or LLVM,
>> as in OSL Nodes
>
> Help me understand - how is this going to work, when most 3D artists
> don't have a compiler installed? Are we going to ship Blender with a
> compiler?
>
>> - source distribution of plugins is C / C++  + some py Wrapper for
>> autocompile or binary distribution in case no compiler is present
>
> So you want to ship binaries as well? Then why bother with
> autocompilation? Or is that only used while developing plugins?
>
>
> On Mon, Nov 02, 2015 at 10:06:08PM +0100, matmenu wrote:
>> Sounds really good and needed as reality showed that being GPL is
>> not enough to make adding functionality easy. Looks also like all
>> devs loose to much time reviewing, so c/c++ plugins are a really
>> good solution to avoid so many modifiers die in the patch tracker or
>> be limited to some custom builds like in past year.
>
> Then again, creating a good plugin system is not easy, so that too
> will take up developers time, which would otherwise be put into
> feature development and bug fixing. Furthermore, creating and
> maintaining an accurate dependency graph of the plugins will also take
> time (and we'll forget to maintain those, causing bugs).
>
> All in all I can see a few cons:
>
> - Blender will become more complex, as not only its functionality
>   needs to be maintained, but also the "plumbing" required for the
>   plugin system.
>
> - Development will become more complex, as different permutations of
>   loaded/unloaded plugins have to be tested.
>
> - Mistakes in a C/C++ plugin can cause all kinds of crashes of Blender
>   itself. In contrast, an exception in a Python script is relatively
>   easy to catch & handle without sacrificing Blender's stability.
>
> - Compilation of the code into libraries is difficult, as it is very
>   unlikely that all plugin developers will have access to all OSses
>   that Blender runs on.
>
> Sorry for this depressing post, but I think we should discuss whether
> we want such a plugin system at all, before diving into the specifics.
>
> Cheers,
> --
> Sybren A. Stüvel
>
> http://stuvelfoto.nl/
> http://stuvel.eu/
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


More information about the Bf-committers mailing list