Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Simple node editor

Discussion in 'Immediate Mode GUI (IMGUI)' started by unimechanic, Jul 5, 2013.

  1. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    I love you guys!

    I've been looking for a way to make my conversation tree editor easier to work with (gotten some minor complaints from the writer...), and I think this is the way to write a good view. Great job!

    @nasoukikos, I'll check out your videos when I get home. Might just look into that patreon of your if they're good.
     
    AthosK likes this.
  2. AthosK

    AthosK

    Joined:
    Jan 20, 2013
    Posts:
    428
    Hey thanks! I plan to make a part 3 when I free up some time, pm if you need anything so that we don't get offtopic from this thread :)
     
  3. Connor2164

    Connor2164

    Joined:
    Oct 12, 2014
    Posts:
    1
    Is there any tutorial for making custom nodes? (Besides just modifying the input and output nodes) I want to be able to put inspector properties and assign objects to variables by dragging and dropping them onto the editor windows
     
  4. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Not really, but I might work that out soon. It's pretty simple, and the three example nodes should just demonstrate what you HAVE to do.

    As of recently, there's now a proper documentation in the Github repo, Check my first post here again:)
     
    Last edited: Jul 1, 2015
  5. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    I updated my post. In short: There's now a proper doc, Baste has setup a GitHub repo for NodeEditor and I'm announcing an update!
     
  6. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    Related: does anyone have any experience with putting open source projects up as free downloads on the store?
     
  7. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Does it make any difference that it's open source and free? Shouldn't differ from usual submission I guess.
     
  8. tswalk

    tswalk

    Joined:
    Jul 27, 2013
    Posts:
    1,109
    I would think it would be easier to deal with if you did as Seneral has and put it out on github or something similar.... why go through all the extra stuff needed to put it on the store?
     
  9. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    Hehe, I put it on github. I just know that more people would see it if we put a stable release up on the store at one point, which is why I'm asking.
     
  10. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Well, I don't think either putting it on the store is necessary. If people need a Node Editor, they will likely google it first. And then the first result they will stumble upon is this one:)

    While I'm at it, I just finished the feature to scale the node canvas. It works, but GUI.matrix is a nasty piece and I had to hack in order to make the clipping zone correct and to make it scale to the center instead of the top left corner. Additionally, some controls are not even scaled and positioned correctly by GUI.matrix, like the dropdown.

    In the next few days I'm going to implement some other goodies and reworking and update the docs.
     
  11. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    If anyone wants to see the work in progress (or submit pull requests), the repo is here.

    We're not guaranteeing stability or anything at this point - we'll probably break the save format a couple of times in the comming weeks.
     
  12. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Exactly. I'm just about to submit the scale feature, so keep an eye on the repo;)
     
  13. Jagwire

    Jagwire

    Joined:
    Dec 5, 2013
    Posts:
    59
    I've been following this thread and working through the videos and I have to say I'm super excited about this. This is a great collaboration! I'm curious though, if it were to be translated to a runtime (read: during gameplay) version, what would it take?

    Keep up the awesome work!
     
  14. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Nice to hear there is interest in Node Editor! :)

    I already had the same idea and I'm planning to implement it at some point, after finishing features like multiple selection handling, node areas and loading seperate canvases as nodes (perhaps even directly editing them).
    It's not that of a trouble, though. If you look into the calculation code, the few functions responsible for calculation aren't depending on anything editor related. You could probably just cut them out, paste them into a MonoBehaviour and use them at runtime:)
    That's the huge advantage of using ScriptableObjects as a format!

    EDIT to RT:
    Sorry, I misunderstood you:O
    Calculation of preset canvases and thus feeding new values is pretty easy, described above. Regarding your real question: I'm not exactly sure. After a quick glance at the code, besides the saving/loading part into the AssetDatabase, everything should be portable, I guess. But that's a thing I probably won't do, if you ever were to port it, please put it up as a branch on your GitHub repo! ;)

    2. EDIT:
    The framework is now mostly updated to support runtime, most editor parts are now extended by a runtime part. A sample component 'RuntimeNodeEditor' shows the runtime usage:)

    An update on my progress:
    Making immense code restructures, making every function as independant as possible.
    Advantages? The system isn't bound to the main canvas anymore, and multiple canvases opened at once in the same window, editing the same node canvas with different views (SplitScreen) and even nested node canvases will be possible!

    Here's a WIP screen showing nested node canvases in a so called 'GroupNode':
    NestedCanvases_NodeGroup.jpg
    Procedural Inputs/Outputs of it is being worked on.
    Do note that, though, what you see there is still WIP and not fully working yet. For example, the clipping rect of the nested canvas is still not correctly transformed.
    Besides that, everything is working for now, the nested canvas behaves just like it's parent.And i could add another group node inside that one and it would still work;)

    Best regards,
    Seneral
     
    Last edited: Dec 26, 2015
  15. Jagwire

    Jagwire

    Joined:
    Dec 5, 2013
    Posts:
    59
    I think the part that frightened my the most was the rendering side. Drawing windows, drawing bezier curves, and other 2D things outside of the UnityEditor namespace seems a bit much. I'm not 100% why Unity didn't expose the Handles and utilities outside of the editor...
     
  16. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    I'm sure there's an alternative bezier formula out there and I would be glad to use it xD But besides that, I see no obvious reasons why it shouldn't work;)
     
  17. Jagwire

    Jagwire

    Joined:
    Dec 5, 2013
    Posts:
    59
    So I've been looking at the code a bit, and I have a few observations:

    1) There seems to be a fair amount of modification to the framework involved to create new Node types. Let's say for example, we wanted to create a Vector3-modeled node--simply put, 3 float inputs, and 1 Vector3 output. First we would add our class, based off any of the 3 examples, then we "register" it with the NodeEditor. THEN, we need to modify the TypeOf enumeration to include a Vector3 entry, THEN we need to define typeData for it. I wonder if it makes sense to have a custom attribute say: NodeType, and TypeOf to be used ala:
    Code (csharp):
    1.  
    2. [NodeType("Vector3", "Add Vector3 Node")]
    3. [System.Serializable]
    4. public class Vector3Node : Node {
    5.     Create() { ... }
    6.     NodeGUI() { ... }
    7.     Calculate() { ... }
    8. }
    9.  
    using reflection, we can scan the assembly, find all classes annotated with NodeType, and register them appropriately from within Node_Editor, without exposing the Node_Editor's delicate underbelly to pesky programmers :)

    The piece I've left out is the ability to add custom input/output types. I think we could use the same pattern for this in some way. I'm less confident about this design piece, so forgive if it seems silly:
    Code (csharp):
    1.  
    2. interface TypeConfig {
    3.     string InputKnob { get; }
    4.     string OutputKnob { get; }
    5.     Color ConnectionColor { get; }
    6. }
    7.  
    Code (csharp):
    1.  
    2. [InputOutputType("Vector3")]
    3. public class Vector3Type : TypeConfig {
    4. ...
    5.    public string InputKnob {
    6.        get {
    7.            return "Textures/My_In_Knob.png";
    8.        }
    9.    }
    10.  
    11.    public string OutputKnob {
    12.        get {
    13.            return "Textures/My_Out_Knob.png";
    14.        }
    15.    }
    16.  
    17.    public Color ConnectionColor {
    18.         get {
    19.            return Color.cyan;
    20.        }
    21.    }
    22. }
    23.  
    Again, on startup, the Node_Editor could scan the assembly and "register" each of these types so they can be used in custom nodes ala:
    Code (csharp):
    1.  
    2. static Vector3Node Create(Rect NodeRect) {
    3.      //...
    4.      NodeOutput.Create(node, "Output Vector3", TypeOf("Vector3"));
    5. }
    6.  
    This way, not only can programmers extend the capabilities, but share them as well with others.

    2) I don't seem to see a way to walk the graph outside of the calculation routines... For example, let's say instead of doing calculations, I just want my designer to be able to add and connect an arbitrary amount of positions (read: Vector3) in sequence. Let's say it's a pathway for a motorcycle to drive in a big circle. I would probably want to serialize this in the form of:
    Code (csharp):
    1.  
    2. [System.Serializable]
    3. public class Pathway {
    4.    List<Vector3> pathPoints;
    5. }
    6.  
    This could be completely straightforward and I'm just being dense, I just wasn't able to find it given 15 or so...

    Other use cases of walking the graph could be AI behavior. First execute routine at starting node and continue in sequence.

    Finally, and this is rather tangential to the implementation itself, but when can you use EditorGUI vs GUI and their respective Layout counterparts?

    I hope this isn't too much at once, I didn't want to forget anything :) Again, this really is awesome stuff and I can't wait to keep going!
     
  18. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Indeed alot, but no problem:)

    1)
    These are possible alternatives that I'll consider implementing at some point, but for now, registering it in the main calss has to suffice I guess. I don't get your fist suggestion, though, as you are giving a Node a type in the attribute... Though, the second one seems to be very reasonable:)
    In my point of view making the code modifyable without exposing it is pretty senseless, as it can be found open source here anyways;)
    A faster alternative for now, if you really want to hide your code, is to move the Type/Typedata code and the context menu code outside into a seperate, exposed script.

    2)
    It's already possible to do something like a walking path, though it's somehow a hack and not optimised. You can just assign the output you want to 'walk along' and leave every other output null in your calculate function, and presuming the following node checks whether any input isn't null, it'll continue there.
    But implementing the 'walking' calculation isn't hard. If you want, you can do that;) I'll be busy with some other features in the next week...

    Best regards,
    Seneral
     
    Last edited: Jun 23, 2015
  19. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    Do feel free to submit patches, Jagwire!

    I'm working on figuring out a way to replicate the behaviour of the CustomInspector pattern in Unity. I kinda want to enable users to do this:

    Code (CSharp):
    1. [CustomNodeEditor(typeof(MyComponent))]
    2. public class MyComponentNodeEditor : NodeEditor {
    3.  
    4.     public override Node[] GetAllNodes() {
    5.         //implement defining all of the nodes that should be drawn here
    6.     }
    7.  
    8.     public override void OnNodeChange(Node node) {
    9.         //implement reacting to a node changing here
    10.     }
    11.  
    12.     public override void OnEdgeChange(Edge edge) {
    13.         //implement reacting to an edge changing here
    14.     }
    15.  
    16. }
    Or something along those lines. This will probably be a seperate from the main setup - instead of saving and loading canvases, you use a canvas as a view for some other model. I'll want this to work for both ScriptableObjects and MonoBehaviours, and draw the correct canvas for whatever you click on - as you do with the normal inspector. This will probably be a NodeInspector window, which is a different window from the NodeEditor window.

    Nothing of this is written yet - as of now I'm looking into finding the correct implementation based on what the current selection is. I'll also try to figure out some design on how the script should look and what features the inspector needs, so if you have any feedback before I really get going, that'd be great.
     
  20. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    So to make it clearer, do you want to display something like an inspector for an object, just in a node? Or what do you mean with making a canvas to display a MonoBehaviour like the inspector?
    What do you imagine where it could be used? And when it's possible, try to make it useable for other, similar purposes too:)

    Regarding your implementation, assuming you want to make an inspector-like node/Nodecanvas, you would have to iterate through the members and fields of the custom type using reflection, then swicthing their types and choose appropriate GUI representations for them. just the basic idea behind, hopefully:)

    And what about the 'Edge'? It's like a connection changed at the edge of the node?
     
  21. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    Say you have a MonoBehaviour wrapper around a road network in a game, looking something like this:

    Code (CSharp):
    1. public class RoadNetwork : MonoBehaviour {
    2.  
    3.     public Transform[] cities;
    4.     public Road[] roads;
    5.  
    6.     public Transform[] GetShortestPath(Transform fromTown, Transform toTown) {
    7.         ....
    8.     }
    9.  
    10.     [System.Serializeable]
    11.     public class Roads {
    12.         private int startCity;
    13.         private int endCity;
    14.     }
    15.  
    16. }
    Each road simply holds the index in the cities-array of the endpoints of the road. This is simple enough stuff - it's pretty much a graph with fancy names.

    Anyways, the first part of the CustomNodeEditor script would look something along the lines of this:

    Code (CSharp):
    1. [CustomNodeEditor(typeof(RoadNetwork)]
    2. public class RoadNetworkNodeEditor : NodeEditor {
    3.  
    4.     public override void GetAllNodes() {
    5.         RoadNetwork roadNetwork = (RoadNetwork) target; // as in customEditor,
    6.  
    7.         Node[] allNodes = new Node[roadNetwork.cities.Length];
    8.         for(int i = 0; i < allNodes.Length; i++) {
    9.             allNodes[i] = new RoadNetworkNode();
    10.         }
    11.        
    12.         for(int i = 0; i < roadNetwork.roads.Length; i++) {
    13.             Road r = roadNetwork.roads[i];
    14.             allNodes[r.startCity].AddEdgeTo(allNodes[r.endCity]);
    15.         }
    16.     }
    17.  
    18.     public class RoadNetworkNode : Node {
    19.          public void AddEdgeTo(RoadNetworkNode) {
    20.              //Setup the input/output stuff
    21.          }
    22.     }
    23. }
    Now, the trick here is that if you have the NodeInspector window, and click a GameObject containing a RoadNetwork component, the window will:

    - Find the RoadNetworkNodeEditor script based on the CustomNodeEditor attribute (made this work just now!)
    - Instantiate a new RoadNetworkNodeEditor (made this work too!)
    - Create a new canvas, and fill it with the nodes from GetAllNodes()

    Then, whenever you use the normal controls in the canvas to add or remove inputs and outputs, that would edit the roads array, through some callback mechanims I'm not quite sure about. If you have stuff like good/bad roads, and names for the cities, you could add that to the nodes and have changes to that reflect back to the RoadNetwork.

    This is an example of something I think would be incredibly powerfull - the ability to create some kind of Node-based view for your components.

    There's some issues here - first of all the way this stuff works isn't quite the same as how the Node Editor is set up now. What I'm thinking of here is more along the lines of a classical graph. The system we have now is a bit more advanced - instead of Edges, it has NodeInput and NodeOutput, which are special cases.

    I think I'll try to solve that by extracting some kind of edge concept from what the NodeInput and NodeOutput shares. Essentially, there's a lower-level graph that lives somewhere inside the Input/Output canvas, and I'll try to extract that to enable a lot more flexibility of the system.

    Does that make sense?

    I won't be getting this done very quickly - we're trying to crank out a playable demo to show off at shows and whatever - but I've got vacation comming up, so I should be able to do some real work on this soonish.
     
  22. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Makes more sense now:) And indeed, that would be useful for alot of cases and worth implementing.

    Just one problem, which you already mentioned: The current Node Editor is specialized. I thought about modifying the NodeInput/NodeOutput, to make it fit for a new, seperate 'walking' calculation system.
    But, to get the most out of it, we need a system that supports the 'walking path' - like calculation as well as the current calculation.

    What about leaving the current system, because it needs little modification in order to be transformed into a walking path calculation system!
    Basically, it's the same concept. We just need a bool in the NodeOutput whether to go to the connected nodes. Additional data can still be passed through the NodeOutput.value. If we really want, we also can abandon the Drag'n'drop Knobs in order to connect, and go with a different approach previously posted in this thread (this post and the following one) to fit the usual style those systems have. But that would be everything we need to change, wouldn't it?

    I've vacances ahead, too, so I'll have alot of time to invest into NodeEditor:)
     
  23. ThatGuyFromTheWeb

    ThatGuyFromTheWeb

    Joined:
    Jan 23, 2014
    Posts:
    29
    Hi. I'm currently writing a (specialised, non-generic) node editor including a reflection based custom inspector for a project of mine, so i'm curious about what you guys are doing here and trying to achieve. One thing i didn't understand is, what this 'walking path' thing is supposed to be.
    How and in what order are nodes evaluated now and what is the difference in the model you guys are planning to implement?
     
  24. Jagwire

    Jagwire

    Joined:
    Dec 5, 2013
    Posts:
    59
    I don't want to speak for the others, but basically, given a Graph data structure, walking is exactly what your question is about--evaluating nodes in a particular order. I'm most interested in creating visual graphs such as these to populate data models such as a dialogue sequence or a game object with configurable components.

    I think the idea here would be a Depth-first traversal which is to say, given a "root" or "main" node, find the nodes connected to it that are the furthest away from it, based on connections, with no child dependencies. Once they are found evaluate them, and then pass those values back up the chain toward the root.
     
  25. ThatGuyFromTheWeb

    ThatGuyFromTheWeb

    Joined:
    Jan 23, 2014
    Posts:
    29
    I think i understood that part. Depth first is what i currently use for my editor. And judging by the function evaluation samples, it seems to be the way, it works in this editor right now. What Seneral wrote sounds more like a special kind of evaluation function inside the nodes, to determine, which node(s?) to visit next and which nodes to skip - which reminds of the behaviour trees i've seen around. Anyway ... interesting project, keep it up. :)
     
  26. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Currently, nodes will be 'calculated' (or visited, whatever) when every 'descendant' has already been calculated. That's suitable for plenty of editor systems related to Calculating/Processing (like substance's node editor) and alot more.

    Then, there's the 'walking', how I call it, where nodes are only calculated/visited, when some other node has pointed to it, and if some conditions are met. Basically that's what Jagwire explained, and that's what I'll implement next. And indeed, it's somewhat a behaviour tree:)

    Are there any methods I'm missing which will be worth implementing?

    Wow, sounds cool! Will you consider sharing that reflection based inspector with us, so we might even implement that as a node? That would be amazing, mixed with a function-call node and procedural inputs/outputs to access the members of the objects in those inspector nodes!
     
  27. ThatGuyFromTheWeb

    ThatGuyFromTheWeb

    Joined:
    Jan 23, 2014
    Posts:
    29
    I'm not sure, this would do you any good. Basically it's only an extension of the ExposeProperties script from the wiki, that can handle submembers using recursion and some custom attributes. Nothing fancy there. More importantly, the overall structure is not very good and it can only support classes that have a certain member design. Which is ok for me, since i write those classes, but it is not open enough to handle other stuff people would want to put into these nodes.

    You may want to take closer look at VFW. Its open source, on github and has support for a ton of things. There is an example showing his drawers in an editor window. It's a bit overwhelming at first ... but can do pretty cool things.
     
  28. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Ok then, but thanks for the hint to look at VFW, it's indeed interesting to look how that would look like. Maybe I'm going further into this topic at some point...
     
  29. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Just updated the Github repo with a new update:

    Major code restructures, seperation of the editor window and the core, MUCH easier implementation of custom Types and Nodes, etc.

    Im fact, too much to even remember what I changed...
    - You'll see I changed some file names, sorry about that, all for consistency!
    - Major restructure in how the canvas(es) are handled: Multiple canvases are allowed, and soon nested, too. Now in any transformation.
    - Automatic registration of Types/Nodes! Thanks Jagwire for the model you proposed!
    - Seperated EditorWindow and NodeEditor core: Marked editor specific code with #if UNITY_EDITOR. Any help to port this code to be compatible without UnityEditor is greatly appreciated!
    - Other changes here and there

    Also, saves are wiped (All wipes usually come when the way connection types are stored changes).
    Sorry for not having updated the docs yet, you'll probably have to take a look into the code if something's not as usual. Maybe look into the example nodes!

    I've waited long to publish the massive code restructure regarding NodeCanvases because I whished to finish nested NodeCanvases first, but well, I decided to first pick up Jagwire's model which makes registration of Nodes/Types not necessary anymore! Yay! Thanks alot for that, Jagwire! When I implemented that, I figured that it wouldn't harm to publish at all. GroupNode just behaves weird regarding the clipping Rect for now, but I'll fix that soon.

    Best regards,
    Seneral

    Edit: Do note that you additional Types/Nodes have to be in the Plugins folder, else they wont be found. That's because of the current assembly, I'm working on a way to search the default one, too.
     
    Last edited: Jul 2, 2015
    Jagwire likes this.
  30. Jagwire

    Jagwire

    Joined:
    Dec 5, 2013
    Posts:
    59
    Cool. Glad I was able to help!
     
  31. Mars91

    Mars91

    Joined:
    Mar 6, 2012
    Posts:
    572
    Hi,
    It's possible for you to make your framework compatible with Unity4.x?
    I'm getting rect.position error on unity 4.3.4 while no problem found on Unity5
     
  32. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Hm don't know about any changes in that area. Does that error appear on every call to Rect.position? Can you send a screen?
    Unfortunately I currently have no install of Unity 4 running...
     
    Last edited: Jul 4, 2015
  33. Blue-Candle-Games

    Blue-Candle-Games

    Joined:
    Jun 17, 2015
    Posts:
    4
    Can this resource be used in a commercial project?
     
  34. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Nvm, see Bastes answer below:)
     
    Last edited: Dec 26, 2015
  35. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,294
    The project has the MIT license (I swear I put it in there somewhere), which pretty much means "do whatever".

    Honestly, it should probably be on the WTFPL, it just wasn't one of the ones that are automatically available :p
     
    Seneral and ThatGuyFromTheWeb like this.
  36. Mars91

    Mars91

    Joined:
    Mar 6, 2012
    Posts:
    572
    It happens only for a single call I will post a screen asap ;)
     
  37. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    I assume asap is still this week? ;) Would like to know what was causing this...
     
  38. mdeforge07

    mdeforge07

    Joined:
    Jun 4, 2012
    Posts:
    9
    I like this project, but am struggling to understand how to connect to so I can use what I make in the node editor at run time.
     
  39. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    What exactly do you mean with "What I make in the Node Editor"?

    You can use the canvases at runtime you create, aslong as no node use the 'UnityEditor' namespace.
    IF you use Editor GUI functions in the Node's GUI code, they must be enclosed with a preprocessor check and accessed like that:
    Code (csharp):
    1. #if UNITY_EDITOR
    2. UnityEditor.EditorGUILayout....
    3. #endif
    Then, you can read out and calculate your canvas at runtime using the functions found in the Calculation region in NodeEditor.cs.

    If you mean the calculated result of the example nodes, you're right, you can't use them at runtime cause it wouldn't make any sense. But it's not intended that way, after all, NodeEditor is a framework where you can build your Editor Extension on, and you will have to implement any of the custom functionality into the Nodes yourself.
    F.E., If you're doing a 'Material Editor', you would have to add the ability to mix materials together and save them yourself.

    If you need any further help, just ask, I'm remaking the docs in the following days, which should clear up similar questions
    Sorry for not doing many updates, I'm currently busy at TESRenewal :D
     
  40. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    Guys this stuff is awesome, just what I was looking for.

    Major thumbs up!
     
  41. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    The MIT license is in the Docs folder.
     
  42. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    As the latest member of this community I have to say this project is Awesome!

    Last night I checked out the latest git and hit the following problems.
    1. Texture paths incorrect, silly me didn't put it in plugins
    2. Textures not read enabled
    3. Textures not setup with Bypass sRGB Sampling (needed for projects that use Linear color space)
    4. Base Node contains Calculate, that's not relevant to me... should be added as a CalculateableNode extension.
    #1 check if the texture is at the correct path, throw a meaningful error.
    #2-#3 This is a unity project commit with meta files.
    #4 Code Cleanup, no rush.

    I fixed 1-3 and made a pull request and it was merged super fast by Seneral, Awesome!

    Then I made a very simple dialogue system with title, body, and options, each leading to separate new dialogues, all tied up with events. I hit a few minor obstacles with the ease of use that I think we need helpers for. For instance right now it takes a very specific if statement to setup a knob. There should be a helper function that did all of this check automatically for ease of use.

    PlaceGUIOutputKnobHere(int index);
    PlaceGUIInputKnobHere(int index);

    I know Skype isn't the perfect media, but it's the only place I'm online so if anyone want to have a skype chat about the future of this project pm me. In my opinion the Unity Community needs a strong node graph system and this being both open source and off to a great start tells me we got a winner.

    My initial take is that the project is suffering from two flaws.
    1. Poor visibility, I had been searching for node systems for more than an hour before I found it.
    2. Poor usability, several tiny errors cost me hours first at getting it to work, and then when I tried to extend it.
    I suggest we fix them in reverse order, let's wrap up the usability with something like my suggested knob helpers above. I want it so simple that everyone can create their own nodes without having to learn the internals of the library. Let's also fix the lost work on recompile, all this stuff serializes so there is no excuse for data loss. This is Unity and code is supposed to change. Also the panel to the right is very useful but it takes up a lot of space and does nothing that justifies the space, I believe a few icon buttons would be better.

    Also let's add a few common examples like a simple Dialogue system and a simple State machine.

    Seneral that texture processing looks super awesome is that open source too?

    Cheers,
    Joen - UnLogick
     
  43. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,745
    I've started adding more PlaceGUI helpers to mimic the EditorGUILayout functions with non editor specific code.
    Also added CreateInput and CreateOutput wrappers to make nicer code.

    As a result this is how my wip State node class looks.
    Code (CSharp):
    1. [System.Serializable]
    2. [Node(false, "State Machine/State")]
    3. public class StateNode : Node
    4. {
    5.     public UnityEvent OnEnter;
    6.     public UnityEvent OnLeave;
    7.     public string stateName = "";
    8.  
    9.     public override string GetID
    10.     {
    11.         get { return "stateNode"; }
    12.     }
    13.  
    14.     public override Node Create(Vector2 pos)
    15.     {
    16.         var node = CreateInstance<StateNode>();
    17.         node.rect = new Rect(pos.x, pos.y, 350, 90);
    18.         node.CreateOutput("Leave", "Transition");
    19.         node.CreateInput("Enter", "Transition");
    20.         return node;
    21.     }
    22.  
    23.     public override void NodeGUI()
    24.     {
    25.         stateName = PlaceGUITextField("State Name", stateName);
    26.         PlaceGUIInputKnobHere(0);
    27.         PlaceGUIOutputKnobHere(0);
    28.     }
    29.  
    30.     public override bool Calculate()
    31.     {
    32.         return true;
    33.     }
    34. }
    I still need a nice way to attach triggers to my transitions. The current output.value would force me to make 1 output per transition rather than the 1 value per input that I want. This boils down to the Calculate step that I think should be added on top of a lean base. Perhaps with the ITypeDeclaration having some indicators of what input and output variables this type really has, instead of some magic mushroom object. :)
     
  44. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Cool, I appreciate your engagement. I hope to focus more on Node Editor soon, too. Changes you are proposing sound really good!

    1. If you're searching for 'Unity node editor', this is the first result. On the other hand, searching for 'Unity node graph' won't even show this at all. Anyone knows if we can tag this thread?
    2. True, for this to work in a customized situation it still needs quite a bit of work and I admit it's sometimes hard to change anything without breaking it. That's because I didn't put alot effort into making this useable straight away, but we'll work on that;)

    As a media for exchanging ideas and discussing topics and organizing everything in general I suggest using Trello. Would be perfectly suitable I guess. I'm going to create a public board for Node Editor, ok?
    There, we can work out how Node Editor should change in order to provide the most out of it, like a Dialogue system, a State machine and (the current) calculation system.

    I really agree we should make some steps ahead in terms of usability and visability:)
     
  45. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Last edited: Jul 19, 2015
  46. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Thanks! ;) TBH, there's not alot of work put into it currently.
    I initially made the Node Editor out of interest to make something like a "Texture Composer". You know, rough concept of an Editor Extension I could make...
    Currently I've other projects in my focus, including this framework, but I'll come back to it when I'm less busy:)
    What I currently have is just a matter of a few hours using this as a starting point :D
     
    chelnok likes this.
  47. terraKote

    terraKote

    Joined:
    Apr 3, 2014
    Posts:
    9
    Thanks guys, especialy @Seneral. With your node example, I can make my dialog editor;)
     
  48. winxalex

    winxalex

    Joined:
    Jun 29, 2014
    Posts:
    166
    Saturday, August 1, 2015



    Extend GraphGUI found in UnityEditor.Graphs. This class is responsible for drawing graph.

    Code (CSharp):
    1. public class GraphEditorWindow : EditorWindow
    2. {
    3. static GraphEditorWindow graphEditorWindow;
    4. Graph stateMachineGraph;
    5.  
    6. GraphGUIEx stateMachineGraphGUI;
    7. [MenuItem("Window/Example")]
    8. static void Do ()
    9. {
    10. graphEditorWindow = GetWindow<GraphEditorwindow> ();
    11. }
    12.  
    ....
    Create Graph structure. It will contains nodes and edges between nodes.
    Code (CSharp):
    1. stateMachineGraph = ScriptableObject.CreateInstance<Graph> ();
    2. stateMachineGraph.hideFlags = HideFlags.HideAndDontSave;
    3.  
    4. //create new node
    5. Node node=ScriptableObject.CreateInstance<Node>();
    6. node.title="mile2";
    7. node.position=new Rect(400,34,300,200);
    8.  
    9. node.AddInputSlot("input");
    10. start=node.AddOutputSlot("output");
    11. node.AddProperty(new Property(typeof(System.Int32),"integer"));
    12. stateMachineGraph.AddNode(node);
    13. //create new node
    14. Node node=ScriptableObject.CreateInstance<Node>();
    15. node.title="mile";
    16. node.position=new Rect(0,0,300,200);
    17. Slot end=node.AddInputSlot("input");
    18. node.AddOutputSlot("output");
    19. node.AddProperty(new Property(typeof(System.Int32),"integer"));
    20. stateMachineGraph.AddNode(node);
    21.  
    22. //create edge
    23. stateMachineGraph.Connect(start,end);
    24.  
    25. graphGUI = ScriptableObject.CreateInstance<GraphGUIEx>();
    26. graphGUI.graph = graph;
    Draw Graph.

    Code (CSharp):
    1. void OnGUI ()
    2. {
    3. if (graphEditorWindow && stateMachineGraphGUI != null) {
    4. stateMachineGraphGUI.BeginGraphGUI (graphEditorWindow, new Rect (0, 0, graphEditorWindow.position.width, graphEditorWindow.position.height));
    5. stateMachineGraphGUI.OnGraphGUI ();
    6.  
    7. stateMachineGraphGUI.EndGraphGUI ();
    8. }
    9. }
    Override NodeGUI or EdgeGUI for more styling and drawing control.

    You could copy paste same settings as MecanimEditor => check source in UnityEditor.Graphs.AnimationStateMachine
     
    Last edited: Aug 7, 2015
    rahuxx likes this.
  49. Seneral

    Seneral

    Joined:
    Jun 2, 2014
    Posts:
    1,206
    Major downsides: You need reflection to get access and you have Zero control over it...
    That's why all popular assets based on node graphs choose to pay for an alternative solution (or get our free solution;) )
     
    Last edited: Aug 1, 2015
  50. Suimisu

    Suimisu

    Joined:
    Aug 2, 2015
    Posts:
    3
    Hey guys,

    Great work:) I just started to read into the code of the node editor and I was wondering how far off the editor is from using it ingame (building node graphs ingame with the GUI as game mechanic and processing the data from the node graph)?

    From what I read in the GitHub repository you already removed some dependencies to the EditorGUI but don't know if that's what you're aiming for.

    Greetings,
    Suimisu