Mathf.Sin(Time.time)

Unity Courses Talk
,
#1

Following on from the previous lecture…

Instead of creating vars for ‘cycles’ and ‘tau’ (which went a little over my head, tbh) I just added in the following statement inside Update():

movementFactor = Mathf.Sin(Time.time)

This worked a treat for me and allowed the platform to oscillate nicely back and forth without any of the headache trying to understand tau, radians, etc.

Can anyone please explain to me why my solution is sub-optimal when compared with Rick’s? (I’m sure it probably is but - since it seems to achieve the same results - I’m not sure why…)

Many thanks!

#2

The solution is perfectly fine, and not at all sub-optimal (even when compared with Rick’s) :slight_smile:

#3

it works because that’s exactly how the Sin function works. Time.time returns the amount of time since the game started, and so it is a value that increases and increases, whereas the Sin functional will constantly and smoothly oscillate between -1 and 1 as the input value you send it increases

#4

Amazing :slight_smile: Thanks again for the reply and for explaining this. Glad to hear my solution isn’t as dumb as I feared it might be…!

1 Like
#5

I spent some time to understand what’s going on, maybe it will be useful)
Dividing current time to period variable is needed to control speed of movement. In this case it slows down it in 2 times.
Multiplying to tau is needed to get radians.

In your case Time.time gives a float value. And between 0 to 6.2… function draws full cycle or Circumference, gives value from 0 to 1 from 1 to 0 then it repeat process. But the function thinks that you are feeding it with radians)

Hopefully I understood it right)

#6

The main perk to doing it Rick’s way is that you get the ability to change the period value in the editor to make it complete a full cycle faster / slower. The “offset” is basically how far you want the obstacle to travel, and then period is how quickly you want it to travel.

There’s other ways to acheive this using your method but a lot of the time in game design you’re sort of building and engine inside an engine so that you can design the other features on top without creating bugs or having to do weird hacks to get a desired outcome

#7

Ummm you can control the cycle here too, due to the fact that Time.time returns (real) time since started, so it is time frame independent and can be combined with any constant variable

[SerializeField] float cycleFactor = 1f; // can be changed in the inspector

movementFactor = Mathf.Sin(Time.time * cycleFactor)
#8

Yeah that obviously works, I just figured the OP was trying to avoid using the additional factors :sweat_smile:

#9

Thanks for the feedback, everyone :slight_smile:

Privacy & Terms