October 28th, 2025
You can now decide if you want to apply or not the Bounds Selected Color in the User Editor Settings.
Added three new editor user settings named Smooth Transform Update (one for Actor preview mode and one for Bounds mode) to change how smoothly you want the Prefab Reference Components preview to update when you move the owning actor in the level. I also added Keep Actor Preview While Move if you want to control if the not updated actor preview stays static or is removed while you perform a move. This isn’t available in the Blueprint Editor.
Actor: Default movement

Actor: No preview update while moving

Actor: No preview while moving

Bounds: Default movement

Bounds: No preview while moving

Inside the Prefab Reference Component Visualizer Manager class you can now override more easily the Color Manager and Draw Manager. See CreateColorManager and CreateDrawManager.
Overall better Editor performance when editing your prefabs and moving them in the viewports.
With the new default editor settings the update rate of the Prefab Reference Components
preview has been synced with the editor update rate. Meaning the preview transforms is updated more smoothly with the moved actor.
August 17th, 2025
Combined with the draw mode (Actor and Bounds) there is now 2 submodes (1 new) for previews. Each submode works for both draw mode.

Colored Component Bounds (Previously the only rendering method): For each PRC draw each allowed primitive components bounds.


Colored Group Bounds (New default): Draw a “group” bounds for each PRC using the primitive components bounds.


(Commit: 0a234a192f0b417e496c91ff49baff85795f5cd5)
A new documentation page was added regarding optimizing the spawn process of prefabs: Link.
When using the async spawn path with an PRC the spawn request might be sent to the prefab runtime manager if you exceeded your max allowed spawn count (MaxPrefabActorSpawnPerTick). You now have more control on how much time you allocate to process those requests when the queue is read (see TimeIntervalBetweenSpawnQueueRead).
I added SpawnQueueTimeBudget which is described as such:
/**
* How many milliseconds we have to read the queue.
* This is NOT used when we spawn a prefab outside the queue.
*
* After each processed spawn request we see how much time we have left,
* if we are under the budget we will keep processing new requests
* otherwise when the time budget is exceeded we stop reading the queue and wait for next read.
*
* This is used by the UPSRuntimePrefabSubsystem, you can change the value at runtime.
* 0 means that we ignore it (infinite budget).
*/And MinimumTimeBeforeNextIterationForBudget:
/**
* How many milliseconds left we want on the budget before doing a new iteration.
*
* Why do we need this? Here is a simple example:
* - SpawnQueueTimeBudget is 11ms.
* - We assume each spawn request takes 5ms to be handled.
* - Before starting we initialize our BudgetTimeout with 11ms.
* - The queue read will be the following:
* - We process request 1, its succeeds, 5ms passed (BudgetTimeout is now 6ms (11-5)), we continue because 6 > 0.
* - We process request 2, its succeeds, 5ms passed (BudgetTimeout is now 1ms (6-5)), we continue because 1 > 0.
* - We process request 3, its succeeds, 5ms passed (BudgetTimeout is now -4ms (1-5)), we stop reading the queue because -4 < 0.
*
* The issue with this is that we EXCEEDED the budget by 4ms and this can be troublesome in some cases (and with different values).
* We cannot precisely avoid this issue because we cannot know in advance how much time a spawn request process takes (unless we have the same exact params, but still).
* To avoid this issue where you exceed the budget time because a little of time was left, we use MinimumTimeBeforeNextIterationForBudget.
*
* Example of its usage:
* - SpawnQueueTimeBudget is 11ms.
* - MinimumTimeBeforeNextIterationForBudget is of 2ms.
* - We assume each spawn request takes 5ms to be handled.
* - Before starting we initialize our BudgetTimeout with 11ms.
* - The queue read will be the following:
* - We process request 1, its succeeds, 5ms passed (BudgetTimeout is now 6ms (11-5)), we continue because 6 > 2.
* - We process request 2, its succeeds, 5ms passed (BudgetTimeout is now 1ms (6-5)), we stop reading the queue because 1 < 2.
*
* This is used by the UPSRuntimePrefabSubsystem, you can change the value at runtime.
* Set to 0 to ignore it.
*/Units of TimeIntervalBetweenSpawnQueueRead, SpawnQueueTimeBudget and MinimumTimeBeforeNextIterationForBudget are in milliseconds for better readability.
(Commit: e25c117d4a0b00b3526099635d8034b93a4cb79b)
Added rich tooltips to UPSSinglePrefabReferenceComponent, UPSNetPrefabReferenceComponent, UPSSinglePrefabSourceComponent and UPSNetPrefabSourceComponent using UDN documentation files (can be found in UnrealPrefabs/Documentation/Source/. (More rich tooltips are planned for other types, Nodes and Menu Entries).

(Commit: 661317897507f536b3cdbfb9eac92f012d893d8d)
Fixed an issue where the root component scale of the referenced prefab actor class wasn’t taken into account in the actor preview.
(Commit: 0a234a192f0b417e496c91ff49baff85795f5cd5)
Fixed the crashes in some invalid referenced prefab actor class scenarios
(Commit: 8de855b07d8cb054d7670b0bc0bb043a020d4542)
August 14th, 2025
Visibility
In editor you can now properly hide/show the preview (bounds & actor) of a PRC when you hide it in editor. Commit: 5f34b5cbb07aafacf66f70763b13de34def49ed6.
You can override FPSEditorPRCVisualizerManager::CanBlueprintPRCBeRendered and FPSEditorPRCVisualizerManager::CanWorldPRCBeRendered to control when PRC previews should be rendered (higher priority than preview settings).
Small refactoring such as whitespace, editing comments and functions.
SlateIM
Disabled SlateIM example widgets and other test types. Commit: 943e58025de407347e3e2be744d05f0c9e7bc024.
Renamed SlateIM module to UnrealPrefabsSlateIM and prefixed all types to avoid conflict with 5.6 SlateIM plugin. Commit: d8fa1514558ee90ea24aa3545fe64c2794251050.
August 11th, 2025