Lerpの戻り値を次の開始位置として更新するLerpの処理

Question

前提・実現したいこと

下記はUnityの書籍のコードの一部を抜粋したものですが
(Unity標準アセットのSmoothFollow.csを改造したものらしく、ほぼSmoothFollow.csのコードでした)、
このLerpにおける処理に関して質問です。
Lerpの戻り値を開始位置として更新するLerpの処理とはどういうものなのか、
また、Time.deltaTimeを掛けている理由やコード中のheightDampingについて
ご教示お願いします。

		//高さに変化を加えるときにどのくらい遅延させるか。
		[SerializeField]
		private float heightDamping;

		void Update()
		{
			var currentHeight = transform.position.y;
			var wantedHeight = target.position.y + height;
			currentHeight = Mathf.Lerp(currentHeight, wantedHeight, heightDamping * Time.deltaTime);
			transform.position = new Vector3(transform.position.x ,currentHeight , transform.position.z);
		}

試したこと

簡単な数に置き換えて試してみました。

		float i = 0;

		// Update is called once per frame
		void LateUpdate()
		{

			float j = 24;
			i = Mathf.Lerp(i, j, 0.5f);
			Debug.Log(i);
		}

出力結果。

12
18
21
22.5
23.25
…

出力結果から、これはイージング処理になるのではないかと思いました。
続いて、Time.deltaTimeで試してみました。

		float i = 0;
		float t = 0;

		// Update is called once per frame
		void LateUpdate()
		{
			float j = 24;
			i = Mathf.Lerp(i, j, Time.deltaTime * 5);
			t += Time.deltaTime;
			Debug.Log(i);
			Debug.Log(t);
			if(t>5){
				Debug.Break();
			}
		}

5秒後に終点に収束になるのかと予想したのですが、出力結果はそうではなさそうでした。
t==2.972162の時点で、i==23.99999の値を取っていました。
Time.deltaTimeを使っている理由がやはりわかりません。

以上を踏まえて質問です。

・質問1。
「Lerpの戻り値を開始位置として更新するLerpの処理」は、イージングになるという認識で合っていますか？
また、それは必ずEase outのイージングになるということでしょうか？
例外や間違いがあればご指摘お願いします。

・質問2。
Time.deltaTimeを使っている理由や効果は何ですか？
指定時間でLerpが終点に収束したりするのでしょうか？
書籍のコードだけならば、何かの間違い、誤植かなと思ったのですが、
Unity公式アセットでもTime.deltaTimeを書いているので、何かしらの意味はあるのではないかと思っています。

・質問３。
heightDampingは、どういう役割を果たしていますか？
書籍のコメントの「遅延させるか」というキーワードが引っかかって、気になったのですが、
Lerpは初めから開始されているので(出遅れてLerpが動いているわけではないと思うので)、
遅延の意味がよくわからないと思いました。
イージングの調整値で合っていますか？
また、heightDamping * Time.deltaTimeが1だったら、一気に終点に来てしまうと思うので、
heightDamping * Time.deltaTime < 1 を満たすようなheightDampingの値を設定すればよいという認識で合っていますか？
(heightDamping自体は1未満であろうと1以上であろうと特に問題ないという認識で合っていますか？)
また、試したことで、heightDampingの時間で終点に辿り着かないという認識で合っていますか？
それともheightDampingは何か時間に作用するものでしょうか？

・質問4。
終点に収束するまでは、Lerpを動かして、収束、もしくは超えたら、
終点に設定するみたいなコードを書きたいのですが、
下記「if(i < j)」の条件だと、ずっとこのif文に引っ掛かるので、
終点への調整処理みたいなのは、どういった書き方をすればよいですか？

			float j = 24;
			if(i < j){
				i = Mathf.Lerp(i, j, Time.deltaTime * 5);
				Debug.Log(i);
			}else{
				i = 24;
				Debug.Log("Break");
				Debug.Break();
			}

Answer 1

質問1について
はい、イーズアウトの一種と言えそうですね。毎フレーム「残りの距離の0.0???...倍だけ目的地に近づく」ということを繰り返すわけですので、回数を重ねるほど残りの距離が短くなり、残りの距離に比例して1回の移動距離も減っていくのでどんどん減速していくでしょう。

質問2について
deltaTimeを組み込んでいるのは、フレームレートが変化しても動きをなるべく同じように見せようとしてのことかと思います。
たとえば30FPSの状況では毎秒30回のペースで目的地に近づいていくでしょうが、60FPSだと毎秒60回のペースになりますので、近づく割合が一定だと60FPSでは30FPSよりも素早く近づいていくように見えるでしょう。
そこで割合にdeltaTimeをかけると、60FPSの時のdeltaTimeは30FPSの時の半分ですから、1回の移動量も半分になってちょうどいい...という理屈かと思います。

質問3について
これについてはご質問者さんのおっしゃる「イージングの調整値」という認識で問題なさそうです。おそらく著者の方もそういう認識だろうと思いますが、「遅延」という言葉を使ってしまったのはまずかったかもしれませんね。おっしゃるように「動きを開始する時刻を遅延させる」ともとれてしまうような表現になっています。
heightDampingに関するその他の認識もその通りかと思います。heightDampingが表す値には時間の意味合いは薄く、もっと大雑把な調整値という認識でいいんじゃないでしょうか（数学的に考えると永遠に目的地に到達しないはずですしね...）。

質問4について
数学的にはいつまで待ってもi >= jにはならないでしょうから、条件としてはApproximatelyを使ったりMathf.Abs(j - i) < 0.001fみたいにあそびを設ければいいんじゃないでしょうか?

質問2について補足
移動量調整としてdeltaTimeをかけるだけでいいのか気になるかもしれません。確かに数学的に考えると不十分かもしれませんが、実用上は問題ないと思います。
下記のようなスクリプトを用意して...

using System;
using UnityEngine;

public class LerpAndDeltaTime : MonoBehaviour
{
    public enum Mode
    {
        Coarse,
        Fine
    }

    [SerializeField] private float deltaTime = 1.0f / 60.0f;
    [SerializeField] private float duration = 2.0f;
    [SerializeField] private Mode mode;
    [SerializeField] private GameObject dotPrefab;

    private float time;

    private void Start()
    {
        var fineModeFactor = Math.Log(Math.Pow(1.0 - (1.0 / 60.0), 60.0));
        var y = 0.0f;
        while (this.time < this.duration)
        {
            switch (this.mode)
            {
                case Mode.Coarse:
                    // 単純なdeltaTimeによる調整
                    y = Mathf.Lerp(y, 1.0f, this.deltaTime);
                    break;
                case Mode.Fine:
                    // 60FPSのときのカーブに近づくよう補正した調整
                    var t = (float)(1.0 - Math.Exp(fineModeFactor * this.deltaTime));
                    y = Mathf.Lerp(y, 1.0f, t);
                    break;
            }

            this.time += this.deltaTime;

            Instantiate(
                this.dotPrefab,
                this.transform.position + new Vector3(this.time, y, 0.0f),
                Quaternion.identity,
                this.transform);
        }
    }
}

フレームレートが変わるとイージングのカーブにどのような変化が生じるか見てみました。
単純にdeltaTimeを使った場合（Coarseモード）ですと、下図のように微妙にカーブが変わってしまいました。とはいえ、10FPSぐらいにまで落ち込んでようやくずれが見えてくる程度ですので、通常は気にする必要はなさそうです。

一方Fineモードではもっとましな調整をしたつもりです（あんな式でいいのか検証不足なので、間違いがあるかもしれません）。

ですがわざわざExpなんかを使ってまで調整精度を上げるだけの価値があるかというと微妙でした。

計算量削減、基準フレームレートとイージング調整値を変更できるように修正

using System;
using UnityEngine;

public class LerpAndDeltaTime : MonoBehaviour
{
    public enum Mode
    {
        Coarse,
        Fine
    }

    [SerializeField] private float deltaTime = 1.0f / 60.0f;
    [SerializeField] private float duration = 2.0f;
    [SerializeField] private Mode mode;
    [SerializeField] private GameObject dotPrefab;
    [SerializeField] private float damping = 1.0f;
    [SerializeField] private double referenceFrameRate = 60.0;

    private float time;

    private void Start()
    {
        var y = 0.0f;
        var referenceDeltaTime = 1.0 / this.referenceFrameRate;
        while (this.time < this.duration)
        {
            switch (this.mode)
            {
                case Mode.Coarse:
                    // 単純なdeltaTimeによる調整
                    y = Mathf.Lerp(y, 1.0f, this.damping * this.deltaTime);
                    break;
                case Mode.Fine:
                    // referenceFrameRate FPSのときのカーブに近づくよう補正した調整
                    var t = (float)(1.0 - Math.Pow(
                                        1.0 - (this.damping * referenceDeltaTime),
                                        this.referenceFrameRate * this.deltaTime));
                    y = Mathf.Lerp(y, 1.0f, t);
                    break;
            }

            this.time += this.deltaTime;
            Instantiate(
                this.dotPrefab,
                this.transform.position + new Vector3(this.time, y, 0.0f),
                Quaternion.identity,
                this.transform);
        }
    }
}

FixedUpdateの世界の時間の流れと実際の時間の流れの比較

using UnityEngine;

public class FixedTimeVersusRealTime : MonoBehaviour
{
    private float previousFixedTime;
    private float previousRealTime;

    private void Start()
    {
        this.previousFixedTime = Time.fixedTime;
        this.previousRealTime = Time.realtimeSinceStartup;
    }

    private void FixedUpdate()
    {
        var fixedTime = Time.fixedTime;
        var realTime = Time.realtimeSinceStartup;
        var fixedDeltaTime = fixedTime - this.previousFixedTime;
        var realDeltaTime = realTime - this.previousRealTime;

        Debug.Log($"Fixed:{fixedTime:F5} Delta:{fixedDeltaTime:F5} Real:{realTime:F5} Delta:{realDeltaTime:F5}");

        this.previousFixedTime = fixedTime;
        this.previousRealTime = realTime;
    }
}

Comments

[退会済みユーザー]

ご回答ありがとうございます。

確認させていただきたいのですが、
今まで、Time.deltaTimeを掛けるのは、
Translateなど物体移動のときに使うものとだけ認識していたのですが、
ご回答いただいて気づいたのですが、Translate等に限らず、
毎フレーム処理で、繰り返し呼び出して値を変化させるものには、
Time.deltaTimeを掛けたほうがよいということでしょうか？
(30FPSの状況で毎秒30回のペースで処理を呼び出して値を変化させるのと、
60FPSの状況で毎秒60回のペースで処理を呼び出して値を変化させるのとでは、
60FPSでは30FPSよりも早く値が変化してしまうので、
変化する割合にdeltaTimeをかけて、60FPSの時のdeltaTimeは30FPSの時の半分なので、
1回の変化量も半分になって、30FPSと60FPSで変化に差異がなくなるということでしょうか？)

Mathf.Expでの検証コードありがとうございます。
Time.daltaTimeの方でも30FPS～240FPSの範囲では問題ないということで、
安心しました。
Mathf.Expのほうは数式的な理解は追いつかなかったですが、
結果の画像から、そのようなコードで精細にFPSの差異をなくすことができるのですね。
ゲーム開発でも、何か正確な物理シミュレーションが必要なときは、
こういったコードで対処できるということが勉強になりました。

[Bongo]

そうですね、移動に限らず回転・拡大縮小や、あるいは幾何学・運動学的プロパティに限らず色や透明度のようなものを変化させる場合でも、deltaTimeをかける処置の出番は多いと思います。おそらく、計算式の形がオブジェクトを移動する場合の式と似ていれば、やはり同様にdeltaTimeをかけてやるべきというケースが多いんじゃないでしょうか。

かといって何でもかんでもdeltaTimeをかけてしまうというのも考えもので、今回のように単純な掛け算では数学的に不適切であるという場合もあるかもしれません（まあ、今回は単純な掛け算だけで効果的に近似ができて有用ですが...）。
他にも「Input.GetAxis("Mouse X")」みたいに潜在的にフレームレート非依存性を持っている値にさらにdeltaTimeをかけてしまうと、かえってズレを大きくしてしまうといった罠がある場合もあるでしょう（参考：https://sleepygamersmemo.blogspot.com/2017/08/unity-mouse-input.html ）。

やはりなるべく処理内容を把握した上でdeltaTimeをかけるかどうか判断するべきかと思います。ですが全部いちいち考えるのは手間かもしれませんので、ひとまずはゲームプレイに影響が大きいもの（当たり判定に関与するオブジェクトの移動など）から優先して検討するのでもいいように思います。
UIをかっこよく見せるためのアクセント的アニメーションとか、当たり判定の関与しない魔法発動エフェクトみたいなものは、見た目がおおむね問題なければフレームレート変動対応をシビアに行う必要はないかもしれません。

※それとすみませんが、イージングカーブ実験用コードのFineモードの計算量にまだ削減の余地がありました（式変形が足りていませんでした）。指数関数と対数関数を1つずつ削除でき、超越関数の数を指数関数1回までに抑えることができそうです。
さすがに単純にdeltaTimeをかけるだけの調整よりは計算コストがかかりますが、案外気軽に使っても代価は安いかな...という気がしてきました。

[退会済みユーザー]

ご回答ありがとうございます。
長くなってしまってすみません、最後の質問をさせていただけたらと思います。

Time.deltaTimeなのですが、使う理由や効果は、次の2つになりますか？

・Update関数の呼び出しや、コルーチンのyield return nullのループのような毎フレーム処理では、
　フレーム毎の呼び出しの時間間隔が一定ではない為(可変フレームレートの為)、
　これらの毎フレーム処理で値の変化処理を行うと、フレーム間の値の変化量に差異が生じる。
　この差異をTime.deltaTimeを掛けることによって無くし、変化量を一定にすることができる。

・FPSが異なる他のデバイスとの差異を無くす為に、Time.deltaTimeを掛ける。
　(前回のコメントの30FPSの状況と60FPSの状況のお話)

今まで、前者の方しか認識していなかったので、わからなかったのですが、
以前、下記URLのような質問をしまして、
https://teratail.com/questions/44392
このとき、質問③の疑問が解決してなくてモヤモヤしてたのですが、
今回教わったことで気づきまして、
「FixedUpdateやyield return new WaitForFixedUpdate()のループのような
　固定フレームレートの繰り返し呼び出し処理で値を変化させる場合でも、
　FPSが異なる他のデバイスとの差異を無くす為に、
　Time.deltaTimeは掛けたほうがよい」ということで合っていますか？

Input.GetAxis("Mouse X")はフレームレート非依存だったのですね。
勉強になります。ありがとうございます。

なるほど、UIアニメーションやエフェクトのスピードなどにずれが生じても問題ないですね。
ゲームプレイの本質に関わるところで、Time.deltaTimeを掛けることに気を付けたいと思います。

イージングカーブコードのご訂正ありがとうございます。
私の数学の理解が未熟の為、こちらのコードはゆっくり勉強させていただきたいと思います。

[Bongo]

はい、まず前半部の2つについては妥当な認識かと思います。deltaTimeをうまく使うと、処理負荷の変化などによるフレームレートの変動だけでなく実行環境の違いによるフレームレートの変化にも併せて対応できるでしょう。

FixedUpdateでもdeltaTimeを使うべきかという件についてですが、こちらの場合はUpdateとは違ってdeltaTimeを使わなくても負荷の変化・実行環境の変化によらず動きは安定していて問題にならない場合がほとんどじゃないかと思います。ただし、動作の調整のために「Edit」→「Project Settings...」→「Time」の「Fixed Timestep」をいじったり、スクリプトからTime.fixedDeltaTimeを変更したりすると、deltaTimeを考慮していない場合は急に動きが変化して修正に手間がかかるかもしれません。個人的にはFixedUpdateでも適切にdeltaTimeを使っておいた方が望ましいように思います。

ですが、「Time.deltaTimeについて。」の質問③のコードの場合はまた違った問題がありそうです。「rb.MovePosition(rb.position + Vector3.up * Time.deltaTime * d);」のような形なら「毎秒dメートル進む」という動きをさせられるでしょうが、AddForceを使ったのではうまくいかないでしょう。おそらく最初は非常にゆっくり動き、そのまま眺めていると次第に加速していくはずです。あるいはもし重力が作用していれば、重力加速度に負けてまったく動かないかもしれません。
AddForceの引数に渡すべきなのは加える力を表すベクトルで、大きさの単位はニュートン（https://ja.wikipedia.org/wiki/%E3%83%8B%E3%83%A5%E3%83%BC%E3%83%88%E3%83%B3_(%E5%8D%98%E4%BD%8D) ）です。これにdeltaTimeをかけるケースはすぐには思いつきませんが、めったにないんじゃないでしょうかね...?

[退会済みユーザー]

ご回答ありがとうございます。
すみません、さらに勘違いをしていたかもしれないので確認させていただきたいのですが、

Updateのような可変フレームレートの呼び出しは、
デバイス(実行環境)ごとにFPSが異なり、
FixedUpdateのような固定フレームレートの呼び出しは、
デバイス(実行環境)が異なっても、Fixed Timestepで設定されている
時間間隔で共通して呼び出されるので、同じFPSになる。

ということで合っていますか？
(FixedUpdateの呼び出しもデバイスが異なるとFPSが異なると勘違いしていました)。

なるほど、MovePositionなどには有用で、
AddForceには、ニュートンの値を渡すので、使うケースはなさそうということですね。

[Bongo]

はい、そういうことです。もちろんタイムステップを0.02秒にしたとしてもUnityが本当にぴったり0.02秒ごとにFixedUpdateを実行するわけではないですが、Unityの世界の中のオブジェクトにとっては0.02秒ずつ時間が進んでいるように見えるので問題ないのでしょう。
FixedUpdateの世界の時間と現実の時間の比較を追記しましたが、FixedUpdateは時々とても早い間隔でループが回っています。Updateの時間の流れとタイミングを合わせるため、1フレーム中に複数回FixedUpdateが実行される場合があるというわけですね。

[退会済みユーザー]

ご回答ありがとうございます。
FixedUpdateの世界の時間と現実の時間の比較のご提示ありがとうございます、拝見しました。
なるほど、実際はFixed Timestep通りに実行されるというわけではないのですね。
全ての疑問が解決しました。
とても勉強になりました。
本当にありがとうございます。