Ragdoll character passing through rope unless thickness is increased

[Milionario]

Hi,

There's a few problems going on in the scene:

- Your rope's stretching scale is set to zero. This will try and force the rope to collapse to a point, since any length x 0 = 0. This will cause collision constraints to work worse since the rope's primary goal is to set its length to zero. Typically, you always want the stretching scale to be 1, and only increase or decrease it to scale the length. If you want the rope to be stretchy, increase stretch compliance instead.

- All rigidbodies in the ragdoll weight 5 kg, so the total mass of the ragdoll is 75 kg.  Rope mass should be at least 7.5 kg per particle to keep a reasonable mass ratio (1:10) and withstand the ragdoll's weight under normal gravity acceleration.

- Rope simulation is being updated 4 times per frame (4 substeps in the ObiFixedUpdater), but rigidbody physics are only updated once at most. The result is that rigidbodies react very late to forces applied by the rope, and these do not propagate fast enough trough joints. The solution is to decrease your physics timestep to increase the frequency at which rigidbody physics is updated, and reduce the amount of substeps accordingly. This ensures that the rope and the rigidbodies are updated in sync, and that forces propagate fast enough trough all constraint trees.

These are the settings I tweaked:
- Set stretching scale to 1.
- Set substeps in ObiFixedUpdater to 1 (could use 2 if you want more stretch-resistant rope)
- Set rope blueprint resolution to 0.5.
- Set rope's mass to 10 for both control points.
- Set Unity's fixed timestep to 0.005 (that is, 0.02/4, which yields the same update frequency for ropes as 4 substeps, but also updates rigidbodies in sync).

With these settings, I can drop the ragdoll from very far above the rope and it reacts properly without any penetration.

let me know if you need further help,

kind regards

Tried your suggestions but the only thing that seemed to matter is to change the unity's timestep, unfortunately I can't do that because the 3rd party libraries i am using do not play well with other than default timesteps..

I find it strange that dropping a normal cube on this rope yields the expected results, and a ragdoll doesnt??

If I use two cubes with a fixed joint, i have the same tunneling effect.. not as easy but happens

https://youtu.be/FkjiB7hpigE

[josemendez]

Tried your suggestions but the only thing that seemed to matter is to change the unity's timestep, unfortunately I can't do that because the 3rd party libraries i am using do not play well with other than default timesteps..

I find it strange that dropping a normal cube on this rope yields the expected results, and a ragdoll doesnt??

If I use two cubes with a fixed joint, i have the same tunneling effect.. not as easy but happens

https://youtu.be/FkjiB7hpigE

This is completely normal, as far as how iterative physics engines work. Basically, every body involved in the simulation is simulated independently. Then, joints (aka constraints) adjust the body positions/velocities so that they meet certain conditions, such as making sure their relative rotations or positions are fixed. However this is done iteratively since a single joint can only correct the position of a couple of bodies. So over multiple iterations, these corrections are propagated to adjacent bodies.

So when the rope and the torso meet, the rope applies a force to the torso so that the rope and the torso end up just touching each other at the end of the frame. However, all other body parts aren’t aware of this force until a frame has passed by and the physics joints have had a chance to run, and notice the torso is in a position higher than it would otherwise be and pull it down.

Now, ideally if Obi and Unity’s physics engine were the same engine, it would be enough to use more iterations to propagate forces trough all bodies. Unfortunately they’re two separate engines running in an interleaved fashion, using forces to interact with each other. So the only possible way to propagate corrections quicker to all rigidbodies in a joint hierarchy is to run both engines more often, hence why:

- lowering the global timestep and using only 1 substep for particles works,
- the less rigidbodies involved in a ragdoll, the sooner forces are propagated and the better it behaves.
- a single cube works fine regardless of the timestep length (since it doesnt have any other bodies constrained to it that would need to have forces/impulses propagated to)

If you want fully accurate interplay of ragdolls and rope-like structures using long timesteps, my advice would be to use articulations. A reduced-coordinate sim will work much better, although with some limitations: no compliant materials, no loops in the body hierarchy, and higher runtime cost.

[Milionario]

This is completely normal, as far as how iterative physics engines work. Basically, every body involved in the simulation is simulated independently. Then, joints (aka constraints) adjust the body positions/velocities so that they meet certain conditions, such as making sure relative rotations or positions are fixed. However this is done iteratively since a single joint can only correct the position of a couple of bodies. So over multiple iterations, these corrections are propagated to adjacent bodies.

So when the rope and the torso meet, the rope applies a force to the torso so that the rope and the torso end up just touching each other at the end of the frame. However, all other body parts aren’t aware of this force until a frame has passed by and the physics joints have had a chance to run, and notice the torso is in a position higher than it would otherwise be.

Now, ideally if Obi and Unity’s physics engine were the same engine, it would be enough to use more iterations to propagate forces trough all bodies. Unfortunately they’re two separate engines running in an interleaved fashion, using forces to interact with each other. So the only possible way to propagate corrections quicker to all rigidbodies in a joint hierarchy is to run both engines more often, hence why:

- lowering the global timestep and using only 1 substep for particles works,
- the less rigidbodies involved in a ragdoll, the sooner forces are propagated and the better it behaves.
- a single cube works fine regardless of the timestep length (since it doesnt have any other bodies constrained to it that would need to have forces/impulses propagated to)

If you want fully accurate interplay of ragdolls and rope-like structures using long timesteps, my advice would be to use articulations. A reduced-coordinate sim will work much better, although with some limitations: no compliant materials, no loops in the body hierarchy, and higher runtime cost.

So this is more of a rigidbodies + joints problem than it is solely with the ragdoll

[josemendez]

So this is more of a rigidbodies + joints problem than it is solely with the ragdoll

Correct, any joint hierarchy will have this problem in any iterative engine. Ragdolls are just a particular case, they aren’t any different from other joint hierarchies.

If you’re ever tried to stack boxes in any physics engine -contacts are just a particular type of joint, that gets created/destroyed at runtime-, you know these tend to sink into each other and the stack becomes unstable unless you use a small timestep (and a plethora of tricks like shock propagation or mass splitting). This gets worse the more boxes you stack, but a single box will never have any issues by itself. All iterative engines suffer from the same or similar issues, since it’s inherent to how they work.

The only ways to propagate forces trough a hierarchy of constraints instantly are to use a reduced coordinates approach (ABA/Featherstone’s algorithm) or use a direct solver, and both are expensive enough that lowering the timestep of an iterative engine is often cheaper.

[Milionario]

Correct, any joint hierarchy will have this problem in any iterative engine. Ragdolls are just a particular case, they aren’t any different from other joint hierarchies.

If you’re ever tried to stack boxes in any physics engine -contacts are just a particular type of joint, that gets created/destroyed at runtime-, you know these tend to sink into each other and the stack becomes unstable unless you use a small timestep (and a plethora of tricks like shock propagation or mass splitting). This gets worse the more boxes you stack, but a single box will never have any issues by itself. All iterative engines suffer from the same or similar issues, since it’s inherent to how they work.

The only ways to propagate forces trough a hierarchy of constraints instantly are to use a reduced coordinates approach (ABA/Featherstone’s algorithm) or use a direct solver, and both are expensive enough that lowering the timestep of an iterative engine is often cheaper.

Do you think its possible to get the desired result without changing ObiColliders thickness and reducing the Unity's fixed timestep?

[josemendez]

Do you think its possible to get the desired result without changing ObiColliders thickness and reducing the Unity's fixed timestep?

Unfortunately not. The correct fix in this situation is to reduce Unity's fixed timestep, changing the thickness of the colliders is a sort of "hack" that allows the rope and the colliders to stay colliding with each other for more frames which ensures enough physics steps take place for the forces to propagate trough all joints in the ragdoll. Using more physics steps (by reducing the timestep) propagates forces in the same amount of time without the need to enlarge colliders.

I'm curious as to why you mentioned other packages you use don't work correctly unless you use the default timestep. I mean, timestep size is a parameter and it's meant to be tweaked, the default value of 0.02 (an update frequency of 50 Hz) is seldom sufficient unless physics in your game are quite simple. In some cases, you can get away by increasing the update frequency of Obi alone (by using more substeps) but this isn't one of those cases.

kind regards,