橋本 Hashimoto   Baku

橋本 Hashimoto   Baku

操作の次元 (メモ)

このページは個人的なメモ書きです。何かあればご連絡ください。

https://www.sanwa-group.com/proshop/egrip_dollies.html

元記事 https://baku89.com/2017/11/18/velocity-curve

あるパラメーターについて動かす時、操作する物理量が何回微分されたものか — 具体的には位置/速度/加速度のどれをアニメーションさせるのかによって「動かし方」を分類できるのではないかとこの数年考えています。

ゲーム内での自機の移動を例にとると分かりやすいです。

移動について
| 操作の量 |,| 何回微分? |,| 次元 |,| 例 |
| 位置 |,| f(x) |,| m/s |,| Pongにおけるツマミ操作 |
| 速度 |,| f'(x) |,| m/s |,| スーパーマリオにおけるスティックの倒し具合 |
| 加速度 |,| f''(x) |,| m/s^2 |,| レースゲームにおけるアクセルとブレーキボタンによる加減速 |

映像制作の中で「動き」について考えるときも、この分類はなかなか有効かもしれません。手描きアニメや、キーフレームアニメーションは位置の推移をプロットしていくことで動かす。ストップモーションやクレイアニメは、フレーム間の**変化量(速度)**だけ対象物をずらしたり変形させることで動きを与えていく。アニメだって頭の中で「速さ」とか「タメ/ツメ」をイメージしながら描くじゃないか、と一瞬思うけれども、結局紙の上に残していくのはあくまでもそのコマにおけるキャラクターの位置。

実写撮影だと、慣性が強く働くものを身体で動かす際には加速度を操作することが多いでしょう。ドリーを手押しする時は、台車に力(≡加速度)を与えることで加速/減速させる。ジブもそう。手持ちカメラやステディカムを操作する際時も、基本的には加速度を操作していることになるのですが、重力との合力になるので少しわかりづらい…。

そういう風に考えれば、3Dソフト上で実写らしいカメラワークをつけようにもどこかぎこちなさが残るのは、アニメーションさせている量の次元が違うからだと説明がつきます。

そもそも多くの映像ソフトが、速度や加速度に対してキーフレームを打つことを許さないのは(パーティクル機能のような例外はありますが)現在の状態をフレーム0から漸化的に計算しないといけなくなるからです。これはノンリニア編集機能のコアたる、時間を前後させながらの編集や、書き出しを並列処理させるにはすこぶる相性が悪いといえます。

またユーザーにとっては、変化量をアニメーションさせては動きの終点を厳密に設定できないという問題もあります。そのために、AfterEffectsの速度カーブは、2つの固定されたキーフレーム間の速度配分のみ編集できる仕組みになっています。

こう俯瞰してみると、アニメーターやモーションデザイナーのような、「動き」について考える人達の多くが、パラメーターの変化量ではなく、その絶対量の推移によって動きをデザインしていると言えます。それは先に挙げたようなソフトウェア側の都合でもありますし、一度紙に描いた線を指でクレイアニメのように押し込んでずらせないように、そのメディアが持つ物性によるものだったりします。

考えてみれば「動き」という概念自体、時間経過におけるパラメーターの変化量を指すので、実際に操作するのが変化量ではなく、

例えば「ここでシュン!っとなる」の「シュン!」は速度のピークを表しています。それを実際に紙やアニメーションカーブ上に再現するときには、一旦頭の中で積分して位置に置き換えてやらなくてはいけません。

現実でものを動かす時は、摩擦で慣性が働きづらいものには速度を、滑ったり転がったりするものには加速度を力として与えることになるので、その積分というワンクッションは、人の身体感覚からすると不自然なことなのかもしれません。パラパラマンガで跳ねるゴムボールを描くことすらとても難しく、アニメーターには鍛錬が必要なのも、本質的にはその部分の違いに由来する反直感性にあるのかもしれません。

そう思ってプロトタイプしたUIがこれです。