I’ve created a fairly simple game, but building the project takes 2-3 hours, and I can’t find any fixes.
There are four main culprits in the build time ( I haven’t documented them all):
Hidden/Universal Render Pipeline/Terrain Lit (Base Pass) - ForwardLit 3072 variants (forward pass)
Universal Render Pipeline/Terrain/Lit - ForwardList 1536 variants (forward pass)
Speedtree8PBR - Forward Lit 2048 variants (forward pass)
(The one is terrain related as well, around 4k variants)
I have one very simple terrain with two texture layers and five types of tree, but all using the same model. There is baked lighting in the scene, and 3 graphics settings (all of which are customized for mobile platforms)
About the only real fix available is a powerful computer. Shader compilation is a very heavily multithreaded task (IIRC one shader compiler instance per thread) so the more cores you can afford the better your results will be.
For example in Unity5, in addition to the fact that everything is compiled instantly, there is a button for selecting which shaders need to be compiled and which not. I also noticed that when you create an empty project in new versions of Unity, many unnecessary modules are automatically connected, which may contain shaders.
I understand that Unity Technologies (Unity Software Inc.) has a lot of money and they can afford ultra-modern workstations for work. With this approach they will create a simud super unoptimized and slow development environment. But maybe the management should pay attention to the speed of compilation, to the fact that not all developers need ar, vr, xr technologies to create games. Maybe. In general, it’s worth making a separate Unity Indie IDE for indie developers faster, lightweight and without all these fashionable virtual 3D modules.
If the shader is not used in the project. Why compile it? It’s pointless. And there are thousands of these shaders… Besides the fact that you have to wait, these shaders will fill your entire hard drive. What if you have several projects? And that, each primitive game like ping-pong will take up several gigabytes of disk space? This is clearly an optimization violation in IDE.
You don’t need an “ultra-modern workstation” or even a “lot of money”. Here’s a variation of a system that I build and recommend to people. You won’t see the one to two minute compile times that you would with a top tier CPU but it’ll still be below 15 minutes or so.
With sales or using existing components like your own case you can easily push the cost below $300.
Only from the perspective of someone that insists on running the latest generation engines on their dinosaur of a computer. But see the problem with that perspective is that this company isn’t running a charity. Unity would have to be able to justify the development costs and if you can’t buy a budget tier system you certainly can’t buy Unity.
You either need to choose a different game engine or use an older release of Unity (eg Unity 5.6.7). You can try the built-in render pipeline too but that’s on it’s way out because fewer and fewer people are using it every year.
My latest work project is currently on its 8th month and the total space consumed by shaders is… 2.5MB. Which is about as I would expect since they’re just little snippets of code that run on the GPU. It only seems like they would be because the shaders take a long time (relatively speaking) to compile due to all the optimizations happening.
If Unity is compiling the shader it means that it detected something trying to use that variant of the shader.
This topic should probably be moved from the main section of shaders. because this is not a shader issue, but an optimization issue…
Why? Unity has become heavy… But this is not a reason to buy a license, this is a reason to buy, a powerful computer.
I don’t want to buy a license anyway. The logo at the start suits me.
My opinion is that even if there are people with dinosaur computers, you need to treat this without contempt.
Yes, this may be suitable for creating portotypes, but not for assembling an executable file.
I’m not even thinking about Unity6 yet, I’m not interested in it. I need a modern offline build tool.
Because sellers also have some requirements for executable files.
I don’t have contempt for them. I don’t even have contempt for the hardware. All of it was fantastic once upon a time, but hardware has a finite lifespan and you can’t expect it to magically run the latest and greatest (relatively speaking since UE is far more capable but also far more demanding).
On the contrary it’s perfectly fine for a final build ready to be released, and if you don’t mind moving one step newer to Unity 2017 you can even release builds for mobile platforms. It’s only truly the consoles where you are locked to recent versions.
You need a modern computer for that, or you need an alternative engine (note though that Godot has higher system requirements than Unity).
Yes, you can test the application on the device, but you will not be able to place it on the play market. You still need a modern compilation tool with APIs of a certain level.
Therefore, it would be nice to have a lightweight and fast version of Unity without any bells and whistles. Somehow there are still several LTS assemblies going on there. It would be possible to write a script that would not include everything unnecessary for bigger part of indie developers in the assembly. This is my vision.
You may be right in some ways…
Also is possible try installing Unity on Ubuntu. maybe it will work better than under pure Windows… The virtual machine also allows to free up the system disk from extra gigabytes.
As for the question itself, perhaps the answer can be found here:
Yes, I launched Unity2023 again. I can note that the requirements for hardware have simply increased. But I don’t see any convenience or intuitiveness in game development. Here you need a reference book or a book of recipes for creating a simple UI or a tilemap.
So, there is no way around those horrible compile times? I mean, I blame the shaders from NatureManufacture’s shaders. They seem to be badly optimized…
