Rigidbody.MovePosition not really smooth

For my personal 3rd person Character controller, I’m using Rigidbody.MovePosition (direction the character is facing).
The camera itself (stand-alone game object in the scene) will perfectly smooth follow the character. The character, however, does not move smooth.
Moving the line of code containing Rigidbody.MovePosition from FixedUpdate to Update did not solve it.

Now, I’ve been looking on Google for quite some time on how to do this, and every time people say “use Rigidbody.Velocity”. But in the Unity documentation, it states:

“In most cases you should not modify the velocity directly, as this can result in unrealistic behavior. Don’t set the velocity of an object every physics step, this will lead to unrealistic physics simulation. A typical example where you would change the velocity is when jumping in a first person shooter, because you want an immediate change in velocity.”

So, because I do expect to use an explosion force, I don’t want unrealistic physics behavior.
I’ve also looked into Transform.Translate, but this does not really have a great Physics simulation…

Does anyone have any idea how to make my character move smoothly, while still having good collision detection, and not modifying the velocity parameter itself?

Hi @DevCas1! Without necessarily disagreeing with @AlwaysSunny’s reply above, the answer to your specific question (in case someone searches for it later) is probably related to the fact that the physics timestep is not the same as the rendering timestep. (See the TimeManager documentation.) For example, imagine your fixed timestep is happening at exactly 100hz. If your rendering timestep is equal or less (i.e. 100fps or less) then you should see no issues. If it goes above 100fps, you will appear to drop frames for anything moving during the physics timestep that does not have some kind of interpolation applied. Moving SetPosition/SetRotation calls to the rendering timestep (i.e. Update) will have no effect because their results will not be processed until the next fixed timestep anyway.

Having glanced at Tera gameplay footage, I’m not convinced driving your player motion with rigidbody physics is wise. There are various discussions of the issues this can cause, and this one is just the tip of the iceberg.

My instinct is to discourage this strategy altogether. I would hazard to say that the overwhelming majority of games with similar movement behaviors are scripting those behaviors by hand, using their engine’s physics simulation exclusively for collision detection.

This suggestion also respects the requested response to explosive forces - that can be scripted by hand, bypassing the physics system altogether. Other kinds of reactions with other physically-simulated props in the scene can also be scripted (bumping into cardboard boxes knocks them over, while bumping into heavy crates does not, etc).

I’d strongly recommend switching to a system like this, which is based on Unity’s native character controller and its rather-lackluster collision response system. You can build upon it safely, because despite being sparsely featured, it’s a strong foundation. (Basically, on collision with a physical prop, you do your own mass-times-acceleration calculation and apply the calculated force to the hit object.)

If you insist on continuing down this path, there are many factors involved which may contribute to the unwanted behavior. Play around with various physics material settings, drag and mass values, etc. Creating a great character controller based on rigidbody physics is difficult even when that strategy is appropriate - you’re in dangerous territory with regard to researching / seeking help in your case: Much of what you find may lead you astray, being written by and for folks who are mistaken about the validity of this approach.

As for something useful to work around this specific issue, I suppose I’d recommend greatly increasing the mass or drag, and / or tinkering with the friction of your actor’s collider / rigidbody. Perhaps as a corrective measure - in other words, only increase the drag while the controller is receiving input, and only while the controller is grounded and hasn’t recently been acted on by another physics object. But be warned, this may be the first of many corrective behaviors, each of which ultimately dilutes the purity of the physics simulation you are relying on.

Refer to my comment on the OP for a proposed explanation of why the behavior is occurring in the first place.