Help Gloth dragging behind parent, help

[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.