I try to make simple analogue Flow Graph (Crayengine) and Blueprints (Unreal engine)
Currently no interface. All FlowNodes created in code. But already exist correct order of execute of FlowNodes and sending data from one flownode to other.
Example do 2 things:
Control camera by separate FlowNode (see Game.cpp)
flowGraphExample_ = new FlowGraph(context_);
SharedPtr<CameraControllerFlowNode> cameraController(new CameraControllerFlowNode(context_));
// Write data to input ports of flownode. In the final it shoud be doing throught UI in Editor
cameraController->inputs_["CameraNode"]->data_ = (void*)scene_->GetChild("Camera");
cameraController->inputs_["MouseSensitivity"]->data_ = 0.1f;
flowGraphExample_->nodes_.Push(cameraController);
Creating cube on start demo shows connecting of 2 flounodes.
First flounode (starter) send signal to its output port when first update.
Second flounode (cubeCreator) create cube when has signal on input port.
[code]
// Create first flownode
SharedPtr starter(new StarterFlowNode(context_));
flowGraphExample_->nodes_.Push(starter);
// Second flow node
SharedPtr cubeCreator(new CubeCreatorFlowNode(context_));
// Write scene pointer to input port
cubeCreator->inputs_[âSceneâ]->data_ = (void*)scene_;
flowGraphExample_->nodes_.Push(cubeCreator);
Nice one! I certainly think that node graphs can make exploration and prototyping much easier. Having just spent 6 months in the depths of node graph code (written entirely in Urho), here are some immediate thoughts:
Some kind of topological sorting of the graph is a must for getting âcorrectâ results (I see you are doing the classic âwhile node inputs are not ready: continue, otherwise, solveâ).
Checking if the user has created a cycle or no is also necessary.
I strongly suggest copying data rather than passing by reference in the nodes. This makes things tricky for component references. I donât have a good solution to this yet either
Along with what nodes can do, a really interesting question with node graphs is how data is presented to the node. For instance, node inputs can expect either items (i.e. A + B = C), or lists (create a single mesh out of a bunch of vertices). But what happens when an âitemâ access input is presented with a list of inputs? Things get trickyâŚ
In my head I was thinking what would be cool is also having a lower-level flowgraph editor which can output .cpp at the end, where nodes canât connect/disconnect at runtime but rather just encompass logic to one entity and only communicates to outside entities through events (using the actor model?). This might make things a lot more optimal in performance and due to communication being decoupled from other objects, this could mutli-thread quite well. The bitsquid article argues though that the parts youâd want to mutli-thread would be iterating over all components within the one system, while the flowgraph is high-level and needs to access multiple things obtusely and would cause sync hell, but if your scene representation is double-buffered then this might not be a sync problem.
Anyways food for thought I guess, great work regardless 1vanK!