Hello
when we edit materials to render through EEVEE:
is there a way to make the Shader compilation faster?
for example :
edit a material in a separate file?
or
any EEVEE configuration?
or
otherwise ?
thank you
is there at least one way to rasterize a group of nodes in the material that has already been completed to prevent them from being recalculated?
Not without changing the source code.
Eevee is quite fast if you just change values in your nodetreeā¦ But if you change the structure of the nodetree, then it needs to compile the whole nodetree into a new GL shader.
You can use Cycles to create/modify nodetrees (as all nodes are pre-compiled in the Kernel), and only jump to Eevee for final ajustments and render.
My personal workflow is to use Emission-Only when creating procedural textures, with low samples and no bounces. When the textures are ok, add the shaders and switch to Eevee, where you can tweak the values at will.
Bake them into a texture??! 
You could bake the shaders into textures. I mean: instead of having a tree of procedural textures plugged into a Diffuse node, bake that in png files (itās not a lot more faster but if you have a lot of materials you will notice the difference).
Also: things with normals, displacent, etc are slower to compile.
Which to me makes material preview useless for material creation.
very good your suggestion
tell me one thing :
cycles does not accept the node: ambient occlusion
what would be the option to replace this node?
another question :
is e-cycles faster than cycles for creating and editing material nodes?
I assume you are referring to OptiX. AO node works with CUDA/OpenCL and CPU
one question was not clear:
if I bake a group of nodes that has already been completed, to prevent them from being recalculated while I work with other nodes of the same material?
does that make the shader compilation faster?
thank you very much
If you bake a part of a nodetree into a texture, then you can replace those nodes with a single ImageTexture node with the baked image in it. It will use more RAM to allocate the texture, but compiling the material will be faster.
This works as long your group of nodes outputs something that can be stored in an image fileā¦ If for example your nodes output a vector, you probably need to bake the texture to an OpenExr file (which allows positive and negative values); if on the other hand they produce a color, a PNG file should be enoughā¦ If they output more values than what an image can hold, you might need to bake more textures.
Is it necessary to delete the nodes on which the bake was made after turning the resulting image on the tree to make the shader compilation faster?
or the simple fact that these nodes are not connected to the material tree is enough?
what hardware do you recommend to speed up the compilation of Shaders?
processor?
RAM?
is there a configuration that makes it possible to never see the shader compilation bar again?
can you help me with this topic below?
I think only nodes under the Output node are taken into accountā¦ but having lots of nodes in the nodetree might still slow down the process, as the nodes list gets bigger and slower to iterate.
Donāt know a good answer to this. As I stated, I use mostly Cycles, so I donāt have this problem.
Another āIDKā answer. Writting one addon to do this shouldnāt be difficult, but I donāt know if anyone did it.
@anon16398817, I know youāve gotten some answers here, but I wanted to point you to the manual page about optimizing nodes where you might be able to get some detailed info on what you can optimize:
https://docs.blender.org/manual/en/latest/render/cycles/optimizations/nodes.html#shader-nodes
Thank you for your help
is there this kind of information for EEVEE?
I donāt use cycles
You know, I didnāt read that page well enough - it mentions how you can exploit how nodes are automatically optimized to help you make the most optimal node trees out of the box, but they arenāt direct hints on how to optimize.
Though there may be some good rules to follow, node compilation is really going to be different based on how your node tree is set up. Are you able to share your .blend file or a screenshot of your node tree so we can see what you are working with?
I donāt have a specific tree
I wanted general tips and resources in this regard
what I quote in the topic: Bakes a group of nodes
Iāve been often frustrated by the long wait (sometimes several minutes) when I load a project that was saved in material preview mode because of ācompiling shadersā.
Now if I save in wireframe or solid view and open the project, I can get right to work. If I want to render, just go to the render mode. But now and then I accidentally hit material preview and then Blender goes unresponsive for several minutes as it sssslllooooowwwwlllly compiles shaders. CPU and GPU are nearly idle during this time, so it seems that there is an opportunity to optimize code and maybe make it multithreaded to speed it up.
To my recollection, this wasnāt a problem before 2.93. I think thatās when I started to notice the long compiling times.
Exactly, that is a great way to put it.
Does anybody know if something is going to be done about the extremely slow shader compilation? Having to wait up to over 2 minutes when opening a scene isnāt good at all.
Iāve got the feeling that v 3.4 has been slower then it was before and it seems to spend more time doing so even if you just make a small change to a node while in the Shader workspace.
Basically, it feels like a regression, but that may just be me.
Itās not just you, itās getting noticeably worse. 2.8 was blazing fast, anybody can compare 2.8 to 3.4 when it comes to shader compilation times in EEVEE. Iām not sure what is happening here but there is a substantial performance degradation regarding shader compilation in EEVEE.