Sequencer sometimes causes collision to be left behind when animating transform of an actor

Development Character & Animation
, ,
1

We’ve been having an issue for a long time where using a sequencer to animate the transform of an actor will sometimes cause the actor’s collision to be left behind or fail to update or something along those lines. This happens in local and multiplayer scenarios, and the only hint that I currently have on how to repro it is that it sometimes becomes easier to repro when running at a lower frame rate.

We currently have no known fix for this issue other than adding an extra keyframe at the start/end of the sequence to “wiggle” the position of the actor, which seems to force it to do an update and keep the collision working. It has to be added to the start or end depending on the situation.

Does this sound like any known issues? Unfortunately I don’t have any repro or sample project to give you, I’m mainly just looking to find out if this is known and maybe also potentially fixed in a newer UE version since we haven’t upgraded p

[Attachment Removed]

2

I can add some bits of info to Justin’s post that I figured out today. The case I was debugging was a level sequence brought to end-state via GoToEndAndStop and collision for a handful of actors didn’t work, even though show collision and chaos visual debugger displayed the shapes where they’re supposed to be. (Idk if it matters, but the actors in question where attached actors.)

After trying to force the sequencer to use ETeleportType::ResetPhysics in its SetComponentTranslationAndRotation and SetComponentTransform wrappers, the collision worked. So I reverted back to not setting it and then looked down the execution path of what ResetPhysics causes to execute differently.

I managed to narrow it down to this in BodyInstance::SetBodyTransform

if(bIsSimKinematic && Teleport == ETeleportType::None)
				{
					Scene->SetKinematicTarget_AssumesLocked(this, NewTransform, true);
				}
				else
				{
					// todo(chaos): Calling SetKinematicTarget_AssumesLocked before SetGlobalPose_AssumesLocked is unnessary for chaos. We should fix this when PhysX is removed.
					if(bIsSimKinematic)
					{
						FPhysicsInterface::SetKinematicTarget_AssumesLocked(Actor, NewTransform);
					}
 
					FPhysicsInterface::SetGlobalPose_AssumesLocked(Actor, NewTransform);
				}

With teleport mode None it ends up calling only FPhysicsInterface::SetKinematicTarget_AssumesLocked, whereas with ResetPhysics it calls SetGlobalPose_AssumesLocked after it (which does SetX/SetR with invalidation enabled).

I then went into FPhysicsInterface::SetKinematicTarget_AssumesLocked and changed the ‘false’ passed to SetX and SetR to be true instead, and that fixed the collision bug.

So while SetKinematicTarget_AssumesLocked claims

// IMPORTANT : we do not invalidate X and R as they will be properly computed using the kinematic target informationIt appears, at least when using GoToEndAndStop with a sequence, that it’s not correct that it will always be computed properly.

Edit: While results where consistent multiple editor restarts and testing with and without the workaround, I now got back some results from packaged testing and it seems the bug might still be there. Will investigate if it actually was applying the workaround there or not.

Edit2: Ignore my edit above. Turns out I made a mistake so the workaround was never active in the packaged test. (Verified again in PIE that the workaround works, another package test will be on monday.)

Edit3: yeah, workaround worked in package as well, so the original findings seem good. (I can add that framerate and/or substepping settings appear to also affect whether collision breaks. Maybe something in how kinematic target applies is affected by those timings.)

[Attachment Removed]

3

Another addition. Given the findings, I suspected this might apply to any similar kinematic transform update and not only ones from level sequences. I just got a confirmation on that. We had another an actor restore save orientation of a component on beginplay that exhibited the same collision issues. In this case the component transform update came from a BP, setting Teleport to true there fixed the issue (as that also sidesteps the “Teleport == ETeleportType::None” case in SetBodyTransform).

[Attachment Removed]

4

Hi folks, and apologies for the delay. Looking at the latest version of the code, there is an explicit call to updated the broadphase. Is this in your code (the call on 2611?) If not then yes it has been updated since 5.4 and should go away on updating to latest.

[Image Removed]

[Attachment Removed]

5

Understood. The quick answer is that we did have some tickets a few years ago around this, but I haven’t seen anything in the newer versions for a while. I’d suspect there is a fix somewhere in the call path, but the one I sent was the most obvious (ie the explicit update in the broadpahse).

However - if I am completely incorrect and it does persist when you move versions, please open a ticket and we can investigate!

Best

Geoff

[Attachment Removed]

6

Hmm I’m not sure. Do you mean line 2611 inside of SetBodyTransform in BodyyInstance.cpp? I don’t see anything relevant to that screenshot you posted so I guess not? [Image Removed]

[Attachment Removed]

7

Ah - no this is in the called function ( SetKinematicTarget_AssumesLocked) not that one. It explicitly updates the physics body using Scene->UpdateActorInAccelerationStructure.

[Attachment Removed]

8

Ah ok. It looks the same as your screenshot.

[Attachment Removed]