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

[Chad Fraleigh]

On Tue, Dec 4, 2012 at 11:49 PM, José Ricarte <ricarte at aixalanca.com> wrote:
> Hi, about  plugins  system support  in Blender, IMHO, as user.  I think
> it would be  to consider  a milestone in future versions.

Something specific to modifiers, or a generic one that does all the
work common to anything that might use plugins (e.g. scanning plugins
directory(s) and probing the so/dll's, a UI to list and allow
disabling/enabling specific ones)? Then it could be used for
modifiers, render engines, specialized [input] devices maybe, etc..

If so, this could be done independent (more or less) of changes needed
to support plugable modifiers.. Just getting the modifiers to a state
that they could be compiled and as pre-linked shared library modules
is a needed leap before actually being plugable and using such an
API/system.


-Chad

>
> -Ciriaco
>
> El 05/12/2012 8:26, Brecht Van Lommel escribió:
>> 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
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
> --
> ------------------------------------------------------------------------
>
>
> www.aixalanca.com <http://www.aixalanca.com>
>
> José Ricarte Fillola
> 677 666 359
>
> ricarte at aixalanca.com <mailto:ricarte at aixalanca.com>
>
> Parque Tecnológico Walqa, Edificio CEEI Aragón Desp.1
> Crtr. Zaragoza Km 67, 22197 Cuarte Huesca
> ------------------------------------------------------------------------
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers