float RadiusSq = length2(LocalBoxExtent);

This doesn't exactly match the CPU logic for static mesh component LOD selections.
We would need to pass up and use the radius squared of the original bounding sphere.

It seems like the issue is that for VTs with VirtualTexturePrefetchMips, TextureMips is empty, so the OutputMipsString lambda needs to look in (*TexturePlatformData)->VTData instead to get the size of OutputIndex

MaterialEditorStats: Error: [SM6] Shader debug info dumped to: "\Saved\ShaderDebugInfo\PCD3D_SM6\NewMaterial_7d16ee4857da21e\Default\FLocalVertexFactory\TMaterialCHSFNoLightMapPolicy\0"

E:\Epic Games\UE_5.7\Engine\Shaders\Private\RayTracing\RayTracingMaterialHitShaders.usf(551,53): Shader TMaterialCHSFNoLightMapPolicy, Permutation 0, VF FLocalVertexFactory:

  /Engine/Private/RayTracing/RayTracingMaterialHitShaders.usf:551:53: error: use of undeclared identifier 'GetSingleLayerWaterMaterialOutput0'

        const float3 ScatteringCoeff = max(0.0f, DFDemote(GetSingleLayerWaterMaterialOutput0(MaterialParameters)));   

                                 ^

MaterialEditorStats: Error: [SM6] E:\Epic Games\UE_5.7\Engine\Shaders\Private\RayTracing\RayTracingMaterialHitShaders.usf(552,53): Shader TMaterialCHSFNoLightMapPolicy, Permutation 0, VF FLocalVertexFactory:

  /Engine/Private/RayTracing/RayTracingMaterialHitShaders.usf:552:53: error: use of undeclared identifier 'GetSingleLayerWaterMaterialOutput1'

        const float3 AbsorptionCoeff = max(0.0f, DFDemote(GetSingleLayerWaterMaterialOutput1(MaterialParameters)));   

                                 ^

MaterialEditorStats: Error: [SM6] E:\Epic Games\UE_5.7\Engine\Shaders\Private\RayTracing\RayTracingMaterialHitShaders.usf(553,39): Shader TMaterialCHSFNoLightMapPolicy, Permutation 0, VF FLocalVertexFactory:

  /Engine/Private/RayTracing/RayTracingMaterialHitShaders.usf:553:39: error: use of undeclared identifier 'GetSingleLayerWaterMaterialOutput2'

        const float PhaseG = clamp(DFDemote(GetSingleLayerWaterMaterialOutput2(MaterialParameters).x), -1.0f, 1.0f);

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

This issue is caused by FSharedStruct batching reachability requests to the same underlying FInstancedStruct multiple times. This is not thread safe as nothing prevents the reachability processor from earlying out, so the hierarchy is processed multiple times across all GC workers.

This can lead to some race conditions where garbage exclusion kills the reference to the UObject** on the struct on one worker as it's currently being batched on another worker. This can lead the reachability to reference nullptrs all over the place.

In essence we need the following 4 criteria:

1. Lots of root UObjects with a reference to a FSharedStruct
2. The underlying FInstancedStruct must be shared between all FSharedStruct. We can do this by copying the FSharedStruct across all root UObjects so the FSharedStruct instance is unique, but the underlying TSharedPtr<FInstancedStruct> just bumps up the ref count.
3. The base struct type for the FInstancedStruct must have a TObjectPtr on it.
4. We must explicitly mark the TObjectPtr as garbage so it goes through garbage elimination during reachability.

If you have a look in the GCStressTestSubsystem in my repro sample for an example.

So the root cause is that FSharedStruct::AddStructReferencedObjects is invoked for each unique FSharedStruct instance, which in our case matches the number of root UObjects we created (10,000 by default in the attached sample). This will invoke Collector.AddReferencedObjects on the underlying UScriptStruct* which is simply the underlying shared single instance shared across all 10,000 instances. This means that the UScriptStruct* reachability is done 10,000 times in this example. This then ends up batching all its own properties this many times, including the TObjectPtr. This gets distributed between all the worker threads and performed in parallel. It's a race to see which route eliminates the UObject** address against all the other workers which are currently reading the same UObject*. We can end up crashing in lots of places in the batching, but it typically goes wrong in DrainValidated when we invoke a ObjectToIndex call, e.g:

ObjectIndices[Idx] = GUObjectArray.ObjectToIndex(ValidatedReferences[Idx].Object);

This reads offset 0xc on a nullptr because it's been eliminated on the other thread. This is checked when we DrainUnvalidated, but as soon as we pass the valid checks we assume that the ValidatedReferences only contains non-null references, which now causes issues because it was valid when the checks were first performed but has been invalidated between the DrainUnvalidated and the DrainValidated calls.

I have created a modified version of FSharedStruct called FFixedSharedStruct. This is effectively an identical version of the engine's version, but I've added an atomic int to the shared FFixedStructSharedMemory which contains the reachability flag. We mark this as reachable when the first FSharedStruct reaches the AddReferencedObject call which causes all future calls to the same underlying TSharedPtr to early out. This ensures that we only batch a single instance of the UScriptStruct.

You can toggle between the 2 FSharedStruct versions with the define in GCStressTestSubsystem.cpp

#define TEST_VANILLA_SHARED_STRUCT 1

#define TEST_FIXED_SHARED_STRUCT 1

This seems to work and follows a similar way to the UObject reachability flag, but I'm not sure if you have a better suggestion for a fix.

There doesn't seem to be any apparent reason this would be needed.

Looking into it, it seems the issue might come from ContentBrowserAssetDataCore.cpp within EditOrPreviewAssetFileItems(..) function which first load the asset and then ask the asset editor subsystem to open the asset's editor. Both those actions have a path into initializating the world:

Note: This issue persists even after applying the fix from //UE5/Main CL 45797729, which addressed a related issue.

We've encountered a crash in UWidgetAnimation::CreateDirectorInstance when repeatedly switching resolutions. We've had it for a while but it's not until recently that we've found a consistent repro.

Our understanding is that it's a lifetime issue. Sequence of events:

1. Viewport resizing triggers Slate to rebuild its widgets
2. Some widget with an active animation gets destroyed/marked for delete
3. UMGSequenceTickManager::ForceFlush is called
4. During Flush MovieSceneEventSystem::TriggerEvents fires
5. Consequently CreateDirectorInstance is called on UWidgetAnimation
6. GetPlaybackContex() returns null
7. CastChecked LogFatal (crash)

One suggested fix would be to detect zero scale and clamp it to some very small nonzero value. Note, though, that almost immediately below the scale factor calculation, there is a comment in the code warning about the drift that may be caused by the current method.

I’ve found an issue with the visualization of PlayerCollisions when using LandscapeSplineMesh with a mesh that has Nanite enabled. The Chaos collisions shown in the Chaos Visual Debugger are correct. It therefore seems to be an Editor issue where the deformation is not applied when Nanite is turned on. If I disable Nanite, the collisions are displayed correctly.

Is this a known issue? Will there be a fix in upcoming versions?

The showFlag.CollisionVisibility 1 cvar is a viewport visualization mode that highlights which Actors will block visibility. The showFlag.CollisionPawn 1 cvar is a Player Collision viewmode which highlights assets that collide with a character or Pawn. In these modes, only the respective collisions are rendered in the viewport.

Problem

The licensee noticed that setting `showFlag.CollisionVisibility 1` in one of their production levels seemed to omit most collision geometry in a Development game build, with `showFlag.CollisionPawn` also exhibiting the same issue. Everything seems to work fine in PIE and when the licensee tried a test level everything seemed fine at first, but then they noticed a select few assets were indeed missing in the collision view. Most of the test level is composed of simple block-out meshes which do not have Nanite enabled, but the pieces with no collision drawn (they do have collision) were production assets with Nanite enabled.

It is the licensee's understanding that the `showFlag.CollisionVisibility` and `showFlag.CollisionPawn` views should work in Development builds of the game, but this doesn't seem to be happening for StaticMesh assets that have Nanite enabled. Since nearly all of their production assets are going to have Nanite enabled this is going to make the collision views in game builds entirely unrepresentative.

Additional Notes

[Link Removed]

Adding a Delay task instead will allow this to work if the delay is greater than that used in Level 2a. If you remove the task from Level 1c, it will also transition to Level 2b as expected. Adding an empty parent state to Level 1c with no changes in tasks also works.

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.