Simple node editor

Oh sure, forgot you already tried develop
@adsilcott @paintbox1 will adress canvas property editor and dynamic knob creation tomorrow probably, both not much to implement honestly...
After that I'll give the multi-multi-connection editing a try ala this idea...
Seneral

 

@Seneral any chance you could take a look at this. it makes implementing pan and zoom system really easy but there is just the one issue wit the zoom happening at the upper left corner of the screen and not at mouse position.


Plug-n-Play Pan and Zoom class for editor windows

 

Hey,
yep wrote an answer about what I use in the framework...
Hope it helps

 

@Seneral awesome , I will take a look at it right now

 

And next update, bringing full dynamic knob support As I said implementing it wasn't hard, but adding support for the Import/Export system was...
I also adjusted the ResizingNode example to have a output knob for each list entry, works wonderfully

Improved some other stuff, too, 5 commits in total, so here are the 3 major commits:
Canvas Property Editor
Dynamic Connection Port Creation
IO Support for Dynamic Connection Ports

Btw, next up is proper multi-multi-connection editing. I've settled on connection clicking as I figured it wasn't that hard to implement and is more consistent than the other idea we previously had...
But that will take some more time, I'm pretty busy right now again...

Seneral

 

Hi,
What is the best way to check if connection was made? Is there callback for it?
Now im checking if they are null on calculate but that dosen't seem optimal.

Thanks,
- J

 

Hi!
Yes, there is a callback. Either subscribe to one of the events in NodeEditorCallbacks or extend NodeEditorCallbackReceiver for monobehaviours...
What do you mean with the null check on calculate? There should not be anything 'null'...
Seneral

 

Hi,

Thanks I will try em out!
I meant like in the example calc nodes below.

Code (CSharp):

1.      
2. public override bool Calculate ()
3.         {
4.             if (Inputs[0].connection != null) // <-- I mean like this
5.                 Input1Val = Inputs[0].connection.GetValue<float> ();
6.             if (Inputs[1].connection != null)
7.                 Input2Val = Inputs[1].connection.GetValue<float> ();
8.  
9.             switch (type)
10.             {
11.             case CalcType.Add:
12.                 Outputs[0].SetValue<float> (Input1Val + Input2Val);
13.                 break;
14.             case CalcType.Substract:
15.                 Outputs[0].SetValue<float> (Input1Val - Input2Val);
16.                 break;
17.             case CalcType.Multiply:
18.                 Outputs[0].SetValue<float> (Input1Val * Input2Val);
19.                 break;
20.             case CalcType.Divide:
21.                 Outputs[0].SetValue<float> (Input1Val / Input2Val);
22.                 break;
23.             }
24.  
25.             return true;
26.         }

I'm trying to make node graph that represents connections between components (and some of their fields). I don't want to actually calculate anything in the graph (components do that) but I connect them up with nodes.
I simply get the component fields via reflection. Does this sound stupid btw?

Cheers,
- J

 

Well callbacks won't save you from that, I'm afraid
It's actually pretty good that way. Basically, values can be directed from other nodes through connections or entered directly into a field if the inputs are not connected. So Input1Val and Input2Val store the real input values at all times.
Calculate is called when a connected input has been updated. So, in the first two checks it is decided whether to use a new connection value or, if not connected, keep the field value instead.
Hope that makes sense for you now!
Seneral

 

Yo,
I think I got it! Thanks for the help mate : )

Cheers,
- J

 

@Seneral
and anyone else reading this .
I am really concerned about the time it takes to process Unitys default IMGUI controls

GUI class controls like GUI.Box , Gui.TextArea are slow

EditorGUI class controls are slower

GuiLayout is much slower

I have not checked but I assume that EditorGUILayout is even slower

Most times you can have a a canvas full of nodes and not notice that during repaint that your processing speed drops dramatically and that your node drag speed is slower


I stress tested my system with over 1800 nodes on canvas and i could still drag my nodes but at less than half the speed i can usually drag them at

You will also notice a drop in speed regardless of if you Reapint when dragging or constantly repaint.


I constantly Reapint because i am using functions that execute extremely fast and are really lightweight , the most process intensive part of my editor is unfortunately the GUI class functions

 

Yes, IMGUI has never been the fastest - this is why it has been replaced at runtime - but for the Editor it is the best.
They could certainly make it faster easily with some internal optimizations but there is usually no need to.
So many nodes are edge cases so I've never noticed it. If you do need to draw so many, consider clipping/not drawing those that are out of the bounds (the GUI should not perform any timed calculations). This should speed it up by alot when not all the nodes are inside the view.
Tell me if that leads you to any solution
Seneral

 

Not rendering nodes outside of the screen is a function that i'm working on , i'm sure that it will make things really fast . especially since in my case not more than 10 nodes may be on screen at any one time .
another really goo workaround is using GL or Graphics.DrawTexture for UI but the issue is that that if you use them for your nodes then they will be rendered above the editor window.
I think that you would have to find a way to clip the textures once they nodes go beyond -1 on the y axis

 

Doing GUI with GL is not an option, atleast not for the framework itself. If you want to do that for your sepecific setup, go ahead
But rebuilding everything for a performance boost most wont even notice over a crappy UI creation is just not worth it I'm afraid...
Hope your clipping yields some good results for you

 

GL works great for me but i don't use it for nodes because of the rendering outside of the editorwindow.
I use it for solid textures inside the bounds of the window.

I like both a non crappy UI and performance
I use a mix of GL, Graphics class functions and GUI class functions in the back end of my system.

Knowing when and where to use each really helps it is better than using GUI classes functions everywhere

 

Yo Seneral,

How would you duplicate object that has reference to a component in scene? (the component needs to be duplicated too you see)
I can see that there is the contextual menu:

Code (CSharp):

1.         [ContextEntryAttribute (ContextType.Node, "Duplicate Node")]
2.         private static void DuplicateNode (NodeEditorInputInfo inputInfo)
3.         {
4.             inputInfo.SetAsCurrentEnvironment ();
5.             NodeEditorState state = inputInfo.editorState;
6.             if (state.focusedNode != null)
7.             { // Create new node of same type
8.                 Node duplicatedNode = Node.Create (state.focusedNode.GetID, NodeEditor.ScreenToCanvasSpace (inputInfo.inputPos), state.connectOutput);
9.                 state.selectedNode = state.focusedNode = duplicatedNode;
10.                 state.connectOutput = null;
11.                 inputInfo.inputEvent.Use ();
12.             }
13.         }

I was thinking I should do new costructor for duplication? I just in general try to avoid editing code from 3rd party as they will update and I hate to merge stuff. Any tricks you might have?

Thanks a lot dude,
- J

 

Well as you see no information at all is currently copied, only the node itself, but it has default values after duplication.
I can try to fix that if I have time, but then it will be generic, no extra function to copy over values Just can't promise when that will be, have lot's to do currently, sorry
Seneral

 

No worries I got it working relatively "ok" way. I can rely on the component super class that does the duplication and I just made new CreateDuplicate function in the node editor. : )

Thanks a lot!
- J

 

Alright, that should do it (until I might find the time to do it generically)
Seneral

 

Hi,
I apologize for responding late but I finally found the time to take a look at it and would like to give some feedback:

1. Canvas/Node PropertyEditor works nicely but I dont like the default UI which is drawn on top of my custom inspector. The inspector stuff for nodes just lists what can be seen at the node already, I would completely remove it or at least put it in the base node implementation of the DrawPropertyEditor call, so its overridable. The inspector of the Canvas has this "open" Button which I find pretty cool, but the remaining default ui should be at least overridable too. Thats all nice debug stuff for developers but just confusing and unnecessarily space consuming to the designers(the people who use node editors for designing quests and dialogs etc). And I think the "open" button should be invisible in the opened canvas to save space for custom propertyeditor stuff. (And because you need an open button on the opened canvas)
2. There is a Method for creating dynamic knobs but none for removing them. In my custom Inspector I add choices for dialog nodes, which result in dynamic outputs. Each choice maps directly to an output. When renaming choices or deleting them, am I supposed to directly access the outputknobs lists for deleting or renaming? Seems to be working at least
3. This has nothing to do with the latest commits: The folder structure of the project could be improved a bit. Overall its pretty tidy but there are a few things that dont quite fit my needs
   1. In my projects I like the external libraries/extensions to be in one folder per lib/extension. Therefore I'd suggest putting the Editor folder in the Node_Editor folder so you can just copy that one folder to your project, where the previous version was.
   2. Can we move the examples to the top where Docs are? Same goes for Saves and everyting else that isnt essential. Right now they pollute my project if I dont remove them everytime I update. And everytime I have to figure out whats necessary and what can be deleted.
   3. This one is luxury and I'd completely understand if you'd just ignore it: I dont think the RT stuff is used by the majority. I would consider separating it into a special runtime folder, so you can easily delete it, if you dont need it. Like I said, luxury that would just give me a cleaner feeling about my project.
4. I dont know if this is because I always try to delete the unnecessary stuff but at the first try to open the editor, it fails to load the last save(of course because I shouldnt have any saves yet)
5. You will probably address this when youre going to touch "proper multi-multi-connection editing" but just in case: Dragging connections from multi(input) to single(output) is working but not from single(output) to multi(input).

Thats all for now. Nothing critical so far. Will report further when I get more time to work with it. Please dont take my feedback as complaints. This framework is evolving really well.

Greetings

 

Hi,
Some good points you raised Can't tell which and when I can adress, but I'll try.

1. Will do that next time working on the project
2. There is already a function, RemoveConnectionPort, aswell as an example node (Resizing Node) that does exactly what you want to achieve
3. Folder structure might not be the best, but I found it quite good so far.
3.1. Can't move editor into the Node Editor folder, there's only been a recent editor version supporting this. I think up until 5.2 you could only have the editor folder immediately underneath Plugins, and for compabilities sake, it' going to stay there... But you can move it no problem whenever you want, it should adapt automatically.
3.2. That would mean the whole Nodes folder and the whole Defaults folder - since they are just the default content extending the framework. Don't think I'll do that, though...
3.3 Isn't Default/Runtime Examples enough?
4. I didn't include the last session cache file from me, no, so there's nothing the editor window shows by default. But that should not throw an error. Could be there's a warning, will try to remove it.
5. Yep, thats one benefit of the new concept I have for editing connections. Don't know when I'll be able to implement it though.

Thanks for your feedback
Seneral

 

Hi @Seneral, I am facing problems with the saving system again. The main problem is, that the node editor creates copies of everything when it saves. I wanted to have a UnityEngine.Timeline.TimelineAsset in one of my nodes to get saved as a subasset of the canvas, so I used CopyScriptableObjects and GetScriptableObjects in my node to let the savemanager know, that the timeline subasset shall be replaced by a copy. But that doesnt work for several reasons:
1. After closing and reopening unity, the timeline subasset is empty. (Instantiate doesn't seem to create a deep copy of the timeline)
2. Nodeeditor is saving(for example because of focus loss etc.) and thus creating copies of the TimelineAsset while I'm editing it in the Timeline Editor Window. Which means I keep editing something, that NodeEditor already stopped caring about.

I know, we've already talked about this and I've tried to make it work, but it just wont in my case. I've always had problems due to scriptableobject replacing.

Do you see any way to disable that save system (maybe per canvas type?) so that I can directly edit the canvas asset in the nodeeditor without copying stuff?

Greetings

 

Hi,

yes, there is a way to change that behaviour, but it is not so easy that I can post a quick fix for it now...
Maybe reconsider if you really need to save the TimelineAsset with the canvas itself? This is the source of problems, the cache system breaks external references of course, it simply is not possible to maintain them when managing multiple versions of an asset... For that case, you usually save that asset externally

If you just care about the timeline window reference, you can disable autosave when switching window focus and the timed auto-saves, leaving only the copy on loading and saving the canvas. If that's enough for you, do this:
- In NodeEditorUserCache l.125, disable the function CheckCacheUpdate which is responsible for the timed saves
- In NodeEditorWindow l.95, disable OnLostFocus which triggers an autosave

Hope that helps,
Seneral

 

Hi,
I thought about saving the timeline as an external asset but the main problem is: When to create or delete it? Every node in my canvas corresponds to a timeline. The timeline asset should automatically be created and referenced when a node gets created. But maybe after creating nodes I dont save. The external assets are already there then. And what if I delete the node? I cant simply delete the external timeline asset, because maybe I dont hit the save button after that.
Of course it would also be more troublesome to have these loose timeline assets exist separately in my project folder. Everyone can easily delete them and thus break the canvas and so on. I also cant give them meaningful names which would result in a folder with thousands of timeline assets having guids as names. That's when it becomes a blackbox no one will be able to understand any longer

Long story short: The best solution for my canvas would be to directly edit the canvas asset instead of a working copy.
I know that must be lots of changes at different locations like handling subassets on node deleting etc, which is why I havent already modified it myself. I just dont know all the places where stuff like that happens.

I dont need that as a quick fix though. Like I said, it would be cool, if every canvas type could decide if thats needed for editing that kind of canvas. If you see any chance of implementing it in a clean way, just take your time. I can wait. I'm already glad to see you're open for discussions about the saving system.

Thanks for always being that responsive

 

Ah, thought you're talking about maybe one or two timelineassets per canvas lol...
Makes sense then

What I could do is modifying the GetScriptableObject/SaveScriptableObject functions to support 'fragile' objects. These could be not be excluded from the cache system. So during it's lifetime it is always ONE single object, always living in the original source file even while working on the canvas. Only when saving to a different save path it will create a copy, but the original will remain. That way references should persist.
There are a few problems to that though:
1. Since caching is disabled for it, all changes you do to it are directly saved to the source file.
2. The saved cache canvas references a future version of the timelineasset (used by the current working copy) and thus when reverting to the original save state, corresponding data in the nodes might misalign. So it's your responsibility to support random 'changes' in the timeline asset, don't rely on cached information in the nodes!
3. If you delete your save file while working on the canvas, your canvas will still work because it's working on a copy but your referenced timelineasset will be missing.

But that should be totally ok for your case I assume It's also relatively easy to implement actually... But don't know when I have time.
Seneral

 

1. You mean changes to the timeline, right? Would be totally ok, that's what I asked for
2. By "reverting to the original state" you mean exiting NodeEditor without saving? Isn't the system automatically saving every now and then and when it loses focus? So that should happen really rarely, no? Or is autosaving just targeting the lastsession asset?
3. Yeah that kind of stupidity deserves punishment Really no problem in my case.

Greetings

 

1. Yes
2. When you work on your canvas and your timelineasset and then revert back to the original source file, meaning you load the file again. The node state will be reset to a previous state but your timeline asset will remain the same. Depending on what you're doing this can cause data misalignment.
3. He, alright then

 

Thanks so much for creating and working on this! If I come up with any exuberant or useful fixes/changes, I'll be sure to contribute. Hoping to use this for a couple of my own tools.

 

Looks great! I'm having a stab at creating a graph for playables, much like mecanim. One thing which would be nice which seems to be missing is being able to select a specific connection, preferably by clicking it. This would be nice for modelling transitions.

 

Thanks Yep, something like this is on the roadmap, but don't know when this will be implemented, sorry
Seneral

 

Hi,

I've tried the example projects to figure out how it works and none of them works at all !!! I've readed the documentation too, to get a general idea about how it works and how to extend it; it seems clear & easy, untill you get the outdated examples (it's very fustrating) .

The general node visual editor is fantastic and I've seem that it's an alive & supported project (las commit is from several days ago), but with no valid examples is useless for anyone who wants to use it.

Using Unity 2017.1.1 on Windows 7 (x64). (just in case...)

 

Sorry for all the confusion in regards to the examples.
In fact, the examples are tailored to the NEWER develop branch, instead of the master branch. I have to admit it's suboptimal but for the lifetime of this project the develop branch was always way ahead in terms of features and stability because I do not have the time to merge with master (last merge was about a year ago). So instead examples have been kept up to date with the develop branch... sorry for that.
As a solution, I recommend to use develop over master.
Also, documentation is completely outdated, but as I said I'm lacking time to keep everything up to date, so I chose the develop version.
Hope you're going to get it working now and be able to use it
Seneral

 

Ok, thanks man for the quick reply (on weekend).

I'll try again next week and see if I can get it up & running so I can start to make my own nodes.

On the other hand and as a suggestion, instead of publishing more updates in the master branch, it could be a good idea to invest time in making that merge betwen master & develop branches, and updating the hole solution (examples, docs , etc...).

Adding more features is not going to help new guys like me in any way because we will be using always the develop branch.

I know what it is not to have anought time to update things (I suffer that problem too in my own projects) but you will have to make that merge sooner or later, thats for sure!

 

Hi,

I've been playing around with this Node Editor Framework and it's amazing.

- I've updated the Dialog example because it refused to build in my project (because unityeditor references). I fixed using prepocessor (#if Unity_Editor in the appropiate places).
- I've updated the Texture example to the develop branch (it's is not difficult at all) but I've lost the example included. I suposse it's not compatible with the new node-conection code.
- It has been impossible to update the regular expresions sample, it's creating some node conections in "runtime" (depending on the regular expresion) and that code has severelly changed so I can't figure out how to proced. It's clearly a most advanced example (let's forget about the state machine...).

The only thing I miss -a lot- is a updated manual, it's a pitty not having an updated one.

For starters -like me- I recommend some previous documentation on the Visual node editor theme:
http://gram.gs/gramlog/creating-node-based-editor-unity/
and look at the video series posted in the first page of this treath.
It's a good starting point to figure out how it works (Nodes, Node connections, NodeEditor, etc...) so you understand what's going on when using this framework.

 

Hey, thanks @jocyf for the input
Yes, you're probably right. As of now, it will probably take some time for me to find some time for this project at all. Next thing will probably be, as you said, merging develop with master (might make a few small additions first) and updating the docs.
Regarding the docs, I will probably integrate them with my site since due to the way github pages are hosted, they're already using my url anyway... As a separate sub-page of course, isolated from my content, but same layout as this doc.
Easier for me to manage, is repo-friendly and is way more lightweight

Thanks for your updates btw, much appreciated!
Yes, regular expressions example is tricky. It should be possible though, I'll give it a try afterwards
State machine is actually possible to natively integrate right now because of the abstraction of ConnectionPort (atleast in theory). Might take a look at that at some point

Seneral

Edit: Uh, after checking, I already had an adjusted Texture composer around, sorry about that. Will check and then merge yours

 

Hi @Seneral i looked into your Node_Editor proyect and it looks sweet. i came here searching for some help ( if you can ) i figured out how to make an node based editor to implement into my Behavior tree editor. everything is working fine but i can't figure out how to make the node canvas with zoom and grid dragging with mouse ( as you can see i'm using Scrollviews ) but it's really messy when the tree comes big .. i downloaded your proyect from github but i can't underestand how it works (it's very fustrating) any help i would be very grateful.

My objetive with the behavior tree editor was at the start a tool only for me and my games .. but i ended published it into asset store ( i'm waiting for approval ) it supports realtime behavior tree display , custom nodes and more..
more info at: https://pedro15.github.io/MoonBehavior/

but i suck at the grid system and zoom system .. :/

 

Well especially scaling IS one of the hardest parts, that's what this project is for.

Don't use scrollrects for scrolling, implement panning using a custom offset on the nodes and custom GUI event handling, much easier

As for scaling, most editors use GUI.scale, but that has it's own issues, f.E. with clipping rect and zoom position. So I created a generic (slightly hacky) solution, GUIScaleUtility, which in the background also uses GUI.scale. Check NodeEditor.cs Draw functions to see how it's integrated, basically it returns an offset you can apply before drawing the nodes, just like pan.

Hope you can figure that out
Seneral

 

@Seneral i will look into it, thanks

 

Ok so I just finished porting the Node Editor Docs from mkDocs to my webpage
Why? Well, it is a bit more difficult to manage and edit, but as the old docs where inevitably hosted over my URL aswell (due to the way Github pages work), I wanted to integrate them with the rest of the page.
Take a look at it: http://www.levingaeher.com/NodeEditor
The old one is still available at: http://www.levingaeher.com/Node_Editor_Framework
Especially take a look at the new WebGL demo, took quite some time to finish it up

Just tell me what you think. In the future I'll then gradually updatge/rewrite/expand the documentation...
Best regards,
Seneral

 

Just spend the whole day rewriting the documentation!
It is now updated to the latest develop branch (finally all this new stuff is not a mystery anymore!), goes into more detail in certain parts, and is better adjusted to the new webpage rather than a mere port. Go check it out, it beg you! Need to find all those typos lol
Only thing (yet again) missing is the Framework Overview, not sure when that'll be worked on.
Also, if you find anything unclear or missing, tell me! I won't know until you do.
Seneral

 

Thanks a lot for that! As a less experienced coder it took me quite some effort to understand it all. That is really appreciated.

 

Thanks man, it was a pain to start with your asset just studying the examples !

 

Thanks both of you If you find any unclarities or find something you really want to have explained more in depth, don't hesitate to tell me

 

Hello everyone. This thread is for general node editor discussion, right?

My idea was too different to be something added to an existing opensource project, so I created a new one, and now I just want to let you know that it's ready for use.
It is very intuitive to use coming from a Unity background, and the editor scripts are separate from the runtime scripts, just like with regular custom editors.

I've already written two extensions using it, and i've found it very easy and pain-free to use.
Check it out here



(If this is a Node Editor Framework-only thread just let me know and i'll remove this message)

 

Around page 2 it kinda turned into a thread for the node editor framework. Think of it as a thread conquest.

Your editor looks like a neat tool, and it's in ways more general purpose, so it definitely deserves a thread of it's own!

 

You're right. It's very general purpose.
I did make a thread a while ago but it got buried pretty quickly.

 

As Baste said, don't worry! Not my thread initially and happy to see other peoples work
Indeed looks very cool. Just two months ago another open source node editor popped up... you guys sure are hard at work
Interesting start you got there, really seems very lightweight. Not as many features, but on the other hand very easy to modify Do you have Undo working yet?

 

Thanks! I actually did some work on UnityNodeEditorBase but it had a myriad of issues and was very complex to work with. Eventually the original author stopped working on it.

I've kept xNode very simple to support as many use cases as possible. Because of this, you'll need to implement your data flow yourself.

I have purposely not built a separate undo stack system. Mainly because the only intuitive way to undo is by ctrl+z, and that shortcut is hardcoded into unity. Instead, xNode uses default undo stack.

 

Oh, interesting. Well, doesn't mean it's completey abandoned, but understand.
Well, I built a tool to use your own undo stack with Ctrl-Z, but I agree default undo stack is the way to go. Lightweight on your code base and works everywhere. Just a pain to get working depending on the structure. I actually had to change the cache system in the Node editor framework to support that Undo...
So you did implement normal undo, that's what I wanted to know Nice!
Next thing I wanted to do with this framework...

 

Implementing undo isn't an issue when you use SerializedProperty as much as I do It's pretty much given to you for free. I just need to make sure it works with node drag and connections as well.