This question was created in reference to: [Weird overlap detection for [Content removed]
Hello. We’ve recently run into an issue VERY similar to the issue detailed in [Weird overlap detection for [Content removed] We are getting unexpected OnOverlapEnd triggers despite our character not leaving the stationary volume. We have only been able to repro while our character was in motion and likely in root motions, similar to the referenced issue. Was this issue ever resolved? I see Geoff Stacey say that it could get a JIRA task in the previous thread.
[Attachment Removed]
HI Alex, please see this thread which should contain the information you are looking for.
[Content removed]
Best
Geoff
[Attachment Removed]
Hey Geoff. Thanks for the response. I looked into the code, but we already have those changes, and we’re notably on 5.6. Here’s some additional notes we’ve been able to figure out as we’ve been testing more:
- This doesn’t repro super consistently, as in, we haven’t been able to repro using a specific movement, but we’ve only been able to repro while animating with root motion
- The bug never repros while our character is idle
- We haven’t been able to repro in editor or on Steam, only on PS5
- Below is what the callstack looks like when our volume is unexpectedly triggering an overlap end with our character
- We’ve checked the location of our character’s overlapping primitive component at this breakpoint and it looks expected
eboot.bin!AEncounterVolume::NativeOnEndOverlap(AActor* OverlappedActor, AActor* Other) Line 222 + 17 bytes C++
eboot.bin!AEncounterVolume::execNativeOnEndOverlap(UObject* Context, FFrame& Stack, void* const Z_Param__Result) Line 580 + 9 bytes C++
eboot.bin!UFunction::Invoke(UObject* Obj, FFrame& Stack, void* const Z_Param__Result) Line 7465 C++
eboot.bin!UObject::ProcessEvent(UFunction* Function, void* Parms) Line 2220 C++
eboot.bin!AActor::ProcessEvent(UFunction* Function, void* Parameters) Line 1462 C++
eboot.bin![Inline Function] TScriptDelegate<FNotThreadSafeNotCheckedDelegateMode>::ProcessDelegate<UObject>(void* Parameters) Line 458 + 22 bytes C++
eboot.bin!TMulticastScriptDelegate<FNotThreadSafeDelegateMode>::ProcessMulticastDelegate<UObject>(void* Parameters) Line 934 C++
eboot.bin!FComponentWakeSignature_DelegateWrapper(const FMulticastScriptDelegate& ComponentWakeSignature, UPrimitiveComponent* WakingComponent, FName BoneName) Line 792 + 5 bytes C++
eboot.bin!TSparseDynamicDelegate<FActorEndOverlapSignature_MCSignature,AActor,FActorEndOverlapSignatureInfoGetter>::Broadcast<AActor*,AActor*>(AActor* Params, AActor* Params) Line 331 C++
eboot.bin!UPrimitiveComponent::EndComponentOverlap(const FOverlapInfo& OtherOverlap, bool bDoNotifies, bool bSkipNotifySelf) Line 4040 + 18 bytes C++
eboot.bin!UPrimitiveComponent::UpdateOverlapsImpl(const TOverlapArrayView* NewPendingOverlaps, bool bDoNotifies, const TOverlapArrayView* OverlapsAtEndLocation) Line 4411 C++
eboot.bin!USceneComponent::UpdateOverlaps(const TOverlapArrayView* PendingOverlaps, bool bDoNotifies, const TOverlapArrayView* OverlapsAtEndLocation) Line 1062 + 19 bytes C++
eboot.bin!USceneComponent::EndScopedMovementUpdate(FScopedMovementUpdate& CompletedScope) Line 1274 C++
eboot.bin!FScopedMovementUpdate::~FScopedMovementUpdate() Line 79 C++
eboot.bin!UCharacterMovementComponent::PerformMovement(float DeltaSeconds) Line 3002 + 5 bytes C++
eboot.bin!UCharacterMovementComponent::ControlledCharacterMove(const FVector& InputVector, float DeltaSeconds) Line 6282 C++
eboot.bin!UCharacterMovementComponent::TickComponent(float DeltaTime, enum ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction) Line 1707 C++
eboot.bin!FActorComponentTickFunction::ExecuteTick(float DeltaTime, enum ELevelTick TickType, enum ENamedThreads::Type CurrentThread, const FGraphEventRef& MyCompletionGraphEvent) Line 1587 C++
eboot.bin![Inline Function] FTickFunctionTask::DoTask(enum ENamedThreads::Type CurrentThread, const FGraphEventRef& MyCompletionGraphEvent) Line 347 C++
eboot.bin!TGraphTask<FTickFunctionTask>::ExecuteTask() Line 706 C++
eboot.bin!UE::Tasks::Private::FTaskBase::TryExecuteTask() Line 528 C++
eboot.bin![Inline Function] FBaseGraphTask::Execute(bool bDeleteOnCompletion) Line 506 C++
eboot.bin![Inline Function] FNamedTaskThread::ProcessTasksNamedThread(int32 QueueIndex, bool bAllowStall) Line 779 C++
eboot.bin!FNamedTaskThread::ProcessTasksUntilIdle(int32 QueueIndex) Line 678 C++
eboot.bin!FTaskGraphCompatibilityImplementation::ProcessUntilTasksComplete(const FGraphEventArray& Tasks, enum ENamedThreads::Type CurrentThreadIfKnown, const FTaskGraphInterface::FProcessTasksUpdateCallback& IdleWorkUpdate) Line 1592 C++
eboot.bin!FTickTaskSequencer::ReleaseTickGroup(enum ETickingGroup WorldTickGroup, bool bBlockTillComplete, TArray<FTickFunction*,TSizedDefaultAllocator<32>>& TicksToManualDispatch) Line 986 C++
eboot.bin!FTickTaskManager::RunTickGroup(enum ETickingGroup Group, bool bBlockTillComplete) Line 2079 C++
eboot.bin![Inline Function] UWorld::RunTickGroup(enum ETickingGroup Group, bool bBlockTillComplete) Line 786 C++
eboot.bin!UWorld::Tick(enum ELevelTick TickType, float DeltaSeconds) Line 1515 C++
eboot.bin!UGameEngine::Tick(float DeltaSeconds, bool bIdleMode) Line 1926 C++
eboot.bin!FEngineLoop::Tick() Line 5625 C++
eboot.bin!MainFunc(void* ArgsPtr) Line 316 C++
libkernel.sprx!0x0000000826F5358D (Module: 0x0000000826F4C000 + 30093 bytes) C++
[Attachment Removed]
Important update!
I have some corrections for some of my previous assumptions. I’ve found a specific repro, and it looks to be very locational-based. I am able to repro by using a specific location (rotation doesn’t matter) in a volume I was able to record that location for. Doing minute movements near that location triggers the overlap end and my logs show that the location is never exact and can be off by < 10 units. Moving quickly through that location repros as well. It’s almost as if this volume has a “gap”. This volume in particular also has at least one more location that triggers the overlap end and also repros consistently. This volume was also in a different level than the ones I was experimenting with previously, so it’s not isolated to this one volume.
03:34:47 OVERLAPDEBUG LOCATION: [-14725.244286, -441.534733, -1124.102906]
03:34:47 OVERLAPDEBUG HEX LOCATION: [c0ccc29f44c337d2, c07b988e43ab7b67, c0919069604ba5f5]
03:34:47 OVERLAPDEBUG LOCATION: [-14725.685395, -442.325842, -1123.937311]
03:34:47 OVERLAPDEBUG HEX LOCATION: [c0ccc2d7bb0a1d89, c07ba536a6282376, c0918fbfce53d61a]
03:34:47 OVERLAPDEBUG LOCATION: [-14726.592553, -443.952787, -1123.596757]
03:34:47 OVERLAPDEBUG HEX LOCATION: [c0ccc34bd8c5b1c2, c07bbf3e9d73528f, c0918e63143079c4]
03:34:51 OVERLAPDEBUG LOCATION: [-14726.549791, -443.876096, -1123.612810]
03:34:51 OVERLAPDEBUG HEX LOCATION: [c0ccc3465f8dcbfe, c07bbe047ccc9241, c0918e738469f9d5]
03:34:51 OVERLAPDEBUG LOCATION: [-14718.355206, -429.179486, -1126.689120]
03:34:51 OVERLAPDEBUG HEX LOCATION: [c0ccbf2d7765f5cb, c07ad2df2d1f698c, c0919ac1a89673f1]
I still don’t want to rule out that the bug is related to animation since this overlap end trigger still only happens on movement.
[Attachment Removed]
Hi Alexander,
This could be a floating point accuracy issue, or an asset setup one (or even an animation issue - but that is the less likely since the animation feeds into the physics and it’d affect the input, not the result).
I’d suggest a few different things:
1) Are you able to try this on the latest version of UE - we tend to have floating point fixes added between versions, so this may in fact already be addressed.
2) Are you able to reproduce this in an example made using a vanilla version of UE 5.6? If so we can take a look at it first hand.
Best
Geoff
[Attachment Removed]
Thanks for the response Geoff. For 1, we are working on getting 5.7 merged in sometime next month. In lieu of approach 2, I’d like to keep digging to understand where this could be happening in the code and where the branch in behaviors in the code could be happening. Would you be able to point us to code that would have changed between 5.6 and 5.7 that would have resolved float point fixes, especially in regards to collision or anything platform-specific?
[Attachment Removed]
So another update on the digging we’ve done. We looked into a few other UE CLs to try and see if our issue will be fixed in 5.7. We’ve tried:
- 41496021: Fix EPA bug on PS5
- 44626661: Fixed a small bug in GJK with a deep initial overlap. The margin was not appropriately accounted for after EPA
- 47159317: BoxOverlapActors failed to catch an overlapped actor with a particular scale, from a particular position
- 46591684: Fix intersects comparing squared with non-squared in Sphere.h
and no luck with our reproduction case. To provide more context on our repro case: we have a general location in which we have 7 volumes that are expected to encompass a character. We have a specific location within those 7 volumes that, when we teleport our character to that location from any other location within those 7 volumes, one of those volumes ends overlap from the teleport, and begins overlap again on the frame following the teleport. This can happen with other volumes in this level and with other volumes in another level. We also can’t guarantee that this is an issue specific to this class of volume; this class of volume just has a very obvious overlap end behavior.
[Attachment Removed]
Thanks Alex,
What is the reason for not being able to provide the repro? Would it help if we made the ticket private? Otherwise we are just going to be speculating about a huge number of different possibilities.
Best
Geoff
[Attachment Removed]
Sorry, not trying to be vague for privacy’s sake even. It’s mainly that this bug has been very cumbersome to reproduce at all, and it’s not been worth for it for us to try repro in a new project/fresh sandbox because we’ve only been able to find it occurring by randomly walking in volumes. It’s not something that we can even guarantee that we can repro manually. The only reason we have a consistent repro is because we’ve recorded a few locations in our existing setup.
I guess we will just have to route back to see if the repro is still occurring once we can merge 5.7.
[Attachment Removed]
Hi Alex, no worries at all. An alternate could be if you can send a ChaosVisualDebugger trace across which shows the issue we may be able to spot something in that.
Best
Geoff
[Attachment Removed]