Cursed gravity with rigidbody2d

Unity Engine
,
1

I just started to use Unity and saw that bodies is falling really slow like they have
weightlessness IV
In Edit>Project Settings>Physics 2D>gravity on the Y is base -9.81

I added to script in function update() this line:

Debug.Log(transform.position.y + " " + (9.8f * Time.time * Time.time)/2f);

and let the body fall from (0.0) position

I noticed that
Falling velocity depends of is body chosen in samplescene or not

While body falls to 100 units in editor it must have fallen to 300 or 2500 units
7627927--949198--upload_2021-11-4_14-13-53.png

Then i created script “Check”

using UnityEngine;

public class Check : MonoBehaviour
{
    // Start is called before the first frame update
    void Start()
    {
      
    }

    // Update is called once per frame
    void FixedUpdate()
    {
        Debug.Log(transform.position.y + " " + (9.8f * Time.time * Time.time)/2f);
    }
}

and all works correctly
7627927--949201--upload_2021-11-4_14-17-43.png

i did not understand what is going wrong
i don’t want to use kludge like “just make gravity 30f” i want to know how to fix gravity to it’s normal value

2

Please use code-tags when posting any code and not plain-text.

It’s moving at a realistic rate. It’ll be your view scale. If you look at planes flying in the sky, they seem to move slow yet they are moving fast. If it were 100m above your head it’d seem fast. It’s all about view scale.

I would recommend watching this great talk by Bennett Foddy. The specific talk about units starts at 4mins in:

3

Seems like you read the top but didn’t saw the first screenshot of debugger where numbers 99 and 2371 did not match because body is falling really really slow

Thanks for the video, but i think you missunderstand me.
body tall is just 2 units and it falls with different velocity in different framerate

4

I read it but your post is hardly clear on stating what you see against what you expect.

it doesn’t matter if your “body tall is just 2 units” if you’re viewing a huge camera area which is why I said view-scale.

Sorry but that’s not true if you’re running physics during the fixed-update so there’s absolutely no frame-rate dependence.

Each simulation step the gravity term multiplied by the body gravity scale multiplied by the delta-time is added to the velocity. Velocity is then integrated to give change of position.

I have no idea what you’re hoping to achieve by outputting “(9.8f * Time.time * Time.time)/2f);”. Look at Rigidbody2D.position and Rigidbody2D.velocity.

5

I wrote that Firstly i saw the low speed
And Secondary i tried to experimentally prove it

I’m outputting transform.position.y and 9.8f * Time.time * Time.time)/2f because i need to match the real path of falling body (by coordintates) and imaginary (by formula) to understand does body falling like it should or not
7629583--949510--upload_2021-11-4_23-44-56.png
Rigidbody2D.position is the same as transform.position.y so there is nothing new and nothing wrong

I didn’t believe my eyes, but numbers can’t lie and if numbers says that body takes less path then it was should to take during same time then it is incontestable proof that it’s falling velocity is smaller then it should be

(So you had not try to answer why real path is egual to imaginary path when i using FixedUpdate and isn’t equal when i using Update)

6

Remember this doesn’t necessarily start at zero the moment your script starts running.

It is at zero when the GAME starts running, and steadily counts up. By the time your scene is loaded and running, who knows where it is?

Instead, track your own time as a float and see.

As @MelvMay and the video points out above, it all will work exactly as you expect, within the confines of the step resolution of FixedUpdate().

7

Body start falling from (0.0) when scene is loaded and i’m working with one scene, so WHERE and WHEN is determined and i think there is no need of float variable “time”