#Rotation and Movement

1 messages · Page 1 of 1 (latest)

errant spire
#

that video is a detailed showcase of a problem, if you'd like to see just what's wrong with the rotations and speed you can skip to 2:20

#

Rotation and Movement

toxic lake
#

Have you followed some guide on Movement and Rotation using Coroutines?

errant spire
#

what?

#

I am not trying to make movement

#

it's just called rotation and "movement" because it's moving too so I didn't know what else to name it

toxic lake
#

Alright. Explain what mechanic you're working on, and what the problem is.

errant spire
#

I need it to happen in exactly one second so let's say that rotation speed Z is 30, I need it to rotate on a Z axis in exactly one second

#

same goes for movement but instead of rotating I need it to move for that amount in a second

#

I would like to avoid all of this being in an Update loop since coroutines are just much cleaner and easier to reuse and stuff

toxic lake
#

I recently had a conversation with someone much more experienced than myself, and I voiced my interest in exploring Movement based on Coroutines, but was told emphatically that it would be using a tool in a way it was not meant, and in a way that is overly complicated, and in a way that is ultimately not necessary.

Since you have set this up already, I'm not going to dissuade you. That's up to your own judgement.
However, I can't imagine anyone here will be able to help you, unless you spam this issue for a week.

I have no special confidence that I can help you solve this, unless you want to rewrite the thing to work in the update loop.
Yet, I have some questions and a few things to point out.

errant spire
#

Sure, I can do it in an update loop but that's say 100 more Update loops/beat

#

this script is attached to every object so that's a lot more Update loops which I am not sure is too performant

#

coroutines on the other hand are ran on other threads from what I know

toxic lake
#
// Can only be stopped by StopAllCoroutines()
StartCoroutine(Move());

// Can be stopped
private IEnumerator DoMove;
//...
DoMove = Move();
StartCoroutine(DoMove)
errant spire
#

although I don't see a reason for it since the object should be moving pretty much it's whole lifetime

errant spire
toxic lake
#

You can store a Coroutine type reference from the return of StartCoroutine() yes
IEnumerator is a more prepared approach. (doesn't matter)

errant spire
#

but some levels in geometry dash have millions of objects so I guess this game would have at least 1000-10000 at most ig

toxic lake
#

Well, unless you are already experiencing issues, optimization should come last.

#

What I wonder is, are coroutines really more efficient?
In some scenarios they could, but you seem to be running them every frame either way, and for visual changes it makes sense to do just that.
Is there something I'm missing?

#

@errant spire

errant spire
#

but sure let's do that again because everyone is telling me to do it even tho I said it's not working

toxic lake
#

Alright, last two things tho:

errant spire
#

will let you know when I rewrite the code and see if anything changed

toxic lake
#

inside the Move and Rotate coroutines,
inside and at the end of the while loop, yield return new WaitForEndOfFrame, I think that essentially brings you to LateUpdate()
And after the while loop, there is yield return null which is normal to use in a coroutine, when suspending it until the next frame.
goto Beginning will never run, and doesn't have to be there.

#

Long story short, I believe you could shorten the existing code by removing the first and last two lines in the coroutines, and changing yield return new WaitForEndOfFrame into yield return null;

toxic lake
#

@errant spire
No need for a coroutine on this one.

Destroy(gameobject, levelObject.levelObjectStats.lifeTime)
errant spire
#

it's exaactly the same

#

like if I didn't change anything at all

#

I would really appreciate somebody helping me with this

errant spire
errant coyote
#

the bottom line doesn't really make sense to me. You are lerping from current rotation to target rotation, with lerpAmount which is in range 0..1?

#

maybe you want something like
transform.rotation = Quaternion.Slerp(originalRotation, Quaternion.Euler(targetRotation), lerpAmount);

#

and originalRotation would be the default/zero rotation you want for that object.

#

@errant spire

errant spire
#

so I am resetting it to 0 every time it gets to 1 and changing the target position to a new one by doing t.pos + lvlObjS.speed

#

same goes for rotation

errant coyote
#

I know what youre trying to do

errant spire
errant coyote
#

You usually lerp like this:

var currentValue = Mathf.Lerp(startValue, endValue, t);
where t is in range 0..1.

OR:
currentValue = Mathf.Lerp(currentValue, targetValue, speed * Time.deltaTime);

#

you are currently doing a mix of both. And it wont work.

errant spire
#

that might be what's causing the rotations to go crazy when they hit -0 but still doesn't solve the problem where it just gets paused for a second after each lerp

errant coyote
errant spire
#

oh... I somehow managed to completely miss that

errant coyote
errant spire
#

let me correct that mistake, it'll prob fix one part of the problem but not sure about the pause

errant coyote
#

Idk anything about any pause, just looking at your rotation code

errant spire
errant spire
errant coyote
#

no idea what im looking at 🤷‍♂️ words would be cool.

errant spire
errant coyote
#

Wanted to add: using Vector3.Lerp with euler angles will not work like you think it will. It should be used with positions only

errant spire
#

same happened with rotation

errant spire
errant coyote
#

@errant spire

#

take 1 problem at a time

errant spire
#

so yeahh... this somehow managed to fix all of the problems

errant coyote
#

I explained everything you did wrong

errant spire
#

I do get how doing Quaternion.Slerp would fix rotations going crazy but the part where it just froze for a second after moving from point a to point b being fixed doesn't make sense to me at all

errant spire
errant coyote
errant spire
#

I might just be too tired to think I don't know, in any case thanks a ton!

errant spire
errant coyote
#

you mixed those two methods

#

of lerping

errant spire
#

yes I do know, I didn't store my starting value(which I am doing now) but I don't get how storing it fixed the object staying in place for a second after reaching point b

#

I don't wanna bother you with it you must have something else to do, as I said thanks a ton for helping me solve this!

errant coyote
#

yeah np 👍