[Bf-committers] Meeting minutes - nodal logic proposal

[Campbell Barton]

regarding making a node system thats usable outside of blender...
- If it uses PyObjects Id assume it would use Mathutils
vectors/matix/quat/eul types too? (which also depends on arithb.c
internal blender math functions)
- if it uses python it may well use some of blenders python utility functions
- Registering nodes would work very nice via the same method as
registering menu's & panels (RNA registration)
- a UI for the nodes themself would probably make use of RNA to define
settings, and use RNA to draw buttons.
- Making a logic system like this Id assume would need to tie into BGE
data somewhat.

all the functions/apis mentioned above are GPLv2

All of this can be swapped out, on the other hand if you write a BGE
logic system it makes sense to use Mathutils & RNA for eg.

I'm not sure how this could work without a fair amount of energy into
making it portable, guess its up to whoever writes it.

On Thu, Nov 5, 2009 at 11:40 PM, Benoit Bolsee <benoit.bolsee at online.be> wrote:
> On Tue, 3 Nov 2009 09:43:13 -0500, Charles Wardlaw
> <cwardlaw at marchentertainment.com> wrote:
>> The nodal logic proposal sounds fantastic.
>
> Thanks, it's really in the design phase at the moment. The real trick is
> to find a generic way to build a node system that allows all types of
> graphical programmation: imperative programming, data flow programming,
> state engine, hierarchical state engine, protocol stack, etc.  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.
>
>> I guess my first question is: why is it limited to the game engine?
>> People have wanted object nodes for years, and that's basically what
>> this is.  Instead of keyboard or joystick input, all you really need
>> is the ability to either run input from a time node (already
>> noted on
>> the wiki page) or to have data pulled towards end result
>> nodes rather
>> than pushed on a frame-by-frame basis.
>>
>
> I'm getting requests to make the engine independent on the game engine.
> That should be possible but I haven't considered all the implications of
> that. The generic node that is at the center of the system is a
> combination of C++ container and python objects.
> Note that I want to provide push data flow (in my new design the logic
> input/ouput will become push input/output that will allow passing
> complex data and not just pulses) and pull data flow as you describe.
>
>> In Maya's dependency graph, for example, result nodes (nodes with no
>> further downstream dependencies) are checked to see if they're
>> "dirty".  If they are, then they call upstream sources and ask them
>> for data.  Nodes asked for data will check themselves,
>> calculate, and
>> cache their values, then send that data downstream.
>>
>
> 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.
>
>> If the nodal logic system were just a bit more generalized,
>> and didn't
>> rely on being in game engine mode to work, it could become a rigging
>> tool on par with Maya or XSI.  Add in the ability to enable /
>> disable
>> node traversals per object (possibly by wrapping nodes as a modifier
>> or something), and bam said the lady-- I have a much stronger
>> position
>> to argue from re: using Blender on a longer project at my studio.
>>
>> How will iteration over lists of objects be handled?  Or will it?
>>
>
> Quite simply I guess: someone just need to implement an enumerator node
> that push each object reference to a graph (encapsulated in a compound
> node for instance) which is looped back to the enumarator node. In other
> words, a graphical representation of a for loop. You could also
> implement some nodes that can operate on a single object or a list of
> objects. Inside each node there is a Python class, it's up to the node
> creator to code it right.
>
>> The other question I have is on this line:
>>
>> > Nodes may be distributed via the standard Blender install, or
>> > through open source libraries, or as closed-source licensed
>> routines
>> > from vendors.
>>
>> I doubt I'll ever fully understand how the GPL works in conjunction
>> with other software licenses, but wouldn't a closed-source node need
>> to be distributed as a C++ dynamic library, and as such not
>> be usable
>> with Blender due to a GPL violation?  Although, if Blender offered
>> some sort of script locking of compiled Python files (a la
>> MaxScript)
>> I could see people releasing paid node collections.
>>
>
> There are requests to develop the node system under a more liberal
> license than GPL. I am not against that idea but I haven't thought of
> any of its implications. I don't want to make my life too complicated
> before starting to code.  For example, I don't know if using Python is
> already a big drawback for non-GPL applications. But basically I am in
> favor of using a liberal license and will try to do it.
>
>> On 2009-11-02, at 9:49 PM, Alex Fraser wrote:
>>
>> > Hi,
>> >
>> > On Mon, Nov 2, 2009 at 4:48 AM, Ton Roosendaal <ton at blender.org>
>> > wrote:
>> >> - Benoit is working now on a new logic editing system for the GE:
>> >>
>> http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic
>> >>   Feedback welcome, design is in progress still.
>> >
>> > This looks great. I've used nodal logic in another game
>> engine before,
>> > and this proposal looks pretty much spot-on. I made a
>> couple of small
>> > changes to the wiki - I hope that's a good place to leave feedback.
>> >
>
> That's fine as long as you make you changes clearly identifiable.
> I've made progresses with the design and I will refresh the wiki with
> more detailed informations.
>
> /Benoit
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell