Dev:Source/Node Editor/Composite/Expand Node System

Introduction

The goal of this project is to expand the current Blender node system to the level that is comparable with the commercial procedural image processing software Filter Forge.
The Filter Forge website can be found at: [1]

Filter Forge uses a node system that is similar to what Blender has right now to build its filters. It has total of 82 nodes under 8 distinct categories:

8 Adjustment nodes
12 Channel
5 External
6 Gradients
7 Noise
4 Patterns
10 Processing
12 Curve ops
11 Curves
5 Controls

After investigating the usefulness of each node and comparing them to the nodes already existing in Blender, we have decided to implement the following 41 nodes:

5 External nodes
6 Gradients nodes
7 Processing nodes
12 Curve ops nodes
11 Curves nodes

Problems

One of the most important problems that arose during our research is the implementation of Curve and Curve ops nodes.
The Curve and Curve ops nodes are rather unique type of nodes that Filter Forge has. Instead of operating over an image they operate over one special type of data called curve input. A curve input represents a curve function in a specified range and is often used to provide inputs for other nodes to define their behaviors.
We believe Curve and Curve ops nodes are what differentiate FilterForge's node system from Blender's current node system.

Why do we think Curve/Curve ops nodes are important

To illustrate the usefulness of Curve and Curve ops nodes, we will use the Wartorn filter from FilterForge made by Richard Bartlett as an example.
The Wartorn filter, created by combining a series of different noise nodes with Curve nodes as inputs, its effect is illustrated in the right image.
In the image on the left side, we removed all the input Curve nodes for the noise nodes (there were four of them) and replaced with an integer.

Image done without the use of Curve node

Image done with Curve node

As can be seen in the images, without the help of Curve nodes, the effects are not comparable.

Problem

Since the curve input data type does not exist in Blender right now, if we are to introduce Curve and Curve ops nodes into Blender, the new data type has to be implemented as well.
However, after inspecting the Blender node system, we find out that most (if not all) of the composite nodes do not check the data type passed down from bNodeStack class,which means if a user passes a curve input data type to one of the existing nodes by mistake, it will either cause a wrong behavior or crash Blender.

Current implementation and future plans

We do not have a final solution to the possible drawback of implementing a new curve input data type right now as we are still consulting the Blender Dev team for permission on some modifications we would like to make.

Current implementation

We have recently redesigned our implementation for curve node, currently we are using the following API for curve nodes: A struct Curve to store the curve data

struct Curve {
	float start, end, min, max;
	short *points;
};

Two constructor functions to initial the struct:

Curve *Curve_new();

Curve *Curve_new_dimension(float start, float end, float min, float max);

And four functions for the node writer to manipulate curve(more to be added later):

void Curve_free(Curve *curve);
float Curve_get_point_value(Curve *curve, float index);
void Curve_set_point_value(Curve *curve, float index, float value);
void Curve_set_muti_value(Curve *curve, float fromindex, float toindex, float value);

Future Plans

The current implementation of curve nodes are very flawed. Since none of the existing node is aware of the introduction of struct Curve, so if anyone to push a Curve struct onto BnodeStack->data it will most likely cause malfunction. The ideal solution should only allow connections in the GUI to be made between inputs and outputs in matched format, meaning Curve outputs to Curve inputs, image outputs to image inputs. In order to achieve this, some revisions on all the existing composite nodes will definitely be needed (adding a check on the input bNodeStack->datatype), as well as some possible revision on the node GUI generation end (preventing user to connect two unmatched type output/input).

The implementation of the rest of the nodes will not require any changes to the Blender code structure. The nodes can be implemented simply by using the data structures that are already in place.

Progress

Both our project and this page are still under construction, please check back later!