Compile shaders on game launch?

Development Rendering
, , , ,
21

well, I don’t really care if you are advertising…while it works!

22

i just make compiler tool like bitkovin do but i can’t see any different, on game launch compile and pre-compiled one
my tool collect all material, material instance and material function and compile all of them

1 Like
23

Been trying this out and it works out amazingly!

2 Likes
24

Just a heads-up—there’s a major misunderstanding here between shader compilation and PSO caching.

  • Unreal already compiles shaders during packaging, so that’s not the issue.
  • PSOs (Pipeline State Objects) are generated dynamically at runtime based on actual rendering scenarios. Epic explicitly states that the only reliable way to collect PSOs is to log them during real gameplay. A Pipeline State Object (PSO) isn’t just a material—it’s a combination of GPU states (blend modes, rasterization, vertex layouts, etc.)
  • Using -clearPSODriverCache resets everything (shaders & PSOs), which can create the illusion that this plugin “fixed” something—when in reality, it just forced a full recompilation.

If this method really worked, Epic would have recommended it. But instead, their official guidance is to collect PSO logs while actually playing the game, because that’s the only way to ensure all needed PSOs are captured.

Anyone looking for a real solution should check Epic’s latest guidance (Feb 6, 2024):
:link: Epic’s Shader Stuttering & PSO Caching Explanation"*

2 Likes
25

Trouble is, you have to collect PSOs by playing the game with various types of GPU ( could be wrong there, but that seems to be the case, also seems impossible to do :slight_smile: ), so real-time shader compilation is supposed to be some sort of compromise ( as outlined at the end of the presentation ).

26

First off, I want to be clear: the asset does not function as intended. Let’s break it down constructively:

  1. It force-loads materials onto a cube and skeletal mesh, regardless of whether the original material was authored for that use case. This is poor practice and can lead to misleading results.
  2. Since UsesWith* flags are editor-only, the system fails to account for components like HISM—which compile differently than a standard static mesh. This creates inconsistencies at runtime.
  3. The Global Time Dilation is arbitrarily set to 5x (and even 10x in some loaders), which seems intended to “speed things up.” This reflects a misunderstanding of how time dilation affects asset loading—it doesn’t help here.
  4. The loading method used leaves assets in a bad GC state. They can (and likely will) be garbage collected when switching levels, leading to runtime crashes or missing content.
  5. The asset claims to assist with PSO caching, even going as far as including instructions for -clearPSODriverCache—which is completely unrelated and provides no benefit in this context.

If it were truly this simple, Epic would’ve shipped a tool like this themselves. Instead, I’d recommend reading this excellent breakdown by the engine team: :backhand_index_pointing_right: https://www.unrealengine.com/en-US/tech-blog/game-engines-and-shader-stuttering-unreal-engines-solution-to-the-problem

Anyone relying on this asset is unfortunately setting themselves up for instability and frustration. I’ve taken the proper approach by loading the actual assets—not just the materials—as recommended by Epic themselves.

Hope this helps clarify things for others looking into similar solutions.

2 Likes