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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers