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

[Edward Amani]

Hi,

this could be part of the deps graph planning as a "bigger project", of 
course, but it is interesting.

Amani.

On 12/5/2012 2:29 AM, Chad Fraleigh 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>