Hi folks
Starting to look into ‘node-based’ interfaces (i.e Shake, Maya’s hypergraph, numerous shader editors, etc), but am phased as how to even thing about starting to code something like this.
I’ ve looked into commercial toolkits like "Tom Sawyer Software"s SDKs, but was wondering if anyone knew of any non-commerical projects, as well as any example code/ideas/suggestions?
Many thanks in advance …
Dan
Are you interested in an SDK just for drawing the nodes and connections? Or more of a complete package?
Also, which gui framework are you developing under?
Ummm. I guess I was looking for the whole package, but an SDK for just the drawing part would help a lot. Do you have any suggestions?
Also, I’m developing using GLUT at the mo, but will probably be using MFC for Win32 with maybe the option WxWindows or QT (if I can afford it!!) for other platforms.
It’s actually quite easy to code a node based interface, it’s just gets very complicated.
I was developing a node based component in vb.net some time ago, you can really take advantage of OOP to create new custom nodes.
This is a small flash movie of where I was at (never did finish it)
http://www.spot4d.co.uk/0x47/Capacity5.swf
All I done was created a class that represents a BaseNode. This class would have properties that defined the look and action of the node. There would be a function (that would be overidable) in there that executes code.
I simply inherited this BaseNode class override the function that execute code to make it do custom things.
Most the hard part was developing a way to drag and click the nodes around the workspace, which was made easier using standard windows events (even easier for me because I was using vb.net events )
I also made custom events that detected when I was ‘connecting’ two nodes together.
Once you have the foundations of the BaseNode coded out, the rest is childs play
Very interesting ‘Geespot’, just what I was looking for!! Cheers. I’m going to code it in C++ not VB, but I guess the theory’s the same?
Also, out of interest how did you make the nodes moveable, and how did you code those neat ‘connections’/'Noodle’s (as Shake calls them!)?
Dan
To make the nodes moveable took me a while to work out. What I did though, was in my BaseNode class (thats the class that represents a node as a whole, similiar to BaseObject in C4D SDK), I stored and X and Y location, and it’s width and height.
Then using an VB.NET MouseMove event ([i]an event that's called everytime the mouse has moved, i'm not familiar with c++ window programming so not sure how this is done[/i]) I would loop through an array of BaseNodes, and execute a boundary checking function in there. It was more of brute force check, but it worked. It might have been slower with many many nodes but I never got that far to test it out.
Note - I can't remember [i]exactly[/i] how I did it, Don't have the code available no more
PSUEDO(ish) EXAMPLE
class BaseNode
{
_x
_y
_width
_height
public:
Bool CheckBoundary(MousePositionX, MousePointionY);
void SetLocation(X,Y);
}
BaseNode::CheckBoundary(MousePositionX, MousePointionY)
{
if(
(MousePositionX > _x) && (MousePositionX < (_x+_width)) &&
(MousePositionX > _y) && (MousePositionY < (_y+_height))
)
return TRUE
return FALSE;
}
BaseNode::SetLocation(X,Y)
{
_x=X;
_y=Y;
}
// General MouseMove event
OnMouseMove(MouseX,MouseY)
{
for (int i =0; i < NodeCount; i++)
{
if(NodeArray[i].CheckBoundary(MouseX,MouseY))
{
// ** Mouse cursor is in Nodes boundary **
// Check to see if mouse button is held down
if( MouseButtonPressed())
{
// Set new location of node
NodeArray[i].SetLocation(MouseX,MouseY);
}
}
}
// Update workspace
RefreshDisplay();
}
The RefreshDisplay() method would simply loop through all the nodes, draw all the nodes using the BaseNode location variables (Infact I had a function BaseNode::Draw()) then I would draw the connecting lines.
The Connecting lines are simple bezier curves with 2 control points arranged so there’s no wierd bending effects.
http://www.cubic.org/~submissive/sourcerer/bezier.htm
That’sa good explanation
Cheers ‘GeeSpot’. The events look very similar to the event callbacks in GLUT, so looks do-able. Also, I did look at some similar bezier stuff, so I’m glad I was on the right track.
On the side of backend node processing, I’ve had a good look thru the Shake SDK docs, and again it looks possible, if a tad daunting!! Never mind, must just get my head down to coding now …
Excellent work, many thanks again!!
I’m in the process of developing a node based system myself right now, but I’m not done yet so I can’t give you any definate answers on how to do it! (^_^)
I started by creating a node class, followed by an attribute class. Attributes can be connected to one another, with each node having one input and multiple outputs. So in the attribute class I have a pointer to the attribute that is the input (if any), and a list of pointers to attributes that the attribute is being output to. The functions to create and destroy these connections is pretty straightforward.
To get started, I wouldn’t worry too much about drawing pretty lines. Maya just draws a line from the center of the input node to the center of the output nodes, and then draws the node boxes on top of all the lines. Houdini draws these lines by moving vertically out of the nodes for a few pixels, draws a quarter circle, moves horizontal to the other node’s input, draws another quarter circle, and then draws horizontally into the node. If they overlap enough, you don’t draw the entire quarter circle (or you scale it down so it fits - the radius is half the horizontal distance between the two nodes’ connection points).
I actually haven’t even tried attacking the graphical interface for my system yet. I do everything through a command line. I wanted my system to be command driven, so I developed that first. Much faster to code up than a graphical interface. This way I can test my system out first and get some basic functionality in place before even having to worry about windows, drawing code, the display loop, mouse events, etc. I can send the commands for “createNode nodeOne; createNode nodeTwo; createAttr -ln “AttrOne” nodeOne; createAttr -ln “AttrTwo” nodeTwo; connectAttr “nodeOne.attrOne” “nodeTwo.attrTwo”; listAttrConnections nodeOne;” and get a printout of all the connections.
This way I can test creating attrs and nodes, deleting attrs and nodes, making and breaking connections, iterating through the DAG graph, etc, etc all before tackling the graphics side of things. And if you think about it, all the above needs to be written anyways before doing the graphical node manipulation interface, so might as well make sure it is well tested before adding more code on top. You don’t even need to go as far as I did and write a command line parser to your app; you can just call the commands from within your main () function and either use the debugger to make sure everything is working, or display status messages with printf or ostreams to the command shell to check your program’s progress.
And of course once you get these basics down, you still have to have a system that checks which attrs are dirty, build a list of what attrs need to be calculated in what order, and then traverse the graph in the correct order, solving as you go. That’s likely a bit of a pain. Haven’t done it yet myself.
Good Luck,
Michael Duffy
You’re a Maya user, right? 
And of course once you get these basics down, you still have to have a system that checks which attrs are dirty, build a list of what attrs need to be calculated in what order, and then traverse the graph in the correct order, solving as you go. That’s likely a bit of a pain. Haven’t done it yet myself.
The way I understand dirty bits best is the push/pull method (I’m pretty sure this is how Maya does it…)
Each attribute (input and output) has a ‘dirty’ bit
Each attribute also has a cached value.
If an input is changed, it’s attribute’s dirty bit is set to 1, this is then PUSHED through the network:
Whenever an input attribute’s dirty bit is set to 1, any output attributes in that node have their dirty bits set to 1 (2)
Whenever an output attribute’s dirty bit is set to 1, each of the inputs connected from it have their dirty bits set to 1. (1)
That will filter the dirty bit down through all of the nodes that would be affected by the changed attribute…
Data is then PULLED from the bottom of the network:
When data is requested from an output, if it’s dirty bit is 0, it returns the current cached value. If the dirty bit is 1, it asks the node to calculate the value of the output. (5) When it gets this, it stores it in it’s cache, sets it’s dirty bit to 0, and returns the cached value
To calculate the output, the node asks the input attributes for their values (6), does what it needs to to, and then returns it
In an input attribute, when it is asked for it’s value, it it’s dirty bit is 0, it returns it’s cached value. Otherwise it requests the data from the output it’s connected to. (4)
There is one major upgrade to this system as described - dependencies - this affects step (1) above… Each output to a node is told which inputs it depends on. In doing this, each input finds out which output(s) depend on it. Then, when an input changes, it only needs to send the dirty bit to the outputs that depend on it.
Anyway, I hope this makes sense - if not, I’ve probably missed out a step or not explained it properly… I talked Dan through a basic version of this yesterday (or was it monday?)…
On a side note, Shake does this a slightly different way… Instead of having dirty bits, it has what it calls a ‘cacheId’ - this is a compressed string representation of all of the nodes above it in the tree. Whenever a node’s contents are requested, it figures out it’s cacheId by asking each of it’s inputs for their cacheIds and then combining them with it’s own parameters. If the cacheId it generates is the same as the one stored internally, and it has a cached image stored, then it just passes that one out rather than calculating it all again…
MDuffy and Hugh: Great info! I’m working with an “open” node-based system right now and have alwayed wondering how the big apps got around the problems I face with my app. It makes a lot more sense now.
-b
The other thing that might be interesting to think about (warning: advanced feature ahead) is upstream flows as well as down…
This is another shake thing...
Remember how I said that, in Shake, image plugs have loads of chldren plugs. Well, not all of these are down-stream plugs - some of them send data UP the tree…
Why's that?
Well, I can only describe it with relation to image nodes - I can’t think straight off how you’d use it with straight data, but I’m sure someone could come up with a use…
Shake uses a PULL/PUSH method (thanks to Angus for the terminology… I just wish I could do the hand signals at the same time!) - don’t confuse this with the PUSH/PULL that I was talking about earlier - they are completely different… I’m just calling them the same thing to confuse you.
At the bottom of the tree, Shake PULLs the image data. This passes a chain reaction up the tree, as each node needs the data from the previous node to generate its own output. However, when the reaction gets to the top of the tree, instead of sending the data straight back down again, it PULLs on an upstream plug, asking from data from further down the tree. This data includes what the current time is, which part of the image is wanted, which colour channels are wanted. This chain flows back down to the bottom of the tree, where the main output has to PUSH some data back up. So for any node, it has to ask for an image (PULL), but before it gets the image, it is asked about some specs for the image that it wants, and it has to answer (PUSH)
If that made no sense to you, I'll try to explain....
Let's say we've got the following nodes
FileIn ("/some/path/to/an/image.tif")
|
Blur (20)
|
Reorder (“rg00”)
When the users says that they want to look at the output of the Reorder node (which switches around channels - in this case it says to keep red and green, and make blue and alpha 0), The following happens:
GUI: Pull on Reorder’s output image buffer
Reorder: Pull on Blur’s output image buffer
Blur: Pull on FileIn’s output image buffer
FileIn: Pull on Blur’s mask plug
Blur: Pull on Reorder’s mask plug
Reorder: Pull on the GUI’s mask plug
GUI: Return “rgba” to Reorder
Reorder: See “rgba”, AND it with “rg00”, and return “rg00” to Blur
Blur: Return “rg00” to FileIn
FileIn: Pass red and green channels of image to Blur
Blur: Do the blur on the red and green channels
Reorder: Pass the image straight through to the GUI
GUI: Display the image
So you see that the saving here is that the Blur node is only doing half the work it would be if it was blurring all four channels, because it already knows that the blue and alpha channels will be lost somewhere below it. Each node has to take the inputs from below, modify them depending on what it’s parameters are and pass them on up the tree.
Anyway, hope that was interesting… it’s a nice way of doing it - passing dirty bits around would still work - you’d just have to think of each node as having lots of connections (and you’d have to make sure that you’d got dependencies implemented, as it could get really messy otherwise!)
Wooooaaahhh!!! Loads of info!! Cheers Hugh & MDuffy.
Just had a thought tho. Is any of this state-based? As in with Shake or Maya, you’re always producing a final image at the end of the graph, however with AI or logic, there surely must be a result, whether it be state or the current anim frame/position?
I’m guessing there’s no major difference, but just wondered what any thought …
Atually you can achieve this without the pull approach if you think in terms of dirty attributes and not dirty nodes. In your example you had one set of attributes holding image data, and another holding a channel mask. So your dependency flow actually looks like this if you think in terms of attributes
GUI.image
|
Reorder.image
|
Blur.image
|
FileIn.image
|
FileIn.mask
|
Blur.mask
|
Reorder.mask
|
GUI.mask
Notice in the above where FileIn.image requires data from FileIn.mask. All the other connections are external node-to-node connections, but the FileIn.image and FileIn.mask are an internal dependency. The FileIn node probably requires inputs of “mask” and “filename”, and has an output of “image”. The “image” output is dependent on clean values from mask and filename, so these two internal dependencies are created by default when the FileIn node is created.
You can accomplish the same as a Push paradigm by simply propogating dirty flags, and then letting the pull approach actually get the data. For example, let’s say that the file on disk changes, thus invalidating the FileIn node (the FileIn node would probably have to be set up in some timed polling event so it could check if the files on disk changed). The FileIn node sets its filename attribute to dirty. Since there is a dependency connection from filename to image, the image attribute is set to dirty. When the FileIn.image attribute is dirtied, it passes the dirty state along its connections, so Blur.image is set to dirty. This in turn sets Reorder.image to dirty, which sets GUI.image to dirty.
Now the next time the GUI is updated, it sees that it needs to recalculate the image so it calls on Reorder.image to give it data, which asks Blur for its image node, etc on down the line. Once it gets to FileIn, the cached value for mask is used because that attribute wasn’t dirtied this time around, so it should still be valid.
And yes, Hugh. I do happen to be a Maya user… 
And no I’m not copying their MEL syntax… completely… hehehe…
Cheers,
Michael Duffy
Just found this and thought it might be useful http://www.boost.org/libs/graph/doc/index.html
Has anyone used this? It looks a lot easier than rollign your own. (you still have to deal with your own GUI callbacks though).
Simon
Cheers Simon, will look into that when I get some time! Busy, busy, busy - too many project finishing!! 
Ta
Dan
I’ve thought about this for awhile sometime ago, and I thought it’d be fun and easy to implement. I’m just wondering, are you guys all doing this for fun in your own projects?
Hi orgee
Why I’m looking into this is for a crowd sim project I’m working on at the moment, and I’m thinking of designing a node network so that users can code the ‘brains’ of the agents of the simulation.
I’d be interested to hear your views/ideas on node-based programming and designing a similar system to material networks (ie. HyperShade in Maya, Houdini’s procedural coding interace, etc) …