[Bf-committers] Meeting minutes - nodal logic proposal

[Erwin Coumans]

I highly recommend checking out Kismet visual logic editor from the  
now free Unreal Editor.

Also Scratch, from http://scratch.mit.edu

Erwin

On Nov 6, 2009, at 13:08, "Benoit Bolsee" <benoit.bolsee at online.be>  
wrote:

> 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 :)
>>
>>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers