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

[Brecht Van Lommel]

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 <chadf at triularity.org> 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