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

[kk]

On Dec 5, 2012 2:38:33 AM, Chad Fraleigh wrote:
> On Tue, Dec 4, 2012 at 11:26 PM, Brecht Van Lommel
> <> brechtvanlommel at 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 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



I am not sure if this would be a new idea to Blender, but Houdini has couple neat tricks. For example it provides inline coding nodes both for cpp and for high performance VEX lang. The codes in the nodes are compiled at runtime when the nodes are cooked.  Maybe there could be a dedicated modifier that can compile the code in real time (even possible?) . While this sure is neither a replacement for a plugin nor for dedicated modifier, it might be able to help with protoyping and or even with distribution if the modifier data could be loaded.


k