[Bf-committers] Meeting minutes - nodal logic proposal

[Benoit Bolsee]

Yes I've checked XSI's ICE. I didn't check Cinema 4D's Xpresso but the
possibility of reusing node graphs for different entity is something I
definately intend to support with the concept of retargetting: first you
get references to objects by digging into the hierarchy (could be group
or armature or parent/child hierarchy). This must be done only once by
using several getReference nodes. Then you pass these references to the
nodes as data input. The node function must use this reference as the
target for actions instead of the default node parent object.

I thought about caching and you're right, this must be a feature of the
engine. In list of options that a node pin must support for best
generality, a definately useful one is caching. By implementing
appropriate stamps and flags, the engine can determine automatically if
a DAG node must be reevaluated or not by walking recursively through the
DAG. Keeping a copy to the previous result is really easy with Python
reference so that no special care must be taken when writing the node
function.  This must be an option as nodes that produce random data will
not use caching of course.

The list of options that a node pin must support is really a key concept
of this design. So thanks for sharing your idea about caching. Here is
the list that I have so far:
- pin direction: input/ouput
- pin type: push/pull
- push input options:
  - trigger node for execution: Y/N
  - queue data: Y/N
  - immediate function on data delivery: Y/N
  - reset after node execution: Y/N
- push ouput options:
  - automatic pulse generation after node execution: Y/N
- pull data input options:
  - set to constant value: Y/N
  - caching: Y/N
- pull data output options:
  - data source: object/function
  - update data inputs before evaluating the function: Y/N
  - caching: Y/N

There are also some options at node level: type of node: DAG node, push
logic, variable, compound node input/output port, and some options at
link level: delay, timestamp.

/Benoit

On Date: Fri, 6 Nov 2009 08:06:52 -0500, Charles Wardlaw
<cwardlaw at marchentertainment.com> wrote 
> > It's not
> > a new subject, many Nodal programmation systems exist already. I've 
> > tried to extract the essense of these systems and with the 
> help of the 
> > robotics experts at the KUL who have already implemented 
> node systems 
> > like that, I came up with this design.
> 
> Well, I like what I see. ^_^ I'm sure you've checked out 
> XSI's ICE by  
> now--that's one of the most impressive systems I've ever 
> seen. You can  
> do everything through nodes, from building new tools to sculpting  
> particle systems. The Pidgeon Impossible guy even showed how 
> he added  
> drag to vertices facing the trailing edge of character geometry,  
> faking the old 2D motion blur cheat on fast-moving objects.
> 
> If you haven't checked out Cinema 4D's Xpresso, it bears a look too.  
> There's this one brilliant feature where the node network can 
> be made  
> to reference objects by relative hierarchies. In other words, 
> you can  
> copy the left arm's node network to the right, and as long as the  
> hierarhies are the same it'll just work, saving a TD a lot of time.
> 
> There's a lot of inspiration out there. ^_^
> 
> > An important aspect of my system is that there will be no hidden 
> > processing such as automatic detection of result nodes, etc. If you
> > want
> > to evaluate a DAG, just build it and connect its result node(s) to a
> > push logic node to trigger it's evaluation. This node can 
> be triggered
> > by a time node (for realtime applications) or by a 'start' 
> pulse that
> > Blender could generate to evaluate the graph.  After that, 
> each node  
> > of
> > the DAG can implement caching logic as they want, it's up to the  
> > creator
> > of the node.
> 
> As long as the start pulse is somewhat automatic that sounds great.  
> Maybe there can be a setting that sets nodes in the network 
> to use the  
> start pulse-- a button or switch or something.
> 
> Pushing data through a DAG is fine for games (I actually like 
> pushing  
> more for certain things because push networks don't have to be  
> acyclic), but for a character rig it's generally overkill and you go  
> through a lot of wasted computation. In a pull network the 
> system can  
> rely on smart caching to skip out on *so* many calculations. 
> It's one  
> of the few things Maya got right. :)
> 
> So as far as that caching goes, I don't think it should be up to the  
> node creator. Apart from that causing inconsistancy in how the nodes  
> work, there's no guarantee that node creators would cache things  
> properly. In Maya the values are cached at the attribute 
> level and the  
> nodes themselves are really just containers of those 
> attributes, with  
> logic for calculation and internal attribute dependency. 
> Makes custom  
> nodes a bit of a pain in the ass to write but it's the best system  
> I've seen so far.
> 
> Anyway I know that a lot of folks are excited about the flashy  
> features like smoke and SPH fluids, but the object nodes are 
> the best  
> news I could have heard all year as a character TD. No matter 
> how you  
> move forwards I wish you all the luck. Is there any non-code 
> help you  
> need at the moment?
> 
> ~ C
> 
> PS apologies for any spelling or grammar mistakes; this was hastily  
> typed on my phone :)
> 
>