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 <dfeli...@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.fe...@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@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