Player's interpolated position gets jittery

So I noticed that my framerate looked poor when the player moved around, and realized it was because my camera is currently set up to lock exactly on the player every update, meanwhile the player movement is updated every fixedUpdate.

The simple solution to fix this is to set my player's rigidbody to interpolate. Now I get smooth movement on the player, and each update the camera can move to an interpolated position.

But I found an odd bug that now occurs.
When my player walks into certain objects, the player (and thus the camera) gets jittery. As best I can tell, it's a vertical motion as if the interpolation figured the player should be moving either up or down.

These certain objects are capsule colliders. I don't get this problem from box collider or mesh colliders.
I thought maybe I was just hitting the rounded edge and the physics calculations pushed it slightly up, but even when I made the capsule so immensely tall that it was in no way touching the rounded edge, I still had this problem.

Has anyone else encountered this before? Any idea of what I might need to be changing or checking?

 

How are you handling collision and movement in general? My guess is you're teleporting your player inadvertently, the physics system realizes you've clipped into the wall, and then teleports the player out -- creating a feedback loop.

 

That's my guess too, but without code its hard to say.

For physics, NEVER use transform.Translate() and NEVER set the position directly.

The only way to to use Rigidbody / Rigidbody2D is to call the .MovePosition() method on the RB.

Same goes for rotating: always use .MoveRotation()

Anything else is considered a "teleport" by the physics system, and like a glass tank of fish, you will startle the physics system if you teleport colliders into each other, and the physics will jerk sharply to try and deconflict.

 

Just a heads up @Kurt-Dekker that MovePosition is also teleportation if the rigidbody isn't kinematic: https://docs.unity3d.com/2019.4/Documentation/ScriptReference/Rigidbody.MovePosition.html

"If the rigidbody has isKinematic set to false, it works like transform.position=newPosition and teleports the object to the new position (rather than performing a smooth transition)."

 

I guess I am, actually.
I have a line that snaps the player to the ground. I have a raycast straight down and if it hits anything it sets the player's position in Y to just above the point where it hits (but sets the X and Z to current values)
After that I apply a velocity to the rigidbody which only has values in X and Z. The player's rigidbody doesn't use gravity, and is not Kinematic.
This was to provide smooth and continuous motion while walking up/down slopes.

So what would be the ideal way to rectify this? I don't really want to use velocities for keeping the player grounded, because then slopes change player speed and the player will continually slide down slopes.

 

This might be a bit of an old thread but I have to respond to this, because 'MovePosition' for 2d rigidbodies does *not* alter it's velocity at all (despite MelvMay's comment here and the documentation on it). I tried reporting this as a bug recently, but the response I got from Unity was (and I will paste it here as a quote, with some underscore added):

So it does teleport and it does not set velocity. Try using MovePosition on a rigidbody2D and you'll find velocity does not change at all.

 

Actually if you do use movePosition on a 3d rigidbody, velocity does change. I'm developing a platformer with both 3d and 2d levels, with moving platforms that have rigidbodies attached to them. I use 'MovePosition' because it a clean kinematic way of moving them, but I need to read their velocity to transfer to the player when he's standing on them.

For 3d I was simply reading velocity from the rigidbody directly, which corresponded perfectly with the velocity required to perform the MovePosition() actions.
It was only when working on the 2d version I found that velocity just returned {0, 0}.
I've done things differently since, but the inconsistency between the two nags a bit.