I’m constantly trying to make my blueprints appear simpler and easier to read, and especially trying to reduce their screen real estate requirements so I can watch them working in real time. I thought this might be a way you could make them appear less cluttered and just as easy to read. In the attached image, the left side shows a Blueprint I’m working on. The image on the right shows the same Blueprint, but that an object reference could be collapsed in an intelligent way to appear in a simpler and visually appealing way. It seems like this case would be easy to detect, and then just collapse to the visual representation in my picture.
I’m not sure if the large blue circle in the right image is simply meant as a pointer on top of the image or if you’d like that blue circle to appear when you “collapse” a variable connection. This is good for one variable, but could get problematic for math and other nodes. How do you think you’d handle those?
After some discussion with you, I can enter this as a feature request (if something similar isn’t already in our system). In the meantime though, I would like to suggest stacking your variables underneath the node. It clusters things together and can help visualize everything better (but that might just be me). It can be effective with one variable or many, even stacking math underneath can help. See below.
Thanks for the note. First off, I’m still fairly new to the engine, so forgive me if there are some obvious flaws in my suggestion. I noticed that Epic prefers the “Helix” style of arranging nodes - it’s good, but still creates some visual clutter.
I was thinking that my suggestrion would be just for blueprint nodes that only have outputs. Since you don’t need to parse any logic when viewing them, it seems like you could simplify their representation. In my suggestion,
-The blue circle with the caret attached to it simply shows the user that there is a node attached to the input.
-When you attach a node with only an output, it collapses down to its simple visual representation.
-The node it’s connected to would show the value that’s being fed into it, perhaps making it easier to parse.
-Disconnecting an output-only node would turn it back into a regular node (exactly how they are now).
I wouldn’t think this makes sense for nodes that also have inputs, since their values would change, and it would be difficult to parse.
If my explanation needs more detail, I’d be happy to mock up a visual diagram of all the states, showing a variety of use cases.
Thanks so much - I really appreciate how responsive you guys are.
-Wright
I took a look at the suggestions you made but unfortunately I can see some problems that will arise if we made the changes. Mostly it revolves around the fact that in the examples you provide you demonstrate with a nice concise variable name and in these examples they would fit nicely into the graph pin on the node and aid in cleaning up the graph.
Consider the following as a means to demonstrate the problems I see
If these variables were placed onto the pin displaying the name the AND node would become much larger in order to display the text. One alternative would be to limit how much of the name we display in the node to keep node bloat down, however this would result in the AND node looking as if it was AND’ing the same variable twice and would clearly be confusing. On the whole, between node bloat and obscured variable names I think the current solution provides more flexibility to users to tidy the graphs in a way that suits them.
As an aside, I did take note that much of the motivation for this was to keep graphs concise so you could follow execution flow more easily. We will be starting work soon on some debugging improvements and I have made some notes to consider ways we can improve this on larger graphs and I have some ideas already on how to achieve this.
just make the spaces in-between pins, node sizes and grid snap conform to the same scale.
as it is now, we have no choice but to make everything wonky and chaotic because there is no size continuity.
for example, the current bp uses (made up values to illustrate a point)
variable node height = 1
pin spacing = 0.73
grid snap = 1.21
where as everything should be 1 so things line up without overlapping or off the end of a crooked spiral type affair.
i cant understand why it wasn’t like this from day 1.
