Shader optimizations (skipping AND operands etc.)

[midgunner66]

@rosenand

They show the documentation page where it warns that using the Custom node prevents constant folding. I checked and the warning is still there…

Yeah, that’s true. I don’t know how much savings you actually get from constant unfolding since it only works on nodes that don’t change per-pixel.
Also, I think you can do constant unfolding by hand if you wanted to: just compute all the constant parts of your material in blueprints, send it to the material using a parameter (or something better), and plug it into your custom expression.

@rosenand

I remember vaguely that if A==B is connected, the material is converted into HLSL differently (probably because the equals condition has a threshold).

I don’t know much about what unreal does under the hood for materials, and in most cases, I don’t worry. But I think you’re right about the equals condition (since that would require more math). Try setting the equals condition to 0 to see if that improves anything.

@rosenand

I thought Saturate would be faster than a full IF

The if statement itself is not what makes if statements problematic: it’s what you do **inside the branches. **Whether you use a saturate or an if statement, you’re still going to be doing something based on the result. If you’re doing a lot of stuff in both branches, in the worst case scenario (both branches are done), you’ll end up paying the price of both branches. However, if you had an if statement that did nothing, you end up paying nothing.
Edit: here’s a super short explanation on thread divergence (when pixels take difference branches of an if statement). This is what makes if statements problematic. This is a better explanation, but on loops.

Edit 2: saturate isn’t bad; my “if you think about it” thing was just generalizing it to code and is probably not how it actually works. the main problem was the division.

@rosenand

Yeah actually I’ve been testing stuff a lot lately, doing small builds and writing averaged performance measurements down for comparison, while learning how to optimize our project in terms of stuff like shader complexity, LODs, dynamic shadow casting settings, culling etc. As there’s no clear, universal guidelines fitting all projects, I arrived at the same conclusion as you: just test and find out. Even did it once with HLSL, actually: I was curious if the Clamp(0,1) node would compile into the same code as Saturate, so I checked in RenderDoc and it did. Once I changed (0,1) to something else, it produced more code.

If you look at a lot of projects, tutorials, examples, etc., you’ll notice material graphs can get pretty big, yet they still run fast. So I really wouldn’t worry about optimizing anything unless you really need to.

Though, it’s important to keep in mind that it’s a material, not a shader. The material is only meant to compute the colors for the gbuffer (hence the diffuse, specular, normal, etc. inputs), and the shader is meant to do the actual lighting calculation (hence the “shading model” property in the details panel). If you’re doing calculations in a material that do more than just calculate color, you should probably be doing it in a shader instead (or blueprints).