I know there is a lot of complaining about shader compiles taking a long time, but this thread has a more specific focus: Under certain circumstances, the entire Unreal Editor UI stops responding to input events until all shader compilation is done.
Here’s an example: Tonight I had a fairly small archviz project open. I had just imported some master materials from the Marketplace, a product I’ve used multiple times before and know works well. This time I wanted to use one of the materials that I hadn’t used previously, and since the product comes with several example maps, I double-clicked one of those to have a look at this material in action.
A two-part progress bar popped up in a modal dialog panel indicating that UE 5 was “preparing shaders”. The percentages moved a little and then stalled, but Task Manager clearly showed that I had all 8 cores of my CPU pinned with shader compiles.
I do not especially mind the long shader compile times which normally run in the background. I don’t mind if the scene viewport shows placeholders or incomplete materials for shaders that aren’t yet ready.
But in this case, I couldn’t work at all because the dialog panel is modal. Furthermore, there was no CANCEL button to tell UE to forget about it and just not load that map.
I waited about 30 minutes, recalling that previously that particular progress bar had appeared stalled for a while and then suddenly jumped to “all done”. After half an hour of no movement, I got tired of waiting and used Task Manager to force-kill the Unreal Editor — not something I do lightly!
My questions to the community are:
Am I doing something wrong that is causing modal behavior in a process that is expected to be backgrounded?
Is there any way to tell, before entering that state, that a map I am about to open will cause a massive shader compile?
Is this a known issue that the Epic team has already stated will be fixed soon?
I’d be happy with a simple CANCEL button on that dialog, so if it’s running too long there is at least a graceful way to say “never mind, i’ll open that map some other time.” Better, though, all shader compiles should be background processes so the UI is never completely unresponsive.
I’ve been looking at the symptoms, and my hypothesis is that this happens if UE was already compiling shaders in background. Perhaps loading a level, which often leads to a small number of shader compiles, is getting stuck behind the work already in the queue.
The idea of a CANCEL button on that progress dialog seems (to me, at least) as a possible workaround for a dependency-driven long blocking situation. I had asked about being able to anticipate the problem, but I don’t seriously think that’s viable (that bullet point was driven by my desire not to “assume” something is impossible just because I can’t think of how to do it).
I am having a similar issue with the shader compilation in UE5 myself, so I’m hoping that we can get some direction on this topic. I’m relatively inexperienced with using UE5 and just began following along with a tutorial for the creation of a small level. The project hinges upon migrating the level assets from the free Medieval Game Environment project into a new project. However, the first time I attempted to do this, the UE5 editor crashed after running for well over an hour.
Before the editor even opened it took a long time to compile the shaders from the launcher. I figured it would be good to go after that first compilation. However, upon opening a level it launched into another compilation all over again. I would have been okay with this, but similar to Syscrusher’s account, I couldn’t interact with any of the UE5 interface while this compilation was happening. My CPU and ram were both capping out at 100% for the majority of this time, and things were not moving quickly. --nor could I tell if something had failed causing the program to be stuck in some weird limbo where it looked like things were happening, but were, in fact, not going anywhere at all. It would be great if shader compilation could be paused or cancelled to prevent it from interfering with tasks that don’t require the compilation in the first place.
This shader preparing has got a lot worse with later versions, as in it takes longer than it used to. But what seems to be new is that it seems to prioritize the shaders over opening a map, or attempt to do both simultaneously, resulting in neither action taking place within a reasonable (hours) time frame. In my case shaders are sorted out much faster if I disable real time rendering and set the window to wireframe, but the shaders never crippled my system back in 4.15-20, and I have replaced my computer twice since then.