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

[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!