All other material settings are preserved when saved to the User library.

In UE 5.7.4, when a looping BlendSpace with Match Sync Phases enabled plays as a SyncGroup Leader and crosses its loop boundary during a transition to an external AnimSequenceFollower in the same group, a marker-consistency assertion fails inside UAnimSequence::AdvanceMarkerPhaseAsFollower() and the editor terminates.

The issue was not observed when playing the BlendSpace alone. It reproduces when an external Follower is evaluated and consumes the inconsistent marker data produced by the Leader.

Description

FMarkerSyncData::CollectMarkersInRange() only uses the following condition:

At the loop boundary, NewPosition becomes less than PrevPosition:

No marker can satisfy both conditions, so the passed-marker list is returned empty.

However, the Leader's final Sync Position correctly reports the next marker after wrapping. This inconsistent information is propagated to the external AnimSequence Follower, causing the next-marker consistency check() inside UAnimSequence::AdvanceMarkerPhaseAsFollower() to fail.

BlendSpace samples are processed through a separate path, so without an external Follower, the BlendSpace-only configuration did not reach this validation in our tests.

Suggested Fix

When NewPosition is less than PrevPosition, collect markers from the following two ranges:

The loop offset should also be applied when calculating DeltaTimeWhenPassed for the

second range.

[Image Removed]

This appears to be an interaction between UE's input capture (FInputModeGameOnly → CapturePermanently mouse capture) and the Windows shell snap handling. While the window holds input capture and crosses a display boundary, the shell no longer receives the snap key input correctly.

Workaround (confirmed behavior):
After the issue occurs, clicking the window, or pressing Win alone to open the Start menu and then refocusing the app, restores normal behavior (capture/focus re-syncs).

Note: This is a Windows standard OS feature, so this may be a Windows-side constraint rather than a strict UE bug. Filing to confirm whether the capture behavior of FInputModeGameOnly should be adjusted, or whether this should be classified as By Design.

UE_DEPRECATED(5.4, "This class is deprecated, there is no replacement because this is not a safe async design.")

UE_API FScopedSkeletalMeshRenderData(USkeletalMesh* Mesh);

https://github.com/EpicGames/UnrealEngine/blob/772ce4ed717be4bd427ca1b59a32b1e82bab2466/Engine/Source/Runtime/Engine/Classes/Engine/SkeletalMesh.h#L417

The deadlock happens here:

https://github.com/EpicGames/UnrealEngine/blob/772ce4ed717be4bd427ca1b59a32b1e82bab2466/Engine/Plugins/Runtime/HairStrands/Source/HairStrandsCore/Private/GroomBindingBuilder.cpp#L2884

The suppression relies on FAnimExtractContext::bIgnoreRootLock, which is WITH_EDITOR-only, so the suppress in FMovieSceneSkeletalAnimationEvaluationTask::Execute is gated behind #if WITH_EDITOR. As a result the mixer's root-motion pipeline behaves differently between editor/PIE and cooked:

• Editor/PIE: the lock is suppressed during eval, real root motion survives, and the extraction task handles locking.
• Cooked: the field does not exist, so the lock is applied during decompression and the extraction task works from an already-locked pose.

This is a runtime system depending on an editor-only lever, so the behavior silently forks between configs.

Repro

• Set up an anim mixer skeletal section using an anim sequence with both Force Root Lock and Enable Root Motion enabled.
• Compare root behavior in PIE vs a cooked/packaged build.

Proposed fix

• Add a runtime (non-WITH_EDITOR) bool to FAnimExtractContext (e.g. bSuppressForceRootLock), separate from the editor-only bIgnoreRootLock so the preview flag's meaning is unchanged.
• Un-gate the three force-root-lock checks (!ExtractionContext.bIgnoreRootLock) currently under #if WITH_EDITOR so they honor the new runtime flag in cooked.
• Set the new flag unconditionally in the mixer eval task and drop its #if WITH_EDITOR guard.
• Default the flag to false so all other runtime paths are byte-for-byte unchanged.
• Add a mixer test comparing a Force-Root-Lock + Enable-Root-Motion section cooked vs PIE.

Key locations

• MovieSceneMixedSkeletalAnimationSystem.cpp (section flag derivation, and the #if WITH_EDITOR suppress in the eval task)
• AnimationAsset.h (FAnimExtractContext::bIgnoreRootLock)
• DecompressionTools.cpp, AnimSequence.cpp, AnimStreamable.cpp (the #if WITH_EDITOR !bIgnoreRootLock force-root-lock sites)

===============================================

This issue is caused by FSharedStruct batching reachability requests to the same underlying FInstancedStruct multiple times. This is not thread safe as nothing prevents the reachability processor from earlying out, so the hierarchy is processed multiple times across all GC workers.

This can lead to some race conditions where garbage exclusion kills the reference to the UObject** on the struct on one worker as it's currently being batched on another worker. This can lead the reachability to reference nullptrs all over the place.

In essence we need the following 4 criteria:

1. Lots of root UObjects with a reference to a FSharedStruct
2. The underlying FInstancedStruct must be shared between all FSharedStruct. We can do this by copying the FSharedStruct across all root UObjects so the FSharedStruct instance is unique, but the underlying TSharedPtr<FInstancedStruct> just bumps up the ref count.
3. The base struct type for the FInstancedStruct must have a TObjectPtr on it.
4. We must explicitly mark the TObjectPtr as garbage so it goes through garbage elimination during reachability.

If you have a look in the GCStressTestSubsystem in my repro sample for an example.

So the root cause is that FSharedStruct::AddStructReferencedObjects is invoked for each unique FSharedStruct instance, which in our case matches the number of root UObjects we created (10,000 by default in the attached sample). This will invoke Collector.AddReferencedObjects on the underlying UScriptStruct* which is simply the underlying shared single instance shared across all 10,000 instances. This means that the UScriptStruct* reachability is done 10,000 times in this example. This then ends up batching all its own properties this many times, including the TObjectPtr. This gets distributed between all the worker threads and performed in parallel. It's a race to see which route eliminates the UObject** address against all the other workers which are currently reading the same UObject*. We can end up crashing in lots of places in the batching, but it typically goes wrong in DrainValidated when we invoke a ObjectToIndex call, e.g:

ObjectIndices[Idx] = GUObjectArray.ObjectToIndex(ValidatedReferences[Idx].Object);

This reads offset 0xc on a nullptr because it's been eliminated on the other thread. This is checked when we DrainUnvalidated, but as soon as we pass the valid checks we assume that the ValidatedReferences only contains non-null references, which now causes issues because it was valid when the checks were first performed but has been invalidated between the DrainUnvalidated and the DrainValidated calls.

I have created a modified version of FSharedStruct called FFixedSharedStruct. This is effectively an identical version of the engine's version, but I've added an atomic int to the shared FFixedStructSharedMemory which contains the reachability flag. We mark this as reachable when the first FSharedStruct reaches the AddReferencedObject call which causes all future calls to the same underlying TSharedPtr to early out. This ensures that we only batch a single instance of the UScriptStruct.

You can toggle between the 2 FSharedStruct versions with the define in GCStressTestSubsystem.cpp

#define TEST_VANILLA_SHARED_STRUCT 1

#define TEST_FIXED_SHARED_STRUCT 1

This seems to work and follows a similar way to the UObject reachability flag, but I'm not sure if you have a better suggestion for a fix.

==============================

When 5.0 first introduced TObjectPtr, the guidance was that it would compile down to raw pointer access in Shipping builds to ensure identical performance.

Evidenced by the following quote from the documentation for 5.0:

UE5 introduces TObjectPtr, a template-based, 64-bit pointer system, as an optional replacement for raw object pointers in editor builds. This system adds dynamic resolution and access tracking in editor builds, while performing identically to raw pointers in non-editor builds.

In recent versions of the engine, this guarantee seems to have been silently dropped.

The introduction of incremental reachability analysis adds code to call ConditionallyMarkAsReachable, regardless of whether incremental GC is turned on.

This causes assembly instructions comparable to the following to be generated inline every time a TObjectPtr or TSubclassOf is assigned:

cmp byte ptr [UE::GC::GIsIncrementalReachabilityPending],r14b

je _____+16Fh

mov rcx,qword ptr [rbx+458h]

test rcx,rcx

je _____+16Fh

call UE::GC::MarkAsReachable

In our game, this adds several megabytes to our compiled binary size, putting pressure on the instruction cache and branch predictor.

Even though incremental GC is experimental and not even supported outside of single-threaded servers, right now every game is paying for the feature even when not enabled, due to `UE_OBJECT_PTR_GC_BARRIER` being unconditionally set to `1` in `ObjectPtr.h`.

My questions are the following:

• It would be nice if this code was automatically compiled out when incremental GC is off, instead of us having to randomly find out about the define during profiling.

• This seems to unconditionally apply to every TSubclassOf as well, even when used as a parameter/local variable and GC barriers are unnecessary.

• Inlining the check to `GIsIncrementalReachabilityPending` makes sense, but it might be worth moving the null object check into `MarkAsReachable` itself, which would reduce the binary size cost of the repeatedly inlined code.

Diff detected in the DiffOnly Cook log:

Serialized Property:
StructProperty /Script/Engine.RuntimePartition:DebugColor

Root Cause

In UWorldPartitionRuntimeHashSet::FixupHLODSetup(), when explicit HLOD Layer Partition Assignation is enabled, a URuntimePartitionPersistent is created with an unstable UObject name:

cpp

NewObject<URuntimePartitionPersistent>(this, NAME_None)

With NAME_None, auto-naming appends a suffix such as RuntimePartitionPersistent_0 / _1, and the suffix varies depending on object creation order across Cook runs. In addition, URuntimePartition::SetDefaultValues() seeds DebugColor from GetName(), so the unstable UObject name propagates into DebugColor.

Both URuntimePartition::DebugColor and FRuntimePartitionHLODSetup::PartitionLayer are UPROPERTYs outside WITH_EDITORONLY_DATA, so the difference lands in the Cooked data regardless of Development or Shipping. Beyond DebugColor, the UObject name itself also varies in the ExportMap / serialized object.

Proposed Fix

Source/Runtime/Engine/Private/WorldPartition/RuntimeHashSet/WorldPartitionRuntimeHashSet.cpp : FixupHLODSetup()

Instead of NAME_None, explicitly generate a deterministic name derived from content (based on RuntimePartition.Name):

cpp

const FName PersistentPartitionName(*FString::Printf(
    TEXT("RuntimePartitionPersistent_%s"),
    *RuntimePartition.Name.ToString()));
FRuntimePartitionHLODSetup& PersistentHLODSetup = RuntimePartition.HLODSetups.Emplace_GetRef();
PersistentHLODSetup.PartitionLayer = NewObject<URuntimePartitionPersistent>(this, PersistentPartitionName);

This is the same class of fix as the deterministic-name approach for Niagara DataInterface MultiProcess Cook.

OFPA (One File Per Actor) is enabled.

When making adjustments to the Vegetation growth Season parameter inside Media Mode, if a scene contains Bushes then any adjustments to the Vegetation growth will adjust the global settings for the Bushes' size.

Edits made in Media Mode should be restricted to the selected media and should not have any effect on the global settings for assets, and this requires manually tracking and readjusting the size parameters for all Bush assets when such edits need to be made.

repro project attached

[Link Removed]

When setting Animator tools to use Collision mode for video, the loop speed of the animator will be twice as fast as specified in the video export.

Attached a sample scene that demonstrates this behavior.

Unclear if this is a regression from 2026.1 to 2026.1 HF2. Last confirmed working correctly in 2025.2.

Limiting the framerate with t.MaxFPS or turning off TLV batching usually seems to make the flickering stop (r.TranslucencyLightingVolume.Batch 0)

• The flickering is from TLV only (not happening with forward translucent shading)
• It seems it also happens without Lumen enabled
• The issue may not happen with older Nvidia drivers, eg, 551.86
• {{r.TranslucencyLightingVolume.Blur 0 }} doesn’t appear to affect the issue

This flickering issue doesn’t appear to be the same issue as the kind of flickering that can occur with meshes that intersect the edge of the TLV.

Additional Notes

r.OneFrameThreadLag 0 will kill it. And the render frame has to struggle (lag) for it to occur.
r.rdg.asyncCompute 0 might stop it, but only because the lag shifts a bit. You will still be able to get it with asyncCompute 0, but it just might be harder to reproduce.

LogTexture: Display: Building texture TwoD: /Game/FirstPerson/Lvl_FirstPerson.Lvl_FirstPerson:PersistentLevel.BM_SM_MeshPaint_C_UAID_047BCBA595B946E702_1748064754.StaticMeshComponent0.MeshPaintVirtualTexture_0 (TFO_AutoDXT VT, 32x32 x1x1x1) (Required Memory Estimate: 1.271932 MB), EncodeSpeed: Fast
LogTexture: Display: Building texture TwoD: /Game/FirstPerson/Lvl_FirstPerson.Lvl_FirstPerson:PersistentLevel.BM_SM_MeshPaint_C_UAID_047BCBA595B946E702_1748064754.StaticMeshComponent0.MeshPaintVirtualTexture_0 (TFO_AutoDXT VT, 32x32 x1x1x1) (Required Memory Estimate: 1.271932 MB), EncodeSpeed: Fast
LogActorComponent: UnregisterComponent: (/Game/Blueprints/BM_SM_MeshPaint.Default__BM_SM_MeshPaint_C:StaticMeshComponent0) Not registered. Aborting.

If the apply step succeeds, saving the BP fails with the error:

"Illegal reference to private object: MeshPaintVirtualTexture /Game/..."