#Frame rate dependant stuff

1 messages · Page 1 of 1 (latest)

oak moon
# 
    void Update()
    {

        Vector3 forward = rb.rotation * Vector3.forward;
        Vector3 right = rb.rotation * Vector3.right;
        Vector3 up = rb.rotation * Vector3.up;


        Debug.DrawRay(rb.position, forward, Color.blue);
        Debug.DrawRay(rb.position, up, Color.green);
        Debug.DrawRay(rb.position, right, Color.red);
    }

should give you the correct lines that unity shows you

#

only wrote it in update so you can see the lines appear, but should be in fixedupdate still

#

And no you dont need to convert rb.rotation. Unity has a quaterion * Vector3 declared, meaning it is a valid way of rotating a vector. We are rotating the world direction of "Vector3.up" to a local direction based on the rb rotation

prime temple
#

Ah I see

#

Will try it out in place of the transform.directions

oak moon
#

these directions also probably arent the main source of the issue. I want to believe its the groundCheck.position but both are probably contributing to it.

#

so what I would do is just simply have a vector3 for the ground check offset. So then you do
groundCheckPosition = rb.position + offset
and suddenly its now in line with the rb position. Right now, especially with interpolate on, your objects are moving every frame and thus the child objects are too

prime temple
oak moon
#

its weird that the lines are so long too, and showing after a delay as well

prime temple
#

I believe it's rotating both in the transform and probably the rigidbody?

prime temple
oak moon
#

its only 1 unit long, because Vector3.forward and the rest are as well. its just simply rotated

#

theres a good frame too where lines are a normal length, but suddenly they expand out. Can you show anymore code like whats actually rotating this object?

#

Like whats keeping the rigidbody stuck to the wall

prime temple
#

I think the value that is 1 is being directly multiplied by the rb.rotation

#

it seems to be lines up

oak moon
#

Oh is it just the addForce doing that, and the rb is rotating via physics?

prime temple
#

Yea, addForce is supposed to add a force downwards to the player, negating gravity and allowing them to stick to the circle slope

oak moon
#

😅 alright this is suddenly confusing, though im assuming its probably a difference in 2D thats causing this because i use 3d mainly. the lines work for me on a basic cube that isnt moving around

5eecdf70b22e2bb24120615486dc0a3d.png
prime temple
#

Yea probably

#

I think the rb.rotation value is directly changing the length of the vector distance

Screenshot_2024-06-11_192808.png
oak moon
#

OH... rb2d.rotation is a float...

#

🤦‍♂️ goddamn

prime temple
#

haha

#

should I use this in that case?

Vector3 rightDirection = new Vector3(Mathf.Cos(rb.rotation * Mathf.Deg2Rad), Mathf.Sin(rb.rotation * Mathf.Deg2Rad), 0);
            Vector3 upwardDirection = new Vector3(Mathf.Sin(rb.rotation * Mathf.Deg2Rad), Mathf.Cos(rb.rotation * Mathf.Deg2Rad), 0);
oak moon
#

ah 2d sucks ass. ok i think this should work
Quaternion quatRotation = Quaternion.AngleAxis(rb.rotation, Vector3.forward);

#

you can use trig and stuff but i dont like to

prime temple
#

should I be using Vector3.right and up? I think forward is towards the screen in 2d

#

ah maybe I'm speaking non sense

oak moon
#

This would just be simply getting the rotation in terms of a quaternion. Really you dont even need the forward direction since u arent using it

#

theres a ton of ways to calculate the directions but i just know it from heart based on quaternion math.

prime temple
# 
Quaternion quatRotation = Quaternion.AngleAxis(rb.rotation, Vector3.forward);
            Vector3 rightDirection = quatRotation * Vector3.right;
            Vector3 upDirection = quatRotation * Vector3.up;
#

Is this correct?

oak moon
#

should be fine

prime temple
#

And my ground functions

    public bool isGrounded()
    {
        Vector3 groundCheckPosition = rb.position + new Vector2(0, -0.445f);
        return Physics2D.OverlapBox(groundCheckPosition, new Vector2(0.57f, 0.025f), 0, groundMask);
    }

    public bool isSloped()
    {
        Vector3 groundCheckPosition = rb.position + new Vector2(0, -0.445f);
        return Physics2D.OverlapBox(groundCheckPosition, new Vector2(0.57f, 0.35f), 0, slopeMask);
    }
oak moon
#

yea should be good as well

prime temple
#

oh wait the offset needs to take into account the rb angle haha

oak moon
#

maybe you also do want to provide an angle for that box, but i dont think that'd specifically be an issue considering that isnt frame rate dependant. the position of the overlap box would be the frame rate dependant part

#

oh yea sorry, it has to use the -up

prime temple
#

Like this? 😅

    public bool isGrounded()
    {
        Quaternion quatRotation = Quaternion.AngleAxis(rb.rotation, Vector3.forward);
        Vector3 upDirection = quatRotation * Vector3.up;
        Vector3 groundCheckPosition = rb.position + -upDirection * new Vector2(0, -0.445f);
        return Physics2D.OverlapBox(groundCheckPosition, new Vector2(0.57f, 0.025f), 0, groundMask);
    }
#

ignore -0.445 it should be positive

oak moon
#

you would want that 0.445f to be just a number, not as part of a vector. Im not even sure that line would compile because u cant multiply vectors

prime temple
#

oh alright haha

oak moon
#

i would also just pass the up direction as a parameter, but for the time being just see if it works

#

because its already being used in fixed update, so no need to recalculate it

prime temple
#

fair enough

oak moon
#

uh looks alright but just to be safe you could debug what that position is. Even just by doing
Debug.DrawRay(rb.position, -upDirection * 0.445f). And maybe put those
-upDirection * 0.445f in brackets so you are sure about the order of operations

prime temple
#

I ran the game, now, the different frame rates aren't 100% equal, but it does seem significantly closer to one another, to the point I think it may not frame dependent?

oak moon
#

Looks a lot closer at least yea

prime temple
#

It also seems to be deterministic now? Running it multiple times, the different frame rates seem to giving the same results

#

the same slightly different results albeit

oak moon
#

Try double checking those directions because i didnt fully go through to ensure the math was correct. One thing could simply be because you have interpolate on. this could cause a difference in what the top height is but i do see even in one run that cube is rotating slightly

prime temple
#

Alright

#

the ray seems correct

#

given transform.position is different to rb.position, when pausing the same, this different seems to correspond to the ray's offset from transform.position

oak moon
#

because im too tired to actually go through that math again 😅

prime temple
#

Given how small these differences seem to be, I'd be willing to call that the inevitable frame rate physics difference and go with it

#

It seems to me that it's barely at all frame dependent, and I'd call that a huge win

#

I can't thank you enough for your help

#

It's weird that only this particular aspect of the physics in my original project had such noticeble frame dependency

#

like I'd test other aspects from a set potion, and the difference in the positions of the end results were so fractionally small

#

just gotta hope I can successfully incorporate the changes you showed me into my original project

oak moon
#

I didnt fully go through the logic of why one would launch higher, but its most likely because one frame rate would move the object in a way so that it didnt appear grounded or sloped.

#

Which likely caused it to launch earlier/later or whatever

prime temple
#

Oh yea just one question

#

In tutorials that can be found in Youtube, I've never seen such in depth logic be necessary for a ground check

#

Would that mean this rb.position code, which to me I've never seen used in this way and is new to me, is really only needed for like, really keeping things organised and to make sure things to properly

#

Sorry if my words don't make too much sense in what I'm saying, english is my second language

oak moon
prime temple
#

Also, huge props to you, you took like an hour out of your day just to help a stranger fix a niche bug

#

🙏Huge thanks

oak moon
# prime temple Would that mean this rb.position code, which to me I've never seen used in this ...

realistically you should be using it, if you want to respect proper physics. There are definitely cases you dont need it, like in my game i move via physics and have child objects that indicate where the player should spawn projectiles. I just use the childObjectName.position and yea there will never be a noticeable difference unless some nerd comes along, decompiles/mods the game to check, and points it out

oak moon
#

i hope my point above about where its not needed is clear though

prime temple
#

the physics in my original game behaved as close as I could make it to the Sonic platformers back in the 90s, which I guess could get quite maths heavy or complicated at times, causing it to the need the indepth code you showed me

prime temple
oak moon
#

even for me its hard to really suggest cases where you should use rb.position or where you can get away with transform.position. I think from this day though you can probably see its use case. Basically if something actually relies on where the rigidbody is then you need it. But knowing what "relies on where the rigidbody is" might be confusing

prime temple
#

Given the other aspects of my original project seem to work just fine, I'll probably give this particular aspect of the physics its own ground check code, otherwise I'd be retesting everything else to make sure it still works

#

Once again, huge thanks!

prime temple
oak moon
#

i learned at least 90% of what i know, rotations and that stuff, from just helping/seeing other people help and trying things out myself based on it