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.

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.

1. The Control Rig creates its hierarchy at runtime via Import Skeleton in the Construction Event (bones and controls do not exist in the asset's stored initial hierarchy)
2. The character is a spawnable whose binding lives in a subsequence
3. Evaluate Sub Sequences In Isolation is OFF

[Image Removed]

Changing any one of these three conditions makes the bake succeed. This points at the rig instance used by the bake being constructed/evaluated without the correct binding context (or with an unapplied sub-section time transform) when evaluation goes through the root sequence hierarchy.

Expected

Bake To Control Rig should construct/evaluate the rig instance with the resolved spawnable binding and correct time-space regardless of where the binding lives in the sequence hierarchy — or at minimum surface an error instead of silently producing an empty bake.

Why it matters

Construction-time hierarchy import is the foundation of modular/procedural rigging, and spawnables-in-subsequences is the standard shot structure for linear content pipelines. The intersection silently breaks bake-to-rig, and the failure looks like a rig authoring error to end users (partial keys, no message), which makes it expensive for studios to diagnose — this one cost a client several days.

Workarounds (validated)

Enable "Evaluate Sub Sequences In Isolation" before baking; or bake in a root-level duplicate of the sub; or use a rig variant with the constructed hierarchy stored in the asset.

float CurrentTime = NormalizedCurrentTime * NewAnimLength;
LeaderSampleData.PreviousTime = CurrentTime;
                        	
FAnimationRuntime::AdvanceTime(Instance.bLooping, NewDelta, /*inout*/ CurrentTime, NewAnimLength);
                        	
LeaderSampleData.Time = CurrentTime;
NormalizedCurrentTime = NewAnimLength ? (CurrentTime / NewAnimLength) : 0.0f;

This uses NormalizedCurrentTime (based on the time accumulator of the BS) to calculate the new PreviousTime and Time of the lead sample (Time is set again in ResetBlendSamples). But this new time bears no relation to the time of the sample on the previous frame when it was a follower and was being updated via the follower branch logic (ie. by UBlendSpace::TickFollowerSamples). So we can get pops from large jumps forwards, or backwards, in the playback time.

Note that while the intention with this update mode is that it’s used with a motion matching or blendstack node, the layer blending when the BS parameters change only partially hides the issue.

Texture size only available for Texture2D, TextureVirtual, Texture2DArray, VolumeTexture and SparseVolumeTexture, not unknown.

This is because Texture Collections that are Bindless mask their texture type with MCT_TextureCollection and FHLSLMaterialTranslator::TextureProperty doesn't take into account that mask, it just checks equality.

This comment in IsGBufferLayoutSupportedForMaterial hints at the confusion: "FMaterialShaderParameters::bHasVertexPositionOffsetConnected means that the material could have WPO".

In other code, the word connected means something else, for example in U*Material::IsPropertyConnected,* it is considered as "is property used and different from the usual default", such as FMaterialResource::IsNonmetal (the connected constant may be a 1 on Metallic pin)

This is because Movie Render Graph does not pass the Assembly object as a context object when evaluating “cat” tokens. This context should always be passed when a user renders a Cinematic Assembly. There is no need to offer an opt-out because always including the context should be considered expected behavior from the perspective of the CAT feature.

The World Outliner itself is not affected. This behavior change came from //UE5/Main CL49143080.

Conditions:

An Object Mixer filter whose GetObjectClassesToFilter() returns AActor. That is the natural thing to write for a tool that lists every actor in a level.

Both Object Mixer surfaces are affected:

• Window > Object Mixer, with the filter ticked in its filter-class menu.
• UObjectMixerEditorUWidget placed in an Editor Utility Widget, with Object Mixer Widget User Config > Default Filter Class set to the filter.

This happens when using Windows Vulkan ES3_1 Renderer, and we do have our own custom integrated code, however none of our code is in involved with the callstack during this crash.

The calls happens when FMobileBasePassMeshProcessor::CollectPSOInitializers is executed, which is why it happens on the game thread.

When checking if this issue has already been addressed in a later changelist, I found that in CL#54496007 from Epic's P4 Main stream, FVariableRateShadingImageManager::IsPipelineVRSEnabled also had the same call to CVarEnableVRS.GetValueOnRenderThread(), which was changed to GetValueOnAnyThread. The changelist comment also mentioned that it can be used during PSO precaching. That function is written right before IsAttachmentVRSEnabled and they both reference the same cvar.

Presumably the appropriate fix is to also change FVariableRateShadingImageManager::IsAttachmentVRSEnabled to use GetValueOnAnyThread.

—

What happens

The collection lands and never breaks. It receives zero OnChaosBreakEvent callbacks and its root stays unbroken indefinitely. It comes to rest at the same height as an identical non-one-way collection, so the collision is definitely happening — it just produces no damage.

This is independent of what it lands on ie A one-way collection also cannot be broken by another collection dropped onto it.

—

What should happen

It should break, identically to the control.

One-way interaction is documented as stopping a body from applying forces to non-one-way bodies. It should suppress the damage a one-way body deals to others; it should not suppress the damage it receives, and it should not stop the body breaking itself on impact.

—

Why it happens

FRigidClustering::ComputeStrainFromCollision discards every one-way contact before any strain is accumulated — Chaos/Private/Chaos/PBDRigidClustering.cpp:2240:

if (ContactHandle->GetContact().GetIsOneWayInteraction())
{
    continue;
}

The flag it tests is set in FPBDCollisionConstraint::Setup — Chaos/Private/Chaos/Collision/PBDCollisionConstraint.cpp:351:

Flags.bIsOneWayInteraction = (bDynamic0 || bDynamic1) && (bOneWay0 || bOneWay1);

That is true for any contact where at least one body is dynamic and at least one is one-way. It never asks what the other body is, so it cannot distinguish "one-way damaging a non-one-way body" (which should be suppressed) from "one-way body being damaged by anything at all" (which should not). The bDynamic term only excludes static/kinematic-vs-static/kinematic pairs, which carry no impulse anyway. That is why the counterpart type above makes no difference.

With level 0, FGeometryCollectionPhysicsProxy marks every particle one-way, cluster root included — GeometryCollectionPhysicsProxy.cpp:1753:

const bool bIsOneWayInteraction = (Parameters.OneWayInteractionLevel >= 0) && (Level[ParticleIndex] >= Parameters.OneWayInteractionLevel);

So CollisionImpulses() stays at 0 for the whole collection, and the release test in AdvanceClustering — PBDRigidClustering.cpp:1178 — never fires:

const FRealSingle MaxAppliedStrain = FMath::Max(Child->CollisionImpulses(), Child->GetExternalStrain());
if ((MaxAppliedStrain >= Child->GetInternalStrains()) || bForceRelease)

Only the first term is affected — externally applied strain still breaks the collection normally.

Confirmed that this exists in latest as well as 5.8 which is the origin or both tickets. This is a regression from 5.7 - although it looks like the guard was not aiming specifically to catch that.

• 5.6 / 5.7 — a plain two-line accessor. It returns the reinterpreted bytes, and GetBoneName null-checks the result (SkinnedMeshComponent.cpp:2241), so garbage-reading-null yields NAME_None. The bug is exercised on every overlap and stays latent.

• 5.8 / FN Main — gained a KnownSkinnedAsset cache-validation block under #if WITH_EDITOR. When the two disagree it calls OutdatedKnownSkinnedAssetDetected(), whose ensureMsgf message arguments dereference the garbage via GetFullName(). That
  dereference has no null-check equivalent, so the latent bad cast becomes a hard crash.

UCharacterMovementComponent::CapsuleTouched casts the overlapped component to USkinnedMeshComponent* with a C-style cast, guarded only by OtherBodyIndex != INDEX_NONE.

Engine/Source/Runtime/Engine/Private/Components/CharacterMovementComponent.cpp:11693

if (OtherComp != NULL && OtherComp->IsAnySimulatingPhysics())
{
    ...
    FName BoneName = NAME_None;
    if (OtherBodyIndex != INDEX_NONE)
    {
        BoneName = ((USkinnedMeshComponent*)OtherComp)->GetBoneName(OtherBodyIndex);   // line 11713
    }

A UGeometryCollectionComponent is not a USkinnedMeshComponent, but it satisfies both guards: it reports IsAnySimulatingPhysics() == true while simulating, and it delivers a per-particle OtherBodyIndex >= 0 rather than INDEX_NONE. The cast is therefore taken on an unrelated type and GetBoneName reads through a garbage SkinnedAsset pointer.

OtherBodyIndex is only meaningful as a bone index for skinned meshes. For a geometry collection it is a particle/transform index and should not be passed to GetBoneName at all.

Call stack:

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION reading address 0x0000000000000012

UCharacterMovementComponent::CapsuleTouched()               CharacterMovementComponent.cpp:11713
USkinnedMeshComponent::GetBoneName()                        SkinnedMeshComponent.cpp:2542
USkinnedMeshComponent::GetSkinnedAsset()                    SkinnedMeshComponent.cpp:2882
USkinnedMeshComponent::OutdatedKnownSkinnedAssetDetected()  SkinnedMeshComponent.cpp:6119
UObjectBaseUtility::GetFullName()                           UObjectBaseUtility.cpp:117

Reached through the ordinary movement path:

UCharacterMovementComponent::TickComponent()
UCharacterMovementComponent::ControlledCharacterMove()
UCharacterMovementComponent::PerformMovement()
FScopedMovementUpdate::~FScopedMovementUpdate()
USceneComponent::UpdateOverlaps()
UPrimitiveComponent::BeginComponentOverlap()
UCharacterMovementComponent::CapsuleTouched()

Original message

The UE5 Interchange GLTF importer appears to truncate skeletal mesh bone influences to a maximum of 4 influences per vertex, even when the source glTF asset contains additional valid JOINTS_n / WEIGHTS_n attribute sets representing more than four influences.

As a result, importing a glTF skeletal mesh through the Interchange GLTF pipeline can produce a skeletal mesh whose skinning data differs from the source asset, with additional bone influences being silently discarded.

Only the first 4 bone influences per vertex are imported. Additional influences present in the source glTF are discarded, resulting in incorrect skinning compared to the original asset.

Flavien reply

Flavien argue that this is what the spec said but the user said I misread the spec

It is the glTF specification that limits mesh bone influences to 4 per vertex. UE is aligned on the format spec.

Where do you get your glTF from? Are you exporting it from a specific DCC?

[Link Removed]

User reply

The glTF spec limits each JOINTS_n / WEIGHTS_n attribute to 4 joints/weights, but it does not necessarily limit a vertex to 4 total influences. Additional influences can be stored in additional attribute sets, for example:

• JOINTS_0 / WEIGHTS_0 → influences 0–3
• JOINTS_1 / WEIGHTS_1 → influences 4–7
• and so on…

The spec explicitly describes this mechanism for vertices influenced by more than four joints.

The asset was exported from Blender 5.2 using its built-in glTF 2.0 exporter.

POST BODY:

• Summary
  An Input Action mapped directly to a Gesture key (e.g. "Pinch", EKeys::Gesture_Pinch)
  keeps firing the Triggered event every frame indefinitely after all fingers are lifted
  from the screen.

Cause:

• In 5.8 the gesture keys became analog (FKeyDetails::Axis1D added in InputCoreTypes.cpp,
  ~line 753); in 5.5 they were Gesture-only, so IsAnalog() was false.
• On release, UPlayerInput::InputGesture stores the last (non-zero) value into RawValue
  instead of 0, and gesture keys lack UpdateAxisWithoutSamples, so RawValue never decays.
• UEnhancedPlayerInput's "analog inputs pulse every non-zero tick" rule then treats the
  stuck RawValue as held every frame, so the default Down behavior stays Triggered.

Fix (any one):

• Zero RawValue on IE_Released in UPlayerInput::InputGesture; or
• Add UpdateAxisWithoutSamples to the gesture keys; or
• Remove Axis1D from the gesture keys (restore 5.5 behavior).

• What Type of Bug are you experiencing?
  Gameplay

• Steps to Reproduce
  1. Input Action IA_Pinch (Axis1D), no Triggers, no Modifiers.
  2. Map it to the "Pinch" gesture key in an IMC.
  3. Log its Triggered / Completed events.
  4. Do a two-finger pinch, then lift all fingers.

• Expected Result
  Triggered stops and Completed fires after release (as in 5.5).

• Observed Result
  Triggered keeps firing every frame forever; Completed never fires.

• Affects Versions
  5.8

• Platform(s)
  Windows

POST AUTHOR: shari_di

CREATED AT: 08/19/2026 07:43 AM EDT

UPDATED AT: 08/20/2026 12:34 AM EDT