[Bf-committers] Meeting minutes - nodal logic proposal

[Erwin Coumans]

Good point.

There is the Nodal Logic GUI (within Blender) and the logic run-time (within
the BGE for example).

A nodal logic run-time might be useful for other game engines,
so it would be interesting if the run-time can be implemented
modular/re-usable.
(even if some GPLv2 parts have to be replaced, it allows for some re-use).

Thanks,
Erwin






2009/11/5 Campbell Barton <ideasman42 at gmail.com>

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