Slerp interpolation in docs uses Time.time....why?

Unity Engine
1

I need a head-check…

The example in the docs here: Unity - Scripting API: Quaternion.Slerp
Shows Time.time being used. Wouldn’t this eventually go above 1 and make all rotations instant? I thought Slerp takes a value for interpolation that is basically a normalized percentage 0.2 = 20% between here and there.

Edit: I forgot to mention that I’ve been using Time.deltaTime (* my speed) and it seems to do what I want consistently (works with Time.timeScale).

2

yupp it would
makes no sense at all, there is no Time variable to replace it with to make it any more correct than this incorrect code, as the correct code would have a variable startTime and then use (Time.time-startTime) * speed or alike

3

(btw I edited my original post while you typed that.)

Right. That is the case if you needed to execute a rotation that you trigger and it goes until done, but if you want something to smooth/chase a rotation, like a turret turning toward an enemy, you’d update the “from” rotation every frame, take a step towards “to” and go to the next frame to repeat. This is when using ‘Time.deltaTime * mySpeed’ makes sense, since it will turn slower if you want to use Time.timeScale for something like a slow motion mode. (I know you know this, I’m directing this at the internet-ether).

On a related point: I just added a pretty clean implementation of this to a “constraint” component I’ll be releasing in the next day or two. I’ll post a link when it goes up. It lets you use any axis, has liner, spherical and spherical limited (RotateTowards). I’m adding axis constraints now (hope I have time). We’ll be using this to drive all of our towers in our TD game and most have separate objects for turn and tilt.

4

Thats the target yes. But with Time.deltaTime*speed that is not what will happen.
Reason is that from and to don’t change and the interpolation time param you give will not change either if you do not

  1. use a delta time measuring as I suggested
  2. alternatively use a time accumulator

with what the code is there you could just as well write 0.0016 into the time parameter and it will always have the rotation thats “0.0016to + 0.9984from”, no changes, assuming you are on 60FPS

5

I’m not sure which part you are referring to with this comment.

You are right that ‘Time.deltaTime * speed’ produces a “constant” as opposed to a value which accumulates, however, it nicely incorporates the functionality with the game’s time. We give the player the ability to change the timeScale so this is a good solution. The scale is just a variable for the script component. Also, with a speed of 1 here and in Quaternion.RotateTowards() you end up with a fairly matched result as far as the speed which the object rotates, which is nice in the case of our new constrain component that we will be distributing - it is user friendly. I could also multiply by timeScale, but this gives a cleaner result so far.

Again, I’m only talking about a situation where you are changing the from rotation every frame as a way of smoothing a rotation, or interpolating towards a rotation. If you were simply going from A to B over X time, then none of this comment applies and I would absolutely create a timer.