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