Simple node editor

In Create, NodeGUI and Calculate you can access the canvas with NodeEditor.curNodeCanvas as these are called by the framework.
This hasn't been added yet as that extra reference means extra work for the save system to replace the reference, but this can be added easily. When your external code makes use of the framework it's recommend to call NodeEditor.Begin/EndEditingCanvas around it so NodeEditor.curNodeCanvas is available.
Sure, you can add it, most likely in Node.InitBase, but you also need to make sure the reference is replaced. In NodeEditorSaveManager.CreateWorkingCopy you have to make sure to replace the reference in each node with the copied canvas. How to do that should be easy to figure out there.
Might add that though

You can see how both GetScriptableObject and CopyScriptableObjects are called in NodeEditorSaveManager.CreateWorkingCopy, too.
CopyScriptableObject is called like this:

Code (csharp):

1. node.CopyScriptableObjects ((ScriptableObject so) => ReplaceSO (allSOs, clonedSOs, so));

An example for both functions are:

Code (csharp):

1. ScriptableObject storedSO; // SO stored inside this node, not externally
2. Node refToOtherNode; // reference to a SO(Node) stored within the canvas by the save system
3.  
4. public override ScriptableObject[] GetScriptableObjects ()
5. { // return SOs with source in this node, like storedSO
6.     return new ScriptableObject[] { storedSO };
7. }
8. protected internal override void CopyScriptableObjects (System.Func<ScriptableObject, ScriptableObject> replaceSerializableObject)
9. { // Replace all references to SOs stored inside this canvas (Node, Knob, SO stored in any of the Nodes, etc.) but not to externally saved SOs like databases
10.     storedSO = replaceSerializableObject (storedSO);
11.     refToOtherNode = replaceSerializableObject (refToOtherNode); // not stored inside this node but the reference to the copied version still has to be updated
12. }

Hope that makes it more understandable. It's pseudo-code but should work

 

For now I can definitely live with NodeEditor.curNodeCanvas, since I just need to access properties of it for displaying in GUI. But a persistent reference might come in handy later.
Nice example. CopyScriptableObjects wasn't that obvious but now I understand
I will try to do the same with the canvas.

 

Got it working now. Added GetScriptableObjects and CopyScriptableObjects to NodeCanvas too. Can you please add these in develop too, so I can get updates of the Framework? I also added a DrawCanvasPropertyEditor() to NodeCanvas, because I Need to Display GUI for editing my new scriptableobjects in the canvas. This is then called in NodeEditorWindow.DrawSideWindow just like DrawNodePropertyEditor.

 

Good idea!
I plan to do alot of these hooks in the framework code, for example in the drawing routine of the canvas itself, so will likely add these together

 

Awesome, thanks! I was actually interested in how you implement RT rendering. In fact, I've got my own library for dependency graph evaluation that's not dependent on Unity and I was looking for a front end to allow for rendering within Unity.
So you're doing it all via old GUI. Do you think this is future proof? I wanted to use old GUI as well but it's stated everywhere that it's deprecated and new GUI is much better (more optimised as well?). I read a book on it but most of the time it seems that's it's mainly designed for creating it all in the editor rather then from code. I then tried to create some basic code for creating it programmatically but it's so painful (with all trigger and events setup, relative calculations/transformations - I've not even yet got to zooming and scrolling and it already seems too complicated, so I constantly feel I'm doing something wrong although I've done WinAPI, MFC and Qt programming in C++ in the past). You obviously have more experience with Unity and C#, so what are your thoughts on new vs old UI for this? Also are you aware of any performance implications when choosing between the two? Thanks!

PS I was also wondering if you're interested in decoupling your node evaluation/validation code from rendering code? I know you're mainly interested in Unity but this could make it easier to switch between new and old UI, for instance, and make code cleaner in general having specific system responsible only for a specific role rather than combining multiple aspects in a single entity (i.e. https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)).

PPS I've also got strange clipping artefact on example node (see attached)

 

Well, I don't know of any plans of them to remove it, and I don't think they will. It's still useful for alot of debugging cases (which they acknowledge in the IMGUI Doc) and it's used in the editor GUI so they have to maintain it either way.
They probably won't risk upsettign alot of users by removing it, atleast for now. And even if, be it to force users to use the new GUI because it's 'better', they probably will have an option to keep it.
Alot of 'probably' and 'I think's, because I can't exactly tell what they're up to. This is just what I would think would happen.

Anyway, the new GUI system is alot faster for normal use cases, which is why they prefer it. But for a Node Editor, it is indeed unacceptable. You probably could make everything work, but I imagine it being like double the work that has already been put into making the IMGUI system fit (which is alot because it has alot of problems aswell).
Some stationary GUI like the side window (or a toolbar, ...) would probably be good to use the new GUI system for, but the Canvas region, I don't think so.
You could do it though, by making nodes prefabs instead of creating them through code, but it would still be a pain and it would make creating nodes way harder and the whole system alot more difficult to mainain.

Other than that, I didn't use the new GUI system that often yet. I'm currently focussing on the editor, that means IMGUI only. Maybe someone with more experience with that system in particular could help you. But my personal opinion is keep using the IMGUI for complicated dynamic cases with advanced controls

No, probably won't decouble the node and the rendering. The node directly affects how it is drawn (in NodeGUI) and seperating it would mean theoretically better structure but also more source code than currently needed and more work involved creating nodes...
And for the above mentioned reasons it is unlikely Node Editor will ever use a different GUI system, atleast as far as I am concerned. And Nodes will always have a GUI.
IMO here simplicity comes first

Any lastly, yes I'm aware of that problem. It's not a problem solely to the ExampleNode, but the runtime GUI style. It's basically using a larger font because of different default fonts in Unity Editor and Runtime, so on some nodes the controls don't always fit anymore.
A solution for this is being worked on with dynamic node rect size, and a simplified version of that is already used in the WebGL demo (didn't want to resize all nodes to fit at runtime ).

 

Hello Seneral
First off, great work on this framework. I've implemented a data flow engine before and know how much work it can be.

I am investigating using the framework for only the Editor features (building graphs), while using my own back-end for the data flow and other logic. I see in the post above this that you are opposed to decoupling the node logic from the node rendering, and I understand your points. However, I'm hoping to find a relatively clean way to interface with the framework to achieve my goals.

For example, I would like to "inject" node definitions into the framework (NodeType.nodes) without coupling my node implementations to it with the use of the NodeAttribute. Since NodeType.nodes is public and static, I could just access it directly, but that would be ugly and might not work because I don't know when FetchNodes() is called. Ideally there would be some way to register with the framework as a "node provider" so that my code will be called inside of FetchNodes() and these additional nodes will be included in the nodes dictionary..

That way, I can implement a single Node class which acts as glue between the framework and my own node logic, thus achieving decoupling without needing to have two classes (one for UI, one for logic) per node.

What are your thoughts about this approach? Are there any other barriers or difficulties that you can think of to using the framework for just the editor?

 

Hey, thanks
I don't think it makes much sense to use the current unmodified framework, as modular as you might want it, to use with a completely different back-end structure the way you imagined it to be.
You don't want the framework to know about the nodes directly (through the node attribute). While the node attribute can be left out without problems, as it contains only meta data, so to speak, the actual regristration to the framework in NodeTypes makes only sense when the framework can actually DO something with you nodes (in this case, call NodeGUI on it to make it editable, saving, etc.). But for this you need to extend Node, which I'm assuming you don't want either.
So, it doesn't make sense to let the framework know of your node class because they are of unknown type, basically.

What you probably want instead (without adding direct dependancy to your existing classes) is some kind of wrapper around your existing back-end (like nodes referencing your data serving as a direct or indirect interface) or integrating your data back-end directly into the framework.
First option is easily done by extending nodes which serve as the wrapper, obviously, and support any callbacks and calls to the data backend.
Second option can be more flexible. As you don't use any existing interface in the framework you need to add it yourself. Whether you need to modify the actual framework code depends on your desired level of integration.
You only want to make it appear on the canvas and make it editable? Then it would be easy enough to fetch your data types yourself (similarily to NodeTypes) and make them accessible to the user through the context menu using the ContextFiller input attribute, as well as making them draw in the canvas (currently no callbacks for that, you'd need to directly modify NodeEditor.DrawSubCanvas - Plans to change that exist).
Saving and general structure is then assumed to be handled by the back-end you already have.

Hope that gave you an overview. Again, I personally won't make much efforts decoupling each part of the framework to serve absolute edge cases - I do think that with existing plans something like a custom backend is possible (see above) but you might then aswell get some reference from the framework just for the GUI part and implement the front-end with that help youself

 

Thanks for the detailed reply! I'll have a look into some of those options when I get a chance, and see how it goes.

 

While I'm slowly pushing out bits from my own customized version of the Node editor and dialog editor, focusing mostly on getting the proper structure before moving into fully overhauling their interface with theme support, I'd like to know what would the best approach be for us to start implementing a custom look without clogging up the nodes with custom theme injections.

With that in mind, I'm also thinking of implementing a compact view mode which especially suits dialog nodes but could be used for anything else. However the problem with that is that you would end up having the same position used, which may or may not overlap through the rest of the nodes, ending up complicating things moreso than it needs to be.

One approach I found with other node systems is that they keep the visual representations of the nodes as compact as possible, with a separate inspector window inside the node editor that is used to edit said nodes.

 

Hey Arthur,
I'm on a mobile so I'm keeping it short.
You can completely modify the whole GUISkin programmatically or with a new GUISkin asset by modifying NodeEditorGUI. Currently, it's only changing some default controls of the editor Skin to look a bit like the Pro skin, nothing fancy.

Someone already implemented that, you need to overwrite a method in your node called DrawNodePropertyEditor which will show up in the side panel (will have to find a different place, like a modal window, now that the toolbar is implemented - but you can always reenable the side panel). You can put all edit fields there and only show the Input/Output fields in the node

Hope that helps you!

 

Hey Seneral,

Thank you, it's exactly what I was looking for! I've got around making a modal window and set up DrawNodePropertyEditor to be drawn there, while populating each dialog nodes to overwrite DrawNodePropertyEditor method.

Now that the modal inspector window is done, I've also implemented a compact view, albeit still huge WIP, it's working well with the newly implemented dynamic node resizing along with calling OutputKnob after each dialog option.


Once both compact view and normal view is all set up properly, I'll move onto setting up a GUISkin, somewhat similar to my custom setup.

 

That's looking really good indeed

 

Hey guys!
Just announced my first tool, a Node Painting extension for TC2
Be sure to check it out!


Have you ever wanted more control over your procedurally generated terrains in TC2? Then TC2 Node Painter is for you!


What is TC2 Node Painter?

TC2 Node Painter allows you to paint TC2 nodes directly in the editor, greatly improving your terrain creation workflow, both procedual and painted.
It helps procedural terrain creators wanting more control over their terrain aswell as terrain painters laying out there terrain manually by offering more options on what to paint. Using this tool you can paint everything, from simple heights and splats over stone fields and forests to whole biomes with little setup required thanks to TC2's simple node editor interface.


Simple terrain height painting setup with auto-splatmapping and additional detail


Check TC2 Node Painter out here!

 

Just a small update, finished the compact view alongside with some substantial changes to the knobs.

If you think this looks like a worthy change I'm more than glad to include the changes for the main nodes as well.



P.S. TC2 Node Editor is looking good.

 

Wow, would really appreciate any addition, because that looks really good
Probably don't want the node GUI put in a side window to be forced, but the general idea is really good and would love to see it work with the toolbar in a seperate window!
I don't have much time working on the editor myself currently due to preparations for the release of TC2 node painter, but my next goal here will be to push knob modularity forth!

 

I have been thinking about sub canvases. I guess the easiest way would be to have a node that allows you to transition to another canvas for part of the tree, that would also be good for usability. Any idea on how that would work? Is there much overhead in loading in another canvas suddenly during runtime?

 

Btw, how do you resize a group?

 

No, not at all. You just load it into memory as any other asset simply by referencing it and then you can always traverse it by simply calling the traversal functions on it. Best way to do that would be a node in which you can choose a canvas to traverse, so the subCanvas can be integrated right inside the normal canvas flow
The biggest problem I see is getting apropriate Inputs/Outputs - currently this is only determined by nodes without inputs/outputs connections, so you might want to have dedicated Input/Output nodes. Also, I recommend taking a look at the Expression Node branch for dynamic node knob creation based on the inputs/outputs of the selected subcanvas when you want to take a fully generic way
Be sure to update us on this and maybe make a PR, I think it could come in quite handy!

There is a narrow border of about 10px around the region (visible only when hovering over it) that you can use to drag the extends of the canvas . You can drag only a single edge or a corner
I have to admit you need to know or try this as there is not real visual indication on how to do it...

 

In my usecase there would only be one output going into a sub-canvas, so a fixed node with one input where you can set a canvas reference, and one sub-root node with one output would do the trick, will experiment a bit with it.

Thanx, will try that for the group, its a bit hard to see that atm : p

 

Alright! Tell me if you experience problems

 

Hello,
I just wanted to come and say a huge thank you for this amazing node framework ! I'm a french game maker beginner, a low level coder, but a correct graphic designer and my english is quite bad, sorry for that
I'm currently on a game project where cameras are mostly statics cams (like for instance in the old Alone in the dark) and I'm using this node editor to plan and set my camera connections (which cam lead to which cam, which trigger launches which cam, which objects are exclusively enabled with which camera, etc ...) Even I can use this framework to achieve what I wanted and that's very usefull. So, really, thank you very very much.

 

Thank you for sharing! It's indeed looking very good, I'm glad it's being used so well

 

Hi,
I've come to a Point where I Need a persistent reference to the canvas in a Node.
I dont Need a General solution here, so I just tried to save a reference when the node is created, but that doesnt work. I guess because it creates a working copy. I also tried overriding CopyScriptableObjects and replacing that reference to the canvas but it throws an error "GetWorkingCopy: ScriptableObject LastSession was not copied before! It will be null!"

Any idea on this?

 

Hi,
nice work. thank you to @Seneral who shares that

 

Hey! Sorry was away the whole day.
The canvas object is the only ScriptableObject in the framework that get's copied first, but does not get added to the SO lookup list (original object -> copied object).
Depending on which branch your using, I can easily change that though, it's not complicated. In fact, I might even add a reference to the canvas in each node by default. But it will only affect the develop branch for now.
Usually you can get by with using NodeEditor.curNodeCanvas if your inside a default Node function (Create, NodeGUI, Calculate, ...) that get's called by the framework.

Thanks

 

Hi, Im using the develop branch right now, but a bit modified as I wrote some time ago:

I dont know, if you've already added these to develop?
NodeEditor.curNodeCanvas only works in the node editor. I might edit a cutscene node with my own editor, while the node editor is closed.

Thanks

 

Looks nice .. will you push that on asset store ? what is your timeline ?

 

No, didn't yet. Will add both to develop right now

 

Thanks! Yes, I plan to put it on the Asset Store when it's ready. It should not take much longer than one week anymore
Will also work on getting my website online before I'll publish.

 

They are online now aswell as a save system improvement (code structure and comments)

 

Thanks! Sorry for the late response, as I've been preoccupied as of late. That's the idea behind it, have both the toolbar and side window to work, but also giving the option to choose compact view or not. Without compact view, the nodes would show up as is, with all the properties editable. Just one thing I'd like to know before I merge the latest changes from the develoment branch and commiting the pull request, should the graphical change and placement to also be included or leave the default ones as is?

 

Hey, no problem.
Sounds good, just be aware allowing to switch between these modes pose some problems with the layout when nodes suddenly get alot bigger, they might overlap.
What are those graphical changes? About the knobs, I like them, but I don't know if they fit the other design elements. But considering I'm not a UI expert the whole UI could be a style-mess without me knowing lol.

 

Hey guys, just came across this today trying to learn how to extend my Editor! Quick question.
Would it be possible to add a camera to the node window, docked in the corner or something? I'm imagining a node based cutscene editor -- where you select a node, and a camera goes to the object the node represents.. then you create and link new nodes that will move the object. The camera will give you a better idea of what moving that character would look like.

Anyways, just thoughts. I have never done any editor scripting before, so Im looking forward to it!

 

Hi!
So you're nodes would represent states in the cutscene (camera position, dialogue options, triggers, etc.) and you want a live preview inside the node editor window, if I understood correctly?
That should be no problem, assuming you have the core cutscene functionality running you can transition to the state of the selected node and use a camera to create a preview in the GUI. This is usually done by setting the RenderTarget of the camera in question to a RenderTexture you can then draw in the GUI. Alternatively, you could let the game tab be the preview for the cutscene, usually alot easier and intuitive.
Hope I got that right

 

Thanks! I'm still new even to Custom Editor windows, so I probably have a bit to go before I get it implemented into the node tree (but not too far! Learning fast!)

Yes. I'd like to basically make each node a keyframe -- use it's x position as a time, then inside the node there would be actions--such as setting camera positions to lerp from/to, or making gameobjects execute animations, playing audio, showing dialogue, etc. The rendertexture would snapshot what that node would look like at that time.

It'd be like a cutscene node editor, basically =D. I know I'm still missing a lot of the big picture, but I do think something like this would be quite doable.

I'm practicing with custom editor windows for a bit -- when I get that down, I'll transition to the node editor. Thanks!

 

Well if you want the nodes to be timed by position, I'd recommend creating a dedicated timeline - much more intuitive.
Taking a step back, you might be better off using an existing cutscene editor. There are plenty of them around, is there really none that suits your needs?

 

I dunno how to do a timeline either, lol.

I'm sure there are -- but I want to learn how to make my own tools for Unity, tired of being bounded to what other people make. Especially to find out that they are poorly coded, or are overly complex. This is mostly a learning opportunity for me. A timeline would be better.. I just wanted to learn the node editor because I liked using node systems with Amplify Shader Editor and Map Magic. If you've resources for that (timeline), I'd love to see them.

 

Understood - although the tool will probably lack alot of features and still take lot's of time, just because these developers spend alot of time doing what they're extremely good at to create these tools.
As a learning project I wouldn't recommend a cutscene editor, that is really complex.
Here are some after a quick search - I make no claim that this list is complete and I apologize if I left any major tool out:
Cinema Director - Sequencer & Cutscene Editor
CutScene
Cinematic Sequencer - SLATE
uSequencer Cutscene and Cinematic creator
Flux

 

There's also animator. https://www.assetstore.unity3d.com/en/#!/content/3485

It's old but open source. After fixing the compiler errors, I got it working pretty well, but the problem with this one is the lack of extensibility. It's code is a monolithic junkyard. It would be to much of an effort, to add new action types. I also found it unnessecarily complex so I ended up, doing my own from scratch, to be able to add new action types just by inheriting an action base class much like in senerals node editor.

Again: Animator works well, if you're satisfied with the actiontypes it comes with. Moving Cameras around is definitly covered.

 

I'll probably hold these style changes off, at least for now. Also before adding compact view it'd probably be a good idea to have some hit detection to check if there aren't any nodes overlapping eachother, or just simply store positions for the two states. I'll see what I can do about the styles. By the way, what's the current status on multiple output support?

There's also MateAnimator which supposed to be the maintained version of Animator.

 

Greetings Seneral and Baste, thanks for all the hard work it took to get this framework up and running. I got ahold of it last week and have been using it to write an editor for a project of mine, and so far its been fun. I do have a major issue that I am running into that maybe you all have encountered with others before, let me know what you think.

The Node Editor relies heavily on Unity's Serializer, which is a real problem when you have a node extension that has generic objects that you want to save and load.

public interface Item {}
public class ItemA : Item {}
public class ItemB : Item {}
public class MyNode : Node
{
[This does not serialize]
private List<Item> myList;
}

I know that Newtonsoft's JSON plugin can serialize these things, but that would require going through the entire framework and converting all the serialize flags to newtonsoft, which is doable, but definitely a pain. Wondering if you guys may have encountered a better way to accomplish this . . .

Still, its a powerful framework. With a bit more cleanup and documentation, I'd say some version of this baby needs to make it officially into Unity at some point.

Thanks again!

 

Cool - yes compact view can be a bit of a problem layout-wise. And honestly, I don't think there's a good way to fix that generally. Currently, we have to options to display the GUI (with your changes): In the node or in the side window. This is a good starting point and has to be decided beforehand.
Now, a collapsable state for the whole canvas would effectively require a re-layout. But a collapsable state on single nodes would not be too much of a problem for the user.
We could try this out... But I'm currently completely occupied by the release phase of my TC2 Node Painter extension and RL. That's also why I haven't made any progression on the new output system.
Thanks for all the input and support of your dialogue example - really amazing!

 

Hi - thanks for the kind words
Yes, I'd also very much prefer to get away from the default serialization system - it is very much a pain
We do have plans to get a runtime-compatible manually-serialized save system ready, though. Either JSON or XML - haven't decided yet.
But as I said, I do not have enough time right now to implement it myself...

And yes, pretty happy with the development so far But still, there are a few things missing, not only documentation - f.E. proper Undo support. That is my next thing I'll definitely take a look at once I got time

Seneral

 

Quick question for you. Is there a specific reason each output is allowed to output connect to multiple nodes, but a single Input knob can only hold 1 connection at a time? I see this code in NodeInput commented out:

protected internal override void CopyScriptableObjects (System.Func<ScriptableObject, ScriptableObject> replaceSerializableObject)
{
connection = replaceSerializableObject.Invoke (connection) as NodeOutput;
// Multiple connections
// for (int conCnt = 0; conCnt < connections.Count; conCnt++)
// connections[conCnt] = replaceSerializableObject.Invoke (connections[conCnt]) as NodeOutput;
}

So it looks like you had it at one point, then decided against it?

 

No, initial decision was exactly as it is right now (which is, I have to admit, very unflexible). This was initially designed for calculation, where it makes sense a calculation result can be used multiple times but a node that can only take two inputs should only get two values.
But of course, for say dialogue systems, this is totally unusuable - you can have multiple options pointing to a dialogue state, but the result on one choice has exactly one outcome.
We are aware of this and have been designing a new Input/Output system (that allows for both options and much more), missing is just the implementation... you can see our discussion here.
Hope that gave you an idea

 

ahh excellent, thanks for the link.

Yes, there are many ways to tackle this particular problem, so its cool to read the ongoing discussion on it. I can solve my particular issue quick and dirty by just generating N knobs, 1 for each connection, so its not a huge roadblock for me at the moment. I was more just curious, and the Calculation logic makes sense to a degree, but I would argue that by limiting the number of connections to the input, you are forcing a 2 to 1 relationship, and forcing a new node when you might not necessarily need it.

For example, if I had a calculation node that multiplied 2 inputs to produce 1 product output, you could only connect 2 nodes to the inputs, and run the calculation only once. If you end up having to multiply 2 numbers multiple times in a single node tree, you are duplicating nodes for what purpose? You could just have a single 'Multiplier Node', and anything that needs to multiply could connect to it.

Just stuff to think about

 

Yes, indeed good points - that's why we're redesigning everything in that matter
Hope to get some progress on Undo first (after I've time again) and then I'll implement our ideas - although that would only be a first draft, but most probably it will be feasable
If you have any other ideas about how to improve our ideas, don't hesitate to add your ideas in the issue.

 

Hello,

My question will probably looks quite weird, but whatever... ^^

I'm actually developing a node editor "Game" with Unity. The fact is that I see a lot of node editors around, but I suppose that they are more for the intern/programming part of the games. My particularity is that I want the final game to be a 3D node editor ! Like you run the game, can open an already made 3D node network and then add nodes, edit them etc...

Do you think it would be actually possible to use a node editor tool like yours but for the game itself ?
The secondary question being, do you thing that it is doable to add the third dimension to this kind of tools ?

I hope my question is clear... ^^
Gratefully,
Daniel.

 

Hey,
interesting question you have there

Adding the third dimension as is is not very problematic, but that will make all existing GUI work useless and you'd have to write your own node rendering completely from scratch...
Doing it in 3D is probably easier than in the GUI (other than the editor control part) but it's still alot of work.
The framework including GUI runs perfectly well at runtime, but as your scrapping the GUI either way that's not much of a thing. Essentially you could use any node editor as the base as most support loading, managing and execution at runtime (I would suppose) so you might have luck with a different tool if you would want to.
But of course this framework would be suited just as good or better than others...
It really depends on the structure now, not the GUI - depending on what you want to use it for, a solution that already explicitly supports this might serve you better.

Anyway, hope you're able to do what you want Would love to see how it turns out - can't imagine a Node Editor in 3D, to be honest...
Seneral