Help Update "lag" between cloth and particle attachment target

[cberinger]

Dear Obi Team,

I made a flag which can be picked up with a handle in VR.
hierarchy is as follows:

handle
solver
- cloth

The handle is connected via particle attachment to the cloth.
When moving the handle in VR (grabbed) then the cloth lags behing.

I read other postings concerning lag but they were related to Pin constraints.
Solver interpolation is disabled.
I tried some of the Obi Updater Components but was not successful...

How can i minimise this lag, oder even prevent it? It really kills the immersion :-(

Cheers,
Christian

[josemendez]

Dear Obi Team,

I made a flag which can be picked up with a handle in VR.
hierarchy is as follows:

handle
solver
- cloth

The handle is connected via particle attachment to the cloth.
When moving the handle in VR (grabbed) then the cloth lags behing.

I read other postings concerning lag but they were related to Pin constraints.
Solver interpolation is disabled.
I tried some of the Obi Updater Components but was not successful...

How can i minimise this lag, oder even prevent it? It really kills the immersion :-(

Cheers,
Christian

Make sure your move the handle before simulation kicks in each frame. Most of the time(*) this means doing it in FixedUpdate(), before the solver starts. If you don't you'll experience a 1-frame delay.

(*)Depends on what updater you're using, or if you're manually updating the solver, where you're doing so. Most commonly you'd use a ObiFixedUpdater(). So, you'd want to move your handle in FixedUpdate, before the updater does its thing. Easiest way is to subscribe to the solver.OnBeginStep event.

[cberinger]

Make sure your move the handle before simulation kicks in each frame. Most of the time(*) this means doing it in FixedUpdate(), before the solver starts. If you don't you'll experience a 1-frame delay.

(*)Depends on what updater you're using, or if you're manually updating the solver, where you're doing so. Most commonly you'd use a ObiFixedUpdater(). So, you'd want to move your handle in FixedUpdate, before the updater does its thing. Easiest way is to subscribe to the solver.OnBeginStep event.

Hi Jose,

thanks for the info! But I currently do not know how to tackle this problem.
I rely on SteamVR(OpenVR) for handling VR interactions (i.e. grabbing). So moving the handle is currently not "in my power", or do you know how to change that?

Is there by chance a sample scene you made previously that uses SteamVR working/configured as you described to me?
To my knowledge I never changed any "update"-related settings in my project - so anybody who is working with SteamVR will initially be faced with this problem?

Cheers,
Christian

[josemendez]

Hi Jose,

thanks for the info! But I currently do not know how to tackle this problem.
I rely on SteamVR(OpenVR) for handling VR interactions (i.e. grabbing). So moving the handle is currently not "in my power", or do you know how to change that?

Is there by chance a sample scene you made previously that uses SteamVR working/configured as you described to me?
To my knowledge I never changed any "update"-related settings in my project - so anybody who is working with SteamVR will initially be faced with this problem?

Cheers,
Christian

Hi Christian,

If you've dealing with physics, you can't update anything related to them in Update(). Must be done in FixedUpdate(), no way around that. It's two entirely different update loops. So anyone using SteamVR handling together with physics (be it Obi or any other engine) will be faced with this.

As far as I know, nothing stops you from writing your own grabber for SteamVR, and do anything you'd like in it. Here's an example:
https://wirewhiz.com/vr-grabbing-tutorial/

[cberinger]

Hi Christian,

If you've dealing with physics, you can't update anything related to them in Update(). Must be done in FixedUpdate(), no way around that. It's two entirely different update loops. So anyone using SteamVR handling together with physics (be it Obi or any other engine) will be faced with this.

As far as I know, nothing stops you from writing your own grabber for SteamVR, and do anything you'd like in it. Here's an example:
https://wirewhiz.com/vr-grabbing-tutorial/

Hi Jose,

thanks for the insight!
One last question though: before using Obi cloth, i used the unity cloth implementation.
As unity cloth did not have this problems, I wonder how this correlates to their approach using also some kind of physics...

Cheers,
Christian

[josemendez]

Hi Jose,

thanks for the insight!
One last question though: before using Obi cloth, i used the unity cloth implementation.
As unity cloth did not have this problems, I wonder how this correlates to their approach using also some kind of physics...

Cheers,
Christian

Unity cloth is updated in Update(), with a variable timestep (which is completely wrong from a physics standpoint). This results in unstable simulation, random jerks, and fluctuating momentum which causes the cloth to be unable to come to a rest. Basically they're advancing the simulation a random amount of time each frame (will only work acceptably well if you have an exceptionally steady FPS, so that every frame is rendered in the exact same amount of time). Here's a comparison between Unity (white cloth) and Obi (blue cloth):



In addition to this, two-way coupling with rigidbodies is not supported by Unity, probably because it would just blow up due to this unphysical behavior (you can't have objects in the same simulation updated at different frequencies). Don't know what they were thinking when they implemented cloth, tbh  

In Obi you can also force the solver to update in Update() by using a ObiLateUpdater component instead of a ObiFixedUpdater. The associated problems are the exactly same, that's why we strongly recommend using the ObiFixedUpdater (and why it is the default).

[cberinger]

Unity cloth is updated in Update(), with a variable timestep (which is completely wrong from a physics standpoint). This results in unstable simulation, random jerks, and fluctuating momentum which causes the cloth to be unable to come to a rest. Basically they're advancing the simulation a random amount of time each frame (will only work acceptably well if you have an exceptionally steady FPS, so that every frame is rendered in the exact same amount of time). Here's a comparison between Unity (white cloth) and Obi (blue cloth):



In addition to this, two-way coupling with rigidbodies is not supported by Unity, probably because it would just blow up due to this unphysical behavior (you can't have objects in the same simulation updated at different frequencies). Don't know what they were thinking when they implemented cloth, tbh  

In Obi you can also force the solver to update in Update() by using a ObiLateUpdater component instead of a ObiFixedUpdater. The associated problems are the exactly same, that's why we strongly recommend using the ObiFixedUpdater (and why it is the default).

Hi Jose,

great support - thanks for the explanation! I now understand!
Anyhow, I realise more and more that for using physics "the correct way" (and in VR) a profound background knowledge is required.

Cheers,
Christian

P.S.: I think Unity themselves added some cloth "light" support in oder to say "we have cloth"