This can be fixed with by changing FScreenPassTexture::CopyFromSlice in ScreenPass to take into account the override with:

CopyInfo.SourcePosition = FIntVector(ScreenTextureSlice.ViewRect.Min.X, ScreenTextureSlice.ViewRect.Min.Y, 0);

CopyInfo.DestPosition = OverrideOutput.IsValid()

  ? FIntVector(OverrideOutput.ViewRect.Min.X, OverrideOutput.ViewRect.Min.Y, 0)

  : CopyInfo.SourcePosition;

...

return FScreenPassTexture(OutputTexture, OverrideOutput.IsValid() ? OverrideOutput.ViewRect : ScreenTextureSlice.ViewRect);

Two lines are written to stderr when this happens:

MallocCrash run out of memory allocating 1048576 bytes, free 893392 bytes
Please increase LARGE_MEMORYPOOL_SIZE, exiting...

These go to stderr rather than the log, and the process ends in _exit(1), so buffered stdout is lost. Redirect stderr to a file to capture them.

Cause. Once a crash is being handled, GMalloc is replaced with FPlatformMallocCrash. Its large pool is 2MB and Free() is a no-op for that pool, so every allocation made while generating the report is permanent. Linux and Android are the only platforms that install this allocator. When the pool is exhausted the process calls RequestExit(true) and the report is lost.

Two allocations dominate the pool:

• Copying the engine log into the crash folder goes through IPlatformFile::CopyFile, which allocates a scratch buffer of min(1MB, log size). Any log larger than 1MB therefore takes half the pool in a single allocation.
• The all-thread callstack dump grows with thread count and is not bounded, and the accumulated thread XML is copied rather than moved when handed to the serializer.

The larger the crash context XML, the more likely this crash reporting failure becomes, so projects with many enabled plugins are affected first: the enabled plugin list is recorded in the crash context.

Workaround. Set unix.CaptureAllThreadStacksOnCrash=false. This restores crash reporting in most cases, at the cost of losing the per-thread callstacks.

It can be reproduced in 5.7 and 5.8.

I noticed an issue when exporting USD assets that contain materials using UDIM textures.

When exporting USD, the “Bake Materials” option allows me to export the base textures and relink them correctly with the USD Preview Material. However, when the source texture is a UDIM/virtual texture, the export only includes the first UDIM tile (1001) and does not export the remaining tiles.

For example, if a material uses:

MyTexture.1001

MyTexture.1002

MyTexture.1003

MyTexture.1004

the USD export with Bake Materials only exports:

MyTexture.1001

This means the resulting USD asset does not contain the complete texture set and the material appearance is incorrect when opened in another USD-compatible application.

Feature request

Would it be possible to extend the Bake Materials USD export functionality so that, when a texture is detected as a UDIM texture / virtual texture, the exporter automatically exports all available UDIM tiles, rather than only the first tile?

Ideally, the exported USD Preview Material would also retain the UDIM texture pattern/reference so that all tiles are correctly resolved when the USD is opened in another application.

This would be especially useful for assets where UDIMs are commonly used.

We were trying to create a custom sequencer track to implement that behavior, though we haven't finished it yet.

This specially complicated when that visibility needs to be animated in a level sequence.

We are experiencing an issue with importing skeletal meshes from alembic. For reference, this issue happens in vanilla engine 5.7.4, but it doesn't occur in versions 5.6.x.

1) After importing an alembic the skeletal mesh asset doesn't contain LOD description. Just after the import when we want to open/use the asset we have a crash on FSkeletalMeshModelingToolsEditorModeToolkit::OnEditorModeInitialized.

[Image Removed]

The AssetLODModes array is empty. 

2) When we save the skeletal mesh asset and then after restart of the editor we want to load the asset it is trying to recover LOD info on the post load step of the asset l*oading(PostLoadRecoverConvertLODModelsToMeshDescription)*.

In most cases, it causes memory overflow and crashes the editor. The worst thing is that the recovery process is running without any prompt to the user. We have only a “Waiting for skinned asset to be ready 0/1” task popup and we have no option to skip it or trigger the LOD rebuild manually, after the recovery also looks like the asset is not marked as dirty and the process can be repeated after each restart of the editor.

The problem escalates because any load of the asset (our internal tools, validators or even native Unreal tools) triggers this time and memory consuming process of LOD recovery.

The callstack of time and memory consuming task:

UnrealEditor-SkeletalMeshDescription.dll!TMeshAttributeArrayBase>::Insert(const int Index, const UE::Math::TVector & Default) Line 192 C++ UnrealEditor-SkeletalMeshDescription.dll!TMeshAttributeArraySet>::Insert(const int Index) Line 422 C++ UnrealEditor-Engine.dll!FAttributesSetBase::Insert(const int Index) Line 1769 C++ UnrealEditor-Engine.dll!FMeshElementContainer::Add() Line 82 C++ [Inline Frame] UnrealEditor-Engine.dll!FMeshDescription::CreateVertex() Line 206 C++ UnrealEditor-Engine.dll!FSkeletalMeshLODModel::GetMeshDescription(const USkeletalMesh * InSkeletalMesh, const int InLODIndex, FMeshDescription & OutMeshDescription) Line 1440 C++ UnrealEditor-Engine.dll!USkeletalMesh::PostLoadRecoverConvertLODModelsToMeshDescription() Line 3690 C++ UnrealEditor-Engine.dll!USkeletalMesh::ExecutePostLoadInternal(FSkinnedAssetPostLoadContext & Context) Line 4085 C++

3) Import options mostly default, unchecked Bake Matrix Animation

[Image Removed]

We are currently experimenting with different Alembic export/import options to find a solution. However, we would greatly appreciate any guidance or assistance you can provide us.

This permanently resets Lumen Radiosity temporal accumulation for the main view, producing severe indirect-lighting flicker — most visibly in Lumen Reflections on water. Direct lighting is unaffected, which makes the issue look like Radiosity noise rather than a resource-lifetime bug.

To mitigate, the signature initialisation can be moved inside a static lambda.

 		static const FNiagaraFunctionSignature OutSig = []
		{
			FNiagaraFunctionSignature Sig;
			static FNiagaraVariable EmitVar(FNiagaraTypeDefinition::GetBoolDef(), TEXT("Emit"));
			EmitVar.SetValue(FNiagaraBool(true));
			Sig.Name = TEXT("Write");
#if WITH_EDITORONLY_DATA
			NIAGARA_ADD_FUNCTION_SOURCE_INFO(Sig)
			Sig.Description = LOCTEXT("WriteFunctionDescription", "Writes data into the Data Channel at a specific index. Values in the DataChannel that are not written here are set to their defaults. Returns success if the index was valid and data was written into the Data Channel.");
#endif
			Sig.bMemberFunction = true;
			Sig.bRequiresExecPin = true;
			Sig.bWriteFunction = true;
			Sig.bSupportsGPU = false;//Cannot use direct index writes on GPU as we write into one shared buffer with all DIs using the same NDC data.
			Sig.AddInput(FNiagaraVariable(FNiagaraTypeDefinition(UNiagaraDataInterfaceDataChannelWrite::StaticClass()), TEXT("DataChannel interface")));
			Sig.AddInput(EmitVar, LOCTEXT("ExecuteWriteFlagTooltip", "If true then the write is executed, if false then this call is ignored and no write occurs."));
			Sig.AddInput(FNiagaraVariable(FNiagaraTypeDefinition::GetIntDef(), TEXT("Index")));
			Sig.AddOutput(FNiagaraVariable(FNiagaraTypeDefinition::GetBoolDef(), TEXT("Success")));
			Sig.RequiredInputs = IntCastChecked<int16>(Sig.Inputs.Num());//The user defines what we write in the graph.
			return Sig;
		}();
		return OutSig;

POST BODY:

• Summary

A TMap where the key is an FString can be created like so:

```
TMap MyMap =

;
```

3. close unreal engine

4. compile your code

5. launch the project. The project's module will fail to load. The error message you receive will be: "The game module 'MyProject570' could not be loaded. There may be an operating system error, the module may not be properly set up, or a plugin which has been included into the build has not been turned on."

• Expected Result

Compile-time error. If that isn't possible then a check being hit would be helpful.

• Observed Result

Project module fails to load. Unhelpful error message is shown. Logs are of no help.

• Affects Versions

5.7

• Platform(s)

Windows

• Additional Notes

Tested in 5.7. I did not try 5.8.

Happens whether FString is key or value.

Causes crashes anytime the code is executed. I chose static variable initialization time because that is the most difficult to debug, to show a case that could cause some engine users to lose a lot of time trying to debug.

It would be a good idea to update that error message so that it asks users to check static variable initialization for any errors.

POST AUTHOR: Fresh_mutroom

CREATED AT: 08/30/2026 06:31 PM EDT

UPDATED AT: 09/02/2026 10:33 AM EDT

As a workaround, the approach suggested by the licensee — clearing the invalid particle references from the GroundParticles array inside DisconnectConstraints — was confirmed to work.

After migrating our animation project from 5.7 -> 5.8 we notice that some level seqeunces take much longer to save (during validation stage). This issue only exhibits when using control rigs in animation mode. Some users have reported it taking up to 30 minutes on some shots, though I have only reproduced it taking 2-3 minutes. These save level sequences in 5.7 would have taken only serveral seconds to save. I attach a simplified repro project which takes about 10 seconds. The more characters the (exponentially) longer it takes to save.

[Link Removed]

A Level Sequence Actor in a Level Instance points to a Level Sequence Asset that has an Event Track that creates the Director when scrubbed over. If Sequencer is open at the same time as the Level Instance is open for edit, a strong reference is created to the Director which uses the Level Sequence Actor in the Level Instance as its outer. When the Level Instance is closed, the level is kept alive by sequencer. Tearing down the level triggers GC which finds the leak and fatal errors.