Search Unity

Please help me better understand gravity in the physics manager.

Discussion in 'Getting Started' started by Deleted User, Feb 6, 2016.

  1. Deleted User

    Deleted User

    Guest

    I'm learning Unity3D by developing a simple character controller. It's very important to me that I understand all the code I use and be able to reproduce it on my own. Gravity is producing unexpected results now that I'm trying to enable it and get off the ground.


    Okay, 1*1 is 1: at -1 a box falls 4 units in 4 seconds as expected.

    Code (CSharp):
    1. rigidbody.position = (transform.position + transform.up * Time.deltaTime);
    (x, y, z) = (x, y, z) + (x, 1, z) * Time.deltatime

    I understand deltatime, the time (seconds) it took to complete the last frame. Hypothetically, if a frame took .5 to render it would be 1 * .5: half a unit per frame. Thus it is an adjusting faction of the distance needed to reach the whole in one second. Without gravity the rigidbody moves up 1u/s.

    When I transform a rigidbody up, no matter what magnitude, the rigidbody rises and then falls. It would seem to me either a MovePosition would be enough to overcome gravity, resulting in a constant rise, or otherwise not enough to get it off the ground.

    What is overcoming a constant force powerful enough to lift an object off the ground after it has done so?

    What MovePosition call would negate -1 gravity?

    Thank you for any insight.
     
  2. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    MovePosition isn't working with physics. It's doing an end-run around physics. As a result, you will not get sensible results if you call it every frame. (If you call it just once, the result is fairly sensible: the object instantly teleports to the position you tell it to, and then continues to behave physically after that.)

    So, your final question is nonsensical. You don't counter gravity by moving position; you counter gravity (a force) by applying an equal and opposite force.
     
  3. shaderbytes

    shaderbytes

    Joined:
    Nov 11, 2010
    Posts:
    900
    force to move an object also has to take mass into account, the more mass it has - the more force is needed. Gravity adds onto this principle
     
  4. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    Good point. The force of gravity depends on mass. (Which is why everything falls at the same rate — more mass means more force, but it takes more force to accelerate a greater mass.)
     
  5. Deleted User

    Deleted User

    Guest

    I was disingenuous (and incorrect) in referring to MovePosition as a force. I understand MovePosition.

    Although you did not answer my question, your input has helped me realize the answer.

    Moveposition is adjusting the body at a fixed rate.The rigidbody is gaining velocity towards the ground and terminal velocity while it's in the air. At some point the object's terminal velocity is higher than MovePosition +1.

    My code path decisions are:

    A -Apply "fake" gravity transforms to my vehicular character controller's transform.
    B -Figure out the velocity and negate it with transforms.
    C -Use forces, mass etc. My last choice because I want precise control over the character's behavior.

    Figuring out the inverse transform to gravity for a given drag/mass would be an interesting project on it's own, though. Thanks, sometimes it just takes talking to someone about something.

    Edit: Velocity is exposed as rigidbody.velocity, so we can simply:

    Code (CSharp):
    1. Vector3 v3Velocity = -(ship.velocity);
    2. ship.position = (transform.position + (transform.up + v3Velocity) * Time.deltaTime);
    I apologize if my semantics or syntax are wrong as they are sure to often be. I'm going to go with option A for now since realism isn't important in my first Unity3D project.
     
    Last edited by a moderator: Feb 6, 2016
  6. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    If you want precise control over the character's behavior, then you should turn physics off (set isKinematic to true on the rigidbody, or remove the rigidbody entirely if you don't need the physics engine to handle collisions). This is what I do in many of my games. Getting the physics engine to do exactly what you want is often much harder than implementing simple physics yourself.
     
  7. shaderbytes

    shaderbytes

    Joined:
    Nov 11, 2010
    Posts:
    900
    Problem here is you are trying to mix using the physics engine and not using it in a bad way in your example already.The problem with your idea is that you are expecting to get a proper velocity from your rigedbody and you are moving the object via setting its transform position directly, which you should not do for non- kinematic rigedbodies. Handling a rigedbodies position outside of the methods provided to move it will probably result in an incorrect velocity recorded internally. I cant say exactly what it would report but I assume it wont be correct since the physics engine didnt move it ... you did ;)
     
    JoeStrout likes this.
  8. shaderbytes

    shaderbytes

    Joined:
    Nov 11, 2010
    Posts:
    900
  9. Deleted User

    Deleted User

    Guest

    I'm not skilled enough to achieve this. I am about to start experimenting with raycast though. I imagine raycasting is a huge part of a kinematic setup. I need world geometry to act on the vehicle as expected, but otherwise to control it entirely myself as a learning exercise. That brings me close to doing a fully kinematic setup. That's just worrying about doing movement right and not worrying about collisions or how collisions would alter movement.

    That's what the API says, and so far it's OK. Velocity seems to behave predictably. I don't think you'd want so much running in fixedupdate, but remember the scope of the project is literally a controller and one scene with three clases and a UI that only does some .ToString text.

    You have to start somewhere. I'm well past "roll a ball" but well aware of my limitations.