[Bf-committers] Separating node systems

[j.bakker at atmind.nl]

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