I can see that using Max LOD on each section to be the value of the LOD that you selected, eg getting mesh LOD 0 you set 0 as max LOD in the details works but it seems like a completely pointless feature to allow for duplication like this, and it seem more like an oversight. At the very least I would expect the the mesh section had a check box, default off called "include subsequent LODs" for some edge case where anyone would want that.

When importing some FBX files, the materials may be missing textures when using the Interchange importer. The attached model was created in Bentley Microstation as a .dgn file and exported as an FBX file. When importing into TM 2026.1 or 2026.2 Preview (Interchange), the model will appear without the associated texture.

This issue does not occur using the legacy importer, and does not occur when using prior versions of Twinmotion, such as 2025.2.

This issue does not affect all FBX files.

POST BODY:

• Summary
  Game packaging crashes at the PSO step. It worked fine in 5.7. I tried everything from deleting the Saved and Intermidiate folder and nothing works

• What Type of Bug are you experiencing?
  Other

• Steps to Reproduce
  Create a PSOBundle and package the game

• Expected Result
  It works

• Observed Result
  It doesn't work

• Affects Versions
  5.8

• Platform(s)
  Windows

• Upload an image
  [Link Removed]

POST AUTHOR: MattDalpe

CREATED AT: 08/25/2026 01:25 PM EDT

UPDATED AT: 10/23/2026 10:18 AM EDT

POST BODY:

• Summary
  When a Character's CapsuleComponent begins overlapping a Geometry Collection that has generate overlap event on, the engine crashes with an EXCEPTION_ACCESS_VIOLATION. The crash occurs inside UCharacterMovementComponent::CapsuleTouched, which calls GetBoneName() on OtherComp using the overlap's body index. his code path appears to assume any component with a valid multi-body index (OtherBodyIndex) is a USkinnedMeshComponent, which is true for Skeletal Mesh ragdolls but not for UGeometryCollectionComponent — a different class that also exposes multiple physics bodies per component. The resulting type confusion leads to invalid memory being read and interpreted as a UObject pointer, which crashes inside OutdatedKnownSkinnedAssetDetected() while building a diagnostic string via GetFullName().

• What Type of Bug are you experiencing?
  Simulation

• Steps to Reproduce

1. Create a new Third Person Template project (Blueprint), default settings, engine version as above.
2. Add a cube (or any simple mesh) to the level and convert it to a Geometry Collection.
3. Set collision response with Pawn to Overlap and enable Generate Overlap Events.
4. Position the Geometry Collection so the default Character will walk directly into it (or drop it near the player start).
5. Play in Editor (PIE) and walk the Character into the Geometry Collection.

• Expected Result
  The Character's capsule overlaps the Geometry Collection normally; OnComponentBeginOverlap fires without error.

• Observed Result

The Editor/game crashes immediately on first overlap with: EXCEPTION_ACCESS_VIOLATION reading address 0x0000000000000012

• Affects Versions
  5.8

• Platform(s)
  Windows

• For crash reports, include your callstack
  UnrealEditor-CoreUObject.dll!UObjectBaseUtility::GetFullName(TStringBuilderBase & ResultString, const UObject * StopOuter, EObjectFullNameFlags Flags) Ligne 117 C++
  UnrealEditor-CoreUObject.dll!UObjectBaseUtility::GetFullName(const UObject * StopOuter, FString & ResultString, EObjectFullNameFlags Flags) Ligne 108 C++
  UnrealEditor-CoreUObject.dll!UObjectBaseUtility::GetFullName(const UObject * StopOuter, EObjectFullNameFlags Flags) Ligne 98 C++
  UnrealEditor-Engine.dll!USkinnedMeshComponent::OutdatedKnownSkinnedAssetDetected::__l2::::operator()() Ligne 6050 C++
  UnrealEditor-Engine.dll!USkinnedMeshComponent::OutdatedKnownSkinnedAssetDetected() Ligne 6062 C++
  UnrealEditor-Engine.dll!USkinnedMeshComponent::GetSkinnedAsset() Ligne 2842 C++
  UnrealEditor-Engine.dll!USkinnedMeshComponent::GetBoneName(int BoneIndex) Ligne 2502 C++
  UnrealEditor-Engine.dll!UCharacterMovementComponent::CapsuleTouched(UPrimitiveComponent * OverlappedComp, AActor * Other, UPrimitiveComponent * OtherComp, int OtherBodyIndex, bool bFromSweep, const FHitResult & SweepResult) Ligne 11694 C++
  UnrealEditor-Engine.dll!UCharacterMovementComponent::execCapsuleTouched(UObject * Context, FFrame & Stack, void * const Z_Param__Result) Ligne 454 C++
  UnrealEditor-CoreUObject.dll!UFunction::Invoke(UObject * Obj, FFrame & Stack, void * const Z_Param__Result) Ligne 7595 C++
  UnrealEditor-CoreUObject.dll!UObject::ProcessEvent(UFunction * Function, void * Parms) Ligne 2234 C++
  [Inline Frame] UnrealEditor-Engine.dll!TScriptDelegate::ProcessDelegate(void *) Ligne 1016 C++
  UnrealEditor-Engine.dll!TMulticastScriptDelegate::ProcessDelegate(void * Parameters) Ligne 1441 C++
  [Inline Frame] UnrealEditor-Engine.dll!UE::Core::Private::TDelegateFunctionWrapper::CallWrapperImpl(const TDynamicMulticastDelegate &) Ligne 454 C++
  [Inline Frame] UnrealEditor-Engine.dll!UE::Core::Private::TDelegateFunctionWrapper::CallWrapper(const TDynamicMulticastDelegate &) Ligne 478 C++
  [Inline Frame] UnrealEditor-Engine.dll!TDynamicMulticastDelegate::Broadcast(UPrimitiveComponent *) Ligne 1504 C++
  UnrealEditor-Engine.dll!TSparseDynamicDelegate::Broadcast(UPrimitiveComponent * , AActor * , UPrimitiveComponent * , int , bool , FHitResult ) Ligne 333 C++
  UnrealEditor-Engine.dll!UPrimitiveComponent::BeginComponentOverlap(const FOverlapInfo & OtherOverlap, bool bDoNotifies) Ligne 4137 C++
  UnrealEditor-Engine.dll!UPrimitiveComponent::UpdateOverlapsImpl(const TArrayView * NewPendingOverlaps, bool bDoNotifies, const TArrayView * OverlapsAtEndLocation) Ligne 4494 C++
  UnrealEditor-Engine.dll!USceneComponent::UpdateOverlaps(const TArrayView * PendingOverlaps, bool bDoNotifies, const TArrayView * OverlapsAtEndLocation) Ligne 1096 C++
  UnrealEditor-Engine.dll!USceneComponent::EndScopedMovementUpdate(FScopedMovementUpdate & CompletedScope) Ligne 1307 C++
  UnrealEditor-Engine.dll!FScopedMovementUpdate::~FScopedMovementUpdate() Ligne 79 C++
  UnrealEditor-Engine.dll!UCharacterMovementComponent::PerformMovement(float DeltaSeconds) Ligne 3109 C++
  UnrealEditor-Engine.dll!UCharacterMovementComponent::ControlledCharacterMove(const UE::Math::TVector & InputVector, float DeltaSeconds) Ligne 6458 C++
  UnrealEditor-Engine.dll!UCharacterMovementComponent::TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction * ThisTickFunction) Ligne 1759 C++
  [Inline Frame] UnrealEditor-Engine.dll!FActorComponentTickFunction::ExecuteTick::__l2::::operator()(float) Ligne 1701 C++
  [Inline Frame] UnrealEditor-Engine.dll!FActorComponentTickFunction::ExecuteTickHelper(UActorComponent *) Ligne 4891 C++
  UnrealEditor-Engine.dll!FActorComponentTickFunction::ExecuteTick(float DeltaTime, ELevelTick TickType, ENamedThreads::Type CurrentThread, const TRefCountPtr & MyCompletionGraphEvent) Ligne 1699 C++
  [Inline Frame] UnrealEditor-Engine.dll!FTickFunctionTask::DoTask(ENamedThreads::Type CurrentThread, const TRefCountPtr &) Ligne 334 C++
  UnrealEditor-Engine.dll!TGraphTask::ExecuteTask() Ligne 703 C++
  UnrealEditor-Core.dll!UE::Tasks::Private::FTaskBase::TryExecuteTask() Ligne 524 C++
  [Inline Frame] UnrealEditor-Core.dll!FBaseGraphTask::Execute(TArray> &) Ligne 493 C++
  UnrealEditor-Core.dll!FNamedTaskThread::ProcessTasksNamedThread(int QueueIndex, bool bAllowStall) Ligne 807 C++
  UnrealEditor-Core.dll!FNamedTaskThread::ProcessTasksUntilIdle(int QueueIndex) Ligne 707 C++
  [Inline Frame] UnrealEditor-Core.dll!FTaskGraphCompatibilityImplementation::ProcessThreadUntilIdle(ENamedThreads::Type) Ligne 1447 C++
  UnrealEditor-Core.dll!FTaskGraphCompatibilityImplementation::ProcessUntilTasksComplete(const TArray,TSizedInlineAllocator<4,32,TSizedDefaultAllocator<32>>> & Tasks, ENamedThreads::Type CurrentThreadIfKnown, const TFunction & IdleWorkUpdate) Ligne 1620 C++
  UnrealEditor-Engine.dll!FTickTaskSequencer::ReleaseTickGroup(ETickingGroup WorldTickGroup, bool bBlockTillComplete, TArray> & TicksToManualDispatch) Ligne 1040 C++
  UnrealEditor-Engine.dll!FTickTaskManager::RunTickGroup(ETickingGroup Group, bool bBlockTillComplete) Ligne 2134 C++
  [Inline Frame] UnrealEditor-Engine.dll!UWorld::RunTickGroup(ETickingGroup) Ligne 786 C++
  UnrealEditor-Engine.dll!UWorld::Tick(ELevelTick TickType, float DeltaSeconds) Ligne 1750 C++
  UnrealEditor-UnrealEd.dll!UEditorEngine::Tick(float DeltaSeconds, bool bIdleMode) Ligne 2171 C++
  UnrealEditor-UnrealEd.dll!UUnrealEdEngine::Tick(float DeltaSeconds, bool bIdleMode) Ligne 546 C++
  UnrealEditor.exe!FEngineLoop::Tick() Ligne 5859 C++
  [Inline Frame] UnrealEditor.exe!EngineTick() Ligne 60 C++
  UnrealEditor.exe!GuardedMain(const wchar_t * CmdLine) Ligne 190 C++
  UnrealEditor.exe!GuardedMainWrapper(const wchar_t * CmdLine) Ligne 123 C++
  UnrealEditor.exe!LaunchWindowsStartup(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * __formal, int nCmdShow, const wchar_t * CmdLine) Ligne 277 C++
  UnrealEditor.exe!WinMain(HINSTANCE__ * hInInstance, HINSTANCE__ * hPrevInstance, char * pCmdLine, int nCmdShow) Ligne 338 C++
  [External Code]

• Additional Notes

• The local variable dump at the crash frame shows `this = 0x0000000000000002` for the `UObjectBaseUtility` pointer passed into `GetFullName`. This is clearly an invalid address, consistent with a small integer or enum member being read from the wrong byte offset and misinterpreted as a `UObject*`.
• We suspect `CapsuleTouched`'s handling of a valid `OtherBodyIndex` (indicating a multi-body `OtherComp`) does not verify that `OtherComp` is actually a `USkinnedMeshComponent` before calling bone-resolution functions on it, causing a type-confused read when `OtherComp` is instead a `UGeometryCollectionComponent`.
• This did NOT reproduce with a Static Mesh using identical collision settings (single-body, so this code path is presumably not entered).

POST AUTHOR: Aestarion

CREATED AT: 09/07/2026 01:43 PM EDT

UPDATED AT: 10/23/2026 10:13 AM EDT

POST BODY:

• Summary
  Changing a material's Blend Mode crashes the editor when that material is currently assigned to a Nanite-enabled static mesh (visible in the level or in the Material Editor preview). The engine correctly logs a warning that the blend mode is unsupported on Nanite, but then proceeds into a Lumen scene card capture path that asserts instead of failing gracefully.

• What Type of Bug are you experiencing?
  AI

• Steps to Reproduce
  Create or use a static mesh with Nanite enabled.
  Assign a material to it (in the level, or set as the Material Editor's preview mesh).
  Open the material and change its Blend Mode.
  Editor crashes immediately.

• Expected Result
  Editor should not crash. Ideally it should block or gracefully reject the invalid blend mode/Nanite combination, consistent with the warning it already logs.

• Observed Result
  Editor crashes with an unhandled assertion.

• Affects Versions
  5.8

• Platform(s)
  Windows

• For crash reports, include your callstack
  LogStaticMesh: Warning: Invalid material [NewMaterial] used on Nanite static mesh [SM_Drone_Two_Mats].
  Only opaque or masked blend modes are currently supported, [BLEND_TranslucentColoredTransmittance] blend mode was specified.

LogWindows: Error: appError called: Assertion failed: Nanite::IsSupportedBlendMode(ShadingMaterial)

[[Link Removed]:\build++UE5\Sync\Engine\Source\Runtime\Renderer\Private\Lumen\LumenSceneCardCapture.cpp] [Line: 312]

POST BODY:

• Summary

Ue 5.8 Fresh install and basically fresh project. Any time Ue detects a change in the project files it crashes after bringing up the message about a change.

Linux Mint, 96gb ram, 4080super.

• What Type of Bug are you experiencing?

Editor

• Steps to Reproduce

Open project in Unreal Editor, adjust a project file i.e. re-export in blender.

• Expected Result

Program doesnt crash.

• Observed Result

Program crashes.

• Affects Versions

5.8

• Platform(s)

Linux

• For crash reports, include your callstack

It juts instantly crashes, doesnt mention a crash report.
EDIT: found some kinda Log file in the projest, is attached.

[Chamkopolis.log|attachment](upload://5QnZnZt9XWbKuqpqeuZT8W0hbUx.log) (304.4 KB)

POST AUTHOR: ChrisCrinkle

CREATED AT: 07/03/2026 07:02 AM EDT

UPDATED AT: 10/23/2026 08:42 AM EDT

Root cause

PostProcessFFTBloom.cpp computes SurveyGroupGridSize from ViewTexelRadiusInKernelTexels (R):

2 * DivideAndRoundUp(CeilToInt(R) + 4, SurveyTileSize)(source)

so the survey grid spans texel offsets -4*G .. 4*G-1, roughly R+4.

BloomSurveyMaxScatterDispersion.usf however defines its center zone with 2R + 1 and edge zone with 2R + 4, i.e. it surveys texels out to ~2R+4. For radii where little rounding up happens, the entire grid lies inside the center zone, the survey is empty and the max scatter dispersion is 0, which makes the bloom vanish.

Fix

Size the grid from 2R:

2 * DivideAndRoundUp(CeilToInt(2.0f * R) + 4, SurveyTileSize)

This guarantees 4*G-1 >= CeilToInt(2R) + 3, the last texel the shader can survey. BloomSurveyKernelCenterEnergy.usf masks by R and is unaffected by the larger grid.

• This shader permutation has SUBSTRATE_INLINE_SHADING=1 and SUBSTRATE_DEFERRED_SHADING=0, the header/BSDF unpack from the payload is compiled out.
• SubstrateGetBSDFSharedBasis takes the inline path and returns the zero-initialized SharedLocalBases, so the hit normal is 0 and the light contribution is 0.
• The LF material's SUBSTRATE_FASTPATH / SINGLEPATH / CLAMPED_CLOSURE_COUNT and the default SUBSTRATE_USES_FORCED_COMPLEXITY=1 also drive how the hit surface is unpacked (the payload writer RayTracingMaterialHitShaders.usf:16-19 uses SUBSTRATE_USES_FORCED_COMPLEXITY 0).

Here is a work around:

[Link Removed]

In a non-World-Partition map with streamed sublevels, PCG Editor Mode interactive tools (Draw Spline / SpacingTool, Area, Paint, Volume, ...) spawn their new tool actor in the PersistentLevel instead of the current level (World->GetCurrentLevel()). This only happens when no compatible actor is selected when the tool is activated. Standard editor actor placement uses the current level (EditorActorSubsystem.cpp, ULevel* DesiredLevel = World->GetCurrentLevel();).

Reported by a licensee (EPS / SF case 27094155).

Expected

The tool actor is created in the current level (e.g. SubLevel_01).

Actual

The tool actor (e.g. "PCG Area Tool Actor") is created in the PersistentLevel and stays there after Accept.

Root cause

1. UPCGInteractiveToolSettings::InitActorAndComponent (PCGInteractiveToolSettings.cpp) reuses a selected compatible actor if there is one; otherwise it calls UE::PCG::EditorMode::Actor::SpawnWorking(World, ...). Every PCG Mode tool goes through this path.
2. Actor::Spawn / Actor::SpawnWorking (PCGEdModeActorHelpers.cpp) don't set FActorSpawnParameters::OverrideLevel. In Main (after [Link Removed]) SpawnWorking also hard-codes ULevel* Level = World->PersistentLevel; for the unique name and the external-actor decision.
3. UPCGActorHelpers::SpawnDefaultActor(const FSpawnDefaultActorParams&) (PCGActorHelpers.cpp) falls back to SpawnParams.OverrideLevel = Params.World->PersistentLevel; when no override is given (since CL 33654117), so UWorld::SpawnActor never reaches its own CurrentLevel default.
4. On Apply, the actor only has RF_Transient cleared and is never moved.

Not a regression. [Link Removed] touches the same function (WP external packaging) but does not change the level.

Proposed fix

In PCGEdModeActorHelpers.cpp, add a GetSpawnLevel(World) helper returning World->GetCurrentLevel() (falling back to PersistentLevel), set SpawnParams.OverrideLevel from it in Spawn and SpawnWorking, and use it for the existing ULevel* Level in SpawnWorking so name, external packaging and level stay consistent. SpawnDefaultActor's fallback is left alone because it's shared with runtime/generation spawning. In WP maps the current level is the persistent level, so behaviour there is unchanged. Fix verified locally on 5.8.3.

Workarounds

• Select a compatible actor that already lives in the target sublevel before activating the tool.
• After Accept, use Levels > Move Selected Actors to Level, then regenerate.

• a World Partition cell that unloads and is reactivated before GC runs
• a global re-register from a cvar sink such as r.CustomDepth or r.RayTracing.Geometry.InstancedStaticMeshes.EvaluateWPO

It only happens in cooked/game builds, because component PSO precaching is disabled in the editor.

Fix: cherry-pick CL 55798320 (//UE6/Main) to //UE5/Dev-Release-5.8. It adds a guarded PrecachePSOs() at the end of both components' OnRegister, skipped when IsPSOPrecacheCalled() is still set. Pending CL 59512334 in Dev-Release-5.8.

Validation: cooked Development Win64 builds from Dev-Release-5.8.

• WP landscape map, player moves far away (cells unload) and back before GC: ensure fires in ULandscapeComponent::CreateSceneProxy without the fix, and doesn't with it.
• r.RayTracing.Geometry.InstancedStaticMeshes.EvaluateWPO 1: same result.
• EngineTest Project.Functional Tests.Tests.Rendering.DebugViewModes.DebugViewModes.BufferCustomStencil on Vulkan SM6 ([Link Removed]): Fail without the fix (groom ensure), Success with it.

Not covered: UGeometryCollectionComponent has the same gap (it precaches in PostLoad only).

When UnrealTestNode.StartTest returns false (or throws), TestExecutor.ExecuteTests moves the test straight to CompletedTests. It never calls CleanupTest or StopTest on the node, so the devices reserved for that test are never released until DevicePool is disposed at the end of the whole run.

• In 5.6 / 5.7 the devices are reserved in UnrealTestNode.IsReadyToStart (UnrealApp.TryReserveDevices()).
• In 5.8 / Main they are reserved by base.StartTest → UnrealSession.LaunchSession.

Tests waiting for those devices fail with "Insufficient devices" after -wait. With -NoTimeout they hang forever while any other test keeps running (the MaxDuration check is disabled, and the insufficient-devices check only runs when no test is running or starting): a soft deadlock.

Reported by a licensee (SF 27104158).

Code (5.6, Engine/Source/Programs/AutomationTool/Gauntlet)

• Framework/Gauntlet.TestExecutor.cs — the Started == false branch in ExecuteTests (~:333-339 in 5.6, ~:384 in Main) only sets timestamps, sets Result = Interrupted, adds the test to CompletedTests and logs "failed to start". CleanupTest is only reached from TickTest (running tests) and the cancel path (starting tests). TestExecutor.Dispose is empty.
• Unreal/RunUnreal.cs — DevicePool.Instance.Dispose() in the finally of ExecuteTests is the only place the leaked devices are released.
• The branch is the same in //UE5/Release-5.6, //UE5/Main and //UE6/Main; its base logic dates from CL 13149436.

CLs 51897540 and 52028138 (5.8+) only partly mitigate it, by moving reservation out of IsReadyToStart. It still leaks:

• when a derived StartTest returns false after base.StartTest succeeded;
• when LaunchSession returns null after exhausting its attempts (only problem devices are released).

Suggested fix

• In the Started == false branch, call TestToStart.TestNode.CleanupTest() in a try/catch, and force the device release. This is needed for multi-pass tests, because CleanupTest only disposes UnrealApp on the last pass.
• Release devices in the failure paths of UnrealTestNode.StartTest.
• Don't call StopTest there: TestInstance is null after a failed launch.

Workaround

In the UnrealTestNode subclass, call UnrealApp?.ReleaseSessionDevices() before returning false from StartTest (e.g. in a try/finally around base.StartTest). Throwing instead of returning false doesn't help; the executor catches the exception and takes the same path.

Affects

5.6, 5.7, 5.8, Main

Cause: the per-frame renderer cleanup CleanupViewFamilies_RenderThread (SceneRendering.cpp) is only queued from FRendererModule::BeginRenderingViewFamilies. With world rendering disabled, UGameViewportClient::Draw only calls PerFrameCleanupIfSkipRenderer, and scene captures (USceneCaptureComponent2D/Cube::CaptureScene -> FScene::UpdateSceneCaptureContents -> FSceneRenderBuilder::Execute) never run that cleanup. ResetAndShrinkModifiedBounds is only called from it, so the scene-level array is never reset. The other work in that cleanup (ray tracing scene/SBT EndFrame, IPersistentViewUniformBufferExtension::EndFrame, hair strands end-of-frame, PrevFrameViewInfo update) is also skipped on this path.

Related to [Link Removed], which covers the per-view-state ClipmapViewState.Cache[].PrimitiveModifiedBounds growth caused by the same setup (FrameNumber not incremented). Fixing [Link Removed] alone does not reset the scene-level array.

Workaround: call ResetAndShrinkModifiedBounds on each Scene->DistanceFieldSceneData.PrimitiveModifiedBounds[] entry once per frame after captures (requires a local engine change), or leave bDisableWorldRendering false.

Present in 5.8 and in current UE5/Main and UE6/Main code.

I've tried this on a Niagara Simulation Cache and it works as expected.

I'd expect this to work on MovieSceneSkeletalAnimationSections as well

POST BODY:

• Summary
  The editor crashes when Media Viewer is viewing/capturing a Level Editor Viewport and the Level Editor viewport type is switched from Default Viewport to Cinematic Viewport. This is not caused by selecting a CineCameraActor itself; the crash happens specifically when switching the viewport type to Cinematic Viewport while Media Viewer is active.

• What Type of Bug are you experiencing?
  Rendering (Graphics / Niagara)

• Steps to Reproduce
  1. Open a UE 5.8 project.
  2. Enable/open the Media Viewer plugin.
  3. In Media Viewer, add or view a Level Editor Viewport.
  4. In the Level Editor viewport dropdown, keep the camera as needed, then change Viewport Type from Default Viewport to Cinematic Viewport.
  5. The editor crashes.

• Expected Result
  Media Viewer should display the Cinematic Viewport, or safely skip rendering/capturing that frame if the viewport render target is unavailable.

• Observed Result
  The editor crashes with an assertion in RenderTargetPool.cpp:

Assertion failed: Texture
File: Engine/Source/Runtime/RenderCore/Private/RenderTargetPool.cpp
Line: 95

• Affects Versions
  5.8

• Platform(s)
  Windows

• Upload an image
  Unable to render embedded object: File (attachment_1.png) not found.

• For crash reports, include your callstack
  UnrealEditor_Core
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_Engine
  UnrealEditor_Engine
  UnrealEditor_Engine
  UnrealEditor_Engine
  UnrealEditor_MediaViewer
  UnrealEditor_MediaViewer
  UnrealEditor_MediaViewer
  UnrealEditor
  UnrealEditor
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_Core
  UnrealEditor_Core
  UnrealEditor_Core
  UnrealEditor_RenderCore
  UnrealEditor_RenderCore
  UnrealEditor_Core
  UnrealEditor_Core
  kernel32
  ntdll

• Additional Notes
  Environment:

• Unreal Engine: 5.8.0-55116800+++UE5+Release-5.8
• Platform: Windows 11 25H2
• GPU: NVIDIA GeForce RTX 4060 Laptop GPU
• GPU driver: 581.57
• RHI: D3D12
• Dedicated VRAM reported by UE: 7957 MB

Notes from the crash log:

• MediaViewer is enabled and loaded.
• The crash is an Assert, not an out-of-memory crash.
• MemoryStats.bIsOOM is 0 in CrashContext.runtime-xml.
• Crash occurs in a Slate Paint context while MediaViewer is in the call stack.
• Original crash log contains user/session identifiers, so this report includes only the relevant sanitized details.

POST AUTHOR: danny6

CREATED AT: 08/30/2026 12:02 PM EDT

UPDATED AT: 10/19/2026 12:48 PM EDT

As a result, unlike in PIE, these WorldSettings are replicated.

PausedTime = Context.World()>RealTimeSeconds - Context.World()>AudioTimeSeconds;

double CurrentSequenceTimeSeconds = UndilatedDeltaTime + AccumulatedDilation - PausedTime;

RealTimeSeconds - AudioTimeSeconds is the total time the world has been paused since it started, not since playback started. If the world was paused at any point before Play(), the first ticks return a time before the start frame.

ShouldStopOrLoop only checks the upper bound in forward playback, so the player evaluates at that negative time. Everything active at frame 0 is unlinked right after being linked. For example, IMovieSceneEvaluationHook::End fires one frame after Begin. The sequence then holds before its start until the elapsed time catches up with the total paused time.

This affects the Audio, Platform and RelativeTimecode clocks.

Scenes containing Orbit Rigs will cause crashes when attempting to Merge with other files.

[Link Removed]
From EPS:
We use Movie Render Graph with multiple layer output and one of the layers is used to obtain a character matte. We collect character actors using a Collection and apply Holdout Modifier, so they render as a black hole.

However, we have noticed, that with the Holdout active on a layer, the geometry does not take deformers into account, such as squash and stretch. As a result, our character matte does not match the characters on the beauty layer and cannot be used in Post. This is serious, as we render a lot of cartoony animated movies and squash-stretch deformers are very common.

Please see the attached repro project. Made in UE 5.7, but issue has been encountered in 5.8 as well.