Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
handles on Obi Rope cause twitching
#11
(11-04-2018, 09:15 PM)josemendez Wrote: 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.


Hello!
I've changed my movement and mouselook code to use fixed update and fixed delta time. I've also set the solver to use AfterFixedUpdate and the handle does not seem to lag behind anymore Sonrisa
However... the twitching is still happening at a set interval and is also not visible when running a standalone at 60 fps. I tried locking it to 30 fps int the standalone version and the twitching is then visible.

Here is a video of how it looks when I play in the editor. As you can see the handles are not lagging behind anymore but the rope is still twitching when I run sideways and look at the rope. I'm not really sure what else I can do right now :/
https://drive.google.com/file/d/1btCQsjz...9dQUU/view

Sorry for being a pain in the ass about this...
Reply
#12
(13-04-2018, 01:13 PM)Semih Wrote: Hello!
I've changed my movement and mouselook code to use fixed update and fixed delta time. I've also set the solver to use AfterFixedUpdate and the handle does not seem to lag behind anymore Sonrisa
However... the twitching is still happening at a set interval and is also not visible when running a standalone at 60 fps. I tried locking it to 30 fps int the standalone version and the twitching is then visible.

Here is a video of how it looks when I play in the editor. As you can see the handles are not lagging behind anymore but the rope is still twitching when I run sideways and look at the rope. I'm not really sure what else I can do right now :/
https://drive.google.com/file/d/1btCQsjz...9dQUU/view

Sorry for being a pain in the ass about this...

Hi,

In the video, the framerate itself seems to have huge spikes at fixed intervals, as the camera movement is very jerky too. This will of course cause physics to have hiccups (specially if you hit max fixed timestep), as the time passed since the last Update for a "hiccuped" frame is much higher than for regular frames.

Take a look at your profiler to see what's causing these spikes. Given the periodicity, I guess it could be GC.
Reply
#13
(13-04-2018, 01:28 PM)josemendez Wrote: Hi,

In the video, the framerate itself seems to have huge spikes at fixed intervals, as the camera movement is very jerky too. This will of course cause physics to have hiccups (specially if you hit max fixed timestep), as the time passed since the last Update for a "hiccuped" frame is much higher than for regular frames.

Take a look at your profiler to see what's causing these spikes. Given the periodicity, I guess it could be GC.

Ok, I'll try and look into it and see if I can solve it. There is no major spikes from what I can see in the profiler though. I'll get back to you if I get stuck.

Thanks for all your help!
Reply