[Bf-committers] Nodify logic , a GSOC project of idea list , need info

[Benoit Bolsee]

Wow, there's a lot of reactions on the Nodal Logic system, it shows the
big interest in Nodal system in general. Being the initiator of this
project, I'll give an overview of the current situation.

The project was initially funded by the KUL as the continuation of the
IK project. During the design phase, I tried to address all
programmation styles and all operational problems that arise when
executing logic graphs inside a specific context (mostly the BGE). The
result is a very generic node system that can be applied to almost
everything.  

The central idea is that a runtime engine instantiate and execute python
nodes. This means that all nodes exchange python data and implement
python callable functions.  I chose Python because it new it well and it
seemed a natural choice for Blender. But after reading the discussion
about sandboxing, I wonder if LUA wouldn't be a better choice.  Note
that performance-wise, my design should be very efficient so that
performance shouldn't be the main reason to switch to Lua.

Designing a node engine is one thing, implementing it in Blender with
its UI, storage and library system is another thing. I have identified
several development stages:

1) Pin and Node objects, including data management
2) graph objects: definition and hierarchy
3) Instantiation of graphs and nodes, loading of node library
4) Runtime engine to schedule and execute graphs and nodes
5) Automatic cache system for DAG.
6) Graphical representation of graphs and hierarchy, storage format
7) Graph editor
8) Node editor (interactive creation of nodes)
9) Definition of context: BGE API extension 
10) Extension to Blender (rigging...)

At this moment, only point 1 is implemented and part of point 3. The
code is available in the ge_nodelogic branch. The code is completely
independent of Blender and is under the zlib license. Unfortunately I
had to stop the project by lack of time. Currently the project is on
pause but I would love to see it restarting. It should be noted that the
budget was available at the KUL to fund this project for at least 6
months.  Maybe it's possible that someone else gets funded to continue
the project if there is a good candidate. 

Talking about GSoC, it is clear that this project exceeds by far the
GSoC scale, but some part of it could fit in GSoC. For example, the
runtime engine is a well defined piece of code for which I have clear
design. However, I don't know if a partial project is a good candidate
for GSoC: the runtime engine alone is of no use if there is no UI to
define the graphs.

As Dalai and Campbell suggested, there are other projects around the BGE
that could be good candidate for GSoC. Here are a few more ideas:

- automatic generation of bone physics shape for better physics
interaction with rigged character.
Skinned character do not update their physics shape as they deform
(except by calling the expensive reinstantiatePhysicsMesh). A simple
approximation can be done by automically creating simple physics shape
for the bone at the start of the game and making these shape child of
the bones for more realistic collisions with the environement.

- Various improvements around Bullet:
  - dynamic armatures: the BGE armature is driven by dynamic armature
simulation running in Bullet.
  - better soft body support: allow grabbing
  - soft volumetric soft body by tetrahedral mesh


/benoit