(18-02-2020, 08:50 PM)Elastic Sea Wrote: When I make the fixed timestamp shorter the rope starts behaving erratically and moves faster and faster. Do I have to keep the timestamp on 0.02?
Opening the sample scene with the crane can cause this, please take a look at this video
https://imgur.com/a/cGSBigv
Unity 2019.3.1f1
Obi Rope 5.1
Constraints are grouped into batches and then solved in a certain order, to ensure maximum parallelization (and performance). In particular, all distance constraints are solved first, then all collision constraints. This ordering however introduces some bias in the results, that can cause a force-feedback loop in some situations.
The crane example has the perfect conditions for this to happen: when the timestep is very low, higher constraint stiffness can be reached. This causes the rope's
bending constraints to become stiffer, causing the rope to whip outwards. This whipping motion causes the box to rotate upwards and collide with the rope itself, which causes a whip motion in the opposite direction (and increases energy in the system, because the pin constraint that keeps the box and the rope together and the contact constraint fight each other as described here:
http://obi.virtualmethodstudio.com/tutor...aints.html).
This whip/collision-whip/collision feedback loop steadily increases the energy in the system.
Solutions:
- Select the rope, and move the second-to-last control point higher. This will ensure the end of the rope does not collide with the box when it moves around, avoiding the feedback loop altogether. This is the ideal fix.
- Disable bending constraints, or at least reduce their stiffness/increase max bending. This will prevent the rope from "whipping" out, causing the box to hit it constantly, again preventing the feedback loop.
- Increase the box mass, 5 kg for instance. This will cause more energy dissipation (that is, slow convergence down). Enough to compensate for the extra energy introduced by the feedback loop, but won't eliminate the loop.