Fixed some multi-line material nodes being too tall:
I also spent some time playing around with pin padding / positioning to try to reduce the horizontal size of nodes, but those changes are a bit more experimental / not a clear win, so they’re not enabled right now.
Notes:
The tangent generation values are now adjustable in the Graph Editor section of Editor Settings under Splines, if anyone wants to have a go and see if there is any more room for improvement.
These were just checked into main today, you can check them out using a GitHub build after commit or wait until 4.5.
I compiled from 4.5 source on friday and then again few hours ago, and man… 4.5 is going to be a huge release (biggest yet i believe). Big usability pass, and polish , “quality of life” thats for sure. I thought the node connections in BP changed a bit.
Loving the extra time in oven. Hopefully 4.5 will branch relatively soon, either way some exciting stuff in store!
THANK YOU! Seriously, the way the splines acted before was quite irritating, I found myself using on average two reroute nodes per line if they weren’t going straight into the next node.
The backwards changes are especially appreciated, though I try to avoid going backward whenever possible.
always bothered me but I couldn’t find a decent solution in how I laid out my nodes, so I just dealt with it.
Sweet! You know, I don’t generally think of myself as having OCD, but I usually try to keep my lines as straight and neat as possible. Should save me tons of time!
On topic of nodes. (my aplology if these features are alraedy implemented)
Can we have ‘black box’, where a part of nodes network, that is within a comment box, can then be compressed in size to show only input & output. That would save a lot of line managment I think. We can identify the purpsoe of the Blackbox via the name & comments.
Highlight line when mouse over, so we can easily trace the path
Allow us to unplug one end of the node & plug it to another. is helpful when we wanted to replace one node with another & the line to the output/input is long.
Also, we should not need to remember varaible names. When we need to access a variable of a class blueprint (say to change the emissivity of a DMI), there should be a where we can pick from it.
1 and 2 are already …? You can collapse a collection of nodes to a single node (not necessarily a FUNCTION which has limitations, but just any arbitrary selection can be collapsed, IIRC), it cannot be replicated but it saves on space.
You also can hover over pins to see where they go via light-up, does not work on wires themselves…?
3 would be very helpful, though I’ve taken to using Reroute nodes when flying pins across large BP distances to both facilitate reconnections AND so I can comment the pin (e.g. “Grabbing AxisInput Vector” or w/e) so I know where that mystery line is feeding from.
looks great, thank you ! I am a bit of a neat freak when it comes to BP & Material graphs, I always find myself trying to get the wires to run straight when possible, and it is annoying when they don’t line up properly.
On a side note, it might not be possible to do, but the ability to create variables in the material graph would make things so much cleaner, not having to run wires all over the place to use the same value more than once. I suspect isn’t possible (otherwise it most likely would be implemented already), so if not, some way of cleaning up the wires in complex material graphs is something I would be very interested in!
@, I don’t see why it’s impossible, shader only requires input parameters not be changed in it( parameter itself could be from a varying source like texture), so i think is a legit request.
I wonder what happen when you duplicate a parameter node, need to experiment.
Duplicating a parameter node works as expected (one value, multiple nodes), so I guess it is possible. But I am working in Material Functions currently, there isn’t really a way of doing the equivalent within the function.
Any way of cleaning up the mess of wires that arises when you are making a complex function would be awesome though!
Yeah, I guess that’s a bit problematic for functions, maybe they can port the local variables from blueprint side.
It used to be really bad but they fixed that in 4.4.
I do have one suggestion for an improvement. Using reroute nodes when doing a loop back can be awkward. The execution lines seem to have a preferred direction so you have to first position the reroute nodes in a certain position relative to each other before you connect them or they drop the line on the other side.
The reroute node needs to first look at whether the other side already has something plugged into it and if so, use that as the reference for how it behaves when dragging from that node to an input.
Nice, that really bugged me. I’m looking forward to more improvements in blueprints.
Someone at Epic should really take a peek at Flowstone (formally SynthMaker), their visual programming system works a treat and is really easy to keep everything neat and tidy, I’m yet to see a better example.
3 exists as well. Ctrl+Click+Drag to move connections from one pin to another. Another little time saver is Alt+Click to break all connections on a pin.
one was the best of the options I tried (reduces both vertical and horizontal padding and places the pins externally), and I really like how the exec pins look here, but the data pin glyphs probably need to be reworked. I also tried pins straddling on the edge (would need to make the unconnected pins opaque in order to increase readability, I think) or right inside of the edge (looked busy / ugly), but nothing clicked.
Usual disclaimer RE: experimental stuff: Bear in mind that it’s unlikely we’ll make drastic changes like or keep the node padding settings around (they’re just checked in so others could play with them and see if we found a happy middle ground, but they currently require an extra SOverlay per node).
