In some scenes with Lumen enabled, interior scene lighting without direct lighting can appear drastically darker in Cloud Presentations than they do in the editor viewport. This only appears to affect Lumen and the lighting in Standard GI is consistent.

Tested in a scene in TM 2025.2 and the same scene in 2026.1

Does not appear to occur for all scenes, but occurs consistently in the client scene.

PCG can be used to spawn Instanced Actors via the PCG IA Interop plugin, that makes Spawned Instanced Actors available as node. When a PCGActor placed in the level runs a PCG graph that spawns Instanced Actors, this creates Instanced Actors Managers with instances.

Problem

The created Instanced Actor Manager actors get MainGrid assigned as Runtime Grid, even if the PCGActor that spawned them didn’t have a Runtime Grid value (i.e. its None). Next time the map is loaded, this results in error messages:

Actor /Game/MAP_ReproPCG.PCG_PlaceInstancedActors references an actor in a different runtime grid /Game/MAP_ReproPCG.InstancedActorsManager_-1_-1_0
Actor /Game/MAP_ReproPCG.PCG_PlaceInstancedActors references an actor in a different runtime grid /Game/MAP_ReproPCG.InstancedActorsManager_0_-1_0
Actor /Game/MAP_ReproPCG.PCG_PlaceInstancedActors references an actor in a different runtime grid /Game/MAP_ReproPCG.InstancedActorsManager_-1_0_0
Actor /Game/MAP_ReproPCG.PCG_PlaceInstancedActors references an actor in a different runtime grid /Game/MAP_ReproPCG.InstancedActorsManager_0_0_0

Suggested Fix

The PCG actor and spawned IAMs runtime grids should match. If the PCG actor had it set to None, perhaps leave the IAMs value as None as well.

Attempting to sign into Twinmotion from within the TM 2026.1 editor results in a consistent sign-in error using the sign-in buttons.

Initial sign-in during launch when logged into the Epic Games Launcher works correctly and this only affects sign-in after launch.

Only TM 2026.1 is affected. Previous versions do not have this issue.

A UInputTriggerChordAction does not fire when the action it references (the "chording action") is mapped in a different Input Mapping Context with a lower priority than the IMC containing the chorded action. Both keys can be held simultaneously and the chorded action never produces a Triggered event.

This blocks the documented and expected use case of layering context-specific chords on top of a base/default input map — for example, a vehicle or mount IMC defining a chord that uses the player's base modifier action.

—

Reproduction

Setup (in-editor)

1. Create two Input Actions:

• IA_Chording — Value Type: Boolean

• IA_Chorded — Value Type: Boolean

1. Create two Input Mapping Contexts:

• IMC_Base

• IMC_Overlay

1. In IMC_Base, add a mapping: IA_Chording → any key (e.g. A).
2. In IMC_Overlay, add a mapping: IA_Chorded → a different key (e.g. S).
3. On the IA_Chorded mapping in IMC_Overlay, add a Chorded Action trigger and set its ChordAction to IA_Chording.
4. In your player controller (or wherever you set up Enhanced Input), add both IMCs via the Enhanced Input local player subsystem:

• IMC_Base at priority 1

• IMC_Overlay at priority 100

1. Bind a delegate (or print string) to IA_Chorded's Triggered event.
2. PIE.

Steps

1. Hold A (the chording-action key) and confirm IA_Chording's Triggered event fires.
2. While still holding A, also press S (the chorded-action key).

Expected

IA_Chorded's Triggered event fires every tick while both keys are held.

Actual

IA_Chorded never fires. The chord trigger silently reports its referenced action as inactive even though IA_Chording is producing Triggered events on the same tick.

—

Verification: swap the priorities

Swap step 6 so IMC_Base is at priority 100 and IMC_Overlay is at priority 1. With this ordering the chord fires correctly. This confirms the bug is a function of IMC priority ordering, not a fundamental cross-IMC incompatibility.

—

C++ Regression Repro

Automation tests covering both orderings live at:

Engine/Plugins/EnhancedInput/Source/InputEditor/Private/Tests/InputTriggerTest.cpp

• Input.Triggers.Chords.CrossContextLowerPriority — reproduces the bug (fails before the fix).
• Input.Triggers.Chords.CrossContextHigherPriority — sanity-check companion (passes before and after the fix).

Run via: UE.EditorAutomation -RunTest="Input.Triggers.Chords.CrossContext".

—

Root Cause

IEnhancedInputSubsystemInterface::ReorderMappings (EnhancedInputSubsystemInterface.cpp) promotes chording mappings ahead of chorded mappings, but only within a single IMC. Across IMCs the merged EnhancedActionMappings list is ordered strictly by IMC priority (high → low).

When the chord trigger and the action it references live in different IMCs, with the chorded mapping in the higher-priority IMC, the chorded mapping is processed first each tick in UEnhancedPlayerInput::PrepareInputDelegatesForEvaluation. Its chord trigger queries FindActionInstanceData(ChordAction)->GetEvaluatedActionTriggerState() — but the chord action's own mapping hasn't been processed this tick yet, so the TriggerStateTracker is still in its post-tick-reset state (None, set in EnhancedPlayerInput.cpp:436 at the end of the previous tick). The chord trigger sees None and produces no event, regardless of whether the chord key is actually held.

Root cause is in UMovieSceneSkeletalAnimationSection::GetAutoSizeRange (MovieSceneSkeletalAnimationSection.cpp:337). It calls InnerToOuterTransform.TryTransformTime(InnerEndTime).Get(InnerEndTime), and when the inverse transform fails to map InnerEndTime to an outer time (because the value is outside the Inner Clamp or Inner Loop range), the .Get(InnerEndTime) fallback returns the raw inner-tick value. That value is then used as if it were an outer-tick value in GetInclusiveStartFrame() + (OuterEndTime - OuterStartTime).FrameNumber, mixing inner-tick and outer-tick values and producing a negative or otherwise invalid length. SetRange then refuses the range and Auto Size has no effect.

This behavior was introduced by CL 40829088 ( [Link Removed] Closed , fixed in 5.6), which replaced the previous TOptional check with a .Get(fallback) pattern.

I've tried variations of the variables and slight changes change the behavior.
This reproduces in both Editor, PIE, and SIE.

I was not able to identify the root cause of the issue.

I've confirmed this behavior reproduces on versions 5.6 and 5.8 (CL45755840).

UV rotation behavior is incorrect for Substance materials that are imported into Twinmotion 2026.1. When applying a UV rotation, lighting and reflection handling are noticeably incorrect at any rotation aside from 180 degrees. At 0 degrees, the material is darker than is should be, progressively brightening until 180 degrees.

This behavior is unique to imported SBSAR files. The samples included in the Twinmotion library do not exhibit the same problem.

This is a regression introduced in 2026.1. A video demonstrating this problem is in the forum post. Attached a sample scene showing the issue.

The client has a file from Twinmotion 2025.2 that contains a sculpted landscape. When converting the file to Twinmotion 2026.1, the landscape becomes displaced from it’s original position, appearing higher than it should.

This effect is consistently reproducible in using the client file.

I was unable to reproduce it in a new scene with a containing only landscape assets.

We hit a regression upgrading our project from 5.7 to 5.8. Map Check (and any other path that ends up calling UWorldPartition::CheckForErrors) assert inside FWorldPartitionStreamingGenerator::ValidateContainerInstanceDescriptors, on the RuntimeGrid check():

for (const FGuid& ActorGuid : Cluster)
{

const FStreamingGenerationActorDescView& ActorDescView =

ContainerCollectionInstanceDescriptor.ActorDescViewMap->FindByGuidChecked(ActorGuid);

check(ActorDescView.GetRuntimeGrid() == ReferenceActorDescView.GetRuntimeGrid());

check(ActorDescView.GetIsSpatiallyLoaded() == ReferenceActorDescView.GetIsSpatiallyLoaded());

check(ActorDescView.GetContentBundleGuid() == ReferenceActorDescView.GetContentBundleGuid());

check(ActorDescView.GetExternalDataLayerAsset()== ReferenceActorDescView.GetExternalDataLayerAsset());

}

What changed between 5.7 and 5.8

Phase ordering inside PreparationPhase did not change. The mutator is still called between two

ValidateContainerInstanceDescriptors() passes. Clusters are still built in UpdateContainerDescriptor → GenerateObjectsClusters from references only. What changed is what the mutator-apply loop writes into.

5.7:

FContainerCollectionInstanceDescriptor::FPerInstanceData PerInstanceData =
ContainerCollectionInstanceDescriptor.GetPerInstanceData(ActorGuid);

if (ActorDescViewMutator.RuntimeGrid.IsSet())
{
    PerInstanceData.RuntimeGrid = ActorDescViewMutator.RuntimeGrid.GetValue();
}

ContainerCollectionInstanceDescriptor.AddPerInstanceData(ActorGuid, PerInstanceData);

Mutator writes a per-instance side-table. FStreamingGenerationActorDescView::GetRuntimeGrid() keeps returning the pre-mutation value, so the second ValidateContainerInstanceDescriptors pass sees a uniform grid per cluster and passes.

5.8 (current):

if (FStreamingGenerationActorDescView* ActorDescView =
ContainerCollectionInstanceDescriptor.ActorDescViewMap->FindByGuid(ActorGuid))
{
   if (ActorDescViewMutator.RuntimeGrid.IsSet())
   {
      ActorDescView->SetRuntimeGrid(ActorDescViewMutator.RuntimeGrid.GetValue());
   }
// ... same pattern for bIsSpatiallyLoaded, bIsHLODRelevant, HLODLayer
}

FPerInstanceData, AddPerInstanceData, GetPerInstanceData were removed; the mutator now writes the shared ActorDescView directly. The second ValidateContainerInstanceDescriptors pass now reads the post-mutation grid and trips the invariant whenever the mutator override touched only some of a ref-connected cluster.

Workaround:

We have made a small internal change that re-splits each ref-built cluster by the four invariant keys right after MutateContainerINstanceDescriptors, before the second validate:

1. if (MutateContainerInstanceDescriptors(...))
   {
      SplitClustersByMutatedAttributes(); // bucket each cluster by (RuntimeGrid, bIsSpatiallyLoaded, ContentBundleGuid, ExternalDataLayerAsset)
      ValidateContainerInstanceDescriptors();
   }
   

Error    LogOutputDevice      Ensure condition failed: SequencerRefCount == 1 [Link Removed] [Line: 967] 

1. Error    LogOutputDevice      Multiple persistent shared references detected for Sequencer. There should only be one persistent authoritative reference. Found 3 additional references which will result in FSequencer not being released correctly.

See proposed fix from partner:

[Image Removed]

Ensure condition failed: NumCPUVertices <= VertexBufferNumElements  File: Engine\Source\Runtime\Renderer\Private\RayTracing\RayTracingDynamicGeometry.cpp [Line: 310]

Vertex buffer contains 503 vertices, but RayTracingDynamicGeometryConverterCS dispatch command expects at least 3670051.

Taking a look at FRayTracingDynamicGeometryCollection::AddDynamicMeshBatchForGeometryUpdate and the MeshBatch *from *UpdateParams *that is failing, shows garbage numbers in *MeshBatch.Elements[0].MaxVertexIndex and MeshBatch.Elements[0].MinVertexIndex. This explains the assert, but not the why. The piece of code responsible for creating this mesh batch is FSplineMeshSceneProxy::GetDynamicRayTracingInstances.

The LodModel.sections and LODModel data don't appear to be correct and *MeshBatch.Elements[0] *can be left in an uninitialized state leading to garbage values in MinVertexIndex and MaxVertexIndex.

A workaround is to default initialize MeshBatch.Elements[0] and use the sum of all the section vertex ranges.

OCIO + nDisplay not producing expected output
The issue is just that when using UE 5.6 or later the resulting colour looks off compared to what 5.5 and pevious versions would produce. I have made 2 other threads about this issue but I didn't have a repro without using our software and I didn't know what the actual problem was. However now I have found the error and was even able to make a workaround on the plugin side. I still wanted to explain what I found in case it's a bug and not intended.

Seems related to the [Link Removed]

PostProcessLocalExposure.usf, ApplyLocalExposureCS function, line 48 (Engine/Shaders/Private/PostProcessLocalExposure.usf)

// BUGGY:
const float2 UV = (DispatchThreadId + 0.5f) * Output_ExtentInverse;

This UV is passed to CalculateBaseLogLuminance() (in PostProcessHistogramCommon.ush), which uses it to compute BilateralGridUVW.xy = UV * LocalExposure_BilateralGridUVScale. Since Output_ExtentInverse is based on the full render target size rather than the viewport size, the UV is incorrect when viewport != render target.

// FIXED:
const float2 UV = (DispatchThreadId + 0.5f) * Output_ViewportSizeInverse;

Both Output_ExtentInverse and Output_ViewportSizeInverse are provided by the SCREEN_PASS_TEXTURE_VIEWPORT(Output) macro in ScreenPass.ush.

When the animation runs, it appears that we calculate the AnimNotifies using PreviousPosition and CurrentPosition within the UAnimSequenceBase::GetAnimNotifiesFromDeltaPositions() function, so that those will fire in this frame.

The problem seems to be that when AnimNotify is running normally, it takes into account the time that the tick has not been updated with URO to calculate the PreviousPosition, but when it is run through Level Sequencer to trigger an animation, it does not take into account URO and enters the PreviousPosition.

Please watch the issues in the attached mp4.