handles on Obi Rope cause twitching

[josemendez]

The video seems to replicate my example. Of course my scene is more complex but my explanation and your video is basically doing what is happening in my game scene.
I've managed to figure out that it does not occur in a standalone version of the game. The twitching is gone in standalone but is still there in the editor (which is fine for now) but now the handle seems to lag behind the object it is supposed to follow, maybe this has to do with it being in LateUpdate?
Should I have the solver use FixedUpdate or LateUpdate? I'm not really sure.

This is a video of me rotating the character around with the mouse and both the start and end handles are parented to the player.
https://drive.google.com/file/d/1wxAzr2T...cQFH4/view

I've also noticed that when changing the length of the rope in runtime sometimes causes errors. Maybe this can be a related issue?
The errors occurs when calling ObiRopeCursor.ChangeLength here:
ObiRopeCursor.cs In RemoveParticles() and AddParticles() methods because "bendingBatch" variable is null.

bendingBatch.SetParticleIndex(constraint - 1, distanceBatch.springIndices[hotConstraint * 2 + 1], ObiBendConstraintBatch.BendIndexType.Second, rope.Closed);
bendingBatch.SetParticleIndex(hotConstraint, distanceBatch.springIndices[constraint * 2], ObiBendConstraintBatch.BendIndexType.First, rope.Closed);

This is what I use to change length and UV at runtime:
https://i.imgur.com/PCH7mSI.png

Amazing Support btw! I really do appreciate all your help so far

Hi,

After watching your video and seeing the specific kind of jerkiness that is happening, I quickly understood the cause. You need to be very careful with the order in which things happen during your frame if you need frame-perfect motion, you also need to understand how and when is FixedUpdate() called.

Unity uses fixed-timestep physics. This means FixedUpdate is called 0,1,2..n times per frame, but the same amount of time passes between calls. Some frames it might not be called at all, some frames it might be called multiple times, depending on how much unsimulated time has been accumulated since the last frame (since rendering takes a different amount of time every frame).

What is happening here is that your character is being updated in Update(), but the rope is being updated in FixedUpdate(). So there's always a 1-frame delay, and sometimes more if FixedUpdate is called less often. If you build a standalone version (which generally yields much better performance than running in the editor) you ensure more consistent calls to FixedUpdate, and this mitigates the issue. You want this sequence of events to happen, in this precise order every frame:

- The character moves.
- The handle updates the pinned particles.
- The rope is simulated.

And you want them to happen in FixedUpdate(). So the solution in your case would be:

- Update the character in FixedUpdate() (this is a must for 100% accurate interaction, since you want character movement to happen right before physics, every frame)
- And set the ObiSolver update mode to AfterFixedUpdate, so that the solver is updated AFTER the character.