01-09-2020, 07:24 AM
(This post was last modified: 01-09-2020, 09:40 AM by josemendez.)
For this kind of thing it is quite important to understand how and when physics are updated in relation to the render loop, and the order in which updates happen in Unity. Physics interpolation also plays an essential role.
If using a ObiFixedUpdater component (which is the most common case), softbody transform position/rotation is updated in Update(), after all calls to FixedUpdate() for that frame have been made.
However, this position/rotation is not interpolated between physics updates, so if your solver has interpolation enabled (see:http://obi.virtualmethodstudio.com/tutorials/obisolver.html) the transform will always be a bit ahead of it and "jitter" compared to the visual position of the particles.
This is because physics state interpolation works by linearly blending between the current physics state and the previous physics state, depending on how much wall clock time hasn't been simulated yet. This solves the problem caused by the fact that in most engines (Unity being no exception) physics aren't updated in sync with the render loop.
So particle positions/orientations can be anywhere between the values for the current frame, and the values for the previous frame. Since the transform is always using the current values, it means it will always be ahead of the particles. Note that this is not unique to Obi, physics state interpolation works this way in all physics engines (Unity's built-in physics, Unreal's, etc).
So in case you want to parent stuff to the softbody and have it track it perfectly, either:
- Disable interpolation entirely. This will result in "stutter" when simulating in FixedUpdate() though, as physics state is not updated in sync with rendering.
- If you have interpolation enabled, interpolate the transforms too so that they move in sync with the particles.
There's more advanced camerawork options you could use, of course: you could extrapolate softbody position from its current velocity to determine where it's moving to, and aim the camera there so that the player sees where it's going to move next, not where it comes from (as that does not give the player much information, and can make the camera feel unresponsive). Based on your video, this is the way to go imho.
If using a ObiFixedUpdater component (which is the most common case), softbody transform position/rotation is updated in Update(), after all calls to FixedUpdate() for that frame have been made.
However, this position/rotation is not interpolated between physics updates, so if your solver has interpolation enabled (see:http://obi.virtualmethodstudio.com/tutorials/obisolver.html) the transform will always be a bit ahead of it and "jitter" compared to the visual position of the particles.
This is because physics state interpolation works by linearly blending between the current physics state and the previous physics state, depending on how much wall clock time hasn't been simulated yet. This solves the problem caused by the fact that in most engines (Unity being no exception) physics aren't updated in sync with the render loop.
So particle positions/orientations can be anywhere between the values for the current frame, and the values for the previous frame. Since the transform is always using the current values, it means it will always be ahead of the particles. Note that this is not unique to Obi, physics state interpolation works this way in all physics engines (Unity's built-in physics, Unreal's, etc).
So in case you want to parent stuff to the softbody and have it track it perfectly, either:
- Disable interpolation entirely. This will result in "stutter" when simulating in FixedUpdate() though, as physics state is not updated in sync with rendering.
- If you have interpolation enabled, interpolate the transforms too so that they move in sync with the particles.
There's more advanced camerawork options you could use, of course: you could extrapolate softbody position from its current velocity to determine where it's moving to, and aim the camera there so that the player sees where it's going to move next, not where it comes from (as that does not give the player much information, and can make the camera feel unresponsive). Based on your video, this is the way to go imho.