Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Help  Strange Behaviour in Editor for V7
#1
Hi,

I upgraded to Version 7 and I have noticed something strange in editor, whenever I select in play mode runtime inside editor the object of Obi Rope, it instantly reflects and rope does some movement. Like for example if an object is hanging by rope its oscillates a little up an down. Similarly I have also noticed that when scene is started the same object oscillates up and down a lot more than before (I kept the parameters same like in version 6), why change in behaviour? It oscillates for about 2 seconds whereas before it was just 0.1 second.
Reply
#2
(06-08-2024, 04:42 PM)vrtraining Wrote: Hi,

I upgraded to Version 7 and I have noticed something strange in editor, whenever I select in play mode runtime inside editor the object of Obi Rope, it instantly reflects and rope does some movement. Like for example if an object is hanging by rope its oscillates a little up an down. Similarly I have also noticed that when scene is started the same object oscillates up and down a lot more than before (I kept the parameters same like in version 6), why change in behaviour? It oscillates for about 2 seconds whereas before it was just 0.1 second.

Hi,

This is completely normal and a consequence of how Obi 7's asynchronous simulation works. In Obi 6, simulation would happen in lockstep with Unity's own physics, like this:

Code:
FixedUpdate()
{
ObiUpdate()
WaitForObiToFinish()
UnityPhysicsUpdate()
}
When a sudden performance drop requires FixedUpdate to be called more than once per frame, this would yield:

ObiUpdate()
WaitForObiToFinish()
UnityPhysicsUpdate()
ObiUpdate()
WaitForObiToFinish()
UnityPhysicsUpdate()
ObiUpdate()
WaitForObiToFinish()
UnityPhysicsUpdate()... and so on.

This ensures that Obi would react immediately after each individual rigidbody update, but has two problems: poor performance (since the main thread must wait for Obi's simulation before proceeding with the next UnityUpdate()) and a tendency towards death spiraling (because of the higher cost of FixedUpdate).

Obi 7 solves these problems by instead deferring Obi's simulation after all calls to Unity's physics engine for the current frame have been made, like this:

Code:
FixedUpdate()
{
if (count == 0)
   WaitForObiToFinish()
UnityPhysicsUpdate()
count++;
}

LateUpdate()
{
for (count)
   ObiUpdate()
WaitForObiToFinish()
count = 0;
}

Since Obi's update happens near the end of the frame, there's no need for the main thread to wait for it to complete until the next FixedUpdate() call which will happen at least one entire frame in the future. This also reduces or eliminates the possibility of death spiraling. When a sudden performance drop requires calling FixedUpdate() more than once per frame you get:

WaitForObiToFinish()
UnityPhysicsUpdate()
UnityPhysicsUpdate()
UnityPhysicsUpdate()
ObiUpdate()
ObiUpdate()
ObiUpdate()

As a result there may be more than one physics update during which Obi doesn't react to the rigidbody simulation immediately, but compensates for it later in the same frame. In the case of a rigidbody hanging from a rope, this means the rigidbody may fall due to gravity for more than 1 physics step, and the rope will later apply a larger force to get the rigidbody back to its position. This is the "oscillation" you're talking about. In Obi 6, at most 1 physics step would take place before the rope had the chance to react, hence the shorter oscillation.

This only happens when there's a relatively large hit in performance, such as when you select stuff in the editor as it has to load component data and present it in the UI. The benefit is much faster simulation and higher resilience to physics spiraling problems.

kind regards,
Reply
#3
Thanks for such a detailed response and explanation.

This is for async behaviour right? If we switch to sync in solver does it make any difference?

Also how I can reduce the oscillation of a weight hanged by rope on runtime?
Reply