We have one background worker evaluating an animation, holding the RigHierarchy's ElementsLock and waiting for the global GC lock

And one Background worker inside garbage collection holding up the release of the global GC lock and calling `URigHierarchy::AddReferencedObjects(UObject *, FReferenceCollector &)`, which tries to lock ElementsLock.

This occurs basically 100% for us when playing for a reasonable amount of time, please advise on a fix.

The leaked track stays active, so it is still uploaded every frame, and it keeps its last sequence index. Once that sequence is released with DeallocateSequence, the ensure fires and the track is left pointing at a freed slot.

This is the non-external-ID path. The sweep is the same in //UE5/Main MassVisualizationComponent.cpp#74 (around line 951) and //UE6/Main #12 (around line 1069). We are on 5.8 with 57928894 and 58169258 cherry-picked from UE5/Main, which is where AllocateSequence and DeallocateSequence come from.

check(CurrentMaxBytesPerPixel <= PlatformSettingsBytesPerPixel);

This can happen with Niagara vfx that has two or more emitters whose materials compile to Substrate uint counts that bitwise OR above the maximum, with blendable Substrate enabled and r.Substrate.ProjectGBufferFormat=0. The base class FMaterialRelevance operator|= function applies Max() to SubstrateUintPerPixel but the derived class FPrimitiveViewRelevance operator|= does not. When a material with 2 units and a material with 5 (20 bpp) uints are combined with | it results in 7 (28 bpp) which triggers the check(). A potential workaround is to add the missing Max():

	/** Bitwise OR operator. Sets any relevance bits which are present in either. */
	FPrimitiveViewRelevance& operator|=(const FPrimitiveViewRelevance& B)
	{
	 const uint32 LocalSubstrateUintPerPixel = SubstrateUintPerPixel;
     
	 // the class is only storing bits, the following avoids code redundancy
	 const uint8 * RESTRICT s = (const uint8*)&B;
	 uint8 * RESTRICT d = (uint8*)this;
	 for(uint32 i = 0; i < sizeof(*this); ++i)
	 {
	 *d = *d | *s; 
	 ++s;++d;
	 }

	 SubstrateUintPerPixel = FMath::Max(LocalSubstrateUintPerPixel, B.SubstrateUintPerPixel);
	 return *this;
	}

There should be a way (CVar) to lift the restriction that prevents the Ensures to be reported.

There is also an error in the logic that collects the CRCs which limits the collection further. Duplicated reports should not be added to the array and\or counted toward the limit.

• Summary
  Hey there - I’ve been sticking with Unreal Engine 5.6 for cinematics because of a regression that's been made to CineCameraActors (specifically the CameraComponent nested inside of them) that's been in every version since Unreal 5.7+

When using LookAt tracking in a CineCameraActor, the camera aims to keep the target in the exact center of the image. But oftentimes, you’ll want to rotate the camera slightly up, down, left, right etc.

You were able to do this in all versions of Unreal 5.6 and prior by changing the CameraComponent inside of the CineCameraActor. This served as a simple offset to absolutely nail your composition and camera, but it seems like this no longer works in Unreal 5.7+ and I've just confirmed it still doesn't work in Unreal 5.8. If you try to adjust the rotation of the component inside once LookAt tracking is enabled, it simply doesn’t allow you to change the rotation, locking you into center-framing on your offset.

Before 5.7 you could adjust the rotation in the CameraComponent when LookAt tracking was enabled
Now in 5.7+5.8, adjusting the CameraComponent rotation does nothing when LookAt tracking is enabled.

Has anyone found a solution for this or is there a clean way to modify the engine to keep the original behavior of CineCameraActors? This is something I use in 75% of my shots so I’ve been using to Unreal 5.6 and it's prevented me from using the latest version of Unreal for a while. Cheers!

• What Type of Bug are you experiencing?
  Other

• Steps to Reproduce
  In Unreal 5.7+, enable LookAt tracking and assign an Actor to Track. If you try to open up your cinecameraactor and adjust the CameraComponent nested inside, if you use the rotation sliders or type in a number, they do nothing and always default back to a value of zero.

• Expected Result
  In all previous versions of Unreal, you could use the CameraComponent's rotation to adjust the composition of your camera while using LookAt tracking. I would expect to be able to use the CameraComponent and it's rotation to adjust the final rotation of the camera, but now it does not affect the camera's rotation whatsoever.

• Observed Result
  Every time you attempt to adjust the CameraComponent's rotation, it always snaps back to zero and never rotates the camera as intended.

• Affects Versions
  5.8
  5.7

• Platform(s)
  Windows

CREATED AT: 10/01/2026 03:17 PM EDT

UPDATED AT: 10/01/2026 03:17 PM EDT

But to instantiate Modular Control Rigs. Modular Control Rigs are all of type ControlRigRuntimeAsset, they are pure data payload, so it is not possible to cast them to a ControlRig class and pass them to this node.

There is no alternative interface provided to be able to do this with Modular Control Rig; not in Blueprint, not in Python.

The cause is an encoding mismatch:

• UAT starts UBT with CreateNoWindow = true, so UBT gets a new hidden console that uses the system OEM code page (932 / Shift_JIS). UBT writes its stdout in that code page.
• UAT reads UBT's stdout as UTF-8. Characters that can't be decoded become U+FFFD, so the original text is lost.

Workarounds

Pass ERunOptions.NoHideWindow to RunUBT (RunUBT function in UBTUtils.cs). UBT then shares UAT's console, so the code pages match.

When importing a .skp model into Twinmotion 2026.2 Preview as Geoemtry, using the Collapse all mode will cause materials to be displayed incorrectly, replacing most materials with a placeholder material.

This does not occur with the Keep Hierarchy collapse mode. Datasmith imports are also not affected.

There are two issues:

1) When some verts are culled from the cloth mesh section, cloth explodes in editor. When this happens in package it can crash

2) If we cull the entire Tshirt so that the mesh underneath the jacket is removed, in editor the transient skeletal mesh shows no clothing data. But in packaged build we get a crash because the mesh section has zero vertices but there cloth data still exists.

Once the issue occurs, it persists until the editor is restarted. Switching Preview Scene Profiles, toggling Show Environment, or closing and reopening the Niagara asset editor does not fix it. The same Niagara System placed in a level renders correctly in the same editor session.

Work around:

• Set r.GPUScene.UseReservedResources=0 in DefaultEngine.ini
• Apply CL 54969077 to the 5.8 engine via cherry-pick.

This happens when Nanite is disabled for the project and a SceneCapture2D using
"Use ShowOnly List" is present in the level.

It does not reproduce in 5.7. Setting r.GPUScene.UseReservedResources=0, which is the 5.7
default, avoids the issue.

Summary

Adding fx.Niagara.DataChannels.Enabled=true to an ini file makes the Niagara editor assert when a Data Channel Read is created. The same operation does not assert when the cvar is left untouched.

Steps to Reproduce

Add the following to <Project>/Config/DefaultEngine.ini:

[ConsoleVariables]
fx.Niagara.DataChannels.Enabled=true

Then:

1. Launch the editor and open (or create) a Niagara System / Emitter.
2. Create a Data Channel Read.
3. The editor hits the checkf described below.

Observed Result

Assertion at Engine/Plugins/FX/Niagara/Source/Niagara/Private/NiagaraTypeRegistry.cpp:331:

bNeedsRegistration = !OldType.IsValid();
checkf(bNeedsRegistration || (NewType == OldType),
    TEXT("bNeedsRegistration: %d, NewType: %s, OldType: %s NewTypeHash: %x OldTypeHash: %x"), ...);

NewType and OldType are two different types that resolved to the same RegisteredTypeDefIndex, and the NewTypeHash / OldTypeHash values printed by the assert are identical.

Expected Result

Creating a Data Channel Read does not assert, regardless of whether the cvar was set from an ini file.

Analysis

1. Registration of the two NDC data interfaces happens only inside the cvar change callback

Engine/Plugins/FX/Niagara/Source/Niagara/Private/NiagaraModule.cpp:168

void INiagaraModule::OnDataChannelsEnabledChanged(IConsoleVariable* Variable)
{
    ...
    FNiagaraTypeRegistry::Register(UNiagaraDataInterfaceDataChannelWrite::StaticClass(), Flags);
    FNiagaraTypeRegistry::Register(UNiagaraDataInterfaceDataChannelRead::StaticClass(), Flags);

These are the only FNiagaraTypeRegistry::Register call sites for these two classes in the engine — there is no registration in StartupModule or anywhere else.

The cvar default is already true (bool INiagaraModule::bDataChannelsEnabled = true;), so writing =true in ini does not change the value, but the ini apply path still calls Set() and fires the change callback. The callback therefore runs during early startup, at a point where the UClass objects are not yet fully initialized and StaticClass()->GetFName() returns NAME_None.

2. The runtime type hash is derived purely from the FName chain

Engine/Plugins/FX/Niagara/Source/Niagara/Private/NiagaraModule.cpp:1659

void FNiagaraTypeDefinition::GeneratePathNameHash()
{
    if (ClassStructOrEnum)
    {
        UnderlyingTypePathNameHash = GetTypeHash(ClassStructOrEnum->GetFName());
        const UObject* Parent = ClassStructOrEnum;
        while ((Parent = Parent->GetOuter()) != nullptr)
        {
            UnderlyingTypePathNameHash = HashCombineFast(UnderlyingTypePathNameHash, GetTypeHash(Parent->GetFName()));
        }
    }
    else
    {
        UnderlyingTypePathNameHash = GetTypeHash(NAME_None);
    }
}

Engine/Plugins/FX/Niagara/Source/Niagara/Public/NiagaraTypes.h:1195

friend inline uint32 GetTypeHash(const FNiagaraTypeDefinition& Type)
{
    return HashCombine(HashCombine(Type.UnderlyingTypePathNameHash, GetTypeHash(Type.UnderlyingType)), GetTypeHash(Type.GetFlags()));
}

The hash has only three inputs. When GetFName() returns NAME_None the name chain contributes nothing distinguishing, and UnderlyingType and Flags are identical for the two data interfaces (the same Flags value is passed at both call sites). All three inputs therefore match, so UNiagaraDataInterfaceDataChannelRead and UNiagaraDataInterfaceDataChannelWrite produce the same type hash.

3. The registry dedupes on that hash, so the second registration silently aliases onto the first

Engine/Plugins/FX/Niagara/Source/Niagara/Private/NiagaraTypeRegistry.cpp:290

const uint32 TypeHash = GetTypeHash(NewType);
...
if (const int32* ExistingIndex = RegisteredTypeIndexMap.Find(TypeHash))
{
    NewType.RegisteredTypeDefIndex = *ExistingIndex;
}

Both classes end up sharing a single RegisteredTypeDefIndex, i.e. a single entry in RegisteredTypes.

4. The assert fires when a correctly-named type later reaches the shared index

When a properly initialized Data Channel Read type reaches RegisterTypeInternal, it resolves onto that shared/stale index. OldType is valid so bNeedsRegistration is false, NewType != OldType, and the checkf at NiagaraTypeRegistry.cpp:331 fires.

Additional Notes

• GetPersistentTypeHash() in the same header uses GetPathNameSafe(Type.ClassStructOrEnum) rather than GetFName(), so it does not degrade to NAME_None. The runtime GetTypeHash() does.
• The checkf message already prints NewTypeHash / OldTypeHash, which makes the collision directly visible in the assert output.
• The same callback additionally runs {{FNiagaraWorldManager::ForAllWorldManagers([](FNiagaraWorldManager& WorldMan) { WorldMan.GetDataChannelManager().Init(); }

  )}} and FNiagaraSystemUpdateContext Context; Context.AddAll(true); (commented "Re-init everything for now") during this early startup invocation, even though the cvar value did not actually change.

• Light Function: both the Content Browser thumbnail and the Material Editor preview
  viewport are affected.
• Post Process: only the Content Browser thumbnail is affected. The Material Editor
  preview is correct, because a Post Process material is previewed through an
  APostProcessVolume blendable rather than on the preview mesh.

This is a regression - the same materials preview correctly in 5.7. Light Function
rendering at runtime is unaffected, so the impact is limited to editor workflow: artists
can no longer identify or browse these materials by their auto-generated thumbnails.

Workaround
Adding the two domains to that check appears to restore the previous preview and
thumbnail behaviour:
Engine/Source/Runtime/Engine/Private/Materials/MaterialInterface.cpp (around line 3057)

// if (MaterialDomain != MD_Surface && MaterialDomain != MD_DeferredDecal && MaterialDomain != MD_Volume && MaterialDomain != MD_UI)
if (MaterialDomain != MD_Surface && MaterialDomain != MD_DeferredDecal && MaterialDomain != MD_Volume && MaterialDomain != MD_UI && MaterialDomain != MD_PostProcess && MaterialDomain != MD_LightFunction)

Both values come from FScene::SimpleDirectionalLight. It is set to the first directional light added to the scene and ignores the rest, whatever their intensity or ForwardShadingPriority. When that light is removed, which includes hiding it, the pointer is set to null and never re-picked from the directional lights still in the scene. So the result depends on the order the lights were added, not on which light is actually lighting the scene.

Expected: the values follow the same directional light the renderer already selects every frame (by ForwardShadingPriority, then intensity) for forward shading, translucency and volumetric fog, and that the Forward Selected Directional Light material node reads. The height fog and volumetric fog fallbacks read the same pointer and have the same problem. Present in 5.6 through current mainline.

This is happening very infrequently. For one a particular project, it is seem once or twice a week across thousands of dotnet invocations.

Based on an analysis of the dotnet diagnostics it appears to be a manifestation of this issue in dotnet https://github.com/dotnet/runtime/issues/119761#issuecomment-4780332027

This issue is fixed in this change https://github.com/dotnet/runtime/pull/129763, but that fix landed after the current version of dotnet in Unreal.