Class UNiagaraDataInterface provides virtual method GetFeedback(), which allows the implementation to fill arrays containing errors, warnings, and information messages based on validation checks. When an error or warning is produced, the Details Panel for the Niagara Module that makes use of the Data Interface will display a generic section "Object has errors" (or "Object has warnings"), plus a customized section "Errors and Warnings" that list the detected issues and possibly contains "fix" buttons.

The validation checks performed by GetFeedback() can depend on data external to the Data Interface itself. For example, a Static Mesh Interface often needs to check if the linked static mesh asset has "allow cpu access" enabled. Up to UE 5.5, changing such external data caused the "Errors and Warnings" section to be updated correctly. Beginning on UE 5.6, however, the section seems to only be updated when a property of the Data Interface itself changes. This can lead to errors still appearing when they were already resolved (e.g. allow cpu access was already turned on but the error did not go away), or to error explanations not appearing at all when a condition triggers an issue (e.g. allow cpu access was turned off, section "object has errors" appeared, but section "Errors and Warnings" did not appear with the explanation and fix button).

(more info on the "callstack" field)

This issue does not happen in 5.3.

This issue happens after CL 27589933, and the direct cause is [Launcher.DeviceGroups] section not saved in [Project]\Saved\Config\WindowsEditor\Engine.ini .

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.

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]

    [WarningsClangToolChain(["-Wno-date-time"], ["-Wdate-time", "-Wno-error=date-time"], ["-Wdate-time"], [nameof(StandardFilters.DeterministcFlagSetFilter)])]  
    [WarningsMSCV(["/wd5048"], null, ["/we5048"], [nameof(StandardFilters.DeterministcFlagSetFilter)])]  
    [WarningLevelDefault(WarningLevel.Off)]  
    public WarningLevel DeterministicWarningLevel  

However, there is a bug that these don't behave the same way in MSVC and clang. Using this one as an example, warningArgs for MSVC is null because this defaults to warning level 1 already, but if you wanted it to be warning level 4, it would be ["/w45048"]. Let's say also that I change the warning level default to WarningLevel.Warning and purposely write code that causes it. When MSVC receives both "/Wx" for warnings as errors and "/w45048", that warning still becomes an error. But when clang receives "-Werror" for warnings as errors and "-Wdate-time -Wno-error=date-time" in an attempt to enable the error and downgrade it to a warning, "-Werror" does not take precedence. It is indeed downgraded to a warning, and the build succeeds.

I was able to fix this locally by changing ApplyWarningsToArgumentsInternal to check (toolChainContext._compileEnvironment.bWarningsAsErrors && level == WarningLevel.Warning), and increasing level to WarningLevel.Error if so. I'm not sure if this is the same solution you would use, as there are probably other ways to handle this.

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;
	}

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.

It can be reproduced in 5.7 and 5.8.

Reported in version 4.25.3 (CL-13942748); tested in version 4.25.3 and version 4.24.3 (CL-11590370)

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.

This can be traced to `FStaticMeshSceneProxy::CanBeOccluded()`, which uses the function "FPrimitiveSceneProxy::IsRuntimeVirtualTextureOnly()" to check if the primitive should only render in RVTs.

This function only considers `ERuntimeVirtualTextureMainPassType::Never` (via `bVirtualTextureMainPassDrawNever`), unlike the similar function `FPrimitiveSceneProxy::DrawInRuntimeVirtualTextureOnly(…)`, which is used for other passes (BasePass, ShadowDepths, etc).

This issue might be shared with "FLandscapeComponentSceneProxy::CanBeOccluded()" as well.

==============================

When 5.0 first introduced TObjectPtr, the guidance was that it would compile down to raw pointer access in Shipping builds to ensure identical performance.

Evidenced by the following quote from the documentation for 5.0:

UE5 introduces TObjectPtr, a template-based, 64-bit pointer system, as an optional replacement for raw object pointers in editor builds. This system adds dynamic resolution and access tracking in editor builds, while performing identically to raw pointers in non-editor builds.

In recent versions of the engine, this guarantee seems to have been silently dropped.

The introduction of incremental reachability analysis adds code to call ConditionallyMarkAsReachable, regardless of whether incremental GC is turned on.

This causes assembly instructions comparable to the following to be generated inline every time a TObjectPtr or TSubclassOf is assigned:

cmp byte ptr [UE::GC::GIsIncrementalReachabilityPending],r14b

je _____+16Fh

mov rcx,qword ptr [rbx+458h]

test rcx,rcx

je _____+16Fh

call UE::GC::MarkAsReachable

In our game, this adds several megabytes to our compiled binary size, putting pressure on the instruction cache and branch predictor.

Even though incremental GC is experimental and not even supported outside of single-threaded servers, right now every game is paying for the feature even when not enabled, due to `UE_OBJECT_PTR_GC_BARRIER` being unconditionally set to `1` in `ObjectPtr.h`.

My questions are the following:

• It would be nice if this code was automatically compiled out when incremental GC is off, instead of us having to randomly find out about the define during profiling.

• This seems to unconditionally apply to every TSubclassOf as well, even when used as a parameter/local variable and GC barriers are unnecessary.

• Inlining the check to `GIsIncrementalReachabilityPending` makes sense, but it might be worth moving the null object check into `MarkAsReachable` itself, which would reduce the binary size cost of the repeatedly inlined code.

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.