As someone with a programming background, here's a fundamental thing about the Cycles node tree I've been thinking about. Let's say you have a node setup like this:

enter image description here

Here we have two computationally intensive shaders, called "Gigantic Shader A" and "Gigantic Shader B", and a Mix Shader is used to switch between them using some black-and-white mask.

In programming terms, this setup can be thought of as an if-else construct, with shader A and B being the two execution branches of the if-else construct.

Now, in basically every sane programming language, the two if-else branches are evaluated "lazily", meaning that either only the first branch or only the second branch is evaluated, depending on whether the if condition evaluates to true or false.

So here are my questions:

(1) Does Cycles have this lazy evaluation optimization as well? More specifically, is Cycles smart enough to figure out that if Fac=0 or Fac=1 in the above Mix Shader, it can completely ignore either shader B or shader A?

(2) If Cycles does have this optimization, then is it also true that the node tree is actually evaluated from right to left, starting at the Material Output node, and not from left to right, as one would naively assume? Because I can't think of any other way to implement lazy evaluation than going from right to left.


When executing shaders, a special optimization is applied to Mix Shader nodes. If Factor evaluates to 0 or 1, any nodes that are only reachable via the unused branch of the mix are not evaluated.

Taken from this page:


This page also describes how the node tree is evaluated.

  • $\begingroup$ Hmm... the page only mentions the Mix Shader under Run-Time Optimizations. So I guess there's no such optimization for the MixRGB node, which can also be used for if-else branching? :-/ $\endgroup$ Oct 5 '18 at 8:22
  • 1
    $\begingroup$ @Nam-QuangTran It works with MixRGB node the same. Pls read the link zzubnik provided. $\endgroup$ Oct 5 '18 at 9:50
  • $\begingroup$ @Jaroslav Jerryno Novotny: I've read the page, and the MixRGB node is indeed mentioned there, but only under "Node Optimizations". This means, in my interpretation, that the MixRGB node is only optimized during the compile-time tree simplication step, not during run-time, unlike the Mix Shader node. Either that, or the run-time section of the documentation is incomplete. $\endgroup$ Oct 5 '18 at 10:08
  • 2
    $\begingroup$ @Nam-QuangTran The tree is evaluated and optimized before every frame that renders. The MixRGB node would change values in single frame time-frame only when motion-blur sub-sampling. I'd have to check the source code or test to see if there is a difference in sub-sampling, I doubt it. Maybe it's only the documentation wording like you say. $\endgroup$ Oct 5 '18 at 11:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.