Bug / Crash Rope attached to kinematic rigidbody glitching during frame drops

[bgrz_]

Hello,

we've been using Obi Rope in our game successfully for a while now, however we had to stay on v3.2 because of the following problem:



Ropes are pinned to colliders that are children of a kinematic rigidbody that's being moved by updating its transform position. These glitches occur during framerate drops (in this video it was caused by enabling Deep Profile to cause more CPU usage, but can also be simulated by resizing the Game window). When updating from v3.2 to v3.5 the glitching in the video started happening (we skipped a few versions so I don't know which exact release after v3.2 introduced this), and I hoped it'd be fixed in v4.1 but it's unfortunately still there. I've tried all combinations of solver mode + script update mode + script execution order, but I couldn't find a sufficient solution. Solver mode LateUpdate comes closest, it gets rid of the glitches, but causes drooping ropes instead.
Used 2018.3.14f1 with v4.1, and v3.5 update was tried in November on approximately 2018.2.20f1.

Link to reproduction project: https://www.dropbox.com/s/tn2ci6c2gimne6...n.zip?dl=0

Does this look like a bug on Obi Rope's side, or can you suggest a combination of settings or a workaround that we could utilize? I tried removing the `transform.hasChanged` check in `ObiColliderBase`, and adding `Physics.SyncTransforms()` to `ObiSolver.SimulateStep`, but it didn't make a difference.

[bgrz_]

@josemendez any ideas how to overcome this?

[josemendez]

@josemendez any ideas how to overcome this?

Hi there,

I sent you a PM with the solution (at least one that makes sense to me... try it out and report back the results!). It basically involves updating your transform in FixedUpdate(), and the rope in AfterFixedUpdate(), so that things happen in the correct order.

every time Unity decides to update physics:
1.- move the transform
2.- update the rope simulation.

kind regards,

[bgrz_]

Hi there,

I sent you a PM with the solution (at least one that makes sense to me... try it out and report back the results!). It basically involves updating your transform in FixedUpdate(), and the rope in AfterFixedUpdate(), so that things happen in the correct order.

every time Unity decides to update physics:
1.- move the transform
2.- update the rope simulation.

kind regards,

Thanks!

I will try to adapt our code to work that way, although it risks breaking many things. The main reason why I wrote is because it used to work fine in 3.2, and was broken somewhere between 3.2 and 3.5.

[josemendez]

Thanks!

I will try to adapt our code to work that way, although it risks breaking many things. The main reason why I wrote is because it used to work fine in 3.2, and was broken somewhere between 3.2 and 3.5.

Hi!

Could very well have been due to a change in Obi, but also due to the nature of FixedUpdate() (Unity decides when to call it, and how many times, depending on how much time the previous frame took to render) having it working might have been pure luck.  

In case Unity calls FixedUpdate() exactly once per frame, every frame, then you'd experience no jittering at all. This can happen if you cap the frame rate, and your fixed timestep is set to exactly the duration of a frame. This is not always the case, though, so things must be done in a way that does not assume how many times will FixedUpdate() will be called each frame, if at all.

[bgrz_]

Hi!

Could very well have been due to a change in Obi, but also due to the nature of FixedUpdate() (Unity decides when to call it, and how many times, depending on how much time the previous frame took to render) having it working might have been pure luck.  

In case Unity calls FixedUpdate() exactly once per frame, every frame, then you'd experience no jittering at all. This can happen if you cap the frame rate, and your fixed timestep is set to exactly the duration of a frame. This is not always the case, though, so things must be done in a way that does not assume how many times will FixedUpdate() will be called each frame, if at all.

Hi Jose,
setting the solver to "After Fixed Update" and updating the position in FixedUpdate doesn't help (neither `transform.Translate` nor `rigidbody.MovePosition`). Can you please try the linked reproduction project? I have just reimported it in a fresh Unity project in 2018.4.2f1 and it works fine, there is no problem with meta files (I have imported Obi Rope package from Asset Store first, then copied the reproduction project files).

[bgrz_]

After going through the ObiSolver code, I found the suspect, and the reason is pretty stupid, as it always turns out to be

In the example I sent you, the solver component resides on the object that's being moved - if I move the solver to a stationary object, the glitching doesn't happen anymore. Still, it might be something you might want to look into, the problematic setup used to work correctly in older versions.

Edit: of course, unparenting the solver opened the whole other can of worms, and from what it looks like we'll have to stay on 3.2