Recalculating constant part of material for every pixel?


I made this material and I wonder if it is recalculating the upper part, which is constant, for every pixel in the texture, what would make this very inefficient…

Thank you.

What do you mean by “recalculations”?
or better yet.
How can a recalculation occur if a variable is not changed by some mean or another?

You have no object position, and only 2 scalar.
unless you are setting it up so that the scalar change at run time, then one can assume that the material - however expensive it may be to render - should not be recalculated at all…

Isn’t it so, that the engine takes the coordinate of the first pixel of the texture (TexCoord), divides it by GridSize param, adds the whole upper part to it (recalculates it?), takes the color at the calculated new coordinate from the texture (texture sample) and adds it to the opacity mask, then proceeds the same with the next coordinate respectively pixel (TexCoord) and so on…?

Hi, you can watch the instruction count when you would replace both your parameters with scalars and when only using texcoord without anything additional to it. I find it sort of strange though that this instruction count increases when replacing scalars with parameters, even though no pixel specific input is used. I would have sort of expected it to get precalculated, so not changing…


And you can also see this instruction count in the shader complexity viewmode.

Each additional texture you use will increase your instruction count. I don’t know what the compiler does when it complies the material (so according to which rules the material gets precomputed and what will be computed during run time), so basically you should watch the instruction count at the bottom of the material when you do changes, this count shows you the run time cost.

Second try to upload the image

UE4 Material compiler can optimize some of the calculations. But I guess that fmod is operation that is not supported. Shader compiler cannot optimize this because those scalar variables are not know compile time. But you can totally calculate this at vertex shader and just output result to custom UV slot and then pixel shader don’t have to do anything extra.