Hi everyone, a short post here that should be expanded as time progresses.
Following the work of Sjoerd De Vries on the HIVE nodal game logic system, it is my plan to continue its development over the summer holidays.
During this period, I intend to have the following deliverables realised:
Functional Blender nodal UI
[LIST=1]
Ability to add, remove and modify nodes
Ability to add, remove and modify node systems
Informative tooltips, attribute names
Hiding information that is not relevant to the current context
Functional BGE “sparta” nodes for logic brick replacements.
In some specific cases this will not be easy to perform:
[LIST=1]
Radar and Near sensors are implementable by using sensor objects. This will be a later target for HIVE, and will be best handled by warning the user that such features do not exist. This will best encourage the same features to work in Panda. To create a radar sensor, create a cone and enable collision, setting it to SENSOR.
Armature sensors are irreproducible at the moment.
BPY conversion tool from logic bricks to HIVE nodes will make a transition easier. This will leverage the Blender operator API rather than being implemented in the HIVE UI
[/LIST]
Documentation and tutorials for basic usage scenarios, and explaining how the learn more about the system:
How HIVE works, in basic user terms
How to use SPARTA (logic brick library)
How to use SPARTA with dragonfly (non logic brick node library)
How to use Python code inside HIVE
How to convert logic bricks to HIVE
How to develop custom HIVE nodes
Expanding the standard library for useful nodes
Implementing BGE (and maybe panda) specific plugins for enabling features per-platform
There are a lot of tasks here but I think that they are feasible within the time that I have allocated.
Currently I’m working from GitHub instead of Sjoerd’s Bazaar repository. This means that I will use Bazaar as a reference, but develop within GitHub. Currently HIVE will run inside a patched version of Blender, with these patches applied (the Game Engine handler patch is already in trunk https://codereview.appspot.com/user/sjoerd_de_vries). I will release a Windows build for Blender with these features, but not until HIVE is somewhat usable, as the UI is quite young in its development so far.
Check my repository here, and I will post in this thread when you can try out certain revisions/branches
And once the converter is done (along with things at the point where everything done with the bricks is possible), we can get rid of the specialized logic window and just have all logic done in the Blender node editor (with HIVE coming standard with Blender). It would not be wise to remove the bricks wholesale on the first release that comes with HIVE though, as people will need time to move away from the system or at least fix any possible issues with the converter for at least one more cycle.
This gets rid of the one window type that can’t be used unless you’re working on a game as well as the one type that cannot work with a vertical interface (the object game properties can go into an object context panel with the LOD and Navmesh controls). Nodal logic is the future anyway, at least I haven’t seen an emerging AAA quality engine for indies not doing it in that manner. When it comes to object properties, this is providing that they are still even needed (probably just have HIVE or your scripts define properties that can persistently exist during the duration of the object)
When it comes to sensor bricks at least, would it be possible for Panda’s logic modules to support Bullet features like this, not having to use objects (or at least having virtual objects transparent to the user) would make it possible to keep things as simplified as possible?
Eventually we would also want Panda3D to control all of the non HIVE-based logic (with the ability for that engine to read bge-specific functions even if it’s just a temporary measure to ensure the continued function and playability of projects while porting).
When it comes to sensor bricks at least, would it be possible for Panda’s logic modules to support Bullet features like this, not having to use objects (or at least having virtual objects transparent to the user) would make it possible to keep things as simplified as possible?
Yes, Panda gives you more control than Blender’s Python API in this manner.
HIVE lends itself well to cross platform development through a plugin abstraction layer, which I’m currently implementing methods for solely in Blender, as I still develop with Blender for the time being.
My current task is to enable copy and paste, and fix other bugs in the GUI code. Most of this shouldn’t take too long, and it’s also an important learning curve, for the internals of the HIVE system.
One of the bigger benefits from HIVE is that it can output non-executable representations of nodes, both to and from code, so you can mix user-defined nodes from .py files with nodes from .workermap files. It also means you can more easily share logic systems with other people.
In theory, using HIVE, object properties would not be necessary, as they can be handled from nodes within the logic system. (Essentially a define node).
I’m currently looking at avoiding interactions with the logic brick system. It does not make sense to use Logic Bricks with HIVE, and may have unintended consequences, so I think it best to unanimously ignore them. Hence, aside from object properties (because of the existing UI support, but this is also feasible in HIVE), things like message sensors are better off being written in Python without leveraging the SCA system.
Logic processing is very rarely the main bottleneck, so speed isn’t really a necessary concern for such things. Typically the slow parts of the application are single systems like collision processing or rendering which are just heavy tasks, not repeated amounts of slightly slower code.
That said, HIVE essentially connects operations almost directly to one another, so Is very fast (compared with pure python code) , and can be extended with c++ nodes if necessary
radar is partially replaceable with python using raycast
disadvantage:
cannot see “piece of mesh”
advantage:
much more performant, meanly and easy to optimize again using time-frequency
it can see object really visible (if there a wall in the middle the other object is not visible)