Compiling Shader Variants Taking Ages

Getting frustrated about this because:
- turning off "Optimize Mesh Data" doesn't work for me
- turning off Vulkan support doesn't work for me
- unity still compiles every variant of every shader even with shader stripping set to All
- using preloaded shaders doesn't affect build time
- using ShaderVariantCollection with all of my used shaders in it changes nothing
- the shadercache continues to be ignored
- removing auto API and only selecting OpenGLES 3 doesn't change anything
- etc.

All of my projects that include Oculus Integration, Post Processing, Speed Tree, or AVProVideo take hours to complete, regardless of size. The problem is the same when building both standalone-windows and for android, VR enabled or disabled, Single-Pass or multipass.

I doubt this is because of any one of these assets, but because unity now just compiles all variants no matter what.

I'm only using 600ish variants, but unity builds upwards of 100,000 variants across each of these assets and my own custom shaders. I'm going to try using scriptable shader stripping, but I doubt i'll be able to work through every keyword in each of these assets and testing builds enough to reach an acceptable build time.

My team is unable to iterate and as a result we go too long between QA sessions and suffer more for every bug we find. I've had to not sleep during conferences and before deadlines in order to wait for builds, spending 5 minutes implementing an attempted fix for a bug and then 2.5 hours waiting to see if it worked. One of my projects now takes 6 hours.

Pls help xoxo

 

+1
This also happens for me when just building asset bundles / addressables.
It started to take ages after I specifically told Unity NOT to build a builtinshaders bundle (in the packed mode build script).

 

I9-9900K at full load, been stuck compiling shader variants for a long time. Will this happen every time?????

I guess I will be catching up on some sleep now.

Please make this less painful!!

 

According to this, it's been fixed in 2019.3 -> https://issuetracker.unity3d.com/is...render-pipeline-slash-lit-shader-is-compiling

 

I was having the same problem with HRDP and 2019.1.3, but I'm happy to inform that this is fixed on 2019.1.5! What took 25 minutes yesterday took less than a minute today. Thanks Unity team!

 

Unfortunately enabling Optimize Mesh Data still causes the same problem in 2019.1.5 for me. Long build times, compiles lots of shader variants.

 

It's also still happening for me in 2019.1.5. My build takes at least 70 minutes, with or without optimize mesh data.
It appears to compile every variant of every shader in my whole project, whether or not I'm using those variants.

 

An occasional fix is to enable "Script Only Build" if you are just changing scripts, but it doesn't allow for even the most basic scene component changes.

 

I just now hate Unity in general tbh, tried 2019.1.6f1 in VR LWRP empty project, deleted everything just left the XR Rig and made a ground, I put lowest possible graphics, Strip all shaders, unchecked everything in Optimization section, unchecked Optimize Mesh Data, Unchecked Vulka, left just Cardboard in VR and I still get 2-3 hours or compiling shaders.........how?? Unity? Cmon.
here is some screenshots I got:
https://prnt.sc/o1j444 , https://prnt.sc/o1j5ku , https://prnt.sc/o1jfiy and the desert at the end *drum roll* https://prnt.sc/o1jkhw - they still not fixing their manifest.xml through all the versions. Is there a way to set this up to prevent this manifest.xml error??
(tear drops just remembering good old stable early 2017 Unity version)

 

Unity 2018.2, building for PC VR, unchecking "Optimize Mesh Data" solved it for me (went from ~45 minutes to <1 minute). Thanks!

 

Btw i like compile post proccessing shader variants for mobile when it doesn’t support mobile VR and must be stripping.

 

I'm using Unity 2019.1
I daredly deleted the project / Library directory.
When you open a project, the project / Library directory is automatically regenerated.
At first, it will open in Desktop mode, so switch to iOS mode etc. if necessary.
(Or open the project by specifying the iOS mode etc from the command line will save time.
The total variants have changed this way.
project settings-> graphics settings
currentry tracked 72 shaders 8572 total variants.
to
currentry tracked 72 shaders 148 total variants.

The first build still took about 30 minutes, but the second build ended in 5 minutes.

And Optimize Mesh Data was off before, but it wasn't shortened much until I deleted the Library.

 

Was this a full build or did you have "Scripts only" checked, or something els? I haven't noticed a difference in subsequent build times, but I am also building for Android (Oculus Quest) so I don't know if that makes a difference.

 

This is a full build. It is not a script only build.
And I am an iOS build.

 

Guys

is this fixed? Bottom line: build out the basic xr project and it takes literally hours to build. None of the solutions here worked for us. We’re not sure how to proceed with LDRP. Not seeing anything here about this being resolved.

 

The problem is fixed in 2019.2.0b10. Create empty project with LWRP and build sample scene with default setting first build takes almost 75-80 min but second build takes only 6-7 min.
I almost stuck all day yesterday. i use 2019.1.4f1 for my android game and i build first time its almost takes 7 hours to Compile Shader Varients and after this Unity Crash

 

This problem is fixed in 2019.1.11f1 for my project.

 

I'm from the future, 2035. Still waiting.

 

from 2019.1.1f to 2019.3.0a11, nothing is working. Over 5milion variants to compile of 1 shader.
Like it was said, every possible variant is compiled. Shader_feature and multi_compile makes variants increase expotentially.
Do anybody have made an issue of this? We need to vote this up because its major problem.

[Edit]
Ok, so... workaround about this problem is to just not use graphics > always included shaders. Its bugged and it forces to compile every variant of shader expotentially like i said up.
Use resources instead. Even if u are using assetbundles you still can load shader or material from resources and overwrite your bundled prefabs materials.

 

Thanks, this helped me go from about a 15 min compilation time to around 2 minutes. I also changed `Instancing Variants `to `Strip All`

 

The other day, I upgraded from 2019.1.1f1 to 2019.2.0f1. I did not change any project settings in between. The number of tracked shaders and variants listed on the bottom of the "Graphics" page within the "Project Settings" window is about the same as the previous version of Unity (145 shaders and 317 variants). Building now takes about 2 minutes when it was about 10 seconds previously. In absolute terms, it's not so much (not building for hours like some of you), but it's still about a x12 increase in my small project. I never even saw the "Compiling Shader Variants" message while building in any previous version of Unity either, but even a blank 2D project has it now, and this blank project takes longer to build on 2019.2.0f1 than on 2019.1.1f1.

I tried the various fixes listed in this thread, but nothing seems to help. I am not using LWRP or HDRP (they're not installed according to the Package Manager).

 

I'm using HDRP and facing the exact same problem. Building my game took about 15 min but it takes 2 hours now

 

Spent days to test and wrote down some conclusion, I've some workarounds before Unity fix this.

see also https://forum.unity.com/threads/sha...ble-long-time-to-compile.724247/#post-4847420

 

I've followed the advice about making the variants file, removing all of the included shaders and it still takes a long time to complie the shaders (even for a headless build that will have no graphics in it). Is there any way to just pre-compile the shaders once and then include those in the build? Redoing this on every build seems odd especially if shaders are rarely changed/added.

 

I agree. Just like the light mapper in Unreal Engine, it tracks and shows something like "You have x objects need to be baked", but have the developer make the choice. In most of the time, shaders are rarely changed and even if they were changed, it's not necessary to compile/strip them for each development build, say maybe we just want to see if netcode works well on both ends, but that stripping/compiling process actually decreased the productivity of the whole studio.

 

This somehow reminds me of the Standard shader things from the past... Trying to build iOS: after being in this step for 5 hours I just had to kill it. (2019.1.13, LWRP, really using about 50 shaders - 150 variants), 50 scenes. Even when setting stripping to none, it is still stripping the vertex programs for some reason.

I know that I should file a bug, but according to Unity policies they do nothing without a project (...and the project is big, and I am not allowed to share it anyway). :/ I just feel that there should be more logging options for the build process (there is nothing in the logs for this build hangup, for example).

 

I found this in the Unity 2019.3.0a12 alpha release notes:

https://unity3d.com/unity/alpha/2019.3.0a12

 

That sounds promising, however, it increased a lot more than 10-20 seconds on my end.

 

Having the same issue with a12. Just get stuck forever never moves

 

I reverted to a5 and it works

 

2018.2.21f1 - PS4 build was taking forever on shader variants. Shut off Optimize Mesh Data and cleared shader variants. Fixed.

 

I was able to workaround this issue by simply deleting the Library folder and let Unity recreate it. From then on, no more hours of shader compiling:
https://forum.unity.com/threads/unity-takes-forever-to-build-a-player-fix-inside.741224/

 

Sigh...was david's kid the one that decided on the new "scriptable render pipeline" thing. Is that why it wasn't simply nix'd right away? Must have been some family member. Because any sober company would have tossed that feature after the first month of issues. VASTLY BETTER features have been removed...and that is still there.

ATTENTION Unity Employees:
What Unity really SHOULD do is have a switch in the build settings that says something like: "Pre scriptable render pipeline mode" (AKA: "Unity 2017 rendering pipeline from when Unity was still a great product" mode)

DO THAT!!! Seriously. That simple bool and some code from the last great Unity 2017 can make A LOT of people happy. Thanks in advance!

 

Trying that now. Still waiting...it's seemingly still compiling THOUSANDS of shaders in a simple scene...and no post processing uber shader in the scene.

 

That didn't seem to do anything on this project.

 

Chill on the fanboy ridiculousness. That doesn't make Unity better and it looks really childish and idiotic.

That would be similar to an apple fanboy defending apple's defective macbook keyboard design.

 

PS: By the way, this project is on Unity 2019.2.2f1 being built to run on android mobile VR (oculus) using single pass stereo. Still waiting for it to finish building...sigh...

Does converting the project to lwrp and using that script that strips the variants solve this better?

Was actually avoiding lwrp because it was so horrible. But maybe it is better with that script.

 

This post https://stackoverflow.com/questions/50150089/how-to-avoid-unity-complie-all-standard-shader-variants talks about a plugin called Shader Control to, well, control shaders, compiling only the shaders you use. Maybe this can help? I'd like to have a solution within Unity without having to purchase a plugin, but, you know, life.

https://assetstore.unity.com/packages/vfx/shaders/shader-control-74817

 

You can just stop shaders from compiling like this:

Code (CSharp):

1. #if UNITY_EDITOR
2. using System.Collections.Generic;
3. using UnityEditor.Build;
4. using UnityEditor.Rendering;
5. using UnityEngine;
6.  
7. class StripShaders : IPreprocessShaders {
8.     public int callbackOrder { get { return 0; } }
9.  
10.     public void OnProcessShader (
11.         Shader shader, ShaderSnippetData snippet, IList<ShaderCompilerData> shaderCompilerData) {
12.         // Debug.Log (shader.name);
13.         if (shader.name == "Standard" ||
14.             shader.name == "Standard (Specular setup)" ||
15.             shader.name == "Standard (Backfaces)"
16.         ) {
17.             for (int i = 0; i < shaderCompilerData.Count; ++i) {
18.                 shaderCompilerData.RemoveAt (i);
19.                 --i;
20.             }
21.         }
22.     }
23. }
24. #endif

 

September 24'th, Unity 2019.2.5f1, still the same stupid problem, I hate LWRP.

 

Takes ages on first compile after any Unity update, even without using any SRP

 

So we are still there, nothing change. I suggest Unity instead of pathetic presentations do code debugging.
I personally don't care cause of all this, I don't care of technical issues, I just want build the project. This is just a mockery!

Seriously, does anybody working on this at all?

 

Still a problem with Unity 202.1.0a11 using the URP

Why do I need compile thousands of shaders!!! Many of them not even used in the scene or project!

 

Call me thick by all means but where do you put it?

 

It's part of SRP so Unity will scan the project and invoke whatever inherited from that interface automatically. It lets you skip shaders you don't want but I don't think that's the solution for this title, as most people are not complaining about too many shaders they don't want get compiled, but complaining about shader variants are not optimized and compiled shaders are not cached properly.

 

This is just starting now for me, it's been 30 minutes so far. I'm going to leave it be and see what happens, it seems to be compiling every shader variant you could ever imagine. I have a project that's more than 3 years old and have done my best to re-optimize, but maybe even shaders that aren't being used have variants being compiled?

P.S - I have no clue what a shader variant is.

https://prnt.sc/qg740e

 

I was able to "fix" all sorts of long shader compile issues by removing the library folder and let Unity generate a new one:
https://forum.unity.com/threads/unity-takes-forever-to-build-a-player-fix-inside.741224/

 

@Peter77
In your case, did this also fix the slow Shader Variants Compilation? (thousands of variants being compiled)

I tried deleting my Library folder, but that fix didn't work for me.
I tested on Unity 2019.3.0f6, the shader variants compilation is still too slow.

Actually, only the first build is slow, the shader variants compilations on following builds are cached and WAY faster.
But that first slow build is still unacceptable, its nothing like 2017.4.

 

I have the same problem.
After a build I have at least 350.000 (with or without XR mode) files in the Library/ShaderCache folder for my project.
On the build server [1] it's still not finished after 3 h 9 min.
Locally [2] it succeeded after around 40 minutes.

What puzzles me additionally though is that on the build server the shader compiler log files stopped being written at except for the first process.
All five processes are working though and monitoring them with the Process Monitor reveals that the log files are successfully written.
That is different to my local build were all process log files increased in size about the same and steadily over the entire build time.

Can somebody maybe reproduce this?
Maybe the shader compilation falls back to single process mode for whatever reason which makes everything even slower?

[1] Xeon Silver 4110 2.10 GHz
[2] Core i7 9700K 3,60 GHz

 

Had the same issue on 2018.3. Android builds were taking 30-50mins each, compiling 1000's of shaders! For just one line of code change...
My issue was solved by removing the Unity Post Processing Stack package I had imported. Takes 5mins per build now.