[Bf-committers] Separating node systems

Tom M letterrip at gmail.com
Tue Feb 15 09:07:02 CET 2011

Have you looked at the game logic node proposal?


Might be worth looking at, I think that some of the work was done for
it all ready.


On Mon, Feb 14, 2011 at 10:33 PM, j.bakker at atmind.nl <j.bakker at atmind.nl> wrote:
> Currently all node systems are implemented in the space_node (design-time)
> and in the blenkernel/node.c (execution-time) and the makesdna
> DNA_node_types.h (datastore/database).
> There are 3 node systems and a new one is on its way:
>  * Compositor
>  * Material
>  * Texture
>  * [[http://phonybone.planetblender.org/ | Particles]]
> The node system has initially designed for the compositor. Since then, the
> Material and Texture node systems have been implemented on top of the
> original code. The Materials and Textures node system uses different styles
> when executing.
> Data needed for design-time and data needed for execution-time are both
> stored in the same structure. As the different node systems have different
> execution styles it is not clear what data is meant for what node system.
> The new compositor design changes totally the initial implementation of the
> node system execution (node.c).
> What I want to propose is to start separating the different node systems
> execution and the data.
> For the compositor I will start developing in a separate library
> ("bf_compositor"). During execution of the node system, the design-time
> node system is converted to the execution-time node system. This
> execution-time node system is then calculated. The implementation of the
> other node systems I will leave unchanged inside the (node.c).
> This way I want to ensure several things:
>  - Keep the code clean; the node systems are technically not the same, so
> why place them in a single file.
>  - Make sure that UI improvements can be done with limited impact to the
> execution engine. The user interface will evolve in a different speed than
> the execution engine.
>  - During conversion (design-time to execution-time) the node system can
> be optimized and modified
>    * Different node grouping based on the internal behavior of nodes.
>    * Filter node and bokeh blurs can be converted to an optimized
> convolution node.
>    * Data type conversion are added to the node system.
>  - In my opinion CPP is better in handling the needed complexity
> (balancing algorithms & graph execution optimizations). but I don't like
> the idea of placing CPP code inside the blenkernel library.
> Reusable components like opencl driver manager, or the new memory manager
> will be placed inside the blender-kernel or blender-library.
> Jeroen.
> --------------------------------------------------------------------
> mail2web.com - Microsoft® Exchange solutions from a leading provider -
> http://link.mail2web.com/Business/Exchange
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list