i have a simple plane controller with a rigidbody. when i dont use interpolate mode i have jitter but collissions work as they should, if i use interpolate the jitter is gone but my plane can fly though collissions. if i use exterpolate it is the same as when i dont use it at all,
how can i get rid of the jitter without sacrificing my collission detection.
since i am a new user i cant upload videos jet of what is happening
With Physics (or Physics2D), never manipulate the Transform directly. If you manipulate the Transform directly, you are bypassing the physics system and you can reasonably expect glitching and missed collisions and other physics mayhem.
This means you may not change transform.position, transform.rotation, you may not call transform.Translate(), transform.Rotate() or other such methods, and also transform.localScale is off limits. You also cannot set rigidbody.position or rigidbody.rotation directly. These ALL bypass physics.
Always use the .MovePosition() and .MoveRotation() methods on the Rigidbody (or Rigidbody2D) instance in order to move or rotate things. Doing this keeps the physics system informed about what is going on.
As far as camera work, perhaps that’s the issue?
Camera stuff is pretty tricky… I hear all the Kool Kids are using Cinemachine from the Unity Package Manager.
There’s even a dedicated Camera / Cinemachine area: see left panel.
If you insist on making your own camera controller, do not fiddle with camera rotation.
The simplest way to do it is to think in terms of two Vector3 points in space:
Then you just need to update the above two points based on your GameObjects, no need to fiddle with rotations. As long as you move those positions smoothly, the camera will be nice and smooth as well, both positionally and rotationally.
i think this might be the problem thanks, i use the physics, so 3d
“This means you may not change transform.position, transform.rotation, you may not call transform.Translate(), transform.Rotate() or other such methods, and also transform.localScale is off limits. You also cannot set rigidbody.position or rigidbody.rotation directly. These ALL bypass physics.”
Another thing to look out for is having a camera attached to something with rigidbody physics, which that almost always causes jittering in my experience
Only if you’re not using interpolation on the Rigidbody(2D). In that case, it’s only updating the Transform when the simulation runs which by default is during the fixed-update as opposed to updating it per-frame.
This is incorrect. MovePosition() and .MoveRotation() also bypass physics. These methods forcefully move the rigidbody to the given position/rotation ignoring collisions, forces, and any other result of the physics solver for this rigidbody. MovePosition() and MoveRotation() produce correct physics effects in other bodies, but not in this one.
The only 100% physics-compliant way to move/rotate a rigidbody is with the methods AddForce and AddTorque (and their variants).
The title of this post is about jitter, and the question text mentions missed collisions.
The most common jitter AND missed collisions cause is using the Transform to move something.
Pedantically yes, telling a Rigidbody to be in a position or rotation using those calls is going to bypass the normal trajectory it would follow. However, 100% of physics callbacks for that body will happen and be correct, so in that sense we are not bypassing anything.
There are so many common uses of .Move*() calls in games for player-controlled or AI-controlled agents, I didn’t feel it necessary to point out that if you’re calling this, YOU are taking over since I assume you KNOW you are controlling an agent, in this case a controlled airplane.
MovePosition() and MoveRotation() bypass both physics calculations and collisions. Callbacks are generated, but collisions don’t affect the resulting position/rotation.
That isn’t true for 2D at all. MovePosition/MoveRotation are simple helpers that calculate the velocity to move to the specified position/angle in a single time-step. They also temporarily disable linear/angular damping too. Collision detection is unaffected. You can essentially do the same yourself, it’s just a convenience call.
AFAIK this is the case for Kinematic bodies in 3D but I’m not the expert there, especially now that there are several backends. For sure, in PhysX, Dynamic bodies are not supported and it results in the pose being instantly set (teleport) so in that case, absolutely it’s not the best.
Treating MovePosition/MoveRotation as normal dynamic motion is where a lot of other devs fail; for instance wondering why gravity is “not working” without thinking how gravity could work when each simulation step the body is being asked to move to a specific position.
Interesting. I often forget to mention that I’m referring to 3D physics
So in 2D physics, if you do a body2d.MovePosition() to a position behind a collision wall, does the physics apply the collision response and keeps body2d at the correct side of the wall? Or does the body trespass the collision wall?
In general MovePosition and MoveRotation should only be used on a kinematic rigidbody from within FixedUpdate but I will sometimes use MoveRotation in Update on a dynamic rigidbody when rotating it with the mouse. Doing this means it’s much more responsive and still allows for some physics interaction with other rigidbodies. Whereas trying to do this from within FixedUpdate with a dynamic rigidbody would result in random jitter.
Yes if it’s a Dynamic body. As I mentioned above, all it’s doing is setting the appropriate velocity. Of course, if it’s using Discrete it may tunnel but as usual, Continuous would stop that.
For 3D it would because it’s only setting the position/rotation directly (teleport) when using a Dynamic body and doing so in FixedUpdate would only update it then rather than per-frame. No idea if interpolation would be supported in 3D for that case.