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
