After reading the majority of this thread it seems to me like the hive conept will work a bit like the UE4 demonstration? http://www.youtube.com/watch?v=acR4n6lJEdQ about 6:10 is what I mean.
If so thats great, there is a big gap to be bridged inbetween Python and Logic Bricks. Blocks of code thinly disguised as logic bricks would be a great thing to have.
so will this be integrated inside blender 2.64 or is it gonna be independent? because it would be really awesome if it was built in or included as a plugin c:
A new update in trunk:
There is now a “profile” feature, customizing the look of a worker node.
For simple workers like variables, you can now see their value on the node canvas, instead of only in the Parameters tab.
Good! There are a couple of things that can be done with beginner programming skills:
Testing any updates to the trunk version on your system. You have to install bzr, use it to download trunk and set PYTHONPATH to the trunk directory. The script to start the GUI is hivesystem/gui/hivegui.py. Having things tested first makes it much easier to prepare new releases.
Improving the look and feel of the GUI.
The current GUI is a Qt-based reference implementation. Qt (PySide) is a well-documented GUI framework with many options to play with GUI design. Unfortunately, I don’t know anything about GUI design, so there are many places where the GUI can be improved. Making it nice and ergonomic will make it easier to create a nice and ergonomic in-Blender GUI port.
Just open a random file in hivesystem/hiveguilib/HQt (nodes) or hivesystem/hiveguilib/PQt (parameters) and see if you can make it look nicer. For example, you could change some colors in HQt/NodeCanvas.py. Or you could edit the function setActive in HQt/widgets/connection.py, and mimic the dataflow effect from the UE4 Kismet video.
Making things easier for others. Little videos or tutorials of installing the hive system, using the GUI and running the examples are a great help!
I’m not really requesting any features :). This is just a result of my mind trying to come up with a few ideas for yourself that ‘could’ be implemented, based on my understanding of what you’re trying to do. This example is pretty heavily inspired by the Blender material node editor.
If you like it I can do some different revisions or something, like I said this is only about half hours work.
Oh and the bi-coloured connection is trying to show the status of the delay. For instance the delay is set to 3 seconds and the line is basically half filled indicating theres about another 1.5 seconds until the script is executed. But that would only apply if the nodes will update in real-time ;). Syntax highlighting (for me anyway) just makes things easier to read.
In today’s meeting we discussed less in relation to HIVE’s inner workings. Instead, we covered the topic of networking. This would at first seem like a digression of mine own doing, but it was for good reason. The reason being that I wanted networking to expand HIVE, rather than sit alongside it. After many crossed lines, and points that weren’t fully fulfilled, we have decided upon a “remote antenna”. Those of you who are reading the FAQ and watching the videos (Yes, they’re coming!!) should be aware of the functionality of an antenna, and the remote antenna permits the same functionality across a network. One can think of it like an RPC of sorts. I hope that this will open new functionality -for internet networking and local networking (communication between scenes perhaps). There will be more extensive documentation upon this at a later time, now is the outlining.
There is the idea for channels - where you can specify the channel that the remote node belongs to. This means that you can have “groups” of nodes. This is like a “packet” which consists of a login id, password and ip perhaps. It enables grouped data to be sent only when all data is collected. Currently this doesn’t support > 1 datatype to be identical per channel, we shall look into whether this need be changed.
Thank you for your clarification, Sinan.
For now, the intended audience is indeed programmers who would like to create their own workers and hives in Python.
For non-programmers, the GUI is not yet mature enough, unless you are tweaking one of the examples.
This error message is completely normal. The hivegui discovers some nodes that use Panda3D, but cannot import them (no Py3 installation for Panda3D exists).
However, the message should simply be printed as a warning, and this should not crash hivegui. Do you have any other error message? What platform are you on?
The add-on zip file does not come with hivegui.py, you will need a standalone install.
If you use easy_install (or one of the Windows installers), hivegui.py is installed in the Python scripts directory. Under Linux, this directory is typically in your system path. So, typing “hivegui.py” from the command line should normally work.
You can install the add-on and the standalone, there is no conflict between them.
This thing has a lot of potential, but I’m running with some issues with the libcontext somehow.
I did a standalone install (which seems to work, well, I get the gui by starting hivegui.py in C:\Python32\Scripts),
is not having “Program Files\Hive System\hivegui.py” (python 3.2 install bug from the readme.txt) a bad thing?
HiveGUI (and WorkerGUI) now support copying/pasting of nodes and their connections
Fixed a bug when deleting an empty node, and another bug when deleting multiple nodes.
The hivegui is designed to be as abstract as possible, with dependencies on Qt confined to specific locations.
I have had a conversation with Lukas Toenne this week. His progress on Custom Nodes is very mature, and once they are in Blender, it will be possible to port most of hivegui quite easily.