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

[José Ricarte]

Hi, about  plugins  system support  in Blender, IMHO, as user.  I think 
it would be  to consider  a milestone in future versions.

-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
------------------------------------------------------------------------