つぶやく［GDC Summer］「Star Wars ジェダイ：フォールン・オーダー」における物理アニメーションの実装手法
 |
筆者が近年，ちょうど関心を抱いてきた技術テーマ「次世代ゲームに相応しいアニメーションシステム」（関連記事）について取り扱っていたセッションがあったので本稿で紹介したい。
タイトルは「Physical Animation in Star Wars Jedi：Fallen Order」（「Star Wars ジェダイ：フォールン・オーダー」で採用した物理アニメーション）で，タイトルのとおり，PlayStation 4，Xbox One，Windows PCで発売されたスター・ウォーズの世界観の三人称視点アクションアドベンチャー「Star Wars ジェダイ：フォールン・オーダー」（以下，SWJFO）のアニメーションシステムを解説したセッションになる。
 |
演技の再生だけでは「浮いてしまう」ゲーム内キャラクターの動き
本稿および当該セッションで用いられる「アニメーション」という用語は「キャラクターなどに動きをつけること」の意で用いられている。日本では「モーション付け」といったほうが馴染みやすいかもしれない。
ゲームにおけるアニメーション処理については，ユーザーの目が肥え始めており，これまでのやり方ではゲームプレイ体験が「しょぼい」と言われる機会も増えてきた。もちろん，デフォルメタッチのゲーム映像ではそうではないかもしれないが，少なくもリアル志向表現やディテール表現を重視したゲームでは，ただ漠然と「事前に役者などの生演技を記録して制作したモーションキャプチャデータを再生してキャラクターを動かす」という手法では不十分になっているのだ。
Waszak氏が最初に見せたのは，本作におけるザコ敵となるストゥームトルーパーがやられたときにアニメーションだ。
 |
左側は「やられ状態」の演技のモーションキャプチャデータをそのまま再生しているだけの状態だ。背後にある壁の存在を無視してアニメーションしている関係で身体の部位や右手に持っている棍棒が壁にめり込んでしまっている。
一方で右側は周囲の壁との当たり判定に配慮し，モーションキャプチャベースのアニメーションに拘束を与えて動きを制限することで身体の部位や棍棒の壁へのめり込みを回避している様子が分かる。
どちらが魅力的なアニメーションか，あるいはどちらがゲーム世界に説得力があるキャラクター挙動かは改めて問う必要もないだろう。
SWJFOにおいて採用した「事前制作したアニメーションに物理シミュレーションの影響を融合させる」ためのテクニックとは？
Waszak氏による説明では，SWJFOにおける「事前制作したアニメーションに物理シミュレーションの影響を融合させるための手段」として，3つのアプローチを採択したと述べている。なお，常に3つ全部を活用したということではなく，動きをつけるオブジェクト（たとえばキャラクター）ごとに適宜，どれか（あるいは複数）を取捨選択して採択したということだ。
 |
1つは「Motors」（モーター）だ。
これは，関節（Joint）という束縛を与えた条件下で動きを与えるアプローチだ。関節ベースで動きを与える，いわゆるキネマティックス的なアプローチと換言できる。
たとえば，モーションキャプチャによって得られた演技データの肘関節の回転（モーター駆動）が左回転だったとして，物理シミュレーションの結果から，ここにさらなる左回転増強が起こりえるとしたら左回転のモーター駆動を速める結果を与えることになる。逆に物理シミュレーションの結果が，ここに逆の右回転の力を加えるものだった場合，モーションキャプチャによって得られた演技データの肘関節の左回転演技にブレーキを掛かることになるだろう。そんなイメージだ。
2つめは「Velocities」（速度）である。
これは，物理シミュレーションの結果で得られた演算対称物の速度の変化を，事前制作した演技アニメーションに融合させるアプローチだ。前出の関節に対して挙動が加えられるのではなく，部位オブジェクト（場合によってはキャラクターモデル全体）に速度変化を与える。
たとえば，モーションキャプチャによって得られた演技データでキャラクターが動いている状態に対し，正面から向かい風が吹いてきた場合，歩行演技アニメーションの足を踏み出す動きにブレーキが掛かることを想像できるだろう。最終的に股関節，ひざ，足首などの関節にブレーキが掛かることにはなるが，物理シミュレーションの結果としての適用先は太もも，脛（すね）のほうになるのはイメージできるはずだ。
3つめは「Constrains」（束縛・拘束）だ。
この「束縛」というキーワードは物理シミュレーションにおいては広い範囲の意味を持つが，一言で説明するとすれば「動きを抑制する要素」ということになろう。
たとえば前出の「やられ演技中」のストゥームトルーパーが，背後の壁に当たっている状態の事例は，ストゥームトルーパーの腕や棍棒が壁を突き抜けないように当たり判定を取ったうえで束縛を与えている好例だといえる。
下の動画はゲーム中の主人公が狙った敵を強制的に引き寄せる必殺技Force Pullを発動している様を捉えた開発画面だが，ストゥームトルーパーがもがき苦しみ足をバタつかせている様子が見て取れる。
 |
注意深く見るとバタつかせている足が，地面に置かれた機材箱に衝突してそれ以上足が動かなくなっているのが分かる。また，それだけではなく，機材箱側もストゥームトルーパーのバタつかせた足の衝突力で動いている。こうした表現によって，ゲーム世界とキャラクターが相互に干渉し合っている様が伝わり，ひいてはプレイヤーが，このゲーム世界が実際に息づいている世界なんだという実感を得ることにつながっていく。
なお，動画中，ストゥームトルーパーにオレンジの人体模型のような人形が重なって描かれていると思うが，これはモーションキャプチャによって得られた演技データだけの動きを可視化したものに相当する。なので，オレンジ色の人体モデルのほうの動きは，機材箱にめり込んだりしているのが分かるだろう。ストゥームトルーパーの動きとオレンジ色の人体モデルの動きとの差こそが，「物理シミュレーションの影響なし/ありの差」という理解でいい。
SWJFOの物理シミュレーションはNVIDIA PhysXベース
なお，本作はゲームエンジンにEpic Gamesの「Unreal Engine4」（UE4）を採用していることもあり，物理シミュレーション部分は基本的にはNVIDIAのPhysXを利用している。
Waszak氏では，本作におけるPhysXの物理シミュレーション用のパラメータ設定についても言及した。PhysXでは，物理シミュレーションの計算精度を制御する（≒計算の反復回数に相当する）パラメータとして「Position Solver Iteration Count」（位置計算反復数）と「Velocity Solver Iteration Count」（速度計算反復回数）があるが，UE4でのデフォルト値ははそれぞれ8と1となっている。しかし，本作では精度を上げる目的で比較的高めの64と32を設定したとしている。
また，「Friction」（摩擦）パラメータ，「Restitution」（反発）パラメータは低めの値を状況に応じて設定したとしている。その理由は，高い値だと，物理シミュレーションの結果の影響度がうまく結果に表れなかったためと説明された。さらに必殺技「Force Pull」に支配されたキャラクタはFrictionパラメータはゼロ（摩擦なし）と設定したとも補足していた。
そして，正確な衝突判定を担保するための「Continuous collision detection」（CCD）は本作では無効化したという。その理由は，これを有効化していると，人体モデルなどの多関節キャラクターモデルの部位制御において，アニメーションと物理シミュレーション結果を合成したときにうまくいかないことが多かったためだ。結局，衝突判定に絡んだ物理シミュレーションについては，CCDを無効化したうえで，自前の衝突補完のプログラムコードを自作して対応したという。
ストゥームトルーパーの挙動チューニング
ここからは，本作で実践された「事前制作したアニメーションに物理シミュレーションの影響を融合させた事例」の数々を，紹介していくことにしよう。
まずはザコ敵のストゥームトルーパーがやられて吹っ飛ぶデスアニメーションだ。
 |
このアニメーションでは，前半の腕を振り回しながら，ややおどけた感じで吹っ飛ぶ動きは事前に制作されたモーションデータでキャラクターを動かしているだけだが，後半は，そのまま，いわゆる木偶（でく）人形のふっとび物理シミュレーションであるRagdollシミュレーションへと切り換えている。
この事例は，前半は「アニメーション再生」，その最後の姿勢から「Ragdoll物理シミュレーション」に切り換えたもの，ということになる。
これはオープンスペースのシーンではうまくハマるが，背後に壁があるとおかしなことになってくる。それを表したのが下の図だ。
 |
背後に壁があることで，壁との衝突判定に配慮し，それ以上，壁の内部に潜り込むことはなくなってはいるが，前半の「吹っ飛びおどけアニメーション」において振り上げた手が壁の中にめり込んでしまっていた。また，ストゥームトルーパーが壁に激突しながら上半身をきりもみ回転しておりなんとも不自然だ。「きりもみ吹っ飛び」はある程度の吹っ飛び距離があるからこそ起こりえるもので，飛距離がゼロでその場できりもみ回転するのは不自然である。
こうした不自然さに対処するため，衝突を検知した際にはストゥームトルーパーの腰に束縛を与えて，上半身が不当に回転しない抑制を与えている。さらに，吹っ飛んだ身体の次の位置が大きく壁を越えてしまうほど衝撃が大きいと判断できた場合は，その時点で前半の事前制作ベースの「吹っ飛びおどけアニメーション」を即時中断し，その場からRagdollシミュレーション支配下に移行させることとしたのだ。
 |
結果としては，前半の「吹っ飛びおどけアニメーション」の再生で始まるところは変わらないが，身体を半身ひねったところで，前述したような制御が入り，腰砕けさながらに地面に身体が倒れる動きとなった。たしかにそちらのほうが格段に自然に見える。
 |
主人公キャラクターの挙動チューニング
Waszak氏は続いて，主人公キャラクター（カル・ケスティス）の動き制御に話題を移した。
主人公に対しても「事前制作したアニメーションに物理シミュレーションの影響を融合させる」仕組みを取り入れてはいるが，衝突関連の正確性よりも「見た目として画動きがかっこよく滑らかかどうか」について重きを置いて作り込みをしたとのこと。
下は，主人公に対する動き制御の基本事例として示されたものだ。
 縁へのぶら下がりアクション |
 壁へのぶら下がりアクション |
これは，崖などの縁や岸壁に掴まってぶら下がり状態で横移動する挙動になるが，腕の動きは完全に事前制作したアニメーションを再生しているものになる。それ以外の部位，たとえば胴体などの下半身や脚部などは，逆に完全に物理シミュレーションの制御下に置いた挙動制御とした。
注意深く見ると，これまたオレンジの人体模型のような3Dモデルの姿が見え隠れしており，これは，主人公に設定された「ぶら下がり状態の基本姿勢」を表している。このオレンジの人体模型の姿勢の方を観察すると，そのひざは曲がり，その曲げ角がほぼ固定化されているのが分かる。この「足曲げ姿勢」がぶら下がりアクション時の基本姿勢なのだろう。
対して，ぶら下がり移動や飛びつきアクションをする主人公キャラクターのほうを観察すると，ひざの曲がった基本姿勢のまま，下半身がぶらりぶらりと揺れているのが見える。この下半身や脚部の揺れは，そうしたアクションの際に発生した慣性モーメントの影響が適用されているためだ。
この出来映えに手応えを得た開発チームだったが，すべての主人公アクションがこの実装アプローチでうまくはいかなかった。
たとえば主人公のスライディングアクションを捉えた動画では，前出の「ぶら下がり移動」と同じで，「腕を広げた中腰姿勢」の基本姿勢に対し，左右方向転換を行った際の慣性モーメントの影響や，障害物からの衝撃を主人公モデルに適用しただけのものだ。これはなんだか「やじろべえ人形」のように過剰にフラフラしていて不自然だった。
 |
これに対処するべく，開発チームは試しに，関節のジョイント駆動の抵抗値を上げてみたところ，今度は逆に硬い動きとなり，不自然な印象には変わりがなかった。揺れにくくするために関節に抵抗を入れてみたが，今度は硬くなり，生き物っぽさがなくなったのだ。
そこで，開発チームが試したのは，関節のジョイント駆動の抵抗値を元の「やじろべえ人形」に戻したうえで，物理シミュレーションの結果の適用割合を50％に減退させるアプローチだった。
 |
たしかに，これで関節のジョイント駆動の抵抗値を上げたときの硬い動きとは異なって見えるようになった。慣性モーメントの影響や衝撃からの影響は受けやすい挙動にはなっているが，その威力は弱く，「動きの余韻」の収束も早い。
この「物理シミュレーションの影響を50％減退させる」というのは，物理シミュレーションの影響に対して，主人公キャラクターが「腕を広げた中腰姿勢」のまま踏ん張って耐えているというような意味合いになっているようだ。そう仮定したうえで動画を見直すと，たしかにそんな感じに見えてくる。
ちなみに，これはセッション内で語られた情報ではないが，実はこのアプローチ，かつてのPS2時代の名作ゲーム「ワンダと巨像」の主人公のキャラクターアクションに採用されたものだったりする。この偶然は非常に興味深い。
なお，実際のゲーム中の映像では，主人公キャラクターモデルからはみ出して見えるオレンジ色の人体モデルは，例によって基本姿勢を表している。衝撃の少ない状態ではオレンジ色の人体モデルで表される基本姿勢と，物理シミュレーションからの影響を適用した主人公モデルとの差異が少ないことが見て取れる。
 |
Waszak氏によるとこの「物理シミュレーションの結果適用割合を減少させる」手法は，かなり広い範囲で応用できたそうだ。ただ，その減退割合は主人公のアクションごとに調整が必要だとも振り返っている。
たとえばクライミングアクションでは，この動きについては，事前制作したアニメーションに対し，物理シミュレーションの影響度は40％としたという。
 |
Waszak氏はこれ以外に，向かい風の威力は45％，ロープの上り下りの際の慣性モーメントの影響は40％と設定したことを報告した。
 向かい風の中での歩行アクション |
 ロープへのぶら下がり/よじ登りのアクション |
梁に対する"うんてい"アクションでは，当初は物理シミュレーションの影響度を50％として設定していた。
 |
これはこれで良さそうな気もしたのだが，開発チームからは，ちょっと「動きがやかましすぎる」という評価が下されたという。たしかに動きとして上下の躍動が大きく，コミカルすぎる印象がある。
そこで，梁に対する"うんてい"アクションでは，物理シミュレーションの影響度を50％とはするものの，物理シミュレーションの影響対象を「主人公キャラクターの腰だけ」に限定する工夫を入れたそうだ。
 |
これにより，上半身の躍動がかなり抑えられ動きがスムーズとなり，かっこよさが出てきている。それでいて下半身の慣性モーメントの影響はそれなりに出ているので躍動感はそこそこに感じられる。
歩行/走行アクションについては，走り出し，停止，方向転換のアクション時には，物理シミュレーションの影響度を40％として設定した。逆に歩行中や走行中のアニメーションに対しては物理シミュレーションの影響度をゼロとした。これは「適用の必要性を感じなかった」ためと説明されている。
実際のテストシーンでの主人公キャラクターの歩行，走行の動きの様子を確認すると，たしかに走り出し，停止，方向転換時には，慣性モーメントの影響で，腕がぐるんと振り回される様が見て取れる。この動画でもオレンジの事前制作アニメーションが重ね合わせられているが，走り出し，停止，方向転換時に，大きなずれが確認できる。これはつまり，そうしたタイミングでは物理シミュレーションの影響が大きく出て，事前制作アニメーションとのズレが出ているということである。
 |
 |
 |
この状態で，十分なクオリティではあったが，テストを重ねていくと，特定の状況下では不自然動きが出てしまうことが発覚したという。
たとえば，人間は歩行/走行動作のとき，踏み出した足とは逆側の手が前に出るような動きが自然となる。これが，物理シミュレーションの影響を適用した結果として，同じ側の足と手が共に前に出たり，引っ込んでしまうような動きになってしまうことがしばしば見られたというのだ。
この不具合に対しては，主人公キャラクターモデルの各関節に対し，束縛を与え，物理シミュレーションの影響範囲の抑制を行うことで対処した。この抑制で，ベースとなる歩行/走行のモーションから大きく逸脱するような手足の振り方にならないようにしたというわけだ。
 |
 |
これと同様の制御は，梁の上を歩くバランスウォークのアクションの際の腕の動きの制御にも採用された。
 |
背中にくっついた相棒ドロイド「BD-1」の挙動について
続いて，Waszak氏は，主人公キャラクターの背中に張り付いて，冒険を助けてくれるオタスケロボ（ドロイド）のBD-1の動きについての解説も行った。
 |
BD-1の下半身部分は事前制作アニメーションの再生のみの動きで，上半身と頭部が物理シミュレーションだけで動きが付けられているという。
つまり，プレイヤーの操作に合わせて稼動するBD-1の動きは事前制作アニメーションだけで動き，物理シミュレーションの影響はなしとし，歩行/走行，その他のジャンプアクションなどによって摂動させられるBD-1の頭部のブルブルとした動きは，これまた逆に物理シミュレーションの影響100％で動かしたとのことだ。要するにBD-1の上半身や頭部は，基本姿勢や演技モーションのないイヤリングやキーチェーンなどのようなアクセサリ類に近い扱いとなっているわけだ。
ただ，主人公の動きが激しいと，物理シミュレーションの結果100％で動きを付けているBD-1の頭部が激しく動きすぎて不自然になり，これに対処する必要が出てきたそうだ。
その対処とは，例によって束縛を与えることになるのだが，その束縛の与え方は「ややアルゴリズム的」となっている。
それは，物理シミュレーションの結果「BD-1の頭部の挙動スピードが遅いときは，頭部の移動範囲を比較的広く許容」し，逆に「挙動スピードが速いときは頭部の移動範囲を小さくする」というものだ。まあ，これも，BD-1の気持ちになると，頭部が遅く揺れるときは気を抜いて揺れに身を任せ，頭部が速く動いてしまいそうなときは，動かないように堪えるといったような意思の反映と考えられなくもないかもしれない。
 |
左側の束縛メカニズムなしの場合は，BD-1の頭部が完全に主人公キャラクターの背中に潜り込んでしまっている。これに対し，右側の束縛メカニズムありの場合はそれが抑えられている。
さて，BD-1の挙動制御には，こうした工夫以外にもいくつかの細かい調整が必要になったとWaszak氏は述べる。
まず，BD-1は，主人公の背中に合体しているときには平常サイズの85％に縮小されるのだという。まぁ，これは「ゲーム的な演出」ということだろう。
そして「主人公の背中にくっついています」という設定上，その物理挙動は，主人公の動きに連動することになるのだが，特定の状況下で「その連動感」（いわば一体感）がぎこちなく，バラバラに動いているような印象になることがあり，開発チームはこの症状への対策を行った。
その対策とは，まず，物理シミュレーションの実践を「主人公用」と「BD-1用」とに切り分け，最初に主人公用物理シミュレーションを計算し，その次にBD-1用物理シミュレーションを計算する順序とした。BD-1はいわば，主人公の付随物とし，BD-1の次の動きは，主人公の物理挙動の影響を受けるとするが，BD-1の動きが主人公には影響を与えないという関係性の演算パイプラインにしたのだ。
しかも，それぞれの物理シミュレーションの計算は，描画（≒表示）フレームレートとは独立した，あらかじめ設定した固定サイクルで行い（たとえば30fps），毎フレームは行わない。描画（≒表示）フレームレートが高い場合（たとえば60fpsや120fpsなど，あるいはその可変フレームレート）は，一番最近に行った物理挙動の演算結果から補間して求められた動きで代行することとした。
この工夫により，BD-1は主人公の動きに深く連動しつつ安定した物理挙動をするようになったとのことだ。
本作の挙動制御の基本方針としては，「事前制作アニメーションと物理シミュレーション」の合成を行うことで，キャラクター演技に，息づくゲーム世界との一体感を与えることを目指す」というものだったが，単一の実装手法ではうまく行かず，さまざまな状況下，制御対象の種別，各キャラクターのアクション，ゲームメカニクスとの都合などに応じて，細かい対応や工夫が必要だったというのが本セッションの総括ということになるだろう。
ゲームグラフィックスに限らず，画像，映像というメディアは，最終的な製品としてリリースする前にさまざまな調整を行うわけだが，「事前制作アニメーションと物理シミュレーションの合成」という要素も，その「調整」テーマに挙がるようになってきた。そんなことが見えてきたセッションだったようにも思う。冒頭でも述べたように，今後のゲームでは「プレイヤーをゲーム世界に引き込むのに十分な説得力のある動き」が求められているだけに，こうした作り込みはどんどん重要になってくるはずである。
思えば，以前は，そうした物理挙動に配慮したアニメーションの作り込みは，ゲームに適した物理エンジンの開発から取り組まなければならず，技術難度が高かった。しかし，最近は，優れた物理エンジンが利用できるゲームエンジンが身近になってきているため（そうした近代ゲームエンジンを利用してゲーム開発を行う場合に限っては），アイディアと手間だけでユニークかつ説得力の高い動きをキャラクターに付けることができるようになった。「UE4×PhysX」で作り込まれた本作は，まさにその好例だったと言えるかもしれない。
本作は世界各国のメディアの「Game Of The Year」のノミネート（SXSW Gaming Awards 2020など），あるいは受賞（Titanium Awards 2019など）を果たしており，全般的に評価が高いので，まだ未プレイの人は，ぜひとも挑戦してみよう。今回取り上げた技術テーマ「事前制作アニメーションと物理シミュレーションの合成」に着目してプレイしてみるとさらに楽しめるはずだ。ちなみに，2020年8月時点でEA Originストアならば半額の4752円で購入できる。
