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

[matmenu]

Hi,
What he said. Ask the Luxcore devs doing the integration with Blender. 
Of course, if you manage to create a proog like a very basic array 
modifier (only make duplicates of selected mesh every 1 BU on the x axis 
with the number given by the user, should be easy to program) that work 
as efficiently memory-wise and as fast as the one shipped with Blender 
and with the methode you discribed would be a great proof that C/C++ API 
is not needed.
Cheers,
Mat

Am 03/11/2015 um 14:50 schrieb Yury Baranov:
> Dalai, I think addon system has pretty much limited functionality.
> 1. No modifiers
> 2. No procedural objects
> 3. No animation controllers
> Every place where addon can't be used and where plugin needs to be used
> have a lot of calculations and a lot of "data sending/recieving/sending
> back" as a task. I think that's the main reason.
> For example, Sapling will be better as a interactive procedural object. But
> it's an addon, with all limitations and problems on the board.
> And of course need to mention that every plugin basically need 4 versions
> (because of its binary nature) - Linux, FreeBSD, Windows(32/64), MacOS X.
>
> 2015-11-03 16:14 GMT+03:00 Dalai Felinto <dfelinto at gmail.com>:
>
>> Hi,
>>
>> I'm missing the main point here which would be, what is the advantage
>> of a C/C++ plugin system over the current Python addon interface?
>>
>> I'm currently developing an addon which relies on an external C++ SDK.
>> I got things working with ctypes and C API. It works pretty fine.
>>
>> Cheers,
>> Dalai
>> --
>> blendernetwork.org/dalai-felinto
>> www.dalaifelinto.com
>>
>>
>> 2015-11-03 10:59 GMT-02:00 Martin Felke <martin.felke at t-online.de>:
>>> Hi, today i wrote down a couple of more thoughts regarding a plugin
>>> system. As said earlier, those serve only as discussion starting points
>>> and are not meant yet as design principles made out of cement. :)
>>>
>>> Fat VS Slim Core
>>> ----------------
>>> - currently we have a fat core which contains all functionality
>>>    as monolith
>>> - hard to extend and to maintain because it might be everything depends
>>>    on everything else
>>> - idea: a slim, "bootloader like" core, which handles modules and
>>>    plugins registration and deregistration and serves as API Hub (of
>>>    existing modules)
>>> - modules are not standalone, they communicate via a central core API
>>>    Hub so they need the core as well
>>> - this way the core can track module APIs and provide a fallback (as
>>>    in exception handler) for missing code / functions (if module or
>>>    plugin is not present)
>>>
>>> Modules VS Plugins
>>> ------------------
>>> - need to distinguish between logical code separation (module) and
>>>    "physical" separation (plugin, as in shared library or dll)
>>> - group existing core functionality to modules (like, an editor could
>>>    be a module, or even a modifier)
>>> - base modules can be provided by "base" plugins, and extension modules
>>>    by external plugins
>>> - plugins can provide parts of modules, entire modules or multiple
>>>    modules (like nodes maybe, modifiers, new editors, or extensions to
>>>    editors)
>>>
>>> Dependencies
>>> ------------
>>> - do we want to have inter-plugin dependencies ? For a slim core
>>>    approach this might be necessary, if plugin A provides a module or
>>>    part where plugin B 's code depends on
>>> - else base modules should be moved / kept in the core, so everyone has
>>>    a minimum set of functionality without needing to use plugins
>>> - but in general, should plugin code only use Core API (the Hub ?)
>>>    would be better than "directly" accessing other plugins code, because
>>>    the core might provide the error fallback in case a plugin isnt
>>>    present
>>>
>>> Plugin properties
>>> -----------------
>>> - should be "hotpluggable", addable, removable during runtime
>>> - core needs to take care of disabling all related functionality when
>>>    module is unloaded (closing editor, saving for example)
>>> - each plugin needs an unique identifier of some kind, and versioning
>>>    info
>>> - if basis modules are in a plugin, this plugin needs to be flagged as
>>>    important or official or so
>>> - plugins could be classified by their purpose, like provides Module X,
>>>    extends Module Y, replaces Module Z, removes Module W
>>>
>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers