Re: [Bf-committers] Conversion to a dynamic/plugable modifier system
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
Re: [Bf-committers] Conversion to a dynamic/plugable modifier system
On Tue, Dec 4, 2012 at 11:26 PM, Brecht Van Lommel brechtvanlom...@pandora.be wrote: 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. I knew (as a whole) it wouldn't be a trivial thing. But the general plan was to add some [API backward compatible] modifier framework/interface changes over time, and then convert an existing modifier or two to be in a self-contained module as a proof of concept and to work the kinks out. At some point after this making them actual run-time loadable plugins would be a next step. Just being modular could allow them to be compiled as a shard library and linked during standard blender compile time.. the plugin stuff would just be some linking glue added on (albeit not trivial in itself). And while in the long term it would certainly be cleaner and better to do the same for all the other legacy modifier code, technically they should still work as-is (if the new code checks what it needs first and falls through to old code on NULL hook functions and such). Of course once a couple are done and a basic example is laid down, then other developers could jump in and each try to convert other modifiers.. and if new issues are encounter in the more complex modifiers, at worse the change could reverted for those specific modifier(s) until more framework updates can be made to support it. The worse case scenario is that even if the end goal ends up a failure, in the effort the code would be made much more modular and code-coupling for them reduced and hopefully make later attempts easier. 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. -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Conversion to a dynamic/plugable modifier system
Hi, this could be part of the deps graph planning as a bigger project, of course, but it is interesting. Amani. On 12/5/2012 2:29 AM, Chad Fraleigh 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
Re: [Bf-committers] BBB Of topic but funny
Douglas, So the reason for this email was to say have a laugh at the fat kid who is walking funny? I highly doubt the kid posted the image himself so that others could laugh at him, so it seems mean-spirited to forward it to a group list in this way. Best to leave that to your Facebook friends. Maybe I'm overreacting but I'm a bit sensitive about bullying behavior. Harley ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Writing a Compositor node plugin?
Dan Eicher writes: Did you add your new files to cmake/scons so they get compiled linked? Dan Hi Is there any chance that the registering the new nodes goes through some old system of nodes? I can now compile without any errors however(maybe naturally) my node does not show up in the nodes in Blender. So I am suspecting that I am not able to register this new node in the system properly. k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Development Environments
While attempting to setup various environments in which I could edit/build/test source pulled from trunk, I came across some issues: The wiki directions for FreeBSD (http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/FreeBSD) are now incomplete (for trunk at least). Since blender now seems to require python 3.3 and [currently] FreeBSD's ports system only has up to 3.2, it would require the developer to manually compile and install the newer python first. Up through blender 2.64 still seems ok. The directions for Windows says to use Visual Studio 2008 and states that the 2010 version doesn't work. However they now have a 2012 version. So.. has anyone tried it with 2012 yet? If I try it, would it be obvious that it's broke (like a compile error), or something more subtle like blender crashes (or acts strange) when run? -Chad ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Writing a Compositor node plugin?
Is there any chance that the registering the new nodes goes through some old system of nodes? I can now compile without any errors however(maybe naturally) my node does not show up in the nodes in Blender. So I am suspecting that I am not able to register this new node in the system properly. I wrote a wiki page on a minimal node tutorial here: http://wiki.blender.org/index.php/User:Sobotka/Misc/Minimal_Node_Tutorial There is a minimal node-skeleton branch here: https://github.com/sobotka/blender/tree/node-skeleton Hope that helps someone a little... TJS ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Writing a Compositor node plugin?
On Dec 5, 2012 6:56:54 PM, Troy Sobotka wrote: Is there any chance that the registering the new nodes goes through some old system of nodes? I can now compile without any errors however(maybe naturally) my node does not show up in the nodes in Blender. So I am suspecting that I am not able to register this new node in the system properly. I wrote a wiki page on a minimal node tutorial here: http://wiki.blender.org/index.php/User:Sobotka/Misc/Minimal_Node_Tutorial There is a minimal node-skeleton branch here: https://github.com/sobotka/blender/tree/node-skeleton Hope that helps someone a little... TJS Hi Troy Thanks for the reply. This is better than what I could have hoped for. I wish I saw it couple days ago but in any case this is great. The old node coding page is obsolete so was little help to me. k ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
On Thu, Dec 6, 2012 at 11:43 AM, Chad Fraleigh ch...@triularity.org wrote: While attempting to setup various environments in which I could edit/build/test source pulled from trunk, I came across some issues: The wiki directions for FreeBSD (http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/FreeBSD) are now incomplete (for trunk at least). Since blender now seems to require python 3.3 and [currently] FreeBSD's ports system only has up to 3.2, it would require the developer to manually compile and install the newer python first. Up through blender 2.64 still seems ok. The directions for Windows says to use Visual Studio 2008 and states that the 2010 version doesn't work. However they now have a 2012 version. So.. has anyone tried it with 2012 yet? If I try it, would it be obvious that it's broke (like a compile error), or something more subtle like blender crashes (or acts strange) when run? -Chad FreeBSD devs will have to build and install python3.3, Since Blender sometimes uses newer versions of Python then Linux disto's provide, we have a section at the top of the linux build instructions [1] (Linking to troubleshooting page [2]). So the FreeBSD instructions could do something similar. As for Windows, I once had MSVC2010-Express working, but IIRC it couldn't link a debug build without MSVC2008 installed, MinGW had the same problem (python32_d.dll relied on it), So you may be able to get other configurations working but if you get strange linking errors its not something we're really able to support ATM. Blender is quite portable but if you use dependencies in our prebuilt lib/ dir - they can be picky with the configurations they work with. [1] http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Linux [2] http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/Linux/Troubleshooting#Compiling ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Development Environments
Hi, On Thu, Dec 6, 2012 at 1:43 AM, Chad Fraleigh ch...@triularity.org wrote: While attempting to setup various environments in which I could edit/build/test source pulled from trunk, I came across some issues: The wiki directions for FreeBSD (http://wiki.blender.org/index.php/Dev:2.5/Doc/Building_Blender/FreeBSD) are now incomplete (for trunk at least). Since blender now seems to require python 3.3 and [currently] FreeBSD's ports system only has up to 3.2, it would require the developer to manually compile and install the newer python first. Up through blender 2.64 still seems ok. There's not many people building on FreeBSD, so indeed this can get out of date. Any help keeping it updated is welcome, most of the active developers don't have FreeBSD installations. The directions for Windows says to use Visual Studio 2008 and states that the 2010 version doesn't work. However they now have a 2012 version. So.. has anyone tried it with 2012 yet? If I try it, would it be obvious that it's broke (like a compile error), or something more subtle like blender crashes (or acts strange) when run? The precompiled libraries (lib/ directory in svn) are specific to the visual studio version. We have 2008 libraries for everything, 2010 usually lags behind a bit, and no 2012 ones yet. I'm not sure about the compatibility between 2010 and 2012, but it might be that all libraries need to be rebuild specifically for 2012 to work. There might be compile errors when building too, but they're likely only minor problems, the big job is getting the precompiled libraries. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
