[Bf-committers] Separating node systems
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.
> mail2web.com - Microsoft® Exchange solutions from a leading provider -
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers