I created new module and modular rig and by default it seemed to be working fine. Then I copied over some variables from my own module, added some nodes and the bug started happening also in the new test modular rig. I removed everything I did trying to find the culprit, but the modular rig stayed broken even with just single float variable.

In 5.7 it worked fine.

Example Setup:

CO_Main – Adds a Cube SK; Adds a 'Children' Object Group

CO_Child – Adds another SK to the Cube SK Component and attaches itself to CO_Main

When creating a COI from CO_Main the reference to CO_Main for Game and Editor exist – all good.

When creating a COI from CO_Child the reference to CO_Child is Editor-Only – it will not appear in the build.

Not knowing which COs would create proper COIs that would build and which COs and COIs would have to be re-created because they are missing Game References causes us some trouble.

Note: bindlessconfiguration=Minimal or higher must be enabled to use Virtual Texture Collections.

Example DefaultEhgine.ini

[PCD3D_SM6]
BindlessResources=Enabled
BindlessSamplers=Enabled

; The lines below fix 5.7 bindless in materials
[ShaderPlatformConfig PCD3D_SM6]
bindlessconfiguration=Minimal
;end fix

[/Script/Engine.RendererSettings]
rhi.Bindless.Resources=Enabled
rhi.Bindless.Samplers=Enabled
rhi.Bindless=Enabled

In Twinmotion 2026.1, when importing certain SKP files with grouped components, materials may render incorrectly on some grouped components and will appear with a dark, metallic color instead.

This is a regression from Twinmotion 2025.

This does not occur for Datasmith imports.

For Datasmith models containing lights, resynchronizing the model after any changes will cause any lights that had shadows enabled prior to the sync to have that setting reverted to Disabled.

This is a regression and did not occur in Twinmotion 2025.2.

In UE 5.7 and later, if a tag is added once to an FGameplayTagCountContainer, the container is reset, and the same tag is added once more, GetExplicitTagCount() returns 2 instead of the expected value of 1.

Reset() clears only the hierarchical GameplayTagCountMap. It does not clear Items, which stores explicit tag counts, or ExplicitTags. Consequently, explicit state from before the reset survives and is accumulated by subsequent updates.

The TagCountReset sample project linked below calls the reproduction function automatically from the default Character's BeginPlay (). The issue can therefore be reproduced by opening the project and starting PIE.

[Description]

In UE 5.6.1, FGameplayTagCountContainer:: Reset() clears all three state containers:

1 GameplayTagCountMap. Reset();

2 ExplicitTagCountMap.Reset();

3 ExplicitTags.Reset();

In UE 5.7, explicit count storage was changed from TMap<FGameplayTag, int32> ExplicitTagCountMap to TArray<FGameplayTagCountItem> Items. The updated Reset() implementation, however, clears only GameplayTagCountMap.

GetExplicitTagCount() and UpdateExplicitTags() read and update Items, while GetExplicitGameplayTags() returns the separate ExplicitTags container. Because neither is cleared by Reset(), the old explicit count and tag remain. A subsequent +1 update increments the stale count from 1 to 2.

At the same time, GameplayTagCountMap starts again from zero, leaving the hierarchical and explicit counts inconsistent within the same container.

[Results]

UE 5.8.1 prints:

1 Tag Count: 1

2 Tag Count: 2

Immediately after the first update and Reset(), the observable state is inconsistent:

GetTagCount(Tag): 0

GetExplicitTagCount (Tag): 1

GetExplicitGameplay Tags(). HasTagExact(Tag): true

[Expected]

After Reset(), the hierarchical count, explicit count, and explicit tag list should all be empty.

Adding the same tag once more should make the second GetExplicitTagCount() return 1.

1 Tag Count: 1

2 Tag Count: 1

[Suggested Fix]

Clear Items and ExplicitTags together with GameplayTagCountMap, preserving the complete-reset behavior from UE 5.6.

[Image Removed]

Exported renders with Lumen can appear overexposed compared to the viewport renders, even when disabling auto-exposure and manually setting the exposure values.

This does not appear to occur on all scenes, and I was not able to reproduce on the New scene, however this occurs consistently on the client file.

A simple fix using a critical section for mutual exclusion, as shown below, suppresses the leak.

static FCriticalSection GInitSplineVertexFactoryCS;  //work around - global critical section
 
static void InitSplineVertexFactory_Internal(FStaticMeshVertexFactories& VertexFactories, const FStaticMeshVertexBuffers& VertexBuffers, int32 LightMapCoordinateIndex, const ERHIFeatureLevel::Type FeatureLevel, FColorVertexBuffer* InOverrideColorVertexBuffer)
{
	// Skip LODs that have their render data stripped (eg. platform MinLod settings)
	if (VertexBuffers.StaticMeshVertexBuffer.GetNumVertices() == 0)
	{
		return;
	}
 
	bool bOverrideColorVertexBuffer = !!InOverrideColorVertexBuffer;
 
	FScopeLock Lock(&GInitSplineVertexFactoryCS); // work around
 
	if ((VertexFactories.SplineVertexFactory && !bOverrideColorVertexBuffer) || (VertexFactories.SplineVertexFactoryOverrideColorVertexBuffer && bOverrideColorVertexBuffer))
 

They point out that CL 52639755 added window closing logic that is intended to close the picker on actor reinstancing, but that (according to the licensee) is triggering incorrectly when the actor reruns its construction scripts but without reinstancing.

When CreateShapes_AssumesLocked fails during async body creation, the failed FBodyInstance is left in Bodies[] with a released actor handle. InitDynamicProperties_AssumesLocked is then called on it and dereferences the null handle.

Regression from 5.7. Reported against 5.8 (project upgrade from 5.7, CL 54667078) and confirmed present in //UE5/Main. Requires p.Chaos.EnableAsyncInitBody=true. The same content ran without incident in 5.7.

Callstack

FChaosEngineInterface::SetSleepThresholdMultiplier_AssumesLocked   ChaosEngineInterface.cpp:1261
FBodyInstance::InitDynamicProperties_AssumesLocked                BodyInstance.cpp:4710
TInitBodiesHelperBase<>::InitBodies                               BodyInstance.cpp:1704

(Line numbers are from the reporting CL; the code is unchanged in //UE5/Main — current locations given below.)

Cause

Three things combine.

1. The failure path leaves the instance in `Bodies[]`.

BodyInstance.cpp:1577-1596 — on bInitFail, the instance releases its actor handle and nulls BodySetup, then continue}}s without removing itself from {{Bodies[]/Transforms[]:

Instance->ReleasePhysicsActor();

Instance->OwnerComponent = nullptr;
Instance->BodyInstanceOwner = nullptr;
Instance->SourceObject = nullptr;
Instance->BodySetup = nullptr;
SetBodyInstanceExternalCollisionProfileBodySetup(Instance, nullptr);

continue;

Contrast the "already got a body" branch at :1550-1559, which does Bodies.RemoveAt(...) / Transforms.RemoveAt(...). InitBodies() subsequently iterates Bodies[] and calls InitDynamicProperties_AssumesLocked() on the failed instance.

2. The `BodySetup` guard no longer fires in 5.8.

5.7 guarded with if (!BodySetup.IsValid()) return;, which caught the nulled member. 5.8 guards with if (!GetBodySetup()) return;, and GetBodySetup() (BodyInstance.cpp:1380) now prefers the async creation inputs:

UBodySetup* FBodyInstance::GetBodySetup() const
{
    if (const FBodyInstancePhysicsCreationInputs* Cached = GetAsyncPhysicsCreationInputs())
    {
        return Cached->ResolvedBodySetup;
    }
    ...
}

FBodyInstancePhysicsCreationInputs::ResolvedBodySetup is never reset on the failure path, so GetBodySetup() returns a live UBodySetup and the early-out is skipped. Instance->BodySetup == nullptr is no longer a reliable signal that physics creation failed.

3. `IsDynamic()` returns true for a null handle.

FPhysicsInterface::IsDynamic() is !IsStatic(), and FChaosEngineInterface::IsStatic (ChaosEngineInterface.cpp:415) returns false for an invalid handle:

bool FChaosEngineInterface::IsStatic(const FPhysicsActorHandle& InActorReference)
{
    if(FChaosEngineInterface::IsValid(InActorReference))
    {
        return InActorReference->GetGameThreadAPI().ObjectState() == Chaos::EObjectStateType::Static;
    }

    return false;
}

So the if (FPhysicsInterface::IsDynamic(GetPhysicsActor())) block is entered with a null handle, and SetSleepThresholdMultiplier_AssumesLocked dereferences it.

Repro conditions

1. p.Chaos.EnableAsyncInitBody=true — body initialized on a worker thread rather than the game thread.
2. CreateShapes_AssumesLocked returns failure (NumShapes == 0) — e.g. a component requesting collision from a mesh that has no collision geometry.

Suggested fix

Early-out on an invalid actor handle at the top of InitDynamicProperties_AssumesLocked. The handle is the reliable failure signal now that BodySetup is not.

 void FBodyInstance::InitDynamicProperties_AssumesLocked()
 {
+    // Shape creation may have failed and released the actor handle, leaving this
+    // instance in Bodies[]. IsDynamic() returns true for a null handle.
+    if (!FPhysicsInterface::IsValid(GetPhysicsActor()))
+    {
+        return;
+    }
+
     UBodySetup* ResolvedSetup = GetBodySetup();
     if (!ResolvedSetup)
     {
         // This may be invalid following an undo if the BodySetup was a transient object
         return;
     }

Worth considering alongside this: clearing ResolvedBodySetup on the failure path, and/or removing the failed instance from Bodies[]/Transforms[] the way the :1550 branch does — either would also close the hole, and the current asymmetry between the two bail-out paths is itself suspect.

Note on content

The triggering content is also wrong — a component requesting collision from a mesh with no collision geometry is meaningless, and that is being fixed separately. But the engine has already decided to fail that body and released its handle, so it should not then walk into a null dereference. 5.7 tolerated the same content silently.

Affected code

• Engine/Source/Runtime/Engine/Private/PhysicsEngine/BodyInstance.cpp:1577 — failure path
• Engine/Source/Runtime/Engine/Private/PhysicsEngine/BodyInstance.cpp:1380 — GetBodySetup()
• Engine/Source/Runtime/Engine/Private/PhysicsEngine/BodyInstance.cpp:4660 — InitDynamicProperties_AssumesLocked()
• Engine/Source/Runtime/PhysicsCore/Private/ChaosEngineInterface.cpp:415 — IsStatic()

Materials with the Clear coat property enabled and two-sided property enabled will not react properly to lighting on the “reverse” face of any geometry they are applied to. The reverse face will appear darker and in Path Tracer renders.

Attached a sample scene demonstrating this behavior. Tested using a Box 10m primitive with a Car Paint material, the reverse face on the interior of the box is lit by an area or omni light, but in Path Tracer the box interior will appear completely unlit.

Switching to a two-sided material with clear coat disabled will show proper lighting.

• r.OneFrameThreadLag 1
• r.GTSyncType 1

The previous skinning bone data can be corrupted and introduce visual artifacts on everything using motion vectors, motion blur being the most visible.

This is hard to reproduce without specific/heavy content. But has been seen in the wild by several licensees.

Licensees have found that the issue comes from SupportsNoOverwriteBuffers() not being robust. The buffer queue is handled with a tick function, and under certain timing constraints will return a buffer that is still in use to be written to.

The issue was introduced in our 5.6 update with the parallel RHI command translate. (Disabling the parallel translate also fixes.)

The dialog reads the dropdown from the workspace-level preset field while the selection is saved to the project-level field, and the two are only synced when the workspace is first opened. Display only, but it caused the reporting licensee to doubt whether the setting was applied.