𝙐𝙇𝙏𝙍𝘼 𝙓𝙍 𝙇𝙄𝙑𝙀 解説 (2/2)

phi16.hatenablog.com

続きです。「アニメーション」の話をします。

目的

今回のアニメーションは全体的に「曲の具現化」として作っています。なので音に合わせた動きをすることが基本。

「音に合わせる」というのはもちろんタイミングだけではなく、リリースの長さ、雰囲気、全体中の重要度、緩急、その他「音に関するプロパティ」なんでも、です。

また、これは「波形としての音」に限らず「リズムとしての音」も含みます、これは即ち無音であっても音に合わせることがあるということです。

今回の曲はめちゃくちゃ「楽しく」「遊び甲斐があり」「システマチックな構成をしている」ので音合わせがやりやすく楽しかったです。

www.youtube.com

基礎

動きを作るにあたり大事なことは、私は、「微分」だと思います。即ち「時間あたりの変化量」のことです。

例えば「瞬間」を表現するとき、文字通り一瞬で出す、ということがまず考えられます。

しかし、知覚的には「これまで無かった状態から、出てくる」という変化が実在しています。たとえ見えなくても。

それを表現することによって、「出現」という知覚を補強することができます。 これが誇張です。

さらには「出現が終わった」という知覚もあります。これを例えば「出現時の変化量を強め、終わったときに逆向きの変化量を与える」ことで表現することができます。

最初に比べて「意味」が乗ってきたのがよくわかりますね。

また、リズムがあるなど未来予知ができる場合には「そろそろ出る」という知覚もまた発生しているはずです。音で言うところのリバースシンバルの役割だと思う。

つまりは「瞬間」とは言えどその前後もまた表現する要素となりうるわけです。

そして「瞬間」に近ければ近いほど変化量は大きくあるべきに見えます。その効果は見ての通り。急激な変化によって瞬間を近似している、と私は捉えています。

なお上に挙げたのは「物体の大きさを変えて瞬間を表現する例」でしたが、他にもいくらでもあります。大事なのは「瞬間の前後も表現対象である」という点。

さて、そんなところでまず根本的に「物の動き」について考えようと思いますが、まぁ最も大事なのはコレでしょう。

運動の第1法則 (慣性の法則)

「全ての物体は、外部から力を加えられない限り、等速直線運動を続ける。」

つまり「最も自然な動き」というのは「まっすぐ同じ速度で動き続けること」ということです。

逆に言えば他は全て何らかの「外部からの力」が働いている、わけです。例えば摩擦力。重力。垂直抗力。弾性力。浮力。

「力学的法則に従う必要はないのでは」と思う気持ちもあるかと思いますが、現実的に人間の目は「力学的法則に従っているように視える」ように出来ている、気がします。これは「等速直線運動じゃない場合、そこに力が加わっているように感じる」という意味です。

まぁ「大きさの変化」みたいな「現実ではありえない動き」になるとそういう認識も結構薄れてそうですけど。

で。

例えば重力。地球上で放り投げた物体は重力によっておおよそ放物線 ("物"を"放"ったときの"線") を描くことが知られています。

なので「重力に従うアニメーションが作りたければ、放物線を描くような動きを作れば良い」ということになります。システマチックですね。

物理現象に従うようなアニメーションは、物理現象を記述すればそのまま「正しい動き」が得られます。この考え方は Physically-Based Rendering に似てますね。

ただしここで注意すべき点として「(地球上の) 全ての物体には、どんな質量であろうと同じ重力加速度が掛かる」という大事な原理があります。つまり重さの表現は、重力では出来ないということです。

対照的に重さが関わってくるのは「物体との衝突」です。質量は「運動をどれくらい維持するか」のパラメータなので、軽いものであれば「維持出来ずに反発する」、ある程度の重さなら「エネルギーを失って停止」、限界を超えれば「衝突対象を破壊」するようになります。

ついでに言えば衝突には変形がついてくるもので (例えば野球ボールとかは打撃の瞬間めちゃくちゃ歪んでるらしいですね)、それを入れると結構「反発感」が出ます。撃力を与えるには時間が必要なのですね (Amebientのときにもちょっと書きました)。

まぁそんな話をしたところで私の作ったアニメーションの9割9分は物理現象に従っていないんですが。とは言えやはり基本は知っておくべきで (これらは「テクニック」じゃないですからね！)、そこから逸脱するのもまた楽しさだと思っています。

easing

なんで easing と呼ばれるようになってるのかは私はわからないんですが、まぁなんか「動きを表す関数」みたいなものだと思います。

追記: これは急な変化を「ゆるやか」に繋ぐという意味っぽいということがわかりました　たしかに

で、世の中にはたくさんの easing 関数があるみたいなんですが、私はそれらはほぼノイズ情報だと思っています (昔はいろいろ使ってたけど)。今回のアニメーションでは基本的に しか使ってません。

その話は一旦おいといて。

easing には「in」「out」「in-out」の3種類がありますが、in-out は in と out をくっつければいいので要りません (実際問題「入り」と「出」が同じ動き (= 同じ意味合い・同じ重要度) であることって無くないですか？)。

ぶっちゃけ out も in をひっくりかえしただけですが、まぁ時間的因果関係としてはこの2つの違いは重要です。

しかしこれも既に説明しています。「in」は瞬間に繋げる「予告のための動き」で、「out」は瞬間から繋がる「応答を示す動き」のことです。

何度も言いますが大事なの (= 動きの中で知覚に与える影響量が多いもの) は「変化量が大きいタイミング」です。私は in/out の区別がいつもわかんなくなるので最近 e1/e0 って呼んでます (1 (おわり) のタイミングが重要か、0 (はじまり) のタイミングが重要か)。

例えば UI でボタンを押したときの反応は、即座にユーザに応答を返すべく、e0 を使います。逆にシステムから返事があるときは、e1 を使うことで予告を行って、驚きをやらわげることができます。

さて、ところでどんな動きが自然に見える (= 外力をはっきりと感じさせない) のでしょうか？

例えば「急に動きがなくなる」のはなんだか不自然です。ゆっくりと速度が 0 になってほしいです。逆に「急に速度が出る」のはまぁ間違いなく外力が発生したんでしょうからそれ自体は問題ありません。

ただ、たとえ「速度がだんだん 0 になった」としても、次の動きには「何か」を感じませんか？

つまり「ぴったりと止まりすぎている」感が。

この感覚の正体は加速度の不連続性です。グラフにすると、こう。

ぱきっとしちゃってます。「加速度変化が不連続」ということは正しく「そこでぴったり力を加えるのをやめた」ということ ( なので)。しかしそれって自然なことでしょうか？

何もしてないなら、こんな不連続な変化が (潜在的に) 起きているはずがありません。

つまり速度がだんだん 0 になるだけでなく、加速度もだんだん 0 になってほしいのです。

そして同様に加速度の変化 (躍度) もできる限りだんだん 0 になってほしいです。そして…

以上の話から、「自然な動き」というのは「無限回微分可能」であることを暗に要求しているのではないか？と言えます。例えば等速直線運動。例えば放物線。例えば や 。そして です。

しかし無限回微分可能であることを要求するということは、テイラー展開を考えると「ある瞬間の動きから、過去・将来の動きを予測できる」ということを意味します*1。これはアニメーションの役割的には良いことだと言えますが、例えば「動きが完全になくなった状態 (= 定数関数) になる」ということは過去にも動きが無かったはずということになります (だんだん停止する「自然」なアニメーションは存在しない！)。これでは「停止するアニメーション」が作れません。

というわけでどうしてもここに妥協は必要です。私は諦めて を適当なところで切断するようにしてて、停止してるように見えて速度すら 0 じゃなかったりします。でもまぁ、ほぼ 0 なので見かけ上大丈夫です。

例えば のときに なのを、無理やり だったことにすることで から への関数にしています。入力と出力に掛け算と足し算をするだけ。

というわけでこんな関数を使ってます。

float e0(float t, float k) {
    float x = exp(-saturate(t)*k);
    float s0 = 1;
    float s1 = exp(-k);
    return (x - s0) / (s1 - s0);
}
float e1(float t, float k) {
    return 1 - e0(1 - t, k);
}

もう私のアニメーションのソースコードの至るところにこれがあります。 で動きの鋭さを変えられる上、 を定数倍・ をその逆数倍することで最大変化量を維持したまま「素早く終わるアニメーション」をつくることもできます。便利。

ほとんどがこれの組み合わせで出来ていますが、たまに欲しくなるものとして「ちょっと行って戻るやつ」があります。

float eb(float t, float b) {
    t = 1 - t;
    return 1 - t*t*(b*t - b + 1);
}

この関数は そして という条件の解として作った三次関数です。out 的な動きをするんだけど、ちょっと行き過ぎるのです。

これを e0 の結果につなぎ合わせてあげる (関数合成する) ことで「ふわっとひろがって、ちょっと戻る」動きを作っています。

これだけで全てのアニメーションが賄えるかというともちろんそうではないんですが、「瞬間の動き」の殆どはこれで十分だと思います。持続的な動き (ふよふよ動いてるものとか) は私はスプライン書いたりしてます (CUEのときにやった)。

なんで世の中のモーショングラフィックスがみんな手でカーブ書いて作られているのかはよくわからないんですが (わかるんですが)、アレは「人が丁寧に動きを描いたことで生まれる歪み」を楽しんでいるんでしょうか？まぁ実際そういうところは多分あると思うんですけど (癖がそのまま「クセになる感じ」になってそう)。

私の作ってる動きも明らかに私の癖が出てるので人のことは言えないですけどね。ただ私の癖は「歪み」ではないと思う。

カーブエディタには2階微分までを表示する機能ほしいですよね。

まぁ手作業モーション (私を含む) はゲームじゃない (interactiveに動きが変化しない) から出来るところありますよね…。それは「良いこと」ですけど。

実装

今回のアニメーションは、前述したように全てがコードで書かれています。物体の位置・回転・色・変形など全てです。

pic.twitter.com/fJACY2ggjH

— phi16 (@phi16_) January 3, 2023

こんな感じ。

この方法のメリット・デメリットについて一応記しておきます。

• メリット
  • 多数の物体に対する動きを一気に記述できる
    • そのうちいくつかだけ違う動き、みたいなこともできる
  • シンプルな関数に従う物理現象の記述が可能
    • ランダムも気軽に使えるしまぁなんでも
  • 動きのモジュール化・使い回しが可能
  • 動きを掛けたり足したりして組み合わせることができる
  • 微分を自前で計算することで速度の値をモーションに使える
  • 非破壊編集 (バージョン管理も簡単)
  • 何を意図した動きなのか「読む」ことができる (言語で書いてあるので)
• デメリット
  • 誰でも書けるわけではない
    • でもアニメーションカーブも大体の人描けなくないですか？ (大体ぐにゃってなるだろうし)
  • 位置を指定するときに数値を書かなきゃいけないのでちょっと直観的ではない
    • とは言えアニメーションカーブも別に「実際の位置」を指定してるわけではないし…
  • これを動くようにするまでの仕組み作りが面倒

うーん。もともとメリットとデメリットが1対1対応するように書きたいつもりがあったんですがコレに関しては圧倒的過ぎてこうなるしかないですね…。

こうなっている全ての原因は「プログラム記述よりもアニメーションカーブ編集ツールのほうが上方のレイヤーにある為、当然プログラム記述のほうが細かいことができる」という点です。まぁあたりまえなのよ。

とは言え現実的な問題の9割は Unity の Animation 編集機能が雑魚なことに起因するのでそこはまぁ…。

正直微分を自前で計算するのそんなに楽ではない (特に Quaternion とか出てくると) ので自動的にがちゃってやってほしいんですけどね。無理かなまぁ。

話を戻して、まず今回の実装はこんな仕組みになっています:

• Timeline で時間を司る Material のパラメータを変化させる
• その Material を貼った Quad をカメラで撮って RenderTexture に保存
• 各エフェクトがその RenderTexture を参照しに行って現在時刻を取得
• 時刻をパラメータとしてエフェクトを記述

これがその Timeline で操作している Animation です。

• 斜めの赤いやつが「現在の小節数」(整数値) です。
• 0 付近の青と緑のギザギザ (三角波) が、「小節開始からの時間」を表現しています。
  • アニメーションで離散的な動きをすると良くない (正確な値が取れる保証がない) ので、2つの三角波から位相を計算するようにしています。
    • CUE のときにもやった。
      • (まぁ今回は 5 分だけなのでシンプルに一本の直線にしてもそこまで精度の問題はなかったかもしれない)

各エフェクトが時間を取り出す部分はこんな感じ。

sampler2D _TimeTexture;
float4 env;
void loadEnv() {
    env = tex2Dlod(_TimeTexture, float4(0.5, 0.5, 0, 0));
}
float localTime(int si, float sl) {
    float2 bt = env.xy;
    int i = bt.x - si;
    float l = bt.y - sl;
    return i * 4 + l;
}

各 vertex shader / fragment shader の先頭で loadEnv() を呼び出すようにしていて、そうすると以降好きなところで「好きなタイミングを基準にした拍時間 localTime」が得られます。

ここまでくればあとはやるだけです。

全てのアニメーションを解説していると無限に終わらないので、好きなところをいくつか紹介していこうかなと思います。

開始直前

ここの役割は2つあります。

• 曲が始まる丁度一拍前に動きがあることで、「開始直前であること」と「一拍の間隔」の情報を伝える。
• 待機エフェクトとメインエフェクトの間を繋ぐ。

ここはまだ音が鳴ってないんですが、それでも一度「ばっ」って大きくなります。急な動きではありますが、完全に認識する必要はなく「次を認識する為の事前動作」になっています。なのでただ大きさが変わる程度です。

メインモーションの開始はちゃんと見てほしかったので、その前に簡素な動きを入れることで注視させるという話ですね。それまで画面に動きがないので視点が揺らいでいることだと思うので。

そして、始まりが近づくにつれ上に加速していき、開始までの予測を提示します。で、メインエフェクトに滑らかに切り替わります (内部的にも全く違う 2 つのオブジェクトです)。

見かけ的には繋がりのない 2 つのエフェクトですが、「同じ方向に同じくらいの速度で動いている」という要素だけで関連性を作ってます。素早い動きだとこういうことができるのが面白いですね。

もともとメインエフェクトは最初に作って、制作終盤になってそこにどう繋げようかな～と思ってたんですが試しに入れてみたらぴったりだったのでよかった、という感じでした。

実装です。

if (lt > 47) {
    s += (1 - e0(map(47, 47.5, lt), 4)) * 0.2 + 0.2; // size
    p.y += e1(map(47.5, 47.75, lt), 6) * 0.5; // position
    c = 1.1; // color
}

ちなみに map はコレです (map(a,b,a) = 0, map(a,b,b) = 1 になるような線形変換)。

float map(float a, float b, float x) {
    return saturate((x-a) / (b-a));
}

開始拍が 48 のタイミングなのでその一拍前から開始します。まず一瞬でサイズを 0.4 増やして変化を視認させつつ 0.2 まで半拍掛けて (47 から 47.5 まで) 落として「予感」を作ります。

そして 47.5 から 47.75 までの 1/4 拍を使って上に動かし、最後の 1/4 拍は動かしません。これは「一瞬詰まった感覚」(ヒットストップと似たようなイメージ) になってくれて (5フレームしかないですけど)、滑らかすぎる問題を解消します。

というのも、47.5 から 48 まで動かしてしまうと滑らかに繋がりすぎてしまって「曲が開始した」という瞬間の感覚が薄れてしまったのです。なので不連続性 (= 大きな変化量) を入れました。

解説用 pic.twitter.com/tBCLCVNQwP

— phi16 (@phi16_) 2023年1月6日

…えー、この様子を見るとわかっていただけるかと思うんですが、コードで書いたとしてもどうせ泥臭いことをすることに変わりはありません。道具の問題なのです。

なのでアニメーション解説としてはもう「基礎」で終わっていて、あとはそれをどれくらい使うかだと思っています…。

折角なのでアニメーションカーブでは厳しそうな部分を多めに紹介します。

声

安直に「波」で声を表現しています。矩形波なのは合成音声的なニュアンスですね。まぁしゅっとするし。

当然この波は正しいものでは一切ありませんが、一応音程に沿って周波数が変わります。

int ix = floor(it);
int ii = floor(ix / 16.0);
int ir = ix - ii * 16;
// 1212123- / 1212124-32 / 1212123- / 1212321-
float h[16] = { 1, 2, 1, 2, 1, 2, 4, 4, 4, 4, 3, 2, 2, 2, 2, 2 };

int h0 = h[ir];
if (ix < 0) h0 = 1;
else if (ii == 3 || (ii != 1 && ir >= 8)) h0 = 3;
if (ii != 1 && h0 == 4) h0 = 3;

ix++;
ii = ix / 16;
ir = ix % 16;

int h1 = h[ir];
if (ix < 0) h1 = 1;
else if (ii == 3 || (ii != 1 && ir >= 8)) h1 = 3;
if (ii != 1 && h1 == 4) h1 = 3;

わかりにくいですね。聴いた感じ 8 拍周期で近い音程になってたのでそれを基準とし、8 拍を 16 分割しています。

半拍毎の周波数テーブルが h というやつです。周期ごとに微妙に違ったりする分は次の条件文でどうにかしてます。

で。「現在の半拍」と「次の半拍」の間をブレンドするために、h0 と h1 を計算しています。波の形の計算は全て h0 h1 それぞれに行って、最後に混ぜています。

float a = eb(map(-0.3, 0.3, frac(it) - 0.5), 4);
if (ii == 1 && ir >= 9 || ix >= 38) a = smoothstep(-0.5, 0.5, frac(it) - 0.5);
bool efi0 = h0 >= 3 || ii == 1 && ir >= 9;
bool efi1 = h1 >= 3 || ii == 1 && ir >= 9;
float freq[5] = { 0, 9, 17, 25, 33 };
float sp0 = efi0 ? 4 : 2;
float sp1 = efi1 ? 4 : 2;
float wav0 = sin(loc * freq[h0] * 2 * pi + lt * sp0) * 0.5 + 0.5;
float wav1 = sin(loc * freq[h1] * 2 * pi + lt * sp1) * 0.5 + 0.5;
if (efi0) wav0 *= tanh(sin(loc * 170 + lt * 8) * 5) * 0.1 + 2;
if (efi1) wav1 *= tanh(sin(loc * 170 + lt * 8) * 5) * 0.1 + 2;
float eff = 0;
eff = max(eff, min(e0(lt-4, 8), 1 - e0(lt-9.75, 2)));
eff = max(eff, min(e0(lt-12, 8), 1 - e0(lt-19, 2)));
eff = max(eff, min(e0(lt-20, 8), 1 - e0((lt-25.75)/2, 2)));
eff = max(eff, e0(lt-28, 8));
base *= lerp(1, 0.5, eff);
base += lerp(wav0, wav1, a) * 2 * eff;

まぁつまり a がブレンド率で。freq が周波数テーブル (64 分割されてるので 32 が Nyquist 周波数、そこから微妙に外れるように値を選んでいます) で。時々誇張したり (efi0, efi1)、声が出てるときはベース波を弱くしたり、いろいろですね。

ちなみに、今回使ってる三角形は実際には全部三角柱で。好きなときに伸ばしたりできるようになってます。これを集めて並べて声の波形を作ってます。

どう並べるかを計算する為には「隣の波の高さ」を知る必要があるので、それも計算してます。こういうのは意外と大変ですね。

着地の衝撃

まず根本的に、各三角形のパラメータ指定を行うインタフェースがこれです。

bool EffectVert(uint id, float z, inout float3 p, inout float4 q, inout float3x3 m, inout float4 c, inout float4 cs);

id はID、z は先程の三角柱の手前 (-1) か奥 (+1) か。これを入力として、位置 p、姿勢 (クォータニオン) q、変形行列 m、色 c、図形指定 cs を返します。

位置・姿勢・色はおわかりの通り。図形指定は三角形に穴を開けたり角丸にしたりするパラメータです。で、変形行列がまぁ楽しい要素で。

単純に単位行列にスケール倍すれば大きさ指定として使えるんですが、まぁそれ以外ができるわけですね。

前の解説で書いた「伸ばす」というのがこれで。こんな関数を作りました。

float3x3 idM() {
    return float3x3(1, 0, 0, 0, 1, 0, 0, 0, 1);
}
float3x3 strM(float3 v) {
    float l = length(v);
    if (l < 0.00001) return idM();
    float3 w = v / l;
    return float3x3(
        1 + v.x*w.x,     v.x*w.y,     v.x*w.z,
            v.y*w.x, 1 + v.y*w.y,     v.y*w.z,
            v.z*w.x,     v.z*w.y, 1 + v.z*w.z
    );
}

idM は単位行列。strM が指定した方向に「伸ばす」行列です。 とは異なり、伸びを の長さに比例するようにしているので少し扱いやすくなってます。

あとはこれに速度を突っ込めば疑似的なモーションブラーになります。おすすめです*2。

というわけで着地衝撃の計算がこちら。

float3 blow(float effT, uint id, inout float3 p, inout float4 q, inout float3x3 m) {
    float slowSpeed = 0.005;
    float lastSpeed = 0.25;
    float weight = 12;
    float mt = effT < 0.125 ? effT : 0.125 + slowSpeed * (effT - 0.125) + (lastSpeed - slowSpeed) * pow((effT - 0.125) / 3.875, weight+1) / (weight+1) * 3.875;
    if (effT >= 4) {
        mt = 0.125 + slowSpeed * (4 - 0.125) + (lastSpeed - slowSpeed) * pow((4 - 0.125) / 3.875, weight+1) / (weight+1) * 3.875;
        mt += effT - 4;
    }
    float3 pp = p;
    float3 fullImp = normalize(pp) / length(pp) * (rand(float2(id,1)) + 0.5) * 500;
    float3 fullImq = randSphere(float2(id,0)) * 20;
    float dt = 0.001;
    float3 g = float3(0,-10,0);

    float ct = min(1, mt / dt);
    float imp = smoothstep(0, 1, ct);
    float impI = (pow(ct, 3) - pow(ct, 4) / 2 + max(0, mt / dt - 1) * 1) * dt;
    p += impI * fullImp;
    p += pow(mt, 2) / 2 * g;
    float3 v = 0;
    v += imp * fullImp;
    v += mt * g;
    q = mulQ(axisQ(impI * fullImq), q);
    v *= 0.075;
    m = mul(strM(v), m) * 0.75;
    return fullImp;
}

ぶっちゃけ私もおぼえてないので解説できないんですが、時間軸 mt がまず歪んでるっぽいですね…。最初は等速 → 減速 → だんだん加速してもとに戻る、みたいな動きだと思います。

時間の変化量が 1 → 0.005 からゆっくりと 0.25 まで増加 → そこから 1 に戻る、という動きをしています。で、これを積分して時間を計算しているみたいです。積分はだるいですね。

あとは衝撃の計算ですが、これは「中央からの距離の逆数の強さで、ランダムな力を与え (fullImp)」「ランダムなトルクを与える (fullImq)」ようです。

が、これを一瞬で与えるのではなく 0.001 秒掛けてるらしいです。この impI の計算は Amebient のときにやった「smoothstep の積分」ですが、細かいことは忘れました。

なんやかんやで位置を計算しつつ、その微分によって速度が算出できます。それを変形行列 m に突っ込んでいますね。

ここまで丁寧 (？) にやる必要があったかはよくわかりませんが、丁寧にやると少なくとも「まともな動き」をしてくれるので、迷わなくて良いんじゃないかなと思いました。まる。

ちなみに、このときの計算に重力も入ってる (p += pow(mt, 2) / 2 * g;) ので、いい感じに落下してくれます。

ぽよぽよ

うちのやつ pic.twitter.com/QkzzFELuTv

— phi16 (@phi16_) 2023年1月3日

お気に入りです。かわいい。

float ut = lt - spawns[id % 5] - 16 * (id / 5);
if (ut < 0) return false;
float4 p0 = poyoPoint(id, lt - dt);
float4 p1 = poyoPoint(id, lt + dt);
p = lerp(p0.xyz, p1.xyz, z);
p.y += noise(float2(id, lt*0.3 + rand(id.xx))) - 0.5;
m = 1;
if (distance(p0, p1) > 0.00001) {
    float3 t = normalize(p1 - p0);
    q = dirQ(float3(0, 0, 1), t);
    m = lerp(0.25, 1, exp(-distance(p0, p1)*0.5));
}
m += 1 - e0(ut, 4.0);
m *= e0(ut * 2, 9.0);
m *= lerp(0.5, 1.5, lerp(p0.w, p1.w, z));
if(ut > 0) c.rgb = lerp(c.rgb, 1.2, 1-e0(ut/2, 8));

これは仕上げ部分のコードです。ぽよちゃんの位置は poyoPoint が計算してくれるので、その間をカプセルでつなぎます。z は今回は 0 から 1 の間の値を取るみたいですね。m は行列ではなくただのスケールを表すスカラー値になってます。

各カプセルを移動方向に回転 q = dirQ(float3(0, 0, 1), t); しつつ、動きが大きいときには縮める処理 m = lerp(0.25, 1, exp(-distance(p0, p1)*0.5)); が入っています。この縮めるやつがめちゃくちゃかわいいんですよね。なんか。

あとは「登場時 (ut = 0) はちょっと過剰に膨らむ」m += 1 - e0(ut, 4.0); 「登場時は 0 から一瞬で膨らむ」m *= e0(ut * 2, 9.0); とか。あと poyoPoint 側で大きさ指定している分を反映するとか。最後は「登場した瞬間に白く光る」処理ですね。

poyoPoint はまぁよくわからない実装になってますが、基本的には「n 拍目で正 n 角形の形に並ぶ (ちょっと上下にランダムにずれる)」「それらを補間するように移動する」という動きをしています。補間関数は次です。

float eb01(float t, float a) {
    t = saturate(t);
    return - 2 * t * t * t + (a + 3) * t * t - a * t;
}

これは の解かな。まぁつまり「最初にぐっと戻る」「着地は急に行う」のをやりたかったのです。a = 1 で使ってます。

後方の円

pic.twitter.com/HTtcQeOBGF

— phi16 (@phi16_) 2023年1月6日

これはちっちゃな話なんですけど。

まず「スケールを変化させるアニメーション」って自然に見えないと思うんですよね。プリミティブなものならまだいいんですが、構造を持った物体が拡大縮小すると違和感を覚えます、私は。まぁ「変形する因果がない」からでしょう。

なので私は「全体のスケール変化」は行わないようにしています。が、なんとなく作ってみたこの動き、スケール変化になっちゃったんです。

厳密に拡大縮小しているわけではないんですが、それぞれの三角形の位置に、同じ倍率を掛けて縮めたらたしかにそれはスケール変化です。でもこの動きをやりたい…。

困ったので、試しに 「内側を 0.2 拍遅らせる」処理を入れてみました。するとスケール感がなくなり、さらに内側と外側で協調動作してる雰囲気も出ました！やったー。

という話。

街

現実の街をうにうに動かすやつはそこまで難しいことをしていません。

v2f vert (appdata v)
{
    loadEnv();
    v2f o;
    o.origPos = mul(UNITY_MATRIX_M, v.vertex);
    o.vertex = UnityObjectToClipPos(v.vertex);
    o.screen = o.vertex;
    float angle = 0;
    v.vertex.xyz = CityVert(v.vertex.xyz, v.uv2, angle);
    o.vertex = UnityObjectToClipPos(v.vertex);
    o.normal = v.normal;
    o.normal.xz = mul(ei(angle), o.normal.xz);
    o.worldPos = v.vertex;
    return o;
}

重要なのは o.screen に街を動かす前のスクリーン座標を格納する という所ただ1つです。CityVert 関数によって v.vertex は好き勝手動いた値が入っちゃいますが、o.screen からは動いていないときのスクリーン座標を取得できます。

あとはこの座標で GrabPass をサンプリングすると、「まるで元の位置にあったテクスチャが移動したかのように見える」というわけですね。簡単ですね。

この方法の自明な欠点は裏面が見えないことです。なのでビルを回転させると存在しない面がめちゃくちゃ見えます。が、回転はうきうきさを表すのに効果的だし、まぁどうせそこまでアーティファクトは気にされないと思ったのでやっちゃいました。

こういう変なことがシェーダは気軽にできるのが面白いところですね。簡単そうなことが逆にできなかったりしますけども。

爆破

これは色々と大変でした…。描画負荷も大変でしたね。

まず各座標に 16 通りの値を定めます。これは「何回目に剥がれるか」を表す数値です。

sampler2D _Noise;
#define peelN 16
int peelIndex(float2 p) {
    int g = tex2D(_Noise, p * 0.1).r * 4;
    float2 p2 = p + tex2D(_Noise, p * 0.3).rr * 2;
    float f = rand(voronoi(p2/2));
    return floor(rand(float2(f, g)) * (peelN - 1) + 1);
}
// int index = peelIndex(worldPos.xz / 16 + uv * 8);

で、各ビルを 16 回剥がす動きを作ります。同じ間隔だと構造がわかりやすくなってしまうので各ビルでタイミングをずらしています。

float3 ori = float3(0,1,0) + n * 0.3;
float3 o = p + n * 20 * e0(t, 4) * e1(t*2, 4);
float d = saturate(p.y / 60);
o += ori * pow(max(0, t * 2 - d), 2) * 100;
return o;

剥がれる動きはコレらしいです。いい感じに下から剥がれていってくれます。

タイミングは これ と似たようなことをやっています。解説できる気がしないのでコードは無しで…。

あとは「剥がれた部分は、現在の剥がれ値と同じ領域だけ白く表示」「街は、現在の剥がれ値よりも大きい領域だけ白く表示」するといい感じになります。なりました。

実装する前はコレ本当にちゃんとかっこよく作れるかな～～～って不安だったんですが、なんとかなってよかった。一番の懸念材料でした。

まぁオーバードローがめちゃくちゃ多くて重いんですけどね！ただ同時に曲自体も「重量感のある部分」だったので、ある意味ではぴったりということで…。

おまけ

ちなみに最後のキラーンってなるやつ、ポリゴンです。

まとめ

個別の演出解説というよりは最初の基礎部分が書きたくて書いた、みたいなところあります。楽しい動きがもっと増えると嬉しいです。

今回、元々はもっとポストエフェクトというか「後処理」をうまく使って絵をかっこよくできたらな、とか思ってたんですが最終的にはそこまでいけませんでした。まぁここまでで満足してしまったところがある。

所謂パーティクル的なエフェクトも使えなかった (「使わなかった」のではないのです、今回に限っては) のでエフェクト力もっと鍛えねばと思いました。まる。

現状の私の能力が出せたという点では満足しています。色々できるようになりたい。

おわりです。何かあれば気軽にどうぞ。

---

ちなみに貼ってあるグラフの殆どは Graphtoy で作りました。最初のやつは Wolfram|Alpha です。動きの gif は shadertoy で描いたものを ScreenToGif で撮ってます。

*1:無限回微分可能だがテイラー展開できない関数の話はしません

*2:三角形以外に適用するときはランダムノイズを掛けるといい感じっぽい気がします