Hello, this is my first post here. I forked and cloned the repository from github and followed the instructions on the github page using Visual Studio 2013. I compiled the projects just as it was indicated, but every time I attempt to build and run the editor (F5 with the UE4 project set as the startup project), it compiles but then the loading screen for the Unreal Editor that pops up starts loading and gets stuck at 45% every time. I’ve tried waiting for long periods of times, but this doesn’t seem to change.
I’ve had the same thing. I have an i5 laptop with 8GB of RAM. When I switched to the GITHUB build to diagnose a crash it took forever to load up…
I installed process monitor
And I could see that the engine was firing up lots of threads to compile shaders, once it eventually finished spawning all the shader threads it loaded up.
You may want to try process monitor and see if thats where your delay is too.
I have an i7 2.60 GHz with 8GB RAM. I took a look using the process monitor and it looks like what you described: three worker threads for compiling shaders are spawned and that’s that. What did you end up doing to address the issue?
EDIT: Let it run for about 30 minutes and stepped away and at some point it ran into completion, which is strange because I had let it run for over an hour previously and it had stuck at 45%. Will try to reproduce. Thanks!
I just left it running. Because I could see all these shader threads being started up and shut down by the editor.exe I knew it was doing some sort of set up and needed to be left to it.
Now all the shaders are built you’ll have to move to a new engine version to get it to rebuild them all. The launch process should be quick now, as it won’t need to build the shaders again.
Also, you left it an hour before then you killed it. It wouldn’t start over and do that hour again because each thread writes the shader to the hard drive. That hour of work will have been saved, and it would pick up where it left off with the next shader it needs to build. Hence if you’d left it from the very start it would have done 1 1/2 hours of shader compiling time.
If you killed it every 15 minutes, still 1 1/2 hours of compiling would go by, but you’d have restarted 6 times.
This is Ridiculous that you have to wait for all the shaders in the assets to be all re-built before the editor even loads itself to open your project up, it pays not to have projects with so many textures assets in then if the editor is going to continually do this compiling. THAT is why Game development is so painfully slow in this engine…
Oh sometimes I forget that in unreal engine there’s both textures and also materials, so maybe they are using the materials instead. I’m trying to resolve my spline issue, for some reason the mesh
deforms when going along the spline points. There’s so many issues going on with this engine, but maybe its the same in most 3d game engines.
Hello. Sorry I’m not good speak English. Please Convert Turkish to English.
Merhaba. Bu sorunla karşılaşıyorsanız muhtemelen kullandığınız Monitör 4K Çözünürlüğündedir. Sorunu gidermek amacı ile Masaüstünüzde bulunan Epic Games’e Sağ tıklayıp Özellikler kısmına gelin. Daha sonra da Uyumluluk bölümüne gelerek, " Yüksek DPI ölçeklendirme davranışını geçersiz kıl. Ölçeklendirmeyi gerçekleştiren : " Seçeneğini işaretleyip altta çıkacak seçeneklerden de Sistem yazanı seçin. Sorunsuz açılacaktır.
This was happening to me as well, but i restarted my computer, Windows 10, and i tried again, it got stuck at 45% again but this time one of those confirmation pop ups came up and i clicked allow, or what ever, then it went past 45% now its working. Hope this helps, it probably wont though.
Im having the same issue. I did what was suggested exactly and it does show compiler running but i isolated its usage with the resource monitor and the shader only is using an average .66% of the cpu and 312mb of memory. Nothing more. Left it on for 24 hours and nothing loaded… whats the next suggestion?? 4.21.1 wont run source or release on my computer so 4.17.2 is my only option
TheJamish hit the nail on the head. If you delete the folder called derived data cache, you can make Unreal recompile all your shaders and it will be at 45% for while. This can happen if you upgrade versions. It happened to me when I went from 4.21.0 to 4.21.1.
I understand its compiling shaders. Although it really should be more verbose. How many shaders are left?
Imagine the number of people that doing this put off using UE when they may have become good game developers eventually.
It seems like everybody who has tried this had the same question.
What gets me the most is it seems to take just as long whether I am using a new powerful PC or an old one.
Appears to be bad coding to me. Although Visual Studio does that too. It doesn’t take advantage of the powerful hardware I have.
When building UE for me it only uses CPU 17%. RAM 30%. Disk 1%.
Why not use what the local machine has to offer rather than leaving us waiting for it for so long like we have nothing better to do.
When you update to a new engine version, move a project to a new engine version or anything like that, you will have to recompile all shaders. Being “stuck” on 45% is almost always shader compilation. This can take a long time. Shader compilation is multithreaded and a faster CPU will help, but in my experience you will need a considerably faster CPU, like a Threadripper, to make any real difference. Moving from an i5 to an i7 will barely make a dent.
Shader Compiling can also be distributed with XGE (Incredibuild) - but that’s only beneficial if you can a) afford the insane incredibuild license costs and b) have a few spare PC’s lying around at home.
You can reduce shader compilation times by making sure that your material “usage” flags are set properly, and by disabling rendering features which create more shader permutations (such as disabling pointlights for example).
I agree however, that the splash screen should give some indication as to what it’s currnetly doing. If you open the engine through visual studio however, you get a nice readout of what the engine is doing in the output log - even if the engine itself is locked up. Pros of being a CPP developer
Just for information, it could also happened if you check " forward shading " in the rendering option. It stayed loaded at 45% for 10 minutes. Everything went fine after.
I had this problem with a 75% load. I can’t comment on whether there is something special about 45% (i.e. algorithm for the displayed loading percentage). But the solution in my case was pretty straightforward. Also I am glad I figured out the “why” of it because it is very very likely to come up again. If you have C++ assets you wrote that exist under “C++ Classes” alongside “Content” it seems to always run default constructors when you load the sln file
**IMPORTANT DETAIL: **This seems to be true whether or not your objects have been instantiated in the project. So if your code default constructor gets stuck… so does the loading screen.
I did a lot of trial and error before I realized it was just the presence of certain C++ classes in the project that caused it. So went and ran/started the unreal editor using “debug” in Visual Studio. Once it got stuck I hit pause on execution. Sure enough it was stuck in an AActor constructor and as I stepped through the code I found the infinite loop that was causing it. The thing that was frustrating for a while is I had no idea what exactly had gone bad. I was already messing around with materials, blueprints, etc… I was not expecting to run into infinite loop errors for things that were not even placed in the level. But live and learn… hope that helps someone not to have to spend as much time I did on this…
