xNode - A general purpose node editor

You're right, the InstancePorts are the way to go in this case. However, I haven't decided on a good way to draw default instance ports yet. Instead, you are required to draw them yourself through node editor code. An example of this can be found in my Dialogue repository.

Renaming is already on the to-do list, but users haven't shown much interest in it, so it had a low priority. I'll have a look at it sometime soon

Edit: Renaming has since been added

 

Cheers

I like this thing so far. I just want to set up a simple graph for some experimentation with skills/powers/tech trees, and dynamic inputs appearing automatically would help with skills which have pre-requisites. Lazy, you see

 

New feature! Rename nodes!

 

Hey Siccity, I just stumbled across xNode while looking for a dialogue system solution. This looks perfect for what I want. However, being fairly new to Unity I am not 100% sure how to get it up and running. I downloaded from GitHub and thats as far as I got. Do I drop it into my project folder? I haven't added anything not direct from the asset store before.

 

xNode is not a dialogue system in itself. It is a framework which can be used to build dialogue systems. You need at least some experience in C# scripting to use it. There's a wiki on getting started here

 

Thanks for the speedy reply. I am aware that xNode is not a dialogue system, but it does look like it could help me towards my goal. I do have some C# scripting experience and whilst being new to node graphs I was hoping xNode would help me learn. I had a look at the wiki and I'm still not clear what folder to drop the download from GitHub into. Should I just import from the asset store so I know it will end up in the right place?

 

Drop it anywhere inside Assets. That's where all the stuff goes

 

Thanks for the help.... and the asset. I'm sure I will have a.few more questions later but for now I'm off to explore

 

Thank the author for the asset

 

I like how clean and straight forward the code is. Thanks for making this available. I also appreciate the rename feature.

Could you add a way to set the default header background color and text color per node class? Same for the body background and text colors? As a stretch goal, let instances of nodes choose their colors. Thanks.

 

xNode supports only tinting bodies. If you want more control, you can change the default skins or extend via editor code. I might add more color control support in the future, but understand that each adjustable feature increases the render time per-node, even if you don't need it.
You can already control instance colors by overriding GetTint() in a NodeEditor script.

 

Thank you.

Also, Siccity, could you add an example showing how to add a serializable delegate to a node with the visual node editor.

I am most interested in C# delegates, both void and non-void return types. I have read that they need to be handled differently from UnityEvent delegates.

This would allow creating a node that triggers a multi-delegate call when it becomes active.

 

C# delegates are not serializable by themselves. UnityEvent is a wrapper that makes it possible to serialize a delegate using reflection and internally caching a c# delegate. Last time i tried UnityEvent on xNode i encountered some bugs on UnityEvents side which I reported as a bug and later got confirmation that they'd fix it. I don't know what state it's in currently.

If you want serializable delegates without doing a ton of complex reflection and optimization work, i recommend you go with UnityEvent (assuming they fixed it).
UnityEvent doesn't support return types though, but luckily I've created a solution for just that. https://github.com/Siccity/SerializableCallback works exactly like UnityEvent, except it lets you use return values, and works perfectly in any script, including xNode.

 

@Siccity

Would it be possible (and easy enough) to use xNode to display nothing more than node boxes (and connection inputs/outputs) that each node has controls (i.e. buttons) that can execute functions within the Unity editor?

I'm mainly interested in the visual parts of this with only very slight interactivity (i.e. no node-based calculations -- each node would act sort of like its own EditorWindow or control group -- the connections would just be visual and nothing more.)

What parts of xNode would I be interested in modifying / including?

 

That is very much possible, yes. You can use Node Editors to add buttons just like you would in a normal Editor script.
Basically override

OnBodyGUI();

and add stuff like

GUILayout.Button();

If you want to draw the default node inspector as well, you can do so with

base.OnBodyGUI();

 

That's really useful -- thanks!

What parts / scripts are necessary to keep to retain this display functionality? I essentially would like to delete anything else that's not relevant to the graph and node / connection display (I'd still like to retain any general graph shortcuts / functionality though), so what files would be necessary to keep / safe to delete?

Also, one other question -- is there a way to make the reroute points smaller/different or just not display unless they're clicked on?

 

xNode is very barebones, and node/connection display is basically all there is to it. There is no built-in traversing or logic system or anything else you don't need.

Reroute points are very new, and currently have no settings. But I'm all open to suggestions as to how they could be improved

 

That's a great thing actually! -- I only just opened it up to see that right after asking about it. I was expecting something much heavier and complex/interconnected. You've done a great job on this man!

Regarding reroute points, there are only two things I can see that would make it worthwhile to improve. The main one is simply a smaller "dot" icon to differentiate it from the typical in/out connector (it's too "fat" and thus prominent as-is atm), but that's very minor -- the eye just goes toward it when looking for in/out connectors, since it's all alone and isolated and out in the open, that's all.

The second thing is to be able to potentially "branch" from a reroute point and spread (copy) that one data point to other nodes (as maybe a reference), or even just a copy (assuming this isn't difficult to do of course). It could just keep the graphs with tons of data on a giant "MEGA NODE" to a minimum.

Another idea for improvement (as an alternative to or to complement the "branch" idea above) on the reroute point (it just hit me) is to legitimately make it "reroute" by creating a second version that acts as a "portal" (that simply connects to another section of the graph -- i.e. it just transports the data to an entirely new section of the graph without any need for keeping up with or drawing more node noodles.) This could keep the visual-complexity of the graph down on much larger graphs. This functionality could be designed as a node, but it seems like it would be a better fit at the barebones level as a reroute "portal" than higher up (at the node level), at least functionally and design-wise. Plus a tooltip or a statusbar text string to show what data/node this "portal" comes from could be highly useful too. Hopefully this isn't out of the scope of what you're going for with this, but it would be great for UX, especially if it isn't too far out of reach.

Speaking of UX -- is there a comment rectangle available, or is that something on your radar?

Don't mind my suggestions -- these are just ideas for better usability (if you choose to go that route.) This is a great system even without these man! -- Thanks a TON for sharing it dude!

 

I've managed to get nodes 'orphaned' in graphs if they are deleted/changed in the code -- is there a way of removing these invisible nodes somehow?

 

Thanks for the suggestions! I've already tried messing around with branching reroute points, but they quickly turned very complex and required certain changes to the core, so I abandoned that feature for now. The "portal" suggestion could be implemented pretty easily though. Just a bool to check whether to draw the next path or not. Could be interesting, but might also just add to the confusion as you can't directly see what connects to where.

The dot design is definitely something I'm gonna change. Making them smaller is a good idea. Tooltips could also be very helpful.

There is no comment rectangle available and I didn't plan on adding it. Instead, i want to add something similar, "groups" that let you collapse and expand collections of nodes. It's a stretch goal, but would help a lot with large graphs.

 

Not sure what you mean by 'orphaned'. Do you mean the Node asset exists but it's not on the graph's list? In that case you may have to manually re-add it to the list in the editor to be able to delete it. If you accidentally end up with a null child ScriptableObject, there's nothing really you can do. Those are completely impossible to touch, but luckily they don't do any harm. That's an issue with Unity. There is a script called NodeEditorAssetModProcessor.cs that tries to catch deleted scripts and remove the nodes before that happens. But it doesn't succeed always, if for example you delete a script outside Unity.

 

The orphans are in the graph's list, but are null and don't appear in the graph editor. Yes it sounds like a null child when I maybe changed the script class name or something.
I have a feeling it may be related to the strange invisible graph problem I had above?
Cheers,

 

Could be, not sure. If the SO can't find the script assigned to it, it becomes completely unusable.
Try taking a screenshot the next time the graph thing happens. Maybe I can see what it's about.

 

@Siccity

Just a quick question and a mention of a "bug" I've seen --


First the question:

What would I need to do in order to display a large image (i.e. centered around the grid/graph's origin point) behind all the nodes so that they overlay on top of the image, but the image still handles zoom correctly too?


Finally, the "bug":

I'm using 2017.1 atm and whenever I right-click to change the name of an empty node, it wants to Cut/Copy/Paste on me by popping up that dialogue for me to pick one. For some reason, selecting nodes requires a few clicks sometimes too. Maybe the two issues are related?

These are minor things, but could be confusing to anyone new to the system.

Either way, thanks again for the awesome framework man! -- I'm enjoying the workflow despite the learning curve!

 

For the image you would need to edit the xNode core, as there is no exposed methods to draw alternative grids yet.
you would need to open up NodeEditorGUI.cs, find the method DrawGrid(); and find a way for it to draw your image with
GUI.DrawTextureWithTexCoords(...);

I noticed the bug as well, I've been looking for solutions. Thank you for reporting it
Not sure about the selecting nodes part tough. For me it always works on first click. Are you clicking the header?

 

Actually, I am.

Seems like it only happens when I first open up the project and then the graph, and then select the header of the node. After clicking a couple of times, it reliably selects from then on and it's not possible to reproduce without closing the project again and reopening Unity. Any idea what might be doing this?

I've managed to do this successfully, however a repeating texture wasn't what I wanted -- just a regular image texture drawn only one time at a specific place in the world, centered and offset from the origin crosshairs (a rect, essentially, that accounts for zoom/pan.)

Seems like GridToWindowPositionNoClipped should be documented -- definitely was the only way I could manage this! -- I now only need to figure out where to place the code!

______________________________


EDIT -- Turns out the "where" was much harder than I anticipated.

If anyone else wants to be a badass like me and dig into the guts of this awesome tool, remember the zoom is a "trick" and deals with matrix resets. In order to draw stuff aligned to the "zoomed" grid, you'll need a combination of the above method on your rects combined with resetting the matrix. NodeEditorGUI.cs drawing events were particularly tricky to navigate around before I got to this point -- but I accomplished it!

I'm offering this here as a way to both say thanks to Siccity and also to save other users (who need to dig into the core) a few headaches with this in the future! n__n

 

@Siccity

Been digging into the core a bit lately and I've got held up on 2 things so far:


Firstly, I have an icon I'd like to add to the graph that requires no window at all -- only a single image file. Is there an easy-ish way to do this using the existing core node stuff? I know I'd probably have to write my own methods for this, but I need to know what parts are essential to getting the node to be a draggable "node" with data essentially. This would allow me to know where I need to look to extend / change parts of the node with my own classes.

Secondly, (I'm totally nitpicking here), but perhaps "GetWidth" is a bit misleading when you're looking to "set" the width of a node? You actually override it to return (and thus "set" a value) of a particular type of node, so maybe changing it to something like "OutputWidth" instead (or make a separate "Set" method) to make it more clear to stubborn people like me who can't fathom the idea of a "get" without the respective "set" -- FYI, I did see it in the docs, but I totally forgot about it when it came time to change my own node's width.


Outside of that, I was wondering -- is there an easy way I could layout a node like almost exactly like I would an editorwindow (i.e. perhaps overriding the node window's rect size and then putting controls anywhere in the rect area I wanted -- that, or just getting the node's rect so I can position my controls manually)? -- I'm noticing this might not be /quite/ as straightforward as I initially thought (due to the noodle stuff), but even for my exotic use-case, most of what I wanted to do is already offered in some form, so props to you for making that not only possible, but still fairly straightforward as well!


It's really amazing that your tool has been so easy to tweak/modify to such an exotic use as mine so far. Thanks again for your hard work man!

 

The first one is not really within the standard xNode bounds. Apart from creating a node type with the single purpose of displaying an image using NodeEditor, you can try extending the editor via the new OnGUI override for NodeGraphEditor, and manually add your image on top, applying correct offset and zoom from NodeEditorWindow.current.zoom/panOffset.

The GetWidth is no more misleading than SetWidth. It's similar to Unity's GetPropertyHeight. Breaking that consistency would cause even more confusion

Node GUIs function not as editorwindows, but as inspectors. The editor code is very similar, and you should be able to do about the same as you could in an editor window.

 

No worries -- like I said, my use-case is pretty exotic, but it's still surprising to me how flexible xNode is to be able to get me so close to do what I'm trying to do without having to rewrite all of your code! -- That's quite a feat!

I was thinking this was possible, but how do I modify the displaying of the node's window itself? -- I mainly just want to make it invisible for a particular node (but it'd be nice to be able to modify stuff like its "skin" too.)

That's why I offered the "OutputWidth" idea, but I can still see where you're coming from wanting to maintain consistency. I don't immediately go to something like "GetPropertyHeight" (despite also being very familiar with Editor scripting) when I think of "GetWidth" in the node context, so maybe it's just a "you" or "me" thing. Either way, maybe just throw a comment in the script just above the "GetWidth" method to let others know (in case they missed it) to override that function in their NodeEditor script to "set" the value or something? I only mentioned it because I was looking an unnaturally long time for a quick way to set the node width and had completely forgotten about the override in the examples. It was an honest mistake I'm sure others could just as easily make.

Yep, no worries! -- it was just my own first impressions about it since each of the nodes look like they'd be little "windows" that'd have their own rects. Seemed like it'd be a little simpler to program that way, but I also can see why you'd choose an inspector too! -- The inspector method seems like it'd be a lot simpler than trying to reposition everything at least.

 

I have used this plugin for a part of my game logic and it helped big time! thanks
I have a question, Is it possible to draw the nodes in the game scene on a ui or gui?

 

One problem I'm running into that I'd love some help on is implementing reorderable lists -- Is this possible to do in a node? All the solutions I've found, including Unity's own internal one, don't seem to like anything but the default Inspector...

 

It's possible, but you will need to implement it yourself. You can use any gui solution you like (IMGUI, UGUI, NGUI etc.). I might provide an example for this soon enough

 

I don't see why this shouldnt work. All other custom PropertyDrawers ive used have been working perfectly fine. Can you give me a link to the implementation?

 

i'm currently doing it manually by getting the values from the nodes. But what we all need is the same visual representation as xNodes because i'm in love with it xD it's so good that i took a screenshot and made some tweaks to use it in UI.
Looking forward to your example! keep up the good work

 

This is an implementation of Unity's internal version (which is actually really neat because you can customize its fields):

http://va.lent.in/unity-make-your-lists-functional-with-reorderablelist/


I also tried the following one (because I really liked the [Reorderable] attribute tag), but found that it didn't let you delete multiple items quickly with the "-" button since it deselects the last item you deleted and never re-selects the next item in the list/array so you can continuously delete stuff -- this behavior is very important because easily filling/clearing parts of an array is incredibly useful.) Here's that one:

https://github.com/SubjectNerd-Unity/ReorderableInspector



It's possible I'm doing it wrong (or trying to implement it in the wrong way/place/script), so please let me know what I need to do to get it right (preferably with Unity's implementation.) Unity's default (non-reorderable) array/list implementation is terrible in-general, but it is especially terrible for nodes.

It would be incredibly awesome if there were an OnReorderableListDraw() method we could override (or "Attribute" tags like in the second implementation I linked to above) that would assist in changing the fields included in our reorderable lists/arrays. This would be crazy-handy for something like Dialogue trees -- but a LOT more too! -- The nodes could be a lot smaller and data could be packed (visually) a lot more efficiently too.


EDIT:
I got the implementation @xeleh mentioned below to work with your custom inspector drawing, but only because it had a function to draw individual list fields. There were two ways I could have implemented it -- through the OnBodyGUI override in a custom NodeEditor and draw it all at once, or through the iteration loop itself and draw each field of the array one at a time -- but I chose the latter since it's a lot more hands-off in the editing process and, more importantly, it keeps all the serialized data in one place.

That said, I'm not entirely sure even that great implementation can do the data-packing I mentioned above (i.e. including multiple fields of different data types), but I won't write it off just yet since I've only just begun to look into it. Anyone who knows this ReorderableList extension's capabilities in that regard is welcome to chime in to clarify.

 

@awesomedata This is the best freely available implementation of a reorderable list for Unity in my humble opinion:

https://bitbucket.org/rotorz/reorderable-list-editor-field-for-unity

 

I think you're right -- I only saw the version on github, which required jumping through some hoops to get it running properly. This version is totally the opposite and I've already got it displaying in xNode!

Writing custom editor controls with serialization is something I've yet to get terribly familiar with, but I think I'm starting to get the hang of this stuff finally.

 

@Siccity

Not sure if you noticed (or if it's an issue to you), but the "blurry" text/controls you see in your nodes/etc is directly related to the exact value of your window's width/height size.

To complicate things, the exact value of your zoom upon zooming "in" is different than the one upon zooming "out" when your zoom value goes above 1.3 -- this gets worse the more you try zooming "out" too due to the precision loss.

This "extra" blurriness is likely caused by a combination of precision issues when dealing with the window size and zoom levels. Additionally, this blur is compounded by Unity's internal canvas on which it draws the contents of the EditorWindow depending on its size (i.e. the canvas shrinks as the window shrinks, and thus becomes less of a square texture -- thus it, too, becomes blurry.) The combined precision-loss from all of the above gives you that "super-blurring" you have now.)


A potential solution to two issues:

Keeping the window "square" tends to reduce the blur a LOT -- Perhaps you could draw the entire window image contents "square" (which means some window content would be drawn partially outside the window's visible area, depending upon the size of the window) to make the blur nearly non-existent? You could just draw this "square" texture at 0,0 at the top-left corner of the EditorWindow perhaps.

It seems like Unity is internally blurring it because it's resizing its canvas texture to match the window. If you can override this behavior by drawing your own square window texture, it should fix that part of it.



For the second issue -- ensure the "zoom" remains at 1x , 2x, 3x, etc. If you want a smoother transition (half-sizes), a 1.4x, 2.4x, 3.4x would be ideal (the ".4x" instead of the ".5x" would be to make it evenly-divisible by the window size). If this isn't possible due to positioning issues, ensure the zoom in/out values' precisions at least match.

 

@Siccity -- Looks like that Null Reference Exception error might have been introduced (rather than squashed) in that last update. I had not been having problems with the error before I updated to the latest version...

Seems like the NodeGraphWindow itself is giving two errors after I close and reopen a Node Graph window:

First this:

NullReferenceException:Object reference not set to an instance of an object
UnityEditor.EditorWindow:GetWindow(Type, Boolean, String, Boolean)
XNodeEditor.NodeEditorWindow:OnOpen(Int32, Int32) (at Assets/Scripts/Editor/NodeEditorWindow.cs:124)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)​

followed by:

NullReferenceException: Object reference not set to an instance of an object
XNodeEditor.NodeEditorPreferences.GetSettings () (at Assets/Scripts/Editor/NodeEditorPreferences.cs:82)
XNodeEditor.NodeEditorWindow.OnFocus () (at Assets/Scripts/Editor/NodeEditorWindow.cs:28)
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:232)
System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MethodBase.cs:115)
UnityEditor.HostView.Invoke (System.String methodName, System.Object obj) (at C:/buildslave/unity/build/Editor/Mono/HostView.cs:272)
UnityEditor.HostView.Invoke (System.String methodName) (at C:/buildslave/unity/build/Editor/Mono/HostView.cs:265)
UnityEditor.HostView.OnFocus () (at C:/buildslave/unity/build/Editor/Mono/HostView.cs:109)
UnityEditor.EditorWindow:GetWindow(Type, Boolean, String, Boolean)
XNodeEditor.NodeEditorWindow:OnOpen(Int32, Int32) (at Assets/Scripts/Editor/NodeEditorWindow.cs:124)
UnityEngine.GUIUtilityrocessEvent(Int32, IntPtr)​

 

I've noticed this error as well, but it doesn't seem to cause any direct issues. I ran a git bisect and identified the bug to have appeared on commit

2582d5aaf3cac7c769ee21cde7de449bee353e6f - Added option to disable autosave in preferences

I'm gonna have a look one of the following days and see what could be causing it and how to fix it.

 

Fixed! :]

 

Hey great framework! Awesome work, thank you very much.

One comment: It looks like the custom nodes are not recognized if the library is put inside the project plugins folder, and the nodes not.

The gragh creates correctly, but it fails to find the nodes, so the context menu wont list any node even if I manually set the menu path using the CreateNodeMenu attribute.

 

Thanks!

I think that's because Unity treats the Plugin folder in a special way, but I'm not sure how. I am aware of the issue. The immediate solution is to just put it anywhere else
I usually have mine in a folder named Submodules

 

All contents of plugins folder are compiled first, and in a separate assembly. So it doesnt have access to code outside it.

I followed the xNode code a bit more, and understood why it would not work. Maybe making the nodes to add themselves to a list of any particular graph would be more flexible. If time allows I will fork the framework and work on a different way to get the nodes.

Thanks again for such a great work.

 

That would be awesome man! -- I would really appreciate it if you managed to accomplish this. I too was having issues with that, but I couldn't figure out where to look to make it possible.

 

I've been trying to implement this, but a coroutine requires MonoBehaviour, and of course the node is a ScriptableObject. In general, I think my application needs to be able to keep track of time. Do you have some suggestions?

 

I usually use my own extension, CoroutineRunner:

Code (CSharp):

1. public static class Extensions {
2.     public class CoroutineRunner : MonoBehaviour { }
3.     private static CoroutineRunner coroutineRunner;
4.     public static Coroutine RunCoroutine(this IEnumerator ienum) {
5.         if (coroutineRunner == null) {
6.             coroutineRunner = new GameObject("[CoroutineRunner]").AddComponent<CoroutineRunner>();
7.             coroutineRunner.hideFlags = HideFlags.DontSaveInEditor | HideFlags.HideInHierarchy | HideFlags.HideInInspector | HideFlags.NotEditable | HideFlags.DontSaveInBuild;
8.             coroutineRunner.gameObject.hideFlags = HideFlags.DontSaveInEditor | HideFlags.HideInHierarchy | HideFlags.HideInInspector | HideFlags.NotEditable | HideFlags.DontSaveInBuild;
9.         }
10.         return coroutineRunner.StartCoroutine(ienum);
11.     }
12. }

The extension lets you call coroutines from anywhere, like TriggerNextNodes(port, 2f).RunCoroutine();

 

Nice! That worked great (much better than creating a dummy GameObject with a MonoBehavior). The only issue is that when control shifts to the next node, the GUI doesn't update (unless I click somewhere in the xNode window). I.e. the node header doesn't turn blue. Is there a way to force a NodeEditor OnNodeGUI()?

I should mention that for now, I'm working with the simple StateNode example and calling MoveNext to transfer to the next node.

Code (CSharp):

1. public IEnumerator NextNodes(float delay) {
2.    yield return new WaitForSeconds(delay);
3.    MoveNext ();
4. }

 

Could it be window a focus problem? Maybe the running of the coroutine pulls focus away from the editor window?

 

Try

NodeEditorWindow.current.Repaint();

And just for the record, CoroutineRunner does just create a dummy GameObject with a MonoBehavior