Hyper PSO Precaching helps reduce first-use loading and rendering hitches by preparing supported rendering pipelines and selected assets during startup and map changes. It includes a customizable loading screen, optional asset preloading, and a World Partition streaming profile.

The plugin supports Unreal Engine 5.8 on Win64. Basic installation and loading preparation require no Blueprint or C++ setup.

Installation

1. Close Unreal Editor.
2. Copy the HyperPSOPrecaching folder to <YourProject>/Plugins/HyperPSOPrecaching.
3. Open the project and enable Hyper PSO Precaching under Edit > Plugins. Restart the editor when requested.
4. Open Project Settings > Game > Hyper PSO Precaching to customize the screen or choose assets to preload.

Recommended PSO and shader-library settings are applied automatically when the editor loads the plugin. Existing project choices are preserved. Restore Recommended Setup is optional and restores the recommended values if you have changed them.

Keep the project’s Config files writable so setup can be saved. The required CommonUI engine plugin is enabled automatically. No third-party loading-screen plugin is needed.

Project Settings

To use your own font, select an Unreal Font asset under Style > Font. Leave it empty to use Unreal’s built-in font. The plugin includes the selected font’s directory when packaging.

Loading Screen Behavior

Preparation runs at startup, during ordinary map loads, and during seamless travel. The screen waits for pending shader work, selected assets, initial streaming, and render preparation. The progress bar estimates this combined work, so it can pause while newly discovered assets are prepared.

The world continues ticking and rendering behind the viewport screen while game-viewport input is blocked. The screen does not delay BeginPlay or synchronize multiplayer match start. Routine World Partition movement does not repeatedly open a full-screen loading screen.

Existing startup movies and MoviePlayer loading screens keep their presentation. Hyper PSO continues preparation afterward when needed. If another loading-screen system requires a manual stop, that system must still release its own screen.

A safety timeout prevents an indefinite plugin preparation wait. The default is 180 seconds after engine loading finishes. Closing because of a timeout does not mean preparation succeeded.

Preparation can reduce first-use hitches, but it cannot guarantee hitch-free gameplay. Assets loaded later, actor spawning, animation initialization, streaming, and gameplay code can still introduce work.

Startup and Map Preload Assets

Under Gameplay Preparation, choose content that should be available before it is first used. Configure these lists before starting play, with loading preparation enabled.

• Startup Preload Assets: shared assets, Blueprint classes, or DataTables to prepare once and retain across map changes.
• Map Preload Assets: select a destination Map and its Assets. These prepare when that map opens, including direct startup and PIE. Assets shared with the previous map are reused; assets exclusive to the previous map are released after the handover.
• Startup Preload Animation Classes: optional animation classes whose defaults and references should be prepared at startup. This does not create animation instances or run initialization graphs.

For example, put shared player assets in the startup list and a level’s enemy or equipment data in that map’s list. Individual World Partition cell loads do not restart the map list.

DataTables and Blueprint Classes

A DataTable selected directly in a preload list prepares all rows and their nested references. A table reached indirectly through another asset is loaded without expanding every row. An explicit DataTableRowHandle follows only its selected row.

Selecting an actor class prepares its defaults and component templates without spawning the actor or running construction scripts.

Preloaded assets use memory while retained. Keep lists focused on content you need soon. Under low memory, some loads can be deferred and preparation can finish with an incomplete result. Dynamically constructed asset paths still need your project’s normal cooking rules.

Preload Blueprint References

Use reference preloading for live data such as inventory, selected equipment, or abilities containing soft asset references.

1. Select the member variable in the Blueprint’s My Blueprint panel.
2. Expand Details > Variable > Advanced and enable Async Preload References.
3. Leave Observe Reference Changes enabled to follow later changes, or disable it for one-time preparation.
4. Compile and save the Blueprint. Keep the generated Config/DefaultGame.ini rules with the project so the selection also works in packaged builds.

Set inherited variables on the Blueprint that declares them. The preloader follows reflected references in structs, arrays, maps, sets, and explicit DataTable row handles. It cannot infer an asset that gameplay chooses later through a tag lookup or other runtime calculation.

Following Changes

Poll for Silent Changes is off by default. Observed selections respond to supported FieldNotify, DataTable, and lifecycle events. An ordinary Set, RepNotify, or in-place array edit does not automatically notify the plugin. Enable polling if your data changes without a supported notification. Polling adds recurring CPU work.

Local-player-owned sources are eligible regardless of distance. Other marked world sources are considered within 10 meters by default, controlled by Preload Nearby World References and Preload World Radius. Walking into range alone does not trigger discovery with polling off. This prepares references on already loaded sources; it does not stream World Partition cells.

Preparing a Whole Actor

In a concrete actor Blueprint’s Class Settings or Class Defaults, enable Hyper PSO Precaching > Async Preload Actor References to prepare its defaults at startup and its eligible live references. New actor selections prepare once by default; enable Observe Reference Changes when ongoing tracking is needed.

A whole-actor selection can include a large runtime catalogue. Prefer individual inventory/equipment variables for live data. If you only need class defaults prepared before spawning, add the class to a startup or map preload list instead.

Custom Preparation Widget

You can replace the viewport preparation screen with your own UMG widget:

1. Create a Widget Blueprint with parent class Hyper PSO Preparation Widget.
2. Design your background, text, animations, and progress bar.
3. Override On Preparation Status Changed and break its Status input.
4. Connect Progress to Set Percent, and Title / Status Text to your text controls’ Set Text.
5. Select it under Project Settings > Game > Hyper PSO Precaching > Style > Custom Preparation Widget.

The plugin creates and displays the widget. Do not call Add to Viewport. Tick and property bindings are not required for status updates. Progress ranges from 0 to 1; the plugin decides when preparation is complete and closes the screen.

Leave the selection empty to use the built-in screen. An invalid widget falls back to the built-in presentation. The selected widget’s directory is included when packaging, so keep presentation assets in a dedicated UI folder.

Custom widgets replace the viewport phase only. Blocking MoviePlayer startup and map loading still use Slate. UMG animations cannot run while synchronous loading blocks the game thread.

Run Gameplay After Initial Preparation

If a gameplay system needs to wait for the first preparation to finish, use the optional Blueprint event:

1. Get Hyper PSO Loading Screen Subsystem through Get Game Instance Subsystem.
2. Bind to On Initial Preparation Finished.
3. After binding, check Has Finished Initial Preparation. If already true, handle Was Initial Preparation Successful immediately.

The event fires once per game instance. Its Ready result is true only after successful preparation. Disabled preparation, cancellation, timeout, or incomplete asset coverage produce false. Later map loads do not repeat the event, and late subscribers do not receive a replay.

This is optional integration for client gameplay. It does not pause the world, delay BeginPlay, or run on a dedicated server.

Editor and Packaged Builds

PIE and editor-launched Standalone use a viewport overlay. Packaged builds can use MoviePlayer followed by viewport preparation. A synchronous map load can temporarily prevent the viewport overlay from animating.

UE 5.8 disables automatic runtime PSO precaching in editor executables, including editor-launched Standalone. The plugin adds explicit compute preparation and initial-view render warmup there. Check a packaged build separately for runtime precaching, loading behavior, and asset availability.

World Partition Streaming

The plugin automatically applies a conservative streaming profile that spreads selected loading and component work across frames. There is no beginner-facing World Partition tuning panel.

Check it in your actual maps, especially at high traversal speeds. Lower per-frame budgets can smooth work but also delay streaming and cause visible catch-up or pop-in. The profile is a starting point rather than a universal performance improvement.

Common Questions

The Screen Stays Open with No PSOs Remaining

Preparation also waits for selected assets, initial streaming, compilation, and render warmup. Use HyperPSO.Status to inspect current preparation work.

A Preloaded Asset Still Hitches on First Use

Check that loading finished before gameplay requested it. Preloading does not execute spawning, animation initialization, procedural generation, or other first-use gameplay work. Narrow the selection to the assets needed before use.

A Variable’s New References Are Missed

Check that the Blueprint and config rules were saved, Observe Reference Changes is enabled, and the source is eligible. Silent writes need a supported notification or Poll for Silent Changes.

The Custom Widget or Font Is Missing

Reselect the asset, save settings, and check the packaged build. Custom widgets must derive from Hyper PSO Preparation Widget and only replace the viewport phase.

Preparation Reaches the Timeout

Check missing assets, memory pressure, streaming backlog, and shader work. Use HyperPSO.Status for diagnostics. For a development preview, use HyperPSO.TestLoadingScreen; HyperPSO.StopLoadingScreen releases the plugin’s own screen.