On Tue, Dec 4, 2012 at 11:49 PM, José Ricarte <rica...@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 <ch...@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@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > -- > ------------------------------------------------------------------------ > > > www.aixalanca.com <http://www.aixalanca.com> > > José Ricarte Fillola > 677 666 359 > > rica...@aixalanca.com <mailto:rica...@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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers