Hi, As you have found from reading the code, Blender wasn't really designed with plugins in mind. Code for things like modifiers tends to be scattered over many files. I fear that making a C/C++ plugin system work is a far bigger project than you might think. Getting all the components like DNA/RNA/blenloader/UI/.. ready for this would be great but I don't think it's a feasible task for one developer.
Making Blender more modular is one of those things that should be tackled as a bigger project, like the 2.5 UI refactor or the planned dependency graph upgrade. For python we have some mechanisms to make extensions work, and I can imagine python modifier support being feasible to add using the bmesh python api. Brecht. On Wed, Dec 5, 2012 at 12:29 AM, Chad Fraleigh <[email protected]> wrote: > I've been looking into the idea of having blender support dynamic (and > thus plugable) modifiers. Right now it requires any new ones to be > merged into the base code and a new version of blender compiled and > released. If the Addons and python scripting required this overhead > then those contributions would likely have grown very slowly.. so > imagine what useful/cool modifiers others could create if not limited > to the normal blender development cycle (not to mention the needed > approvals that keep dozens of user-specific modifiers from being added > and cluttering up blender, but could also discourage useful ones due > the extra effort). > > Some possibilities being: > > * Adding a custom modifier for a large project (like those open > source movie initiatives) where utilizing the modifier stack reduces > overhead compared to running a script update to do the same (and is > reversible/togglable unlike most mesh scripts). > > * Override a built-in modifier with a better version. > > * Could allow early access to new bundled modifier(s) without the > instability of using an entire blender version while it is under new > development. This assumes the new modifier is compiled as a dynamic > module and the so/dll can be just copied (or something to this > effect). > > * Prototype new modifiers and testing/refining them before > contributing them as a bundled one. > > * Might help with implementing true python based modifiers. > Technically dynamic modifiers aren't required for python based ones, > but may have some common framework changes related to mapping ad-hoc > handlers. > > > I'm keeping a list of issues, ideas on required changes, and general > notes on a [semi-]private wiki. Here is it's current list of issues > that need to be accounted for: > > * A static compile-time ModifierType enumeration exists which has > values that are stored in the .blend files and must remain > predictable. With a dynamic system (in which arbitrary authors can > write their own modifiers at will) the potential loss of a central > Type ID would need to be accounted for. Perhaps a UUID based system in > this event. There is also a NUM_MODIFIER_TYPES constant used for a > static array allocation in > source/blender/blenkernel/intern/modifier.c. > > * Hard-coded modifier types are checked in various [non-modifier > specific] code to perform custom handling. For these few well-known > types this could still be used [statically], where the rest are > code-coupling free. Or ideally, there might be a better way to do it > and eliminate this coupling all together. > > * In source/blender/blenloader/intern/readfile.c conversions (e.g. > addresses remapped, cache clearing, version updates) are done for > several ModifierData references (for both object held modifier data > and the modifier list). This would need to be done by each modifier > directly via a hook function. > > * In source/blender/blenloader/intern/writefile.c referenced data > is written. This would need to be done by each modifier directly via a > hook function. > > * Most (or all) of the modifiers have a custom icon in the UI. A > hook to provide icon data would be useful. > > * There is RNA data for each modifier. Currently this is statically > defined in source/blender/makesrna/intern/rna_modifier.c. > > * It is documented when adding a modifier that > property_data_modifier.py needs to be updated to include a method of > the new modifier name. > > * Accessing fields of compiled internal blender structures may > break between blender versions. Limiting to a specific blender version > range, or using SDNA information to validate and/or access that data > in a portable way may be needed. > > > So now that all that is out of the way.. would anyone be offended if I > did work toward this goal? Was there someone already doing this who's > feet I would step on? In my vision it would ideally require inverting > the packaging of modifier related code (i.e. all code related to a > specific modifier being in that modifier C file [or modifier directory > if grouped that way] rather than being scattered in readfile, > writefile, rna_modifier, and other global "activity" files). > > > -Chad > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
