かなりふつう

間が空いたけど、続き書くよ！


前回のおさらい。

・・・①

こういう式がありまして、これをグラフに描画すると


こうなるんでした。でも、これは入力するべきｘが－６～＋６で、使いづらい。
ｘの値域を０～１にして、適宜ゲインをかけて調整できるようにしたいってことでした。
ちなみに、こんな風に使いやすい値（１とか）で処理できるように改良することを
「正規化」と呼びます。正規化という言葉は意味がわかりにくく、難しい印象がありますが、
「～をまとめて１と考えると」などの思考は皆さん日常でも頻繁に使っていると思いますが、
それがまさに正規化です。鉛筆１２本を１ダースとして処理するのも、一種の正規化です。


てことで、上の式を「正規化」して
　　・・・②

という式を作りました。これは要するに、ｚに０～１を入れたとき、①の式でｘに
－６～＋６を入れたときと同じ結果になるようにしようというのが目的でした。
ｘにその値域を入れるということは、-ax（ｅの指数）の結果は

※ａ＝１とする
ｘ＝－６のとき、－ａｘ＝６
ｘ＝±０のとき、－ａｘ＝０
ｘ＝＋６のとき、－ａｘ＝－６
です。
　では、ｚを入れてこうなってくれるでしょうか。

ｚ＝０のとき、ｅの指数＝６
ｚ＝0.5のとき、ｅの指数＝０
ｚ＝１のとき、ｅの指数＝－６

ちゃんとできてますね。それじゃ、Ｙはどうなるんでしたっけ。

ｚ＝０（ｘ＝－６相当）のとき、Ｙ＝１／（１＋ｅ＾６）＝１／403.43 ≒ ０
ｚ＝0.5（ｘ＝０相当）のとき、Ｙ＝１／（１＋ｅ＾０）＝１／２＝０．５
ｚ＝１（ｘ＝＋６相当）のとき、Ｙ＝１／（１＋ｅ＾-6） ≒ １／１＝１

はい。見事にｚが０～１のとき、Ｙが０～１になっています。
ちなみに、これをEXCELでグラフに描いてみた結果がこちら。



　線が３本ありますが、これは今まで「ａ＝１」と言ってきた、いわゆるゲインを
調節してみたものです。このａはｅの指数全体に掛けるものなので、やっていることは
ｅの指数部分「6-12z」を「a*(6-12z)」としているだけです。最終的には、このａを
GTA内で調節することにより、こんな感じでカメラの加速の仕方をある程度調節
できるようにします。


　もう少し進めましょう。


　GTAは３Dですから、座標も当然X・Y・Zの３つがありますが、基本的には、
上にある式を３つの軸それぞれに同じように適用させて処理します。
　３軸別々のゲインを設定できるようにすればかなり柔軟なカメラワークが作れると
思いますが、その調整はイメージしにくく非常に面倒になることは間違いないので、
３軸独立ゲインは実装しないことにします。

　さて、それでは具体的にGTA上で話をしましょう。
　仮に、カメラワークを以下のように実行したいとします。

初期値（始点）
　X：2500.0
　Y：1300.0
　Z：20.0

目標値（終点）
　X：2550.0
　Y：1400.0
　Z：25.0

※ここでのXというのは、GTAの3D座標を示す変数です。これまでにやってきた計算式の
Xとは意味が違いますので注意してください。

　GTAでは、この座標の単位１が約１ｍ程度のようなので、この動きはざっくりと言って
けっこう大きな動きです。Zも20から25なので、地上から屋根の高さくらいまで動くことを
意味します。まずはこれを、1000フレームで動かしてみようと思います。

　目標値まで動かすということは、初期値から、進んだフレーム分の変化量を足すという
ことです。０フレーム目であれば変化量は０ですから、初期値＋０、つまり初期値と
同じ、要するにまだ全然動いていないということを示します。
　逆に１０００フレーム目であれば、「終点－始点」をまるまる変化したわけですから、

③
　Xの変化量＝2550－2500＝50
　Yの変化量＝1400－1300＝100
　Zの変化量＝25－20＝5

となりますね。その変化量を初期値に足すので、変化した結果

　変化後のXの値＝2500＋50＝2550
　変化後のYの値＝1300＋100＝1400
　変化後のZの値＝20＋5＝25
　

となります。当たり前ですね。ここまでは長々と書いてきた計算式なんて使う必要も
ありません。

　では、500フレーム動いたときはどうでしょうか？
　500フレームというのは、総フレーム、つまり1000フレームのうち、何％でしょう？
これは簡単です。500／1000＝0.5＝50%です。全体を１としたとき、0.5進んだ地点
ということです。

　さあ、出ましたよ。この0.5です。
　今まで色々計算式をいじってきました。その目的が「０～１で操作したい」ということ
でしたね。この０～１の値が、この「どのくらい進んだか」を意味するわけです。
つまり、500フレーム動いたときには、この動いた割合0.5を、式に代入して計算すれば
よいのです。

　まず、元々「変化する量」とはいくつでしたか？要するに、全部動かしたらどのくらい
でしょうか？それは③で出ていますね。そのうちの半分、0.5なんですから、
「0.5の変化に対して、実際に動く量はいくつか」ということを計算します。ここでいう
変化が、②のXに相当します。実際に動く量の割合が②式でのYです。実際に動く量の
割合が求まれば、「全部動かしたときの変化量」にその割合を掛け算することで、
「実際に動く量」が求められます。
　計算してみましょう。

動いた割合が0.5のとき、実際に変化する量に対する、変化するべき量の割合は

　変化するべき量の割合＝１／（１＋ｅ＾（6- 12 × 0.5））
　　　　　　　　　　　　＝１／（１＋ｅ＾０）
　　　　　　　　　　　　＝１／（１＋１）
　　　　　　　　　　　　＝０．５

となります。これに「実際に変化する総量」をかけると

　変化するべきＸ＝50 × 0.5 ＝ 25.0
　変化するべきＹ＝100 × 0.5 ＝ 50.0
　変化するべきＺ＝5 × 0.5 ＝ 2.5

最終的に、500フレーム経過したときのカメラの座標は

　500F後のXの値＝2500＋25.0＝2525.0
　500F後のYの値＝1300＋50.0＝1350.0
　500F後のZの値＝20＋2.5＝22.5
　

となりました。これが本当に求めたい答えです。
これが出れば、あとはプログラムコードを組むだけです。

とゆーことで、今までの流れを一般化してみましょう。


１、初期値（始点）を記録する
２、目標値（終点）を記録する
３、総変化量を求める（目標値－初期値）
４、総フレーム数を記録する
５、任意のフレームが総フレームのうちどのくらいか、その割合を計算する
６、求めた割合を計算式に当てはめ、実際に動く量の割合を求める
７、「総変化量 × 実際に動く量の割合」を計算し、「実際に動く量」を求める


という流れになります。これこそが「理論を実装に変えた」瞬間です。
ついに、あーだこーだ机上で述べてきた空論が、形を持って結果として出てきました。

ついでに、実際の計算も一般化しておきましょう。

１、ゲインをａとして代入しておく
２、始点をそれぞれ「bX，bY，bZ」とし、それぞれにXYZ値を代入する
３、終点をそれぞれ「eX，eY，eZ」とし、それぞれにXYZ値を代入する
４、総変化量を「dX，dY，dZ」とし、１と２から計算した結果を代入する
５、総フレーム数をtFとして、これに代入しておく
６、ｎフレーム目のtFに対する割合をrFとし、計算して代入する

　　このとき、rFは
　　rF ＝ ｎ ／ tF

７、実際に動く量を「ΔX，ΔY，ΔZ」として、計算して代入する

　　このとき、７の値は
　　ΔX ＝ dX ／（１＋ｅ＾（ａ×（6-12 × rF）））
　　ΔY ＝ dY ／（１＋ｅ＾（ａ×（6-12 × rF）））
　　ΔZ ＝ dZ ／（１＋ｅ＾（ａ×（6-12 × rF）））

８、ｎフレーム目のカメラ座標を「rX，rY，rZ」として、結果を代入する

　　このとき、８の結果は
　　rX ＝ bX ＋ ΔX
　　rY ＝ bY ＋ ΔY
　　rZ ＝ bZ ＋ ΔZ



はい！できましたー！
このrX，rY，rZが、ｎフレーム目におけるカメラ座標となるわけです。
GTAは変数に名前を付けられない上に、わずか31個しか使用できないのでこの記事の
ように分かりやすいまま実装することはできませんが、なんとかうまくコーディング
すれば同じ処理を実現できます。


ということで、あとはプログラムの話になりますので以降は割愛。
割愛しないと、何百行ものコードを記事に羅列するだけで、
誰も、どころか自分もわからないと思うので。

　こんな感じで、１つ１つ目標に向かって適切に考えて、しっかり理論と数式を結び付けて
いくことで、プログラムコードという実装へ落とし込むことができます。最初は何を
やっていて、どこを目指しているのかわからなくなることも多いと思いますが、その時は
素直に一旦諦めて棚上げしてしまった方がいいです。もっと小型の、シンプルなアイデアを
形にすることを何度か実践して練習し、その流れを身体で覚えた方がいいでしょう。
たとえば、今回のようにカメラワークのエンジンそのものを作ろうとすると、今が
どうなっていて、何が不便で、どうすれば改善できて、そのためには何が必要で、
どれだけ複雑なのか、ちゃんと把握できていないとパンクしてしまいます。今回の
改良も、これまでのSlideCameraWorkという実績があるからこそスムーズに行えたもの
なんだということを知っておいてください。

　本当の最初は、確か何かキーを押すと今の視点で固定されるだけ、という極めて
シンプルなものだった気がします。そこから、カメラを動かすコードの存在を知り、
でも２つのコードがセットになっていて、試行錯誤しながら動作を覚えていき、
カメラを移動させる方法を考えたけれども満足できず、もしかして、ものすごく細かく
瞬間移動カメラを連続実行させれば、滑らかなカメラワークとして機能するんじゃないかと
思ったらうまくいって、そこから始点と終点を決定するためのインタフェース作りに
悩んで、変数が多すぎて大混乱の中でメモリ操作を覚えて、そしてカメラの回転なども
改良に改良を重ねて、そして現在のSlideCameraWorkがあるという感じです。Pixivだったら
評価点１００点ももらえないような子供のおもちゃレベルのものからのスタートだった
わけです。なんとかなるものですね。

　なのでこれが実装へ漕ぎつくための唯一のやり方ではありません。しかし、いい加減な
ところがあってはそこから先へは進まないということは分かってもらえたと思います。
漠然としたやる気だけで事に臨まず、堅実に着実に、真剣に取り組んで作ってみて下さい。
ちょっとずつだけどよくなっていき、次第にできることが広がっていくと思います。


以上、また何かあったらそのときに。
この新しいエンジンを積んだSlideCameraWorkは、なるべく早く公開まで持っていきたいと
思います・・・。がんばる。



.