講演者 原 龍 岩澤 晃
SNS投稿可能
資料はCEDiLにて公開予定
※下記URL参照
https://cedil.cesa.or.jp/
下記資料に乗っていることも記載してあります。
自分の知識を安定させるためにやっていますが、間違っているかもしれないので詳細はアップされる資料を参照ください。
資料に載っていない講義者の発言もフォローしているところがあるので、そのあたりは参考になると思います。
最初に講義内容を記載し、最後に講義に関しての感想や意見などを書き込んでいます。
少し荒いのでそのうちリファインするかもしれません。誤字などに気が付かれた方いましたらコメントいただけると幸いです。
■講義内容
ここ数年で発表されてきたアニメーション関連技術をどのように組み合わせたかという話がメイン
アンリアルエンジン4を使用していますがエンジンに依存しない内容なのでそちらに関しての言及はなし
■資料補足
DCCツール（ビデオゲームを含むインタラクティブコンテンツを作るためのツールの総称）から出力されたアセットをゲームエンジンが読めるフォーマットでコンバートしたデータのことをuassetと表記します。
モーションuassetのタイムラインに対してゲームエンジン上で設定されたクリップデータののことをNotifyと表記します。
■アニメーションシステムの全体像
・フィールドボディのアニメーションレイヤー
Locomotion 全キャラクター共通移動系
全キャラクターで使用しているアニメーションが一番低レイヤーにある
各ステートはモーションの有無で分岐
モーションパックの切り替えで動きを全体的に切り替えることができる
メンテナンスがしやすく不具合が少なかったが、アニメーションのつながりを凝りたい場合にやりにくいというデメリットがあった
キャラクター固有アクション
Locomotionより優先。リクエストがあれば即時ブレンドが実行される
同じレイヤーのリクエストがあればすでに動作している動きは破棄され次のものが再生される
モーションのつながりを担保していないため絵が破綻しやすい
常駐の部位指定ブレンド
Resident(部分ブレンド) 常駐の部位指定ブレンド
しっぽなどLocomotionのステートに依存しないもの
■レスポンスの良さと絵を両立させるために
レスポンスをよくするためにモーション遷移タイミングはゲームプレイ側で比較的自由に扱えるようにしたい
可能な限り破綻させたくない
↓
補完ロジックで速度の連続性（慣性）を再現する
・慣性補間
ブレンド開始直前のポーズキャッシュをもとに加算アニメーションを生成する
モーションアセットのEvaluate回数が少なくなるためCPU負荷も低い
ただしメモリ使用量は増える
・躍度最小モデル
人間の動きには普遍的な特徴がある
評価関数がいくつか定義されている
慣性補間では躍度最小モデルが使用されている
加速度の変化率である躍度を2乗したものを区間内で積分し、それを評価関数として最小になるものを最適としている
遷移時の速度を維持するので自然なブレンドを実現可能
あまりにも違うモーションだとうまくつながらないが、破綻しにくいのでコンボなどアニメーションをつなげるときに許容する入力タイミングを比較的広くとることができる
※慣性補間のアルゴリズム式の紹介あり。詳細は展開された資料を参照
・オーバーシュート問題
値によっては収束までの過程で0を超えてしまう。その状態。不自然ブレンド、行き過ぎる状態。
※こちらも資料詳細。ブレンド時間を短くすることで対応できるようになったとのこと
慣性補間はアンリアルエンジン4.24からは標準機能になった
■遷移先モーションポーズ比較（Pose Matching）
走っている → 止まる動作を行う時に複数の動きを設定しておいて、現在の動きから適当なものを選択して遷移させる
遷移先モーションの候補が複数ある場合にポーズ比較による自動選出を行う
遷移先モーションはキャラクター単位で出追加指定が可能
→特定のキャラクターだけ候補を増やすことが可能
Nortifyを設定して遷移先候補フレームを追加/限定可能
ポーズの比較はすべてのボーンで比較するのではなく、セットアップ時に対象のボーンを指定する
→二足歩行の場合は下半身の形状が近いほうを優先して選出するようにすると全体的に良い結果になった
慣性補間は補間前後のポーズ差分が少なければ加算される値がゼロに近づくためブレンド時間を長くしても違和感にならない
基本は長い時間をかけてのブレンドで問題ない状態。個別に調整したいところだけ対応する。 → 一つのデータ設計の理想形に近づいていると思うとのこと
ブレンド時間の調整時間を減らすことができた。
■移動入力補正
コントローラーやAIからの入力に対してボーン単位で回転補正を設定。
プレビュー環境でキャラクターを動かしながらリアルタイム編集
設定はIK Control Rigによって共有可能
・移動入力補正
Charactor(uaset) モーションデザイナー作業
プレビュー環境でキャラクターを動かしながら調整する
IK Control Rig(uasset)
Unreal Engine 4セットアップ作業
■IK/Facial Control Rig
モーションポーズに対して様々なポストプロセスを実行して補正している。
・Look at
キャラクターを任意の方向に向かせる
補完ロジックは慣性補間と線形補間のみ
ボーン毎に重みや角加速度を設定可能
慣性補間を使う場合は収束までの時間に対してランダムバイアスを設定できる
→最終的に同じ角度に収束するにしても、動きが一定になりにくくなる
角度制限はPitchとYawで分けている
※左右の軸まわりの回転がpitchで、上下軸まわりの回転がyaw
モーションポーズを維持するためのボーンの向きをメッシュ空間で計算するオプション有り
ワークフロー
IK Control Rig(uasset) Unreal Engine4セットアップ作業 各種パラメータ設定を行う
↓
Motion(uasset) モーションデザイナー作業
↓
Game Data ゲームデザイナー or プログラマ作業 Look At Targetを指定する
作業順番としては上記であるが、あとでIK Control Rigを変更してもよい。
大事なことはモーションデザイナの作業を複雑化させていないということ
不具合が発生する可能性を極力減らして、何かあったとしてもIK Control Rigの調整だけで解決できるようなフローにしている
・Aim
Look at とは明確に分けている
Aimはエンドエフェクターを複数持つことができるが、その代わり補完ロジックは簡易的なものしかないというすみわけ
補完ロジックはEaseOutと線形補間のみ
※対象が動き続けるため慣性補間は相性が悪かった
Aim Groupをセットアップ時に定義してNortifyからAim Group指定で呼び出す
グループ×ボーンごとに重みや角速度を設定可能
ワークフロー
IK Control Rig(uasset) Unreal Engine4セットアップ作業
↓
Motion(uasset) モーションデザイナー作業
↓
Game Data ゲームデザイナー or プログラマ作業 Look At Targetを指定する
・Hand IK
アルゴリズムはFABRIKを使用
IKターゲットは二種類
グローバル座標を指定するManual設定
エフェクター相対位置を指定するLook設定
ワークフロー
IK Control Rig(uasset) Unreal Engine4セットアップ作業
↓
Game Data ゲームデザイナー or プログラマ作業
・FABRIKについて
IKターゲットに対して末端ボーンを移動させる際に開店行列を使わずに各ボーンの位置を船上に配置して決定する手法
逆行列計算を必要としないので少ない計算コストで近似値的な買いが得られるのが特徴
『FINAL FANTASY VII REMAKE』ではHand IK/Foot IKに使用
・Foot IK & Hip Control
地面の凸凹を検出して足先の位置変更を行う
Foot Lock（足先一固定）により、腰の位置に動的なオフセットをかけられるようにした
バトル中のガード歩きは通常の歩きモーションを流用しているが、重心を落とすために腰位置を10㎝程度下げながら再生している
→モーションを増やさずにガード歩きに対応できた
すり足歩行にならないように、Base Height（爪先 or 踵の内、地面から最も近い高さ）分は地面から離れるように保証している
経ちもしくは歩きの場合、設置している足の中で地面の高さが最も低い位置に合わせて腰を落とす
傾斜に合わせてルートボーンを回転させ、腰の位置を補正する
ワークフロー
IK Control Rig(uasset) Unreal Engine4セットアップ作業
↓
Motion(uasset) モーションデザイナー作業
・Balance
Foot IkやHip Controlで体の軸がずれるので、傾斜角に合わせてボーンに回転補正を行う
設定できるのは下記項目
Ptichに対する加算値
Ptich絶対値に対する加算値
Rollに対する加算値
■ゲームエンジン上でのコントロールリグは必要なのか？
ランタイムで補正及び調整作業ができるというのが重要
専用のプレビュー環境を用意してもゲームを動かしながらパラメータを調整したいことがある
→実際のゲームが動いている環境で調整したことが出てくる
環境（背景物や周囲のキャラクター）のへんかで結果が変わるものについては積極的にゲームエンジン内のコントロールリグで対応したほうが調整が早い
どうせ実際のゲームが動いている環境で調整したことが出てくるんだから、それを見越して設計する必要があるということ
・BodyDriver(物理アニメーション)
テクノロジー推進部が開発している物理アニメーションシステム
一部のキャラクターの死亡演出に使用
単純なラグドール（物理）とは違い、ヒット位置を手で押さえる、歩きながら倒れる等の演出的な動きをランタイムで生成して再生する
ワークフロー
Physics Asset(uasset)
BodyDriver Data(uasset) Unreal Engine4セットアップ作業
↓
Game Data ゲームデザイナー or プログラマ作業 BodyDriver開始時に攻撃方向や強さを渡す
・物理高速補正
Position Based Dynamics[MHHR01]を使用した物理的な拘束条件を適用する補正処理
→設定されたスプラインなどに沿って動かした場合にも自然な動きにするように対応
モーションを増やさずに動きを作ることができる
拘束条件のプリセット化されてた組み合わせをメッシュにユーザーデータとして設定
一部のキャラクターでは加算で再生する
ダメージリアクションに物理拘束補正を併用
攻撃の方向によって絵が変わるのでヒット時の気持ちよさに繋がる
メッシュ空間での物理シミュレーションで負荷も少ないため、簡易的な背景物にも使用
物理のoN/OFFや速度、重力などがゲームプレイから制御しやすい
基本的な動きだけつけて、あとは物理処理に任せるという対応が可能
ワークフロー
Physics Constraition Data(uasset)
↓
Game Data ゲームデザイナー or プログラマ作業 ON/OFF等の制御が必要な場合にのみ呼び出し
中川展男 CEDEC 2017
PBDは物理オブジェクトの位置を速度から単純計算し、設定された高速条件をイテレーション指定地を修正した後に位置の差分から速度を確定させるという手法。
手法自体がシンプルなので安定性も高く、処理コストも少ないためゲーム向き
拘束条件をゲーム都合で調整できるので物理的には正しくない演出的な動きにも対応しやすい
Position Based Dynamics[MHHR01]を使用した物理的な拘束条件を適用する補正処理
→設定されたスプラインなどに沿って動かした場合にも自然な動きにするように対応
モーションを増やさずに動きを作ることができる
メッシュ空間での物理シミュレーションで負荷も少ないため、簡易的な背景物にも使用
・Kine Driver（補助骨）
CEDEC2019 次世代を見据えた新しい補助骨システムの開発
テクノロジー推進部が開発する補助骨システム
DCCツール上でリアルタイム動作する
エクスプレッションを設定でき、ゲームランタイムでも同じ結果を得られる
ワークフロー
KineDriver Data(kdi) Mayaセットアップ作業
・Bonamik（骨物理）
CEDEC2016 CHARACTOR&ENVIRONMENT WORKFLOW
テクノロジー推進部が開発する骨物理システム
キャラクターの揺れ物全般に使用
アーティストが制御しやすい
場面に合わせてNotifyでパラメータ調整ができる
ワークフロー
Bonamik Data(bnm) Mayaセットアップ作業
■Facial Animation
・Saccade(眼球運動)
視線を移動させる時、眼球は短い時間で移動と停止を繰り返す
一度に移動する確度には制限がある
視線を向けた状態で対象物がゆっくりと移動する場合にのみリニアに動く
Micro Saccadeによって視線が動かないときにも眼球が止まることはない。こちらはSaccadeよりも移動と停止の周期が早い
・Gaze diversion（視線を逸らす）
何かを注視するときにも無意識に視線を逸らすということをしてしまう。
特に会話するときは非言語的コミュニケーションとして無意識に視線を逸らす。
相手を凝視するのは敵対心の現れ
条件をしっかりやると大変なので、時間経過でランダムに視線をそらしてみたが問題なかった
・Saccadeに対する瞼の連動
眼球の動きには必ず瞼が連動する
Saccadeの細かな動きがわかりやすくなる
Yaw、Pitchを入力として、上下左右のポーズモーションをブレンドしている
・まばたき
時間経過で発生する周期性まばたき
2～10秒でランダムに発生する
急な眼球運動によって発生する反射性まばたき
Look At対象位置が大きく移動すると発生する
完全に閉じたまばたきが発しえした場合はSaccadeの移動角度制限を無視する
まばたきのアニメーションは一連のモーションとして持たず、目を瞑ったポーズモーションをブレンドしている
時間とブレンド率のカーブはアセットで設定
まばたきは常に完全に閉じるわけではなく、0.5～1.0のランダムバイアスをブレンド率にかけている
・ボディの動きからSaccade自動生成
体感と顔の向きからSaccadeを自動生成
すべてのボディモーションに対してjenkinsからカーブをベイくしている
AIからLook Atリクエストがない場合に使用
・HappySadFace（自動リップシンク）
テクノロジー推進部が開発している自動リップシンクシステム
音声とテキストから専用フォーマットで出力し、MayaとUnreal Engine4でリップアニメーションを再生
JP/US/FR/DEの4言語に対応
タイムラインデータがシンプルなテキストデータなので、全体的に滑らかにするための一括フィルタリングのようなこともできる
ボイスから音素を抽出して形状データのインデックスをタイムライン化しているため、形状データを変えれば同じように動く
音素に対する形状の対応表は言語ごとに作成
感情によって表情が変化するのに合わせて形状データのプリセットも差し替えるようにした
課題
ボイス内にあると想定する音素のリストがテキストの内容に依存するためテキストが間違っていたりアドリブボイスが頭に入っていると精度が極端に落ちる
リップが動いていないデータに対してアラーチェッカーを用意できるが、動いているけどあっていないというのは目視で確認する必要があるため確認コストが高い
・ボイス音量から眉のアニメーション生成
ボイスのアタックを検知して、音量に応じて眉を上げる加算アニメーションを生成する
加算なので小刻みに連続再生されても問題ない
眉を上げた状態のポーズモーションを用意して、ブレンド率に応じて加算する。
・ボイス音量から状態加算アニメーション生成
ボイスのアタックを検知して、音量に応じて状態を前後させたり頭や首をひねる動きを加算アニメーションとして生成する
加算なので小刻みに連続再生されても問題ない
加算値はIK Control Rigでプリセットとして定義。
どのプリセットを再生するかは再生時にランダムで決定。
・ボイスから表情アニメーション生成
ST Emotionを使ってボイスから感情を推定。
感情パラメータの変化に合わせてアック種表情ポーズをブレンドする
表情パラメータは1ボイス単位ではなく、タイムラインデータになるので1ボイスの中でも表情を変化させることができる
推定の精度は70％程度だったが、何かしら変化があるだけで表情の柔らかさが全然違う
・ラッセルの感情円環モデル
表情パターンはラッセルの感情円環モデルを参考にして全キャラクターにセットアップ
感情パラメータの変化に合わせて円環モデルの中でサンプリングする位置が変わるが、線形でブレンドすると硬さが出てしまうため、ブレンドカーブを使ってサンプリングする位置を変化させるようにした。
・ST Emotion SDK
リアルタイム動作可能な感情解析モジュール
火との声から5つの感情状態を10段階で検出する。
検出できるのは「喜び」「怒り」「悲しみ」「平常」「興奮」
ゲーム文宇アデノ技術協力は本タイトルが初だが、これまでに数々のサービスで採用された実績があり信頼性が高い
■まとめ
レスポンスの良さと絵を両立させるために
慣性補間+Pose Matching
環境にあった納得感のある動きにするために
ゲームエンジン上で動作するControl Rig
Position Based Dynamicsを使った都合の良い物理シミュレーション
カットシーン以外でも自然なフェイシャルを量産するために
ボディやボイスを利用した自動生成
■総評
情報量が多すぎる！
調べながら確認しながら見ていたので1時間未満の講義を見るのに5時間くらいかかっています。
動画を止めて確認して、という作業を繰り返していたが全然進まなくて絶望。
実時間は1時間くらい進んでいるのに動画自体は2、3分しか進んでいないかんじ。
見るのに時間がかかるということは内容が理解できていないということですね。
デザインのクオリティを上げるためにここまで細かい処理を積み重ねているのがすごいですね。
この発表の後追いをするということだけでもすごいことだと思うのですが、先駆者として手順を作り上げる過程を考えると想像を絶します。
基本的な考え方として
・どうすればより良いコンテンツが作れるのか、デザインのクオリティを上げられるのか
というところが第一にあるように思います。
そのうえで「ゲームプレイをするうえで気になるような処理にできる限り対応する」ということが方針になっているのではないでしょうか。
それを実現するためにデザイナーの仕事量を減らしつつクオリティを担保する、ということを目指しているように思います。
更にそれを実現するために必要な技術を検討し、より良いものを採用しているという感じですね。
もうプログラマがプログラム関連にだけ詳しければいいという時代は終わり、デザインをよくするためにはどのようなことに気を付けていないといけないか、それを実現するためにどのような知識を持っておかないといけないかという部分が問われるようになっています。
Saccadeで検討されている人間の自然な動きというのは優秀なアニメーターであればこの辺りを表現できているんですよね。
デザインをやっているとちゃんと物を見なさいと言われるのですが、この講義で取り上げられているようなことをどれだけ認知できているでしょうか？
生きている間中見ているはずなのに気になっていないのは、ちゃんと見ていないということなんですよね。
多言語のリップシンクの対応はすごいの一言ですね。
音素から感情をくみ取るというのが簡単に言ってますがすごいです。
自然な動作を実現するためには多くの情報をデータに設定する必要があり、それを実現するためにはこれからは画像や音声から感情などの情報を読み取るような、いわゆる認知の検出が必要になってきそうです。
「音素のリストがテキストの内容に依存するためテキストが間違っていたりアドリブボイスが頭に入っていると精度が極端に落ちる」という部分に関して、ゲームのシナリオは感情を表現するときに「…」を多用しがち。
それを声優さんに渡すとうまく演じ分けてくれるのですが、それだと感情の起伏を検知することができない。
シナリオの作り方も今後変えていく必要がありますね。
講義内容に関して前提となる知識が膨大になってきています。
講義内容を理解するためにはCEDECで今までに発表されている内容は理解していないと駄目ですね。
本来であれば更にその先の、発表する側に回れるようにどの技術を採用していくのかという部分まで関画れていないといけないのですが。
何はともあれ一朝一夕にはできませんし、すべてを自分一人でやる必要もないのでできるところからやっていくしかないですよね。