To optimize this the way you want:
-Replace the lerp with an if
-Plug mask into A>B and the purple node into A==B
-Set the A input to 1 and plug Condition A’s if result into B
-Plug Condition B’s floor result into A<B in Condition A’s if node
Extras (general shader optimizations):
-Replace the pow with a multiply and plug vector length into both A & B
-Replace distance with distanceSquared (not a node, so you’ll have to make it yourself; it’s just the distance formula without the sqrt) and in blueprints (not the material) square the range parameter.
Improvements:
-Lerp and multiply are no longer needed, reducing the math that needs to be done.
-Since branching (if) is used, the shader can take advantage of branch optimization (only executing one branch, which is what you were asking about). Although, from Chosker’s link, this may not happen.
Extras:
-When squaring a number, multiplying it by itself is faster than pow(n, 2).
-DistanceSquared removes the sqrt, requiring one less calculation. As long as the exact distance isn’t needed (as is the case with distance comparisons), the result is identical to having the sqrt. The range parameter needs to be squared to take into account the missing sqrt, but since it’s done in blueprints, it’s only squared once on the CPU; plus, squaring is not an expensive operation (just multiply the number with itself).
Explanation:
The reason this works is since all conditions need to be true, it can be thought of as a line of conditions. As we go down the line, if any condition is false, we stop and return false (0). If we reach the end of the line with all conditions being true, we return true (1). Since all conditions return either a true or false, instead of combining them and returning the result, we can just return the result of the false condition.
For example: for two conditions, the possible cases are:
A = false -> return A (false)
A = true -> B = false -> return B (false)
A = true -> B = true -> return B (true)
The way you have it written, it’s not a condition, but a math operation (since you use multiply). So chances are it’s always going to calculate both sides. It may be smart enough to know not to calculate Condition B if Condition A is 0 (since anything times 0 is 0), but I wouldn’t count on it.
Also, you plug that result into a lerp, which is another math operation. So once again, it’s going to calculate both inputs (A and B) unless it’s smart enough to only do one side when alpha is 0 or 1.
And because you’re using math to emulate a logical operation (a branch), it’s, if anything, going to be more expensive than just using an if statement since the GPU has to crunch numbers just to get a 0 or 1.
So, with the way you’ve written it, zero optimizations are (likely) going to happen; it’s very likely that all nodes are going to be executed. Using if statements, there may be a worry about both branches being executed; but even then, it’s still less expensive since there is no multiply or lerp being used, reducing the math that needs to be done.
Also, does the inverse transform matrix have any input? If not, Condition B is always going to return the same value (0), which is what MostHost LA pointed out.