Help Simulation order and OnAnimatorMove

[josemendez]

All right--again, not trying to be rude, but it's disheartening to see other questions being answered in the forums while this one is being glossed over. Is there something I can do to illustrate the issue more or perhaps, get some sort of clarification on the problem I'm experiencing or if it should even be behaving like this at all? Surely I'm not the only person that has encountered this--I know that Obi Cloth is a complicated beast, but it'd be great to get some sort of response from the asset creator, even if it's a "I have no idea what you're talking about", so I can at least open up other routes of investigation.

Hi there!

Sorry for taking so long to answer your question. As you've correctly guessed, Obi hijacks the update cycle of the Animator, by manually calling its Update() method (this is very easily doable using Unity's API, nothing out of the ordinary in here: https://docs.unity3d.com/ScriptReference...pdate.html). We are passing it the delta time, to keep it in sync with the physics simulation. The time passed to it depends on which update mode you select. When using UpdatePhysics, Time.fixedDeltaTime is used.

Generally you want characters to update their animation in sync with cloth physics:

- first update animation
- then update the physics
- repeat.

Code:

to recap, our game does not use physics at all and nothing happens in FixedUpdate, nor do we want it to

Well now it does, since cloth physics are physics, and animation needs to happen in sync with it. This is what setting the Animator to UpdatePhysics ensures. Using LateUpdate mode for the physics solver is not physically correct (as the delta time passed is not a fixed value, but a filtered out version of the delta time between frames), and should only be used in emergency cases.

FixedUpdate() can be called many times per frame, or none at all, depending on your fixed timestep and how much time has passed since the last frame. This is again, standard Unity behavior (or rather, standard game engine physics behavior) and nothing can be done to prevent it. So if you directly use the character position to drive the camera every frame, the cam will stutter together with the physics.

There's many possible fixes to this. The quickest, dirtiest one is to use some sort of low pass filter / damped spring on your camera, to give it some slack. Something like this will filter out any jittering in the character movement before applying it to the camera:

Code:

cam.position = Vector3.Lerp(cam.position, character.position, 0.1f);

Same for orientations, but using quaternion slerp instead of vector lerp.

An alternative would be interpolating the physics state of your character, which is the recommended solution as stated in the Unity docs, and the common solution to this issue in most games: https://docs.unity3d.com/ScriptReference...ation.html

This would interpolate the character position using the previous physics step position, its current one, and the amount of unsimulated physics time left in the current frame, ensuring buttery smooth movement.