Chaos Ragdoll Rigid Bodies not Falling Asleep Properly

Development Asset Creation
, ,
21

Hi Geoff, thanks for the reply.

I traced the code a bit and I think I’ve found the issue.

In

void FPBDIslandManager::ProcessSleep(const FRealSingle Dt)It will only process island sleep if Island->Flags.bIsSleepAllowed is set to true, which it does every frame with this comment:

// This gets set to false again next tick if there are moving kinematics in the island Island->Flags.bIsSleepAllowed = true;Next in here:

void FPBDIslandManager::UpdateGraphNode(FPBDIslandParticle* Node)It looks like it will not allow the island to sleep if the particle is moving. This is the test to determine if the particle is moving:

bool IsParticleMoving(const FGeometryParticleHandle* Particle)It looks like there are a few kinematic spheres in position mode (I don’t know what they are to be honest, as they are not associated with any bone and the debug names are empty)

And to check if the sphere is moving it checks if the delta between the target and the particle position is non-zero:

// For kinematic particles check whether their current mode and target will cause the particle to move // For all other modes (Velocity, None and Reset) check that the velocity is non-zero const FKinematicGeometryParticleHandle* Kinematic = Particle->CastToKinematicParticle(); const FKinematicTarget& KinematicTarget = Kinematic->KinematicTarget(); if (KinematicTarget.GetMode() == EKinematicTargetMode::Position) { bIsStationary = (Kinematic->GetX() - KinematicTarget.GetPosition()).IsZero() && (Kinematic->GetRf() * KinematicTarget.GetRotation().Inverse()).IsIdentity(); } else { bIsStationary = Kinematic->GetV().IsZero() && Kinematic->GetW().IsZero(); }These spheres then prevent the entire island to go to sleep. I double checked the actual delta and it looks very small. Perhaps we just need some sort of threshold here?

Kind regards,

Ben

22

That is strange about the spheres. I’ve tried your repro project and I can’t see any ragdoll effects. It seems to be playing a level sequence. If you could let me know where to find the ragdoll effect example you are using I can take a look.

I’d be wary of altering that code - essentially that just masks a problem at engine level. I’d be more curious what those spheres are (I don’t have that when I try in a local example), and why they aren’t the same as the target - what is stopping that from happening?

I’d also be curious if you start with a vanilla project, and try the physics asset for the default manny, whether you’d find the same as me - ie it sleeps as expected

23

Hi Geoff,

I found the source for those spheres, they seem to be constraints created by the Physical Animation Component. Which explains why you are having trouble seeing it in game for you. We have it enabled for our in-game characters, the dummy character in the in physics asset editor has it as well.

The spheres are created here:

void UPhysicalAnimationComponent::UpdatePhysicsEngineImp()I tried adding a bit of epsilon for the position test but it would simply accumulate enough errors before waking up again.

My current working theory is that the Physical Animation Component is accumulating really small errors in the kinematic target it generates, causing the constraints to never fall asleep.

24

Aha! Okay I’d need to see a repro, but this could be that the PhysicalAnimationComponent is applying forces on top of the ragdoll simulation, adding another level of things fighting for convergence. This could lead to what you are seeing. Why is this enabled when the character is ragdolling though?

25

Hi Geoff,

Physical Animation Component is the out-of-the-box solution for motorised ragdolls, we use it to produce a smoother transition into full ragdoll by manipulating the motor strength.

You can reproduce the bug with the dummy character in the physics viewer which also has physical animation component…what’s strange is that even with no active physical animation profile selected (motor strength of 0) i am still seeing the jittering, which would indicate that kinematic targets are still constantly moving (albeit by a vary minor amount).

26

Hi Benjamin,

I see, can you send this as a repro exactly how you have it set up.

I can completely see the use case for this, but when the full ragdoll is blended in - for me this shouldn’t have any constraints from this component. I’d like to see if they are finding their way to the solver.

Thanks

Geoff

27

Hi Geoff,

Frustratingly I tried following the same set up in vanilla engine but I am not able to observe the same jitteriness we see in our own project. I also don’t have the source downloaded so I can’t really confirm if the island has actually gone to sleep in the debugger.

In any case I have zipped up a new version of the test project, once you load up the level press the P key to start ragdoll.

Here’s a summery of the setup:

  • In the physics asset (PA_Mannequin) I’ve added a new physical animation profile called ‘Test’
  • The player character now has a Physical Animation Component
    • The Physical Animation Component is linked to the Skeletal Mesh Component on the begin play event.
  • When the ‘P’ Key is pressed:
    • Enable simulation for all bodies below pelvis
    • Set blend weight for all bodies below pelvis to 1.0
    • Activate the ‘Test’ profile on the physical animation component.
    • Set the strength to 0 so it should have no effect.

Kind regards,

Ben

28

Hi Benjamin,

Thank you for the repro - that helps a lot. I’ve had both Jittery cases and settled cases in the example… but even stationary and what looks to be settled it isn’t sleeping. As a quick helper - we have an awesome tool called Chaos Visual Debugger which you can use to check most physics things. Chaos Visual Debugger - User Guide for UE 5.4 | Tutorial

I’m going to check what is happening at the core level and see why the kinematic side isn’t converging

Geoff

29

Hi Benjamin,

I’ve taken a look into this, and the issue in this case is the interaction from the Physical Animation Component, and the Physics Engine was at fault. Essentially the Kinematic Target type is reset each tick, and it is designed to go through a multi tick stage process which isn’t happening. The simplest, and likely default way of using this is to add an extra node to your blueprint to set the SkeletalMesh to a nullptr as in the picture attached. This then stops the per tick update from the PAC and the character will then go to sleep.

[Image Removed]If you can try this and confirm it works on your end that’d be much appreciated.

All the best

Geoff

30

Hi Geoff, I can confirm that clearing out unlinking the skeletal mesh from the physical animation component does fix the issue and the physics bodies are going to sleep as expected, I think as a stopgap fix this will be good for now, thanks for all the help!

31

My pleasure Benjamin,

I’ll reach out to the devs and find out if this is expected - I’ve seen this used for example to move a character in a vehicle sim, so it may not be designed to switch off unless this is reset by the method above - it could be a good old fashioned bug :smiley:

All the best

Geoff