You have a boolean variable and a very very very heavy pure function that also returns a boolean.
The Boolean is set to false.
Plug the simple boolean into the first AND input and the heavy function into the second Input.
Execute the Graph and you’ll notice that the heavy heavy function gets executed.
One point agaist it might be that the AND operator’s behaviour wiuld then depend on the pure-ness of the operands.
Imagine at some point in your development, a pure function needs to become impure…
In your scenario above, you could also feed the first boolean through a second branch, comparing it to a static true/false. This way you could avoid evaluation of the second operand/function…
You need to change a lot of wiring around, if you change it as an afterthought…
Something like this.
you evaluate the second (heavy) condition only if the first one evaluates to true.
Kind of like splitting an “if (a && b)” into a nested if-then-else-if form.
Much cleaner and without the need to look up to what an AND node is connected to (puer/impure?) to know how it will behave.
^This can be a solution for some cases, but I wouldn’t say this is more readable. Imagine doing multiple heavy functions. Using a Branch for each function is a waste of space and instructions.
While it is indeed an additional node in the graph, a short circuit evaluating operator would do the same instructions internally.
So instruction wise its about the same…
I don’t see how short circuiting has anything to do with evaluating pure vs impure nodes. Perhaps I am missing something.
Impure nodes execute when the exec wire passes through them, and any outputs effectively persist during that frame (if not longer).
Pure nodes execute when a wire they output is needed for an input on an impure node.
Oversimplified, sure.
bool SomeResult = MyImpureFunction(Params in);
if (SomeResult && MyPureFunction())
{
// some action
}
if(MyPureFunction() && SomeResult)
{
//some other action
}
Yeah, you can break your code if you change a pure node to an impure node, but that is a drawback to BP, not a drawback to short circuiting. You’d run into the same problem currently. In fact, an impure node that returns a bool should return false if never called before (if everything in UE4 is zero filled), so the effect of changing a pure node to be impure should not be different just because short circuiting exists.
if (A == true)
{
if (B() == true)
{
// heavy stuff
}
}
By using a second branch, you are making basicaly the pure function impure.
I somehow prefer that (sequential evaluation) over a context dependent AND operator…
Blueprint does need short circuit evaluation though. I find it a bit baffling that Select nodes evaluate all branches even though the condition dictates that only one branch would ever need to be.
Wow, yeah that’s new to me. I was always taught that the select node was more efficient than a branch, but based on this I guess that would be wrong probably about half the time.
I’m thinking I’m being smart avoiding branch nodes and I’m actually just wasting my time haha
Yeah the lack of SCE is confusing at best, harmful at worst. However it’s also been discussed for a while now… Blueprints just don’t do it, they evaluate all branches on everything.
