Rope stretching a lot when attached to fast-moving body.

[Dissident Dan]

Hi, I have an ObiRope using a PinConstraint to attach to a rigid body. The body moves at about 15 units/second (quick, but not unreasonable IMO). I noticed two things:

1) The pinned particle often lags behind the rigid body and has to catch up once it slows down.
2) The rope stretches out, with big gaps between the particles.
3) The particles exhibit a clustering effect, often with pairs of particles and then the aforementioned gaps in between the pairs.


Questions)
A) The stretch compliance is zero, so this is theoretically as unstretchy as the rope can be. Is there any way to avoid this stretching?
B) I'm thinking that the clustering of the particles must have something to do with the way Obi interacts with FixedUpdate (I'm using 3 substeps in the solver). Is there any way to smooth this out?

In the attached image, the little, grey spheres are the particle positions for the rope. The rope is attached at one end to the small, grey cube on the right side of the image.

[josemendez]

Hi, I have an ObiRope using a PinConstraint to attach to a rigid body. The body moves at about 15 units/second (quick, but not unreasonable IMO). I noticed two things:

1) The pinned particle often lags behind the rigid body and has to catch up once it slows down.
2) The rope stretches out, with big gaps between the particles.
3) The particles exhibit a clustering effect, often with pairs of particles and then the aforementioned gaps in between the pairs.


Questions)
A) The stretch compliance is zero, so this is theoretically as unstretchy as the rope can be. Is there any way to avoid this stretching?
B) I'm thinking that the clustering of the particles must have something to do with the way Obi interacts with FixedUpdate (I'm using 3 substeps in the solver). Is there any way to smooth this out?

In the attached image, the little, grey spheres are the particle positions for the rope. The rope is attached at one end to the small, grey cube on the right side of the image.

Hi Dan,

All 3 points are a fundamental consequence of how iterative solvers work in general:

1) Every frame the rigid body moves, then the rope has to try and catch up with it. Unless you have enough pin constraint iterations, this delay will be noticeable. A pin constraint does not "teleport" the rope to a position (unlike a handle, or if using Obi 5, a static attachment), instead it applied forces to both the particle and the rigidbody, over multiple iterations.

2) Again, this is due to how iterative solvers work. If the solver has not enough time budget (iterations) to get very close to the solution, it will stop as soon as it finishes all iterations, regardless of how close to "perfect" the results are. If you give the solver a larger budget (increasing the max amount of iterations), it will reach a better solution (that is, one closer to a rope with actual zero compliance), but will also spend more time in it.

The "error" remaining when the solver aborts the simulation after a given amount of iterations manifests itself as spurious (unwanted) compliance. In other engines it manifests as jittering or exploding simulations, so in this sense Obi is quite benevolent. If it can't reach a perfect solution given the time constraints, it will settle for a solution that's as good as possible, but still acceptable.

3) This is because constraints are grouped and solved in a fixed order. In the case of ropes, all even constraints are solved first, then all odd constraints(*). This is done because constraints must be solved in multiple threads to maximize performance, and you can't solve two constraints that share a particle in different threads (would lead to a race condition, and crash). This makes odd constraints have slightly more "power" over the final result, as they're solved last. This is not noticeable unless the rope is very overstretched, so you can see this pattern. Switching the distance constraints to parallel mode (in the ObiSolver, right next to the amount of iterations) will completely get rid of this biasing, at the cost of slower convergence (more iterations/substeps needed to achieve the same result).

This page might give you a bit more insight:
http://obi.virtualmethodstudio.com/tutor...gence.html

(*): Btw, this method is known as red-black Gauss-Seidel.

[Dissident Dan]

Hi Dan,

All 3 points are a fundamental consequence of how iterative solvers work in general:

1) Every frame the rigid body moves, then the rope has to try and catch up with it. Unless you have enough pin constraint iterations, this delay will be noticeable. A pin constraint does not "teleport" the rope to a position (unlike a handle, or if using Obi 5, a static attachment), instead it applied forces to both the particle and the rigidbody, over multiple iterations.

2) Again, this is due to how iterative solvers work. If the solver has not enough time budget (iterations) to get very close to the solution, it will stop as soon as it finishes all iterations, regardless of how close to "perfect" the results are. If you give the solver a larger budget (increasing the max amount of iterations), it will reach a better solution (that is, one closer to a rope with actual zero compliance), but will also spend more time in it.

The "error" remaining when the solver aborts the simulation after a given amount of iterations manifests itself as spurious (unwanted) compliance. In other engines it manifests as jittering or exploding simulations, so in this sense Obi is quite benevolent. If it can't reach a perfect solution given the time constraints, it will settle for a solution that's as good as possible, but still acceptable.

3) This is because constraints are grouped and solved in a fixed order. In the case of ropes, all even constraints are solved first, then all odd constraints(*). This is done because constraints must be solved in multiple threads to maximize performance, and you can't solve two constraints that share a particle in different threads (would lead to a race condition, and crash). This makes odd constraints have slightly more "power" over the final result, as they're solved last. This is not noticeable unless the rope is very overstretched, so you can see this pattern. Switching the distance constraints to parallel mode (in the ObiSolver, right next to the amount of iterations) will completely get rid of this biasing, at the cost of slower convergence (more iterations/substeps needed to achieve the same result).

This page might give you a bit more insight:
http://obi.virtualmethodstudio.com/tutor...gence.html

(*): Btw, this method is known as red-black Gauss-Seidel.

Thanks for the detailed explanation!