かなりふつう

　頭の中では難しいことを考えても、それを実際にモノとして動かすことは大変です。
　今回はほったらかしにしているSlideCameraWorkのフェード動作エンジンリニューアルを、
このままだといつまでもやらないので記事にしてやらざるをえない状況にもっていこう、という
目論見です。

● １，どんな風に動かしたいのか

　今回改良しようとしているのは、カメラの等速移動ではなく、最初がゆっくりで段々速くなり、
後半もゆっくりと止まる自然な動き、いわゆるフェード移動です。現時点でもそれは実装されて
いますが、実はけっこう無理して作ってありまして、使ってみるとけっこう困った動作をすることが
あります。

　現在は、始点から終点までの総フレーム数をＦとすると、0.2Ｆまでそれなりな加速度で加速し、
0.2＜現在フレーム＜0.8の時に最高速度となり、0.8以降で同様の減速を行う作りになっていまして、
１フレーム当たりの移動量はＦの逆数となっています。総フレーム数が多いほど、１フレーム当たりの
移動量が小さい、つまりゆっくり滑らかに動くということです。

　ですがそれだと、低速の時は移動量は小さくないと「低速」と言えませんよね。実は低速の段階
では、総移動距離の0.2倍を目標値として、そこからＦに応じた加速度係数を求め、各フレームの
移動量を割り出しているのです。つまり、Ｆが大きければ移動量が小さくなるのは変わりませんが、
移動距離に達するまでは現在の速度によって移動量が変わるのです。これを逐次積分して正しく
計算すればよいのですが、処理がメンドイのでしておらず、単純に必要移動距離に達するまで、
つまり最高速度に達するまでの指数計算になっているのです。

　一言で言うと、総フレーム数はＦになりません。もっともっと長くなるのです。そのため、
使用者は総フレーム数から計算で総動作時間をリニアに計算することができず、試行錯誤
しながら丁度いい長さと滑らかさになる総フレームを見つけ出さなければならないわけです。
これは総移動距離によっても（計算の丸め等の影響で）変わってくるので、かなり厄介です。

　とまあ、こんないい加減な動かし方をしているせいで、使い勝手はいいとは言えませんし、
何よりも総フレーム数をやたらと多くし、総移動距離を非常に短くとった場合、１フレーム
当たりの移動量があまりにも小さくなり、計算の丸め誤差によってゼロになってしまうことが
あるのです。これはＸ・Ｙ・Ｚ方向別々に計算されるため、Ｘだけ移動速度が完全にゼロに
なり、Ｚだけがそれなりに動くといった結果になったとき、設定した軌道とまったく異なる
方へカメラがゆっくりと動いていき、当然目標座標には辿り着かないので、自分で停止させるまで
動き続けるというオソマツな挙動を示すことがよくあるのです。

　この理由は色々あるのですが、一番大きいのは、その理想的な曲線を１つのシンプルな式で
表す方法を知らなかったことですね。あるフレーム、もしくは移動距離のとき、速度はいくつ
になる。そんな一意な値を出してくれる関数が分からなかったので、こういう場当たり的な
計算をしてフェード動作をごまかしていたわけです。

　ということで、今回の目標は「現在位置を１つの関数式で一意に求めて設定する」ことです。
これならば、どんなに移動速度が遅くとも、現在フレームに対して座標が決定されるため、
フレームが進まないということが起きない限りカメラの動作が止まることはありません。
要するに、以前は現在地点から速度を割り出していたので速度ゼロになることがあったが、
このやり方はまず位置が決定され、その結果として速度がいくつであるという流れになるため、
コンスタントにカメラが動作するということになります。なぜなら、総フレーム自体は決定
しているのだから、フレームをコンスタントに増やしていけばカメラが止まることはありません。
もちろん、現在速度も気にする必要がありません。非常に信頼性のある動作が作れるのです。

　実際、どんな動きをさせるのかというと、


　こんな感じです。縦軸が現在位置、横軸がフレームです。
　この関数は曲がりくねってますが、フレームが進んでいって右端に到達すれば、必然的に
現在位置は一番上に来ます。しかも、最初はフレームが進んでも現在位置があまり動かない、
つまりゆっくり動き、中盤で速くなり、後半ゆっくりになります。つまり、フェード動作を
してくれます。こういうＹ＝αＸみたいな関数式があれば、Ｘを与えるだけで勝手に理想的な
現在位置を割り出してくれるわけです。現在の動作方法に比べて、いかにシンプルで正確か
お分かりになるでしょうか。

　さらに、このＳ字のウネウネ感は、ゲイン（係数）を掛けることで調整できます。つまり、
最初がやたらとゆっくり、中盤が一気に動くような曲線を作ったり、最初の加速はそれなりに
スムーズで、中盤もそれほど速くはならないような曲線も作れます。それを使用者が調整
できるようにすれば、フェードの具合も自由自在な、とても便利なカメラワークMODが
作れるわけです。
　ちなみにこの曲線はシグモイド曲線というそうで、関数式も非常にシンプルです。


　ということで、こういう夢のような話をずらずらとしてきましたが、これをプログラムにまで
落とし込んで実際に動くようにしないと何の意味もありません。それをダラダラと作っていこう
と思います。「俺余裕で作れるんだけど・・・」って人がいたら、ソースコード全部あげますので
ぜひお願いします。っていうか自分のMODは全てオープンソースなので、勝手に改良して
公開してください。多くの東方GTA作者の助けとなると思いますので。
　opcodeでプログラム組むのって、コンスタントに作れるんだけどメモリ処理が大変なんです
よね・・・。



　ということで、興味がある人は今後も読んでみてねヾ( ﾟдﾟ)ﾉﾞ