FlowGraph

Share your helpful Urho3D code snippets, samples and tutorials here.

FlowGraph

PostPosted by 1vanK » 18 Dec 2016, 13:51

https://github.com/1vanK/Urho3DFlowGraph

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:

1) Control camera by separate FlowNode (see Game.cpp)

Code: Select all
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);


2) 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: Select all
// Create first flownode
SharedPtr<StarterFlowNode> starter(new StarterFlowNode(context_));
flowGraphExample_->nodes_.Push(starter);

// Second flow node
SharedPtr<CubeCreatorFlowNode> cubeCreator(new CubeCreatorFlowNode(context_));
// Write scene pointer to input port
cubeCreator->inputs_["Scene"]->data_ = (void*)scene_;
flowGraphExample_->nodes_.Push(cubeCreator);

// Connection
flowGraphExample_->Connect(starter->outputs_["Start"], cubeCreator->inputs_["Create!"]);


p.s. sorry for russians comments in code :)
User avatar
1vanK
Moderator
Moderator
 
Posts: 430
Joined: 26 Jun 2015, 19:16
Location: Internet

Re: FlowGraph

PostPosted by sabotage3d » 18 Dec 2016, 23:14

Nice! Screens please.
User avatar
sabotage3d
Have many posts
Have many posts
 
Posts: 515
Joined: 25 Oct 2014, 13:26

Re: FlowGraph

PostPosted by 1vanK » 18 Dec 2016, 23:50

No UI currently
User avatar
1vanK
Moderator
Moderator
 
Posts: 430
Joined: 26 Jun 2015, 19:16
Location: Internet

Re: FlowGraph

PostPosted by godan » 19 Dec 2016, 00:39

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....

Anyway, great work! Keep it going!
User avatar
godan
Active user
Active user
 
Posts: 122
Joined: 23 Sep 2014, 20:28

Re: FlowGraph

PostPosted by 1vanK » 19 Dec 2016, 05:37

Thanks! Any help is welcomed to make Urho better ;)
User avatar
1vanK
Moderator
Moderator
 
Posts: 430
Joined: 26 Jun 2015, 19:16
Location: Internet

Re: FlowGraph

PostPosted by boberfly » 29 Dec 2016, 21:43

Hey 1vanK great work! I didn't see this before until now.

Some resources which might be cool to see, if you haven't seen these already:
http://bitsquid.blogspot.ca/2010/09/visual-scripting-data-oriented-way.html

'Breadboard' is a graph/node/flowgraph scripter in the same vein:
http://google.github.io/breadboard/

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!
User avatar
boberfly
Active user
Active user
 
Posts: 107
Joined: 27 Mar 2014, 01:14
Location: Australia


Return to Code Exchange

Who is online

Users browsing this forum: No registered users and 0 guests

cron