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 <[email protected]> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- ------------------------------------------------------------------------ www.aixalanca.com <http://www.aixalanca.com> José Ricarte Fillola 677 666 359 [email protected] <mailto:[email protected]> Parque Tecnológico Walqa, Edificio CEEI Aragón Desp.1 Crtr. Zaragoza Km 67, 22197 Cuarte Huesca ------------------------------------------------------------------------ _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
