Massive Performance Drop

[Noblauch]

Hi, I have quite a problem in perfromance here and hope someone can help!

I used Obi Rope for about two weeks now and undestand the concept (as far as I can tell).
But I get massive game-breaking frame drops in my VR application, even the rope is set to minimal substeps and segments.

I added a screenshot of the profiler and the solver. The rope is the only instance of obi simulation in the scene and every big blue bar is generated by ObiFixedUpdater.FixedUpdate().
As a VR-Dev I need to stay under 11 ms, which is already twice blown away by the obi solver that only has to deal with 16 particles and 2 substeps.
I even disabled substep unity physics even though I have two way Rigidbody coupling, because if I enable that my workstation gets almost killed.

I was very patient until now, but as the deadline approaches I cant waste another 3 days experimenting with whats wrong.
I hope someone can help, because 22 ms for 16 particles can't be right, under no circumstances, and I don't even know what to change anymore.

Also I'm wondering why the Obi Updater is calles so often, it's almost called every 1,5ms, but with 2 substeps (at least with substep unity physics enabled) I would assume that the updater is called every 50ms / substeps, since FixedUpdate() rund every 50 ms.

I'm left very confused, but removing all obi objects would be the very last solution.
I'm using ObiRope Version 5.0 and Unity 2019.2.8f1

I hope you can help me!

Greetings from Germany,
Nils Ole

[josemendez]

Hi, I have quite a problem in perfromance here and hope someone can help!

I used Obi Rope for about two weeks now and undestand the concept (as far as I can tell).
But I get massive game-breaking frame drops in my VR application, even the rope is set to minimal substeps and segments.

I added a screenshot of the profiler and the solver. The rope is the only instance of obi simulation in the scene and every big blue bar is generated by ObiFixedUpdater.FixedUpdate().
As a VR-Dev I need to stay under 11 ms, which is already twice blown away by the obi solver that only has to deal with 16 particles and 2 substeps.
I even disabled substep unity physics even though I have two way Rigidbody coupling, because if I enable that my workstation gets almost killed.

I was very patient until now, but as the deadline approaches I cant waste another 3 days experimenting with whats wrong.
I hope someone can help, because 22 ms for 16 particles can't be right, under no circumstances, and I don't even know what to change anymore.

Also I'm wondering why the Obi Updater is calles so often, it's almost called every 1,5ms, but with 2 substeps (at least with substep unity physics enabled) I would assume that the updater is called every 50ms / substeps, since FixedUpdate() rund every 50 ms.

I'm left very confused, but removing all obi objects would be the very last solution.
I'm using ObiRope Version 5.0 and Unity 2019.2.8f1

I hope you can help me!

Greetings from Germany,
Nils Ole

There's so many misconceptions here... I'll try to help:

FixedUpdate() (and thus, ObiFixedUpdater) is not called every 50 ms. It's not even called at a fixed real-world frequency, despite its name. It is called when the amount of unsimulated wall-clock time is larger than whatever your Fixed timestep setting in Unity is.  The default is 0.02, so it would be called once for every 20 ms of wall-clock time that have passed since the last FixedUpdate call. So it may be called once every few frames, to multiple times per frame.

Now, if you have 2 substeps, FixedUpdate() is still called at whatever frequency you have set it to. However, each call to it, Obi advances the simulation using two substeps of half the duration. Suppose your timestep is 0.016, your game runs at a steady 60 fps, and you have two substeps: FixedUpdate would be called once per frame, and Obi would be updated twice per frame, each call advancing the simulation by 0.008 seconds.

Your problem is very likely a wall of despair/death spiraling situation. This happens when the amount of wall-clock time taken to render a full frame is long enough that the amount of accumulated time to be simulated the next frame increases every frame. This forces Unity to call FixedUpdate() more than once per frame, in fact it will call it as many times as your Max fixed timestep value allows it to. So in the worst case, you can end up with tons of FixedUpdate() calls every frame that will slow down your game to a halt. In your case, Obi is being updated 10x2 = 20 times per frame.

Try setting both your Fixed timestep and your Max fixed timestep to 0.02. Things should improve quite a bit, from there you can increase the Max fixed timestep a bit.

[Noblauch]

Thank you for your quick response and explaination!

Setting the Maximum allowed Timestep down really helped to get the calls per frame down which is great. I'm still optimizing the wohle szene, which contains some heavy rendering which triggered the spiral in the first place I guess.
But if I set the "Substep Unity Physics" on true again, one ObiFixedUpdate() takes about 1.5 - 2 ms, which is quite much for that little amount of vertices in my opinion. My machine is running a i7-8850H.

I'm still trying to get used to Obi Rope, it's overall a great plugin and I had it on my list quite a time now. But there are still some behaviours that I can't really explain to myself.

Greetings,
Nils Ole

[josemendez]

Thank you for your quick response and explaination!

Setting the Maximum allowed Timestep down really helped to get the calls per frame down which is great. I'm still optimizing the wohle szene, which contains some heavy rendering which triggered the spiral in the first place I guess.
But if I set the "Substep Unity Physics" on true again, one ObiFixedUpdate() takes about 1.5 - 2 ms, which is quite much for that little amount of vertices in my opinion. My machine is running a i7-8850H.

I'm still trying to get used to Obi Rope, it's overall a great plugin and I had it on my list quite a time now. But there are still some behaviours that I can't really explain to myself.

Greetings,
Nils Ole

"Substep Unity Physics" basically substeps the entire Unity physics loop too to keep both Obi and Unity in sync, so these extra 1.5-2 ms are actually the entire physics update of your scene. So a big performance impact is of course to be expected as you're now calculating all physics (colliders, rigidbodies, etc) more than once per frame. This is needed if both engines are expected to interact, as you cannot update different objects at different timesteps if they take part in the same simulation. Well, technically you can, but stability then goes out of the window.

All of this is not exclusive to Obi. Pretty much all game engines in the market approach physics using a fixed timestep of a semi-fixed timestep for stability reasons, so there's not much we can do to simplify it. You can ignore most of it if your game doesn't use physics or uses very basic physics... but as soon as you need something more than a character running around a static level or a few crates, deeply understanding fixed time stepping is a must unfortunately.