handles on Obi Rope cause twitching

[khalvr]

Since i switched to using handles on my cords, the rope has started twitching in a very odd way which reminds me of an issue you sometimes get when using a skinned mesh renderer with dynamic batching in Unity. The thing is, dynamic batching is disabled for my project, and it appears that it is the particles themselves who are twitching (see gif). What can i do to fix this? I decided to fall back on ObiRope just for the visuals, but now even that seems to have its issues. 

[attachment=79]

[Semih]

Since i switched to using handles on my cords, the rope has started twitching in a very odd way which reminds me of an issue you sometimes get when using a skinned mesh renderer with dynamic batching in Unity. The thing is, dynamic batching is disabled for my project, and it appears that it is the particles themselves who are twitching (see gif). What can i do to fix this? I decided to fall back on ObiRope just for the visuals, but now even that seems to have its issues. 

Hello! I know this post is two months old but I've found no other thread with the same problem.
I've also started experiencing this issue. I have a rope with two handles, each handle is connected to the top/bottom particles of the rope. I have these handles parented under my player and when I move sideways and look at the rope it twitches at a fixed interval (almost every second). 

Have you found any solution to this?

[josemendez]

Hello! I know this post is two months old but I've found no other thread with the same problem.
I've also started experiencing this issue. I have a rope with two handles, each handle is connected to the top/bottom particles of the rope. I have these handles parented under my player and when I move sideways and look at the rope it twitches at a fixed interval (almost every second). 

Have you found any solution to this?

Hi,

This is a known bug that has been fixed in Obi 3.4, updating should fix it.

kind regards,

[Semih]

Hi,

This is a known bug that has been fixed in Obi 3.4, updating should fix it.

kind regards,

Hi,

I do believe that I have Obi 3.4 as I downloaded the asset yesterday. The twitching seems a bit better when I change to "Late Update" instead of "Fixed Update" in the Obi Solver but the twitching is still very noticeable.
I did notice this in the changelog "- Bug that caused twitching when performing more than 1 physics step per frame when using handles." How can I check if I'm performing more than 1 physics step per frame?
Both of my handles are parented to different game objects and both of those objects are moving via transform translate. Is that OK?

Any ideas on how this can be fixed?

[josemendez]

Hi,

I do believe that I have Obi 3.4 as I downloaded the asset yesterday. The twitching seems a bit better when I change to "Late Update" instead of "Fixed Update" in the Obi Solver but the twitching is still very noticeable.
I did notice this in the changelog "- Bug that caused twitching when performing more than 1 physics step per frame when using handles." How can I check if I'm performing more than 1 physics step per frame?
Both of my handles are parented to different game objects and both of those objects are moving via transform translate. Is that OK?

Any ideas on how this can be fixed?

You can check it by looking at Unity's profiler, to see if there are frames where FixedUpdate is being called multiple times (the amount of times for each function call is one of the columns in the profiler).

If you're still experiencing twitching in 3.4, I'm most certain it is due to a different reason because handles have fundamentally changed. Specially since you mention it happens in LateUpdate too (if it was due to the original bug, it wouldn't happen at all in LateUpdate mode).

Can you share more details on your scene?:
- Does the twitching stop if you disable collisions in the solver?
- Are the rope handles inside the objects they're attached to?

[Semih]

You can check it by looking at Unity's profiler, to see if there are frames where FixedUpdate is being called multiple times (the amount of times for each function call is one of the columns in the profiler).

If you're still experiencing twitching in 3.4, I'm most certain it is due to a different reason because handles have fundamentally changed. Specially since you mention it happens in LateUpdate too (if it was due to the original bug, it wouldn't happen at all in LateUpdate mode).

Can you share more details on your scene?:
- Does the twitching stop if you disable collisions in the solver?
- Are the rope handles inside the objects they're attached to?

My profiler said 1 call per frame.
Ok here is more details.

Here is a screenshot of my Obi Solver settings: https://i.imgur.com/1sWc51W.png As you can see my collision is turned of.
Here is a screenshot of my Obi Rope settings: https://i.imgur.com/eGXZPq0.png

I have a rope that has maybe 20 particles from the beginning. The first particle and last particle has a handle each. So I can set that start and end of the rope via the handles. I have the start handle parented under my player which moves via the CharacterController.Move(..) method. The end handle is just parented to the scene (parent = null) and is moving by a scripts Update method via manipulating its transform position.

When I move around with the character the rope twitches at the start handle (the one parented to the player) but it does not seem to twitch at the end handle. It looks like the rope resets to the start handles position every second or so, almost like it is updating too slow or something.
Does it matter where the actual Obi Rope gameobject is (the one with ObiRope, ObiSolver, MeshRenderer Components)?

Also I have an idea on how to "fix" this. Is it possible for you to help me make the reverse of this function found inside "ObiActor.cs":

Code:

public Vector3 GetParticlePosition(int index)
{
     if (InSolver)
     return solver.renderablePositions[particleIndices[index]];
     else
     return (ActorLocalToWorldMatrix * initialScaleMatrix.inverse).MultiplyPoint3x4(positions[index]);
}

I want to be able to SetParticlePosition(int index, Vector3 newWorldPosition).

This way I can set the start and end particle position without using handles?

[josemendez]

My profiler said 1 call per frame.
Ok here is more details.

Here is a screenshot of my Obi Solver settings: https://i.imgur.com/1sWc51W.png As you can see my collision is turned of.
Here is a screenshot of my Obi Rope settings: https://i.imgur.com/eGXZPq0.png

I have a rope that has maybe 20 particles from the beginning. The first particle and last particle has a handle each. So I can set that start and end of the rope via the handles. I have the start handle parented under my player which moves via the CharacterController.Move(..) method. The end handle is just parented to the scene (parent = null) and is moving by a scripts Update method via manipulating its transform position.

When I move around with the character the rope twitches at the start handle (the one parented to the player) but it does not seem to twitch at the end handle. It looks like the rope resets to the start handles position every second or so, almost like it is updating too slow or something.
Does it matter where the actual Obi Rope gameobject is (the one with ObiRope, ObiSolver, MeshRenderer Components)?

Also I have an idea on how to "fix" this. Is it possible for you to help me make the reverse of this function found inside "ObiActor.cs":

Code:

public Vector3 GetParticlePosition(int index)
{
    if (InSolver)
    return solver.renderablePositions[particleIndices[index]];
    else
    return (ActorLocalToWorldMatrix * initialScaleMatrix.inverse).MultiplyPoint3x4(positions[index]);
}

I want to be able to SetParticlePosition(int index, Vector3 newWorldPosition).

This way I can set the start and end particle position without using handles?

Hi there,

Will try to reproduce this and get back to you asap.

There's Oni.SetParticlePositions(), which is the low-level equivalent of GetParticlePosition() (which is a simple wrapper over Oni.GetParticlePositions(), that returns the position conveniently expressed in world space), but that's already what handles use.

[josemendez]

Hi,

I replicated your scene as you described it, but I'm unable to reproduce the issue. The rope works perfectly smooth for me, using the sample character controller found in the Unity docs (which uses CharacterController.Move()). See the attached video, maybe you spot any difference between your scene and mine?

[Semih]

Hi,

I replicated your scene as you described it, but I'm unable to reproduce the issue. The rope works perfectly smooth for me, using the sample character controller found in the Unity docs (which uses CharacterController.Move()). See the attached video, maybe you spot any difference between your scene and mine?

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

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