Speed Up UE Shader Compiles

What This Tutorial Covers

This guide focuses on Unreal Engine shader compile configuration, especially the settings found under:

[DevOptions.Shaders]

You will learn what the most important options do, which values are usually safe to adjust, and how those settings affect compile speed, CPU load, and editor responsiveness.

This tutorial covers:

• Where to find BaseEngine.ini
• How to locate shader compiler settings
• What shader worker processes are
• How Unreal decides how many CPU threads to use
• How to reduce unused compile threads
• How to tune batch size and worker priority
• How to balance faster compiles against system responsiveness
• Which settings beginners should avoid touching too aggressively

Important Warning Before Editing Engine Config Files

Be careful when editing engine configuration files. BaseEngine.ini affects the installed engine version, not just one project. If you change the wrong value or use extreme settings, you may cause instability, excessive CPU usage, or unexpected editor behavior.

Before changing anything, make a backup copy of the file.

BaseEngine.ini
BaseEngine_backup.ini

If something goes wrong, you can restore the original file. Do not skip this. It takes ten seconds and can save you from wasting time later.

Also understand the tradeoff: faster shader compilation usually means Unreal uses more CPU resources. That can make the editor, browser, recording software, or the rest of your system feel heavier during compilation.

Where to Find BaseEngine.ini

First, locate your Unreal Engine installation folder. If you installed Unreal Engine through the Epic Games Launcher, the default path on Windows usually looks like this:

C:\Program Files\Epic Games\UE_5.4\Engine\Config\BaseEngine.ini

The exact version number depends on your installed engine version. For example:

C:\Program Files\Epic Games\UE_5.5\Engine\Config\BaseEngine.ini
C:\Program Files\Epic Games\UE_5.6\Engine\Config\BaseEngine.ini

Open the file using a text editor such as Notepad, Visual Studio Code, Rider, Notepad++, or any editor that can safely edit plain text files.

Once the file is open, search for:

[DevOptions.Shaders]

You can also search for:

worker

That will usually bring you close to the shader compiler settings section.

What Shader Compilation Actually Does

Unreal Engine materials are not directly used by the GPU in the same way you create them in the Material Editor. Unreal has to compile material graphs, shader permutations, platform-specific code, lighting options, quality levels, feature levels, and rendering paths into shader programs that the engine and GPU can use.

This is why shader compilation can explode quickly. One master material with many static switches can create many shader permutations. A large asset pack with hundreds of materials can trigger thousands of shader jobs.

Shader compilation is not only about one material. It is about every combination Unreal needs for your target platform and rendering configuration.

That is why optimizing shader compile behavior matters. You are not only saving seconds. Over a full project, you may save hours of waiting.

Understanding Shader Compile Workers

Unreal Engine can compile shaders through external worker processes. These are separate processes that handle shader jobs outside the main editor process.

This is important because shader compilation can run in parallel. Instead of forcing the editor to do everything on one thread, Unreal can distribute work across available CPU cores.

More worker usage usually means faster shader compilation, but it also means more CPU load. If you use every available thread, your system may become less responsive while compiling.

bAllowCompilingThroughWorkers

bAllowCompilingThroughWorkers=True

This setting allows Unreal Engine to use external shader compile worker processes.

In most cases, keep this set to:

True

If this is disabled, shader compilation can become much slower because Unreal will not use worker processes effectively.

Recommended value:

bAllowCompilingThroughWorkers=True

bAllowAsynchronousShaderCompiling

bAllowAsynchronousShaderCompiling=True

This setting allows shader compilation to happen asynchronously in the background.

Without asynchronous compiling, the editor would feel much more blocked while shaders compile. With it enabled, Unreal can continue doing other work while shader jobs are processed.

For normal development, keep this enabled.

bAllowAsynchronousShaderCompiling=True

Turning this off usually makes the workflow worse, not better.

NumUnusedShaderCompilingThreads

NumUnusedShaderCompilingThreads=3

This value tells Unreal how many CPU threads should remain unused while compiling shaders.

For example, if your CPU has sixteen threads and Unreal leaves three unused, then shader compilation can use roughly the remaining available worker capacity while the system keeps some headroom.

Lower values usually mean faster shader compilation because Unreal can use more CPU threads. But lower values also increase CPU pressure.

Example options:

NumUnusedShaderCompilingThreads=3
NumUnusedShaderCompilingThreads=2
NumUnusedShaderCompilingThreads=1
NumUnusedShaderCompilingThreads=0

If you have a strong desktop CPU and you do not mind the system becoming busier during shader compilation, you can try reducing this value.

A safer starting point is:

NumUnusedShaderCompilingThreads=2

Aggressive setting:

NumUnusedShaderCompilingThreads=1

Very aggressive setting:

NumUnusedShaderCompilingThreads=0

Do not blindly set it to zero on weak laptops or machines where you are also recording, streaming, rendering, or running other heavy tools.

NumUnusedShaderCompilingThreadsDuringGame

NumUnusedShaderCompilingThreadsDuringGame=4

This is similar to NumUnusedShaderCompilingThreads, but it applies while a game is running.

This value is usually more conservative because Unreal needs to keep the game responsive while shader compilation happens.

If you are testing gameplay while shaders compile, leaving more unused threads can reduce stutter. If you only care about faster compilation and do not mind temporary runtime performance drops, you can reduce it cautiously.

Safe example:

NumUnusedShaderCompilingThreadsDuringGame=4

Faster but heavier:

NumUnusedShaderCompilingThreadsDuringGame=2

I would not aggressively lower this unless you understand the tradeoff. The editor may still compile shaders while you are testing in PIE, and using too many threads can make the game feel less stable during that time.

ShaderCompilerCoreCountThreshold

ShaderCompilerCoreCountThreshold=12

This setting decides when Unreal switches from fixed unused thread counts to percentage-based thread calculation.

In simpler terms, Unreal checks your CPU core or thread count. If your CPU is below the threshold, it relies more on fixed values such as NumUnusedShaderCompilingThreads. If your CPU is above the threshold, it can use percentage-based logic.

If you have a modern CPU with many cores, this setting becomes important. If you have an eight-core or ten-core CPU and want Unreal to use percentage-based settings earlier, you can lower the threshold.

Example:

ShaderCompilerCoreCountThreshold=8

This can make PercentageUnusedShaderCompilingThreads matter sooner on CPUs that do not reach the default threshold.

PercentageUnusedShaderCompilingThreads

PercentageUnusedShaderCompilingThreads=50

This setting controls what percentage of CPU threads should remain unused when Unreal is using percentage-based shader compiler thread logic.

A value of fifty means Unreal leaves about half of the CPU thread capacity unused for shader compilation. That is safer for system responsiveness, but slower for compile speed.

If you want faster shader compilation on a strong CPU, this is one of the most important settings to test.

Conservative setting:

PercentageUnusedShaderCompilingThreads=50

Balanced setting:

PercentageUnusedShaderCompilingThreads=25

Faster setting:

PercentageUnusedShaderCompilingThreads=20

Aggressive setting:

PercentageUnusedShaderCompilingThreads=10

If you set this too low, Unreal may use a lot more CPU during shader compilation. That can be good if you want speed, but bad if you need to keep working smoothly while shaders compile.

MaxShaderJobBatchSize

MaxShaderJobBatchSize=10

This controls how many shader compile jobs are grouped into a batch.

Larger batch sizes can reduce overhead because workers process more jobs per batch. On modern CPUs, increasing this value slightly can improve efficiency.

Default example:

MaxShaderJobBatchSize=10

Moderate increase:

MaxShaderJobBatchSize=15

More aggressive:

MaxShaderJobBatchSize=20

Do not push this blindly. Bigger is not always better. If batches become too large, feedback may feel delayed and memory pressure can increase depending on the project.

bPromptToRetryFailedShaderCompiles

bPromptToRetryFailedShaderCompiles=False

This setting controls whether Unreal shows a prompt when shader compilation fails.

For normal development, leaving it false can keep the workflow cleaner. Unreal will not interrupt you with prompts for every failed shader compile.

But if you are debugging shader issues, material compiler errors, custom HLSL problems, or engine rendering changes, enabling this can help.

Normal development:

bPromptToRetryFailedShaderCompiles=False

Debugging shader failures:

bPromptToRetryFailedShaderCompiles=True

bDebugBreakOnPromptToRetryShaderCompile

bDebugBreakOnPromptToRetryShaderCompile=False

This is mainly useful for engine developers or people debugging Unreal Engine source code.

If you are a gameplay developer, environment artist, technical artist, or Blueprint developer, you almost certainly want to leave this disabled.

bDebugBreakOnPromptToRetryShaderCompile=False

bLogJobCompletionTimes

bLogJobCompletionTimes=False

If enabled, Unreal logs shader job completion times. This can help with profiling shader compiler behavior.

For most developers, this creates unnecessary log noise.

Keep it false unless you are actively profiling shader compilation.

bLogJobCompletionTimes=False

ProcessGameThreadTargetTime

ProcessGameThreadTargetTime=0.01

This controls how much time the game thread can spend processing shader compile results.

The default value of 0.01 means roughly ten milliseconds. This gives Unreal a small slice of game thread time to process completed shader jobs without locking the editor too aggressively.

Raising this value may help shader results get processed faster, but it can also create stutter if the editor or game thread spends too much time handling shader results.

Recommended for most users:

ProcessGameThreadTargetTime=0.01

Only adjust this if you know why you are doing it.

WorkerTimeToLive

WorkerTimeToLive=20

This setting controls how long shader worker processes stay alive after becoming idle.

A lower value frees resources sooner. A higher value keeps workers alive longer, which can help if you compile shaders frequently in bursts.

Default style value:

WorkerTimeToLive=20

If you are constantly changing materials and causing repeated shader compiles, a slightly higher value may reduce worker restart overhead.

WorkerTimeToLive=60

Do not set it extremely high unless you understand the memory tradeoff.

BuildWorkerTimeToLive

BuildWorkerTimeToLive=1200

This is similar to WorkerTimeToLive, but it is more relevant for build workflows and automated build environments.

The default value of 1200 seconds equals twenty minutes.

For local development, you usually do not need to adjust this.

BuildWorkerTimeToLive=1200

WorkerProcessPriority

WorkerProcessPriority=-1

This setting controls the priority of shader compile worker processes.

Lower priority keeps your system more responsive. Higher priority can make shader compilation faster, but it can also make the editor or other apps feel heavier while compiling.

Common values:

-1 = lower priority
0 = normal priority
1 = higher priority
2 = even higher priority

Default is usually safer:

WorkerProcessPriority=-1

Balanced faster setting:

WorkerProcessPriority=0

Aggressive setting:

WorkerProcessPriority=1

I would not jump directly to high priority on a weak CPU. Test normal priority first.

Safe Settings to Try First

If you do not want to overthink everything, start with only a few changes. Do not change ten settings at once. Change a small group, restart Unreal Engine, test shader compilation, and watch CPU usage.

A reasonable first tuning pass:

NumUnusedShaderCompilingThreads=2
PercentageUnusedShaderCompilingThreads=25
MaxShaderJobBatchSize=15
WorkerProcessPriority=0

If your CPU is strong and your system remains responsive, you can try:

NumUnusedShaderCompilingThreads=1
PercentageUnusedShaderCompilingThreads=20
MaxShaderJobBatchSize=20
WorkerProcessPriority=0

If you want a more aggressive compile-speed setup:

NumUnusedShaderCompilingThreads=1
PercentageUnusedShaderCompilingThreads=10
MaxShaderJobBatchSize=20
WorkerProcessPriority=1

Use aggressive settings only if you can tolerate higher CPU usage. If your machine becomes hard to use during shader compilation, back off.

Recommended Settings by Hardware Type

Low-Core Laptop

If you are using a laptop with fewer cores, do not push shader compiling too hard. You need to preserve responsiveness and control heat.

NumUnusedShaderCompilingThreads=3
PercentageUnusedShaderCompilingThreads=50
MaxShaderJobBatchSize=10
WorkerProcessPriority=-1

This is slower, but safer.

Mid-Range Desktop

For a normal gaming or development desktop, you can usually be more aggressive.

NumUnusedShaderCompilingThreads=2
PercentageUnusedShaderCompilingThreads=25
MaxShaderJobBatchSize=15
WorkerProcessPriority=0

High-Core Workstation

If you have a powerful CPU with many cores and strong cooling, you can use more compile workers.

NumUnusedShaderCompilingThreads=1
PercentageUnusedShaderCompilingThreads=10
MaxShaderJobBatchSize=20
WorkerProcessPriority=1

Watch temperatures, memory usage, and editor responsiveness. More speed is useless if the system becomes unstable.

What These Settings Cannot Fix

These config changes can help Unreal process shader work faster, but they do not fix every shader problem.

They will not fix:

• Bad master material design
• Too many static switches
• Massive material permutation counts
• Overly complex shader graphs
• Poor asset organization
• Wrong rendering feature usage for your target hardware
• Importing huge marketplace packs without cleanup

If your project creates too many shader permutations, tuning worker settings helps only part of the problem. You still need to simplify material architecture.

Material Workflow Tips to Reduce Shader Pain

Config tuning is useful, but better material workflow matters even more in large projects.

• Use material instances instead of duplicating full materials.
• Avoid unnecessary static switches in master materials.
• Keep master materials focused instead of making one monster material for everything.
• Separate character, environment, UI, VFX, and prop material needs when necessary.
• Remove unused assets and unused material features.
• Be careful when importing large packs with hundreds of materials.
• Test shader cost early, not after the whole environment is built.

Brutal truth: if your material system is messy, no config file will fully save you. These settings make the compiler faster. They do not make bad shader architecture good.

How to Test Your Changes

After editing BaseEngine.ini, restart Unreal Engine. Then test with a real shader workload.

Good test cases:

• Open a project with many uncompiled shaders.
• Import a material-heavy asset pack.
• Change a master material used by many instances.
• Switch rendering settings that trigger recompilation.
• Clean Derived Data Cache only if you intentionally want a heavier test.

Monitor:

• CPU usage
• Memory usage
• Editor responsiveness
• Shader compile count speed
• System temperature if using a laptop

If the system becomes too slow to use, your settings are too aggressive.

Should You Edit BaseEngine.ini or Project Config?

Editing BaseEngine.ini changes the installed engine version. That means the change can affect every project using that engine installation.

This is useful if you want a global development workflow improvement, but it also means you should document your changes.

For team projects, be careful. Do not assume every teammate should use the same hardware tuning values. A developer with a sixteen-core workstation and a developer with a laptop should not necessarily use the same shader worker settings.

Best practice: keep personal machine-specific tuning documented separately instead of forcing it on everyone.

Common Mistakes

Changing Too Many Values at Once

If you change everything at once and something feels wrong, you will not know which setting caused the issue. Change a few values, test, then continue.

Using Aggressive Settings on Weak Hardware

Faster compile settings can make your machine feel locked up if the CPU is weak or already busy.

Ignoring Heat and Power Limits

Laptops can throttle under heavy shader compilation. If your CPU gets too hot, it may reduce clock speed, and the aggressive settings may not help as much as expected.

Expecting Shader Settings to Fix Bad Materials

If your master material creates too many permutations, the real fix is better material design.

Forgetting to Backup BaseEngine.ini

Always backup the file before editing. This is basic discipline.

Practical Configuration Example

Here is a balanced example for a modern desktop CPU. This is not universal, but it is a good starting point for testing.

[DevOptions.Shaders]
bAllowCompilingThroughWorkers=True
bAllowAsynchronousShaderCompiling=True
NumUnusedShaderCompilingThreads=2
NumUnusedShaderCompilingThreadsDuringGame=4
ShaderCompilerCoreCountThreshold=8
PercentageUnusedShaderCompilingThreads=25
MaxShaderJobBatchSize=15
bPromptToRetryFailedShaderCompiles=False
bDebugBreakOnPromptToRetryShaderCompile=False
bLogJobCompletionTimes=False
ProcessGameThreadTargetTime=0.01
WorkerTimeToLive=20
BuildWorkerTimeToLive=1200
WorkerProcessPriority=0

If your system remains responsive and you want more speed, lower PercentageUnusedShaderCompilingThreads or increase WorkerProcessPriority cautiously.

Best Settings to Change First

If you only want the highest-impact settings, focus on these:

• NumUnusedShaderCompilingThreads: controls how many threads are reserved.
• PercentageUnusedShaderCompilingThreads: controls CPU headroom on higher-core machines.
• MaxShaderJobBatchSize: controls shader job batching efficiency.
• WorkerProcessPriority: controls worker process priority.

These are the most practical settings for most developers. The rest are useful to understand, but you usually do not need to touch all of them.

Best Practices for Unreal Shader Compile Optimization

• Backup BaseEngine.ini before editing.
• Change only a few values at a time.
• Restart Unreal Engine after making changes.
• Monitor CPU usage after tuning.
• Use balanced settings if you record tutorials, stream, or multitask.
• Use aggressive settings only when you want maximum compile speed.
• Keep material architecture clean to reduce shader permutations.
• Use material instances where possible.
• Do not force one machine-specific config on an entire team.

Conclusion

Shader compilation will always be part of Unreal Engine development, but you do not have to accept the default experience blindly. By tuning the shader compiler settings inside BaseEngine.ini, you can make Unreal use your CPU more effectively and reduce unnecessary waiting during development.

The most useful settings to test are thread reservation, percentage-based unused threads, shader job batch size, and worker priority. Start with safe values, test your project, and adjust based on your hardware.

Do not chase extreme settings just because they look faster. The best setup is the one that gives you faster compile times while keeping the editor responsive enough to keep working.

Watch the full tutorial: Speed Up Unreal Engine Development With Better Shader Settings

More Unreal Engine tutorials: rambod.net

Subscribe for more: Rambod YouTube Channel

Frequently Asked Questions

Will these settings work in Unreal Engine 5?

Yes, these settings are relevant to modern Unreal Engine versions. Exact defaults may vary by version, but the general shader compiler workflow remains similar.

Do these settings improve game FPS?

No. These settings mainly affect shader compilation workflow during development. They do not directly optimize runtime frame rate.

Can this break my Unreal Engine installation?

Bad values can cause unstable behavior or poor responsiveness. That is why you should backup BaseEngine.ini before changing anything.

What is the safest setting to change first?

Start with NumUnusedShaderCompilingThreads and PercentageUnusedShaderCompilingThreads. These usually provide the clearest compile speed difference.

Should I set unused threads to zero?

Only if you have strong hardware and you do not mind heavy CPU usage. For many developers, leaving one or two threads unused is smarter.

Why is shader compilation still slow after tuning?

Your project may have too many shader permutations, heavy master materials, large imported assets, or complex rendering settings. Config tuning helps, but it does not fix bad material architecture.

Should every teammate use the same settings?

Not necessarily. Shader compile settings should match hardware. A high-core workstation and a laptop should not always use the same values.