in depth info about shader compilation

My landscape material currently has a huge compilation time. It is a very complex shader and now I am looking for in depth ways to optimize the compile time…
I already have the only flag ‘for landscapes’ enabled.

What I try to figure out is:
does it make sense to remove all single scalar values that uses lerp nodes and replace them for example with a combined float4 and lerp them? (to reduce connections)


do material functions add up to compile time?

in short…is there a in depth guide on how to improve shaders in terms of performance and compile time?
regards! Tom

In most cases, things like that should be optimized automatically.

Nested material functions tend to slow up compile times, but I don’t think it is significant.

Regarding compile time, the most contributing factor will probably be number of landscape layers.
Worth mentioning, that having tessellation enabled on landscape material tends to give undue increase in compile time

ah that tess is indeed trippling the amount of compiling shaders…

when you say the number of landscape layers…you talk about really the fact that there may be 10 or 15 layers regardless what they are doing in the material?

Lets say I have 4 nature layers:

and then I use 8 landscape layers to modify the 4 nature layers, add some variation etc.
Would I really benefit from it when I try to reduce those 8 landscape layers back to 4 and to the variation part inside the material with other techniques?

How many layers do you have currently and how many shaders is it compiling when you make a change and hit apply?

What sort of variation you are adding using those ?
If it’s like brightness changes and things like that indeed you can do it in the shader itself and ends up a lot cheaper and nicer.

I have 11 layers. For my biggest landscape with tess enabled i have around 20K shader compiling. On 4 components (much landscape comps deleted) without tess enabled I have around 350, when I enabled tess, i have around 1000.

Well, it is a bit advanced here.
For example, I use one layer to heightblend stones into sand. The painted area is where rocks go inside sand and popup nicely.
Another one is mixing variation of rocks.
Another one for storing local heights (from World Machine) and use that info to select either top mountains or footer mountains.

I have around 4 a 5 layer that really paint areas cover with either rocks, pebbles, soil etc. (so called nature layers)
I also have a layer that controls how much displaced areas are. Some rocks are popping out more then the others.
Obviously, there is room for optimalisation, but I am married here with the current look and feel of the landscape. It all looks very organic and nature like now. x-)

btw: currently i have put al sample nodes into one material function. If I replace all sample nodes with a constant node ZERO, so basically no layer is used anymore I stil get a huge compile times.
Feels like the layers don’t really contribute to compiling times. But not sure here. Worth mentioning that I also use triplaner setup and quite a few textures.

Did you just say 20,000 ? :eek:
Are you allowed to post screens of inside the function?

I am referring to landscape layers only

Yes. Compile times will be shorter

Thats on par with what I was getting for comparable material

If that are texture sample nodes you are referring to, then doing so will not change compile times. However, if you mean LandscayeLayerSample nodes, then most likely something different is the case.
Are you blending material networks consecutively?

yes, I was talking about the landscape sample nodes. I just took a dive into some nodes and turns out the triplanar complex node from the lib is the real killer here.
This node is doing a lot of math to correct normal angles. If I remove this one, the compile times are much much faster now. Bummer…without the triplanar, the whole landscape lookds odd.

And yes, I am blending materials, but I dont use material attributes. I use material functions as I just assume that it would be cheaper then using whole material attributes.

yes, indeed 20K :-o
I have functions in functions. There is one giant function that holds up about 5 a 6 material function each containing material stuff. Then they all got blending using one big lerp material function in which I connect diffuse, roughness, cloth, height, displace.
But I guess the triplanar nodes with the norma correction math is the killer here…without this math the compile times is done in minutes. If enabled, it can take up to 10 minutes now. (for a small piece of the landscape and tess disabled)

If you want to use tirplannar for multiple layers, I suggest you making a custom triplannar material function, where you would do the blending before 3 projections are lerped.
Do your layer blending 3 times for RG, RB, GB projections, and then you will have to transform final normals only twice, for RB/GB and RG projections.
Height blending will have tripple cost in this case, however.

makes perfect sense…! I try that. Just need to figure a way to lerp textureObjects.

Actually the way your functions are setup is what’s getting you. Having complex functions in functions is very expensive. Try making 1 function for each material and then blend the functions using MatLayerBlend_Standard.
I currently have 7 layers here with tessellation for all layers and when I hit apply it’s about 1250 shaders to compile. 20,000 is very unnatural.

really? I could not have imagine that this could be such a huge impact, but I suppose it does. So material attr are cheaper?
Anways…bottomline, I see now quite a few things that I can do to reduce compile time!