Download

About reroute nodes: fewer is better in BP compiling process?

Hello! I use to add lots of reroute nodes to keep my BPs clean and easily readable.

May this cause issues, overweight final coding, worse optiization or any others in compiling process?

Why original Epic macros or function or material scripting, doesn’t generally have any rerouting at all?

Single shot question: Is there a somewhat reason to limit rerouting nodes as possible?

Thank you!!!

I think you should be okay. I don’t know if they have a performance hit, maybe they do when you have millions of them but I don’t think that will be the case. They are used primarily as a visual aid to keep your blueprints easy to read. I use them quite often.

Thank you Don, I supposed the same, but I still can’t figure out why Epic BPrinters doesn’t use rerouting… if you open and take a look at any BP macro or material graph by Epic it looks really a wired messy spaghetti bunch… ok it works and that’s it!

Not sure but maybe these macro were made at a time when reroute nodes didn’t exist, and they haven’t redone every existing functions and macro. It is just a supposition however

Reroutes are fairly new nodes, so not many people use them.

They are marked as ignored by Kismet Compiler, so will not add to compilation times, all they do is pass execution flow away.

The only impact they have is graph rendering performance on your editor.

If you dial down the spline curvature in Editor settings you can cut down on reroute nodes (if the rendering inside the graph is starting to become laggy especially). By the way, Functions automatically grant you getters / setters. It’d be nice sometimes if every graph offered this (new graphs / macros etc). You’d have to be careful in large graphs with naming clashes, but it would mean less extra variables having to be created manually or far fewer long messy wires and less reroute nodes overall…