30 Minutes To build.... How long does yours take?

30 minutes from starting unity to the project recompiling. This is in native windows. Force closing unity and reopening it works, but this seems to be a transient problem.

 

Sorry, just be super clear, by compiling do mean project recompiling (just in editor after opening), or when you hit play, or when you hit build?

 

in editor, just after opening.

 

You said two other people on your team are having the same problem. Are you using version control? This may be longshot, but if you are using version control, and don't have the library directory ignored, it could cause a recompile after an update/pull. That's just a guess. It shouldn't have to recompile when you open unless there were significant changes. (Or complex shaders that were changed.).

 

If you are doing frequent WebGL builds then cloud build is a must.

 

We're using Unity Collaborate in beta 17.

 

That seems like a decent solution while they are working the kinks out. Ideally, they'll focus on optimizing the build process after they get it producing builds that are reliable and high performance. It is odd why it takes so long. Plenty of RAM to work with. Any computer these days has a decent CPU that should easily burn through the kind of processing needed for a compiler. I get that it is doing multiple compiles. Compiling this to that. And that to the over yonder and so forth. Just seems like each one would be very fast. In my test project I don't have much in the way of assets.

 

Hi ZombieGorilla,

Just stumbled upon this thread, and started looking into AssetBundles. Was wondering how exactly you use them to speed up your development process? Are you saying that you use separate projects for file types to test they function as desired individually in Unity, then add them to an AssetBundle which you load in to your project which you are testing on devices? This way the actual build time is minimal, and then the internet download speed and processing of the asset bundles is faster than if Unity had to build the assets every single iteration?

 

The assetbundles were built directly from those projects. They were broken up by asset type, (buildings, units, environments, fx and UI). It did a couple of things, it meant that multiple people could easily work at the same time with no collision. We had something around a 1000 buildings, there was no point the UI designers having to load a project with tons of models, for example. It also meant that the main project was pretty much just code. It loaded and compiled very fast. Basically, for example, if a character animator was working on an animation, they would make their changes, right click on the prefab and select an option to build bundle, and it would create the 3 bundles (webplayer, ios and android) and drop them in the bundles directory. He could then fire up the game and see his changes right away in-game. If he was satisfied and done making changes, he would just commit those files to the repo, and within about five minutes, those new bundles would be pushed to the dev server and the whole team would see them on device or in the editor.

The build process could also be run directly from a techart machine that had checkouts of all those repos. So on the rare occasion where we had to rebuild everything (major Unity version change), we could just run a script that rebuilt everything. This also allowed us to do a few other things as well. Every asset to be bundled was added automatically to spreadsheet with our default settings. (texture compression, meta data, things like that). We could change those settings in the spreadsheet and rebundle using the new settings. This meant the artists didn't have to really worry about texture compression/size/settings as a rule. It would handled automatically, and tweaked easily after the fact. Later versions of the pipeline tracked files and textures all the way from maya and created database entries automatically and managed dependencies. They were big projects, so anything we could do to make the artists and animators lives more efficient was a huge savings.

Every asset had it's own bundle (mostly... common things like some UI and some others were grouped). This meant that for the player/client, it only ever downloaded the assets it actually needed, rather than a bunch of stuff that wasn't. Buildings, for example, were upgradeable and each had 10 different versions depending on your level. So only the ones you actually needed were downloaded to your device. This kept things as small as possible.

 

Thank you for the rapid and detailed response, I think I understand what you mean by the workflow enhancement! So each person would work in their asset type project, viewing small changes in the Unity Editor until they are satisfied, at which point a custom editor script would create the required asset bundles with the new asset, put them in the relevant location for accessing, and the eg: animator could then build the app, which would download from just his/her bundles directory until they are happy with the addition?

 

Essentially, but they don't actually have to build the app, they just need to launch it. Assetbundles are loaded remotely.

 

Try this Solution

 

It only took 2 years @sfbaystudios, but here's a solution!

 

mine is still compiling a build its been 3 days now and im on a mac do you thing its stopped working it still seems to work but this is rediculous it does say baking though,

 

mine also has two new assets which when i tried it on windows, same version it crashed and it only seems to half work on mac.

 

i do get the great graphics of the terrain and the aqua water which reflects on playing but still nothing after 3 days on build.

 

A better option than cloud build (more reliability/performance, but potentially more setup hassle/expense), if you have a suitable spare machine, is set up a local build machine using Jenkins.

You can set it up to automatically build and upload the build to HockeyApp (or a similar service) every time you commit to source control, then you just download it from there to your devices.

Another thing to do is ensure you can easily switch to a minimal configuration of your project, with all non-essential assets removed, and only the bits that you need to test. (e.g. if your game has lots of large level scenes, disable those in build options, and just keep the one you need to test). Doing a smaller build like that can save a bit of build time.

 

Our build times for Holodance went up from 1 1/2 hours in Unity 5.6, which already was painfully long, to an insane 3 1/2 hours in Unity 2017.4.1f1. We have tried AssetBundles a while back but that was a major waste of time (while builds sometimes were much quicker, build times also became very unpredictable, and the final nail in the coffin was that using AssetBundles messed up Steam's patcher causing huge downloads for tiny updates).

Doing minimal builds with just a few scenes does help, sometimes. Also, using automation where we trigger the build and upload the game to Steam via a batch file automatically when the build is complete helps because I can start the build still in the office, and then push it online from home.

I'm considering trying Unity 2018.1 because it has build reports which should help a lot in figuring out what it actually is that is taking so long.

EDIT: Ah, one thing I still should mention: One thing that's extremely annoying is that sometimes, build will fail after many hours due to some Shaders not compiling (usually includes in the same folder not being found after moving folders around) - a simple "reimport" on those Shaders would fix the issue, so it's quite annoying that a build fails that late in the process, when the fix would be so easy.

 

Our game takes about 15 minutes to build on a 8 core computer. Its the last step that takes time. Tha game is about 12 gigabytes built. I think assets with alot of shaders brings up time, I added CTS to try it out and the build time went crazy, had to delete the asset.

 

I'd like to know if that works halfway decent at figuring out the bottleneck in build time. I haven't tried it yet.

 

Hi. Its taking too much time when i Build and Run my Unity Project. the unity Freeze it "BUILDING GRADLE PROJECT" !! How to solve this issue?
thanks

 

Build your game, if you finished the development. You have plenty possibilities to test your project in the editor, before you build. Bulding and fixing, building and fixing should not be necessary. If you build it for a phone, then check the resolutions 16:9, 9:16 and try to change the resolution dynamicaly. Mostly the UI fails, because of layouting issues. Can you tell us why are you building for target and what do you test?

 

Related question. If you build and while it's building change and save scripts. What version of the scripts does it use? The pre saved one or the new saved one?

 

As far as I'm aware the compile process happens at the beginning of the build. So any scripts changed during the build process won't affect the build.

Of course I haven't tested this. Its also possible that changing scripts just breaks Unity. In any case, I wouldn't recommend trying it.

 

That is not really good advice: Even in a regular Windows PC game, builds frequently behave differently from the editor, and we've had plenty of bugs in builds that never occurred in the editor.

Yes, having the editor to quickly do gameplay tweaks is certainly the way to go - but I'd do a full build at least once a week, and even more frequently especially early in development.

That really depends on the kind of game you are developing. If, for example, you are developing a mobile VR game (for Daydream, Gear VR or the likes), while you can test "general VR" in the editor, there is no way to test how the game actually runs without doing a full build.

Ironically, the discussion about build times gives another pretty strong argument for doing full builds frequently: By doing builds early and often, and carefully monitoring those builds, you get an understanding of what can ruin build times and also build sizes. By only doing builds very sporadically, you may add something to the project that completely ruins build time / build size, and it may be much harder to figure out what caused this later down the road (at least in Unity 2017.4, while finding out what adds to the build size is comparatively easy, the ridiculous build times caused by shaders require significant amounts of trial and error).

 

I agree, it depends on. If you have time for this, then do it, but I'm an indie developer. If you are payed for the job, then who cares. Surely it can make sense, if you have to show the results of your work.

 

Actually, what I was trying to say was basically, that not doing builds and testing on standalone builds will frequently cost you more time in the long run than doing that kind of testing.

What I usually do on my main project is start a build after working on the project, so I can do the testing the next day, without having to wait for the build to complete.

Also, for a smaller version of the project, I was able to get the build times down from 3 1/2 hours (for the original, full project), down to less than 10 minutes for the reduced project. Doing this did take a few days - but now, we can do fairly quick builds, which is really important because we can only do the real testing on the devices (this is mobile VR/AR, where the usefulness of testing in the editor is extremely limited).

 

12 hours and still working.

 

Ha my tini mobile game only took like 5-20 seconds.

 

What kind of machine do you run? Cloud build?

 

10 mins Google Play Bundle.
2-5 mins for a general Windows build.
Having an i5 g8 with 8GB RAM.

 

me ! 9 hours and still working.
Actually unity build is a disaster, I don't know why it was so horribly long !

 

What's your hardware? Is it doing a lightbake or something? Or is this a first build from a project folder, where it's also putting together the shader cache?

My project is ~6gb just for assets. If I pull a fresh copy to a computer that will take 45 to 60 minutes to build. After that, it's less than 10 minutes for new builds. Build machines are different, but I7s with 16gb RAM and SSDs.

 

If you don't bake lights manually it will do it when you build.

 

simple scene from Unity Assets, going on 4 hours now.
From the way the task bar looks it will take 6 more hours.

Processes CPU usage :
1) Job process.exe : 9 threads 34%
2) Job process.exe : 9 threads 34%
3) Unity.exe : 93 threads 16%

all other processes < than 1%

If this CPU fan was pointed at the ground, we would have lift off.
Too bad it's not winter now, i could turn off the gas heaters in the house.

2 hours later, Killed the build, something is not right.

 

Again, have you baked lighting? Otherwise it will be done when building

 

Just as an update to this - apparently, more recent Unity versions build much much much faster. I'm not sure which version exactly brought this but currently, on 2019.1, our full main project builds in roughly 8 minutes.

Yes, that is the same project that had build times of up to 3 1/2 hours.

One thing that we did do that is known to have a significant effect on build times is reduce shaders and shader variants. This obviously did give us some improvements but the really big change seems to be Unity having a more optimized build pipeline now.

We also did optimize some of the assets for smaller build sizes and went down from roughly 8GB to around 6GB. Again, this did improve build time but not nearly as much as the apparent optimizations in Unity's build pipeline.

That said ... gameplay performance seems to be a little worse with each Unity version.

 

That has to be part of problem. The scene i downloaded to use from the asset store, i was told by the author that it would need to be baked. Have no way to do that but in the building of it.

Although as long as it takes when in scene mode to change any particle field can take 5 minutes or even more.
Just so slow, I guess it could be my computer is just not up to the task.

 

Turn of automatic baking (its default off in 2019 but was on in earlier versions). If its on it will put the maps in gi cache which is wierd. Instead bake manually, when its completed the maps will be put alongside the scene file. If you use git LFS you can check in the maps.

 

using Untiy 2019.2.3f
I'll check it anyway.

Never had status display stating that it was baking.

Thanks

 

If someone is still facing this and has an antivirus installed, Try Adding your project folder to Antivirus Exclusion list. My build time came down from 18-20mins to 2-3mins. I have a pretty big code base.

 

Jesus help me. I'm sitting here 15 minutes already waiting for a super simple build that used to take 1 minute with a much more involved project. Not sure what has been changed in the build process to make it this slow. I'm using 2019.3 btw.

Edit: Build just finished and it took over 20 minutes -_-

 

Did you update Unity? The first build often takes very long because all the shaders need to be recompiled.

 

Haven't updated because I found 2019.3 the most stable version on Linux this far. Like mentioned before when you make another build it is significantly faster and it takes about a minute.

 

Updated from 2020.3 to 2021.2 and split my project from 3 scenes into 27 scenes. Build times with 3 scenes was 2-3 minutes and now take 8-12 minutes.

 

Update: I installed Unity's experimental Build Report Inspector and it says over 8 minutes are used by building scenes! I guess I should go back to putting everything in one big scene... wish I would have known before doing all the work of splitting everything up! I don't even have any baked lighting either.

 

I would not recommend this. Multiple scenes is just way too valuable a feature, especially since you've done the work.

Large amounts of time building scenes is usually related to lighting. Do each of your sub-scenes need to have lighting baked? I'm not sure how you split up your scenes, but you can turn off or adjust light baking in (for example) UI and Audio scenes that don't need it.

 

I tried disabling/clearing out all baked lighting as well as disabling baked GI and light probes (after seeing other people talking about lighting-related issues). Some scenes have a single point light. I originally split everything into scenes so that I could do baked lighting for each scene...

I just rolled back the changes and have moved the 25 scenes into 3 (instead of 1) so build is now 3 minutes (2 of which are Building Scenes).

 

Are you accounting for build caching in your comparisons?

 

How can I tell? As far as I can see there isn't much caching happening. I repeated each build 2-3 times without making any changes and the times are almost always nearly identical.