[Bf-committers] Conversion to a dynamic/plugable modifier system

[Chad Fraleigh]

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