Unity AddForce causing twitch

Question

Since this wasn't clear enough, I've removed even more code. It kind of defeats the purpose I was aiming for, but I guess getting any answer relevant to the problem is better than none.

What I want: A cube to leave the ground with N velocity in the negative x direction, then gravity pulls it back down.

THE SETUP:

void Start () {
    rb = GetComponent<Rigidbody>();
}

void Update() {

    //Jump
    if (Input.GetKeyDown("space"))
    {
        jump = true;
    }
}

TEST 1 (I really thought this should work as it was the solution I saw in so many google results)

void FixedUpdate()
{
    if (jump)
    {
        rb.AddForce(new Vector3(0, 0, -5000f));
        jump = false;
    }
}

TEST 2 (Added ForceMode.VelocityChange)

void FixedUpdate()
{
    if (jump)
    {
        rb.AddForce(new Vector3(0, 0, -5000f), ForceMode.VelocityChange);
        jump = false;
    }
}

TEST 3 (Tried other ForceModes)

void FixedUpdate()
{
    if (jump)
    {
        rb.AddForce(new Vector3(0, 0, -5000f), ForceMode./*INSERT OTHER ForceModes*/);
        jump = false;
    }
}

TEST 4 ( I know, changing velocity directly is a bad thing, but seeing as what I want is the cube to move upwards at a certain speed, it made sense to try it )

void FixedUpdate()
{
    if (jump)
    {
        var vel = rb.velocity;
        vel.z += -5000f;
        rb.velocity = vel;
        jump = false;
    }
}

It's been a long day, I'm sure I left some other attempts out.

Can someone explain to me why the cube is teleporting from Z=0 to Z= -2 (or some other value depending on the magnitude of the force)?

I can understand if it was something having to do with impact force not having enough time to change the velocity, but then why did the position change so drastically? And why didn't changing the velocity work, even though I know that is a bad way to go about it?

Answer 1

Your problem comes from changing the velocity of the rigid body in a update. In my Spencerian this does not work at all. You have two solutions. Dont move your character with physics engine or use AddForce to move him. I changed your Fixedupdate to this and it works fine for me :

    void FixedUpdate()
    {
        float moveHorizontal = Input.GetAxis("Horizontal");
        float moveVertical = Input.GetAxis("Vertical");

        Vector3 movement = new Vector3(moveHorizontal,0, moveVertical);
        _rigidBody.AddForce (movement * speed);

        if (jump)
        {
            _rigidBody.AddForce(new Vector3(0, 500, 0));
            jump = false;
        }
}

Note I did not add ground checks and I use _rigidBody = GetComponent<Rigidbody>(); in the Start() method. Its a good tip not to use GetComponent in Update methods.

Answer 2

After several more hours working on it, I've narrowed it down to a bug/peculiarity in the Unity engine.

I deleted everything and started fresh, on doing so, the original code worked fine. During my attempts to replicate what I originally had, I found that adjusting the drag to something > 1 while either turning on/off the "Use Gravity" tickmark or changing the gravity from 0 to 9.81 or reverse between two runs caused the problem with no way to undo it.

As best I can tell, what happened was the cube moved at an incredible speed, seeming to teleport, but then was restricted to its maximum velocity in the second frame, then had its velocity reduced due to the gravity, making it stand still then fall. The slowness was also caused by the drag, which I managed to overcome by writing my own function to simulate the acceleration due to gravity, though this stopped working properly when I re-did the entire project, causing the cube to drop at incredible speeds as it no longer needed to overcome the 'invisible air resistance'.

Even after reducing drag back down to 0 this problem persists, meaning that although the surface to surface friction was returned to 0, the air drag was not.

This was done using Unity 5.3.5f1 (64-bit)

Answer 3

Whenever you are using rigidbody to control movement you are handing over control to the physics engine. Unless you really know what you are doing, you should not set velocity (or position for that matter) explicitly if you are using the physics engine. It will result in unpredictable behaviour.

If you want to jump then ou should add force with ForceMode.Impulse as per documentation: Rigidbody.AddForce

Let the gravity control when the body should start moving down. If you want classic platformer behaviour like the Super Mario games you grew up with, remember that Mario's world has a higher gravity constant than 9.82 m/s as described in this very scientific analysis

The code posted by @Uri Popov should work, but, as stated I would use ForceMode.Impulse to be able to set a jump impulse that is defined in SI-units. If you want the user to be able to control the jump height by holding the jump button for different lengths of time then you want to use a force, i.e. ForceMode.Force for a variable length of time, say 0-0.5 seconds.

EDIT:

Ok you want the cube to get a certain velocity when jumping and then want gravity to affect it and make it go down?

Here's example code that makes that happen:

    void FixedUpdate()
    {
        float jumpVelocity = 5;//Meters per second
        if (jump && isGrounded())
        {
            _rigidBody.AddForce(new Vector3(0, jumpVelocity, 0), ForceMode.VelocityChange);
            jump = false;
        }
    }

Note that in this case I use the notation of y-axis being height, if you really really want to continue using z-axis then just apply the velocity change to that axis instead.

I think your problem is not in code per se, you need to read up on classical newtonian mechanics a bit before making a physics based game.

EDIT 2:

As you updated your answer again, I'll add another edit. Remember that the physics engine is using SI base units. This means that if you add a velocity change of 5000 that means you add 5000 m/s or 18000 km/h.

I think this may cause issues with the physics engine as the drag at those speeds will be enormous, and even if IRL drag would sooner or later reduce the speed to more sane values, in the discrete model in the engine with floating point errors and such maybe it could result in the body coming to a complete stop one frame later.

Try once more to do the same while first checking that all values are more "normal", i.e. gravity ~10 N/kg, drag < 1 and velocity changes 1-10 m/s. Also check that gravity is pointing the right direction (normal setting is negative y), and that the physics update step is about 0.02 s.