Help Gloth dragging behind parent, help

[zagoalie]

I am using A Obi skinned renderer on some fabric attached to a 3d hand/curser. when I move the hang around the cloth seems to lag behind it. the part of the cloth along the top of the hand is set to zero on all of its constraints, yet still, it seems to trail behind the hand. 

here is video of the issue: https://gyazo.com/86cc2f1cc0ea6ee0817190786a4dbdf6

I have tried turning damping on and off as well as interpolation and shock propagation seems like none of the obi solver settings fix this problem.

my goal is that the top of the cloth stays bound statically to the hand, and only the hanging tails move around in relation to how the hand is moving.

Edit: i am also using the particular attachment script attaching the upper cloths particles to the bone in the for arm, still no luck.

[josemendez]

I am using A Obi skinned renderer on some fabric attached to a 3d hand/curser. when I move the hang around the cloth seems to lag behind it. the part of the cloth along the top of the hand is set to zero on all of its constraints, yet still, it seems to trail behind the hand. 

here is video of the issue: https://gyazo.com/86cc2f1cc0ea6ee0817190786a4dbdf6

I have tried turning damping on and off as well as interpolation and shock propagation seems like none of the obi solver settings fix this problem.

my goal is that the top of the cloth stays bound statically to the hand, and only the hanging tails move around in relation to how the hand is moving.

Edit: i am also using the particular attachment script attaching the upper cloths particles to the bone in the for arm, still no luck.

You just have to keep Unity's update order in mind.

Physics (including cloth) are updated in FixedUpdate() by default, which is called before Update(). Make sure you're moving the hand at the start of FixedUpdate(), or you will introduce a 1-frame delay. Typically, you'd use Update() or LateUpdate() to move the hand, but that's too late as physics have already been updated that frame. See:https://docs.unity3d.com/Manual/ExecutionOrder.html

For convenience, you can subscribe to solver.BeginStep event and move the hand there. This event is called right before cloth physics are updated, so you don't have to worry about your script's FixedUpdate() being called before/after the solver's FixedUpdate().

[zagoalie]

You just have to keep Unity's update order in mind.

Physics (including cloth) are updated in FixedUpdate() by default, which is called before Update(). Make sure you're moving the hand at the start of FixedUpdate(), or you will introduce a 1-frame delay. Typically, you'd use Update() or LateUpdate() to move the hand, but that's too late as physics have already been updated that frame. See:https://docs.unity3d.com/Manual/ExecutionOrder.html

For convenience, you can subscribe to solver.BeginStep event and move the hand there. This event is called right before cloth physics are updated, so you don't have to worry about your script's FixedUpdate() being called before/after the solver's FixedUpdate().

Previously i was using unity cloth to do the same thing, and i didn't notice this happening then, does obi solve in a different order to defult unity cloth?

[josemendez]

Previously i was using unity cloth to do the same thing, and i didn't notice this happening then, does obi solve in a different order to defult unity cloth?

Yes. Unity cloth is updated in LateUpdate(), which results in highly unphysical simulation as the delta time for the simulation varies every frame.

You can achieve the same in Obi by using the ObiLateUpdater component instead of ObiFixedUpdater. See:
http://obi.virtualmethodstudio.com/tutor...aters.html
http://obi.virtualmethodstudio.com/tutor...cture.html

In fact, you can update Obi whenever you want by writing your own Updater component. However I'd recommend doing the proper thing and just updating your input before physics.

Here's a comparison between Unity's built-in cloth and Obi. As you can see, updating  physics with a variable timestep causes cloth to jitter, gain momentum and never come to rest:

[zagoalie]

Yes. Unity cloth is updated in LateUpdate(), which results in highly unphysical simulation.

You can achieve the same in Obi by using the ObiLateUpdater component instead of ObiFixedUpdater. See:
http://obi.virtualmethodstudio.com/tutor...aters.html
http://obi.virtualmethodstudio.com/tutor...cture.html

In fact, you can update Obi whenever you want by writing your own Updater component. However I'd recommend doing the proper thing and just updating your input before physics.

Here's a comparison between Unity's built-in cloth and Obi. As you can see, updating  physics with a variable timestep causes cloth to jitter, gain momentum and never come to rest:

Awsome, thank you very much for the speedy response

[Rene-at-melcher]

For others looking for a solution to an obi simulation lagging behind a VR controller in unity; this is the solution. In the case of VR, it is important for player immersion to have the visual of whatever they are holding to update as late as possible to have it feel like they are holding it. In my case, I have a rod / rope attached to an object in the players hand and it would visually lag one frame behind and noticeably detach when the player waved their hand.

With Unity's XR Interaction toolkit I found that you can swap the Fixed Updater for "Obi Late Fixed Updater" on your Obi solver and it will solve the problem while allowing you to keep the tracking type of the VR controllers to "Update and Before Render". The lower quality of the simulation is ok since the rope will be in constant movement in the players hand and not be as noticeable... though it seems the late fixed updater is attempting to account for the time disparity anyway... so potentially the best of both worlds? Does the late fixed updater produce simulation quality on par with the standard fixed updater?

Anyway, having the updaters modular and swappable is very helpful, thank you. If this solution still has issues lagging in certain cases, you could probably create an updater that listens to the controller and invalidates when the controller updates.

[josemendez]

With Unity's XR Interaction toolkit I found that you can swap the Fixed Updater for "Obi Late Fixed Updater" on your Obi solver and it will solve the problem while allowing you to keep the tracking type of the VR controllers to "Update and Before Render". The lower quality of the simulation is ok since the rope will be in constant movement in the players hand and not be as noticeable... though it seems the late fixed updater is attempting to account for the time disparity anyway... so potentially the best of both worlds? Does the late fixed updater produce simulation quality on par with the standard fixed updater?

ObiLateFixedUpdater will execute a single fixed-length simulation step once all FixedUpdate() calls for the frame have been finished. Of course this is not ideal, since FixedUpdate might be called more than once per frame, but ObiLateFixedUpdater will be executed once at most resulting in missing simulation time and sudden "slow-mo" effects sometimes.

ObiLateUpdater will execute a single, variable-length step in LateUpdate(). It tries to reduce the impact of variable-timestepping by using a low-pass filter on the timestep, smoothing out "peaks" that could lead to sudden energy gains/losses. Still, it's not comparable to actual fixed timestepping in terms of quality. This is the approach used by Unity's built-in cloth, as far as I know.

ObiFixedUpdater does the right thing: 0, one, or more fixed-length steps per frame. It's the only updater guaranteed to conserve energy and look good at all times. The other two should only be used when there's no alternative.

Anyway, having the updaters modular and swappable is very helpful, thank you. If this solution still has issues lagging in certain cases, you could probably create an updater that listens to the controller and invalidates when the controller updates.

Modular/swappable update scripts are useful, but remember it's not the only way to control execution order.

Keep in mind that the ObiSolver component has several events that you can subscribe to, and get callbacks at different points during simulation:

• OnBeginStep
  
• OnSubstep
  
• OnEndStep
  
• OnInterpolate
  

OnBeginStep is called right before each simulation step begins, no matter what Updater you're using. Subscribing to it and performing input there (VR or ortherwise) is a better approach, as it lets you use ObiFixedUpdater and still get no delay at all in input.

In addition to this, Unity lets you set Script Execution Order (https://docs.unity3d.com/Manual/class-MonoManager.html). This lets you write a component whose FixedUpdate() is always called before ObiFixedUpdater.

Using any of these methods you can achieve the same goal: that input must take place before simulation to avoid delays/lags.