その動き、機械が見つけます!? モーション・マッチングで、 やるぜ働き方改革！【CEDEC2024】

その動き、機械が見つけます!? モーション・マッチング で、 やるぜ働き方改革！ Epic Games Developer Relations, Software Engineer 湊 和久

自己紹介 Epic Games Japan でサポートやってます 湊と申します～ ■略歴 学生時代にゲームを作り、調子こいて大学をドロップアウト 路頭に迷う 20代は職も会社も転々とし、 一時期（手で描くほうの）アニメーターも・・・ 主な職歴に ・バンダイナムコゲームス／スタジオ ・Ubisoft キャラのアニメ制御まわりも3-4タイトル経験 今日はアニメ関係の話ができて嬉しいです！よろしくお願いします！

手描きアニメーター時代も アニメーション制御プログラマだった時代も 共通で苦しんだことがある 足ィ！ 動きの繋ぎ込みの難しさの象徴

■業界俗語 「滑る」 体重が乗ってる足がズレること

足よ、滑ることなかれ ※ https://www.clipstudio.net/oekaki/archives/151955 より引用 https://x.com/oyamanime99/status/1346045 778934992898 どんな低予算アニメや子供向けアニメでも足は原則合わせてた 筆者の経験では、映像作品で足が滑るとリテイクを食らうのが基本

• https://www.clipstudio.net/oekaki/archives/151955
• https://x.com/oyamanime99/status/1346045778934992898

でもゲームでは・・・ 成功例 GIF GIF GIF ©Ubisoft 滑りまくり！ （実際、抑制するのは一筋縄ではない） 割り切ってるゲームもあるし、限界まで努力しているゲームもある いっそワイヤーアクションみがあってカッコイイまであるのも事実 ゲームでは足滑りが気にならんという 人もおるかものう ✖ゲームでは足が滑っても気にならない 〇気にならない水準まで工数かけて作りこんでる

とはいえ GIF GIF カットシーン ←→ GIF インゲーム カットシーンは映像クオリティ（映画・TVアニメ並み）なのに、 インゲームは「動きがパカパカ、足は滑り、ターンテーブルで振り向く」 ・・・いつまで受け入れられるかは分からない 今日は足滑りの解消を一つの指標として、 アニメの繋ぎこみに使える新しめの技法をチェックしていきます

ゲームアニメーションにおける 従来手法 とそのジレンマ

本日の講演に関連する従来手法 ■クリップ再生 ■ブレンド ■ブレンドツリー 単一のアニメーション（クリップ）を そのまま再生する基本手法 複数のクリップを混合させて、別の動 きを合成したり、クリップ再生をクロ スフェードする技法 ブレンド結果を別のブレンドに投入 し、ツリー状の関係性が生じたもの ■ステートマシン ■ブレンドスペース 肥大化するブレンドツリーを分割できる手法。「泳ぎ」「走り」「落下中」な ど、大枠のキャラクターの状態（ステート）を扱えるようにし、ステートの下 にブレンドツリーをぶらさげる。 複数クリップを四象限グラフにバラま いてブレンド比率を決める応用手法 ステート間の遷移はブレンドで移行する

ジレンマ①： ブレンド前提のクリップ編集 ・演技に必要な最低限の尺へのトリミング ・関連するクリップの尺合わせ ・同期マーカーの仕込み …なかなかつらい

ジレンマ②： ステートマシンのマイクロマネジメント ・状態と状態のあいだに、追加の状態が必要（「状態遷移」状態） ・状態遷移の取り消しや遷移先の変更への対応 ・やがて人智を超えた蜘蛛の巣図に・・・ 右足前 歩き始め 右足前 待機 左足前 待機 左足前 歩き終わり 左足前 歩き始め 右足前 歩き終わり 前歩き ループ

ブレンド前提のクリップ編集という苦行 複雑性が爆発するステートマシンのマイクロマネジメント これを乗り越えても、カンタンに足が滑る残酷な現実 この三重苦を 一撃で葬るかもしれない新しめの技法が・・・ モーションマッチング

モーションマッチング の 概要

モーションマッチング をざっくり述べると ● キャラクターの動作をリアルタイ ムに自動で繋ぐ技術 ● 特に、足の動きが非常にスムーズ に繋がるようになるのが特徴

モーション・マッチング技法採用タイトル例 「PART I」でも 使ったよ 2016年技術発表 2017年リリース 国産初採用 タイトル チャプター5で採用 UE5.4で正式公開 100体同時に出るゲームじゃない が、おおむね十分じゃろう 100体のPCとNPCに適用。 モバイル～Switch～ハイエンドで データ量を変更しつつの縦マルチ対応

動作の仕組み ● 大量のアニメーションクリップを データベースに登録 ● サンプリングしてポーズに分解 し、加速度や速度、軌跡を分析 ● ランタイムではキャラクターの ポーズ履歴をとり、過去／未来 （予測）軌道を算出 ● これらの情報を手掛かりに、「今 の動きに繋がるポーズ」を非常に 短い周期で検索し適用していく GIF

ちょっと何言ってるか分からない

ちょっと何言ってるか分からない ので・・・ 公式サンプル で モーションマッチングの 動作を見てみよう

おすすめの二大教材 （どっちもやりましょう） Your First 60 Minutes With Motion Matching 以下「60分チュートリアル」 左を軽くやらんと 右が分からんよのう～ Game Animation Sample 以下「公式サンプル」

Game Animation Sample Epic Games による公式サンプル（大量のデータ付き！） 「500以上」の 高品質アニメーション 収録アセットはすべて再利用可 （※UE5採用プロジェクトにおいてのみ） モーションマッチングを含む 最新技術の実装サンプル 「無料」です

実行時の主な操作方法 あとで見てね 左スティックで移動 左スティックでカメラ操作 右スティック押し込み(R3)で ストレーフのOn/Off RBで「歩き↔走り」

パルクール操作 Aボタンで「ジャンプ」 障害物の近くで押すと 「トラバーサル」 障害物の高さで 動きが変化 トラバーサルは専用クリップの 単発クリップ再生（”モンタージュ”）で実現

専用ウィジェットで内部動作を可視化 このパネルに触れると、ヘルプ機 能満載のウィジェットが開く 軌道の可視化 MMクエリ可視化 アクセスしやすい位置へ ドッキングしておこう

巻き戻し リワインドデバッガ ②PIEを開始 ⑤PIEを一時停止 ④キャラを操作 ①主キャラを選択 ③録画ボタンをクリック ⑥マーカーをスクラブし 巻き戻す

タイムマーカーを戻し、 モーションマッチによるBlend Weightsを確認 「クリップの途中から、再生速度をい じりながらブレンド」という離れ業を みせているのが分かる ※再生速度変更は許可時のみ

ポーズ検索 Pose Search - ポーズ間の 低コスト入札合戦 モーションマッチングでは、検索フレーム（e.g.毎フレーム）において 状況にベストマッチするポーズを1つ選出 ポーズのコストを評価し、もっとも安いものを選ぶ

ブレンドスタック しかし、これまで再生していたクリップを即打ち切るわけにはいかないの で、ブレンドで余韻を混ぜ込みます。 このブレンドの積み重ねをブレンドスタックと言います。

従来ブレンド VS ブレンドスタック 従来の「ブレンド／ツリー／スペース」では、アニ メーターが選定したクリップ同士の混ぜ合わせを予め 設計して組み込み、ブレンド率で出力を決める。 いわば、アニメ界の「あいがけカレー」であり、面倒 なぶん、味のコントロールが可能である。 一方、「モーションマッチング」ではシステムが 「いま一番グッとくる」クリップを一つ選んで再生。 いわば、「バイキング」スタイルであり、 システムは次々に最適な一品を口に入れるため、 その場で口内調味された複雑な味が生み出される。 ブレンド ブレンドスペースが不要というか 同じことはできないんじゃな

モーションマッチには 難所も多い でも今日は次の点に注目したい！ 「ブレンド前提のクリップ編集」からの解放！ 「ステートマシンのマイクロマネジメント」からの解放！ 少ない工数で、 足を滑らせず繋がるアニメーション再生を実現！ AAAAの土俵では、データ量で殴りにいくケのある技術だが、 最小データ量だと従来技法でバチ組みするより品質が向上 （主観ながら、「うちはモーション量少ないんで、ステートもシンプルなもんっすよ～」系プロジェクトで も導入検討の余地あり）

10分で分かる UE5モーションマッチング 組み込みガイド

モーションマッチング組み込みまでの ３ステップ クリップの準備 データベースの 構築 ABPへの 組み込み ※ABP=アニメーションブループリント

クリップの準備 「ルートモーション」を有効化した アニメーションシーケンスを用意 動きの持つ軌道や速度の解析に ルートモーションが必須 ルートモーションで動くわけではないが、 ルート骨の動きが必要 ループアニメーションには Loopフラグを付与すること

モーションマッチング組み込みまでの ３ステップ クリップの準備 データベースの 構築 ABPへの 組み込み

ポーズのデータベースを作ろう！ + Add 1 スケルトンを指定して 「ポーズ検索スキーマ」を作成します 2 スキーマを指定して 「ポーズ検索データベース」を作成します 3 データベースに「アニメーションシーケンス」を 登録（ドラッグ＆ドロップ）していきます

有効／無効ボタン GIF 選択クリップの解析結果 方向によって移動する長さがバラ バラでも、もう問題ないんじゃよ

モーションマッチング組み込みまでの ３ステップ クリップの準備 データベースの 構築 ABPへの 組み込み

Motion Matching を利用したABPの超基本構造 ステートマシンの場合 モーションマッチング

Motion Matching を利用したABPの超基本構造 ステートマシンの場合 Motion Matching 中身は複雑でも、ABP上では 「ポーズ出力ノード」の一種 Pose History 必須要件の「ポーズ履歴」を記録！ Output Pose直前にするのがコツ モーションマッチング ここでデータベースを指定 軌道はどこで作る？

軌道の生成と指定… 専用ノード があります 詳細は60分チュートリアルや、 公式サンプルのABPにある「GenerateTrajectory」関数の実装を参照

ステートマシン時代がそうであったように、 Motion Matchingの出力ポーズに、追加のノードを接続できます （モンタージュやIKなど） ただし、Pose Historyノードの位置は原則Output Pose直前こ Motion MatchingノードとPose Historyではさむ感じ 最終的に取ったポーズと近いものを 探してこそのモーションマッチングじゃからのう

モーションマッチング組み込みまでの ３ステップ クリップの準備 データベースの 構築 ABPへの 組み込み

結果 GIF

ポイント

DB （データベース） 今回の手順解説において、 まずアニメーションシーケンスをデータベースに突っ込んだわけですが…

DB （データベース） コマをバラバラにしたけど、 一応元アセットごとに横に並べているの図 DBに投入されたアニメーションシーケンスという一連のパラパラ漫画は、 （デフォルトでは）ほぼ一枚ずつに分解され、要素を解析され、”スクラップ”される この一枚一枚を「ポーズ」といいます

マッチする子は いねえがあ～ モーションマッチングの「ポーズ検索」では、 軌道や過去のポーズとの類似性を踏まえて、 “スクラップ”から、ベストマッチするポーズを探す この検索は、理想的には毎フレーム行われる 軌道

① 見つけた！ 採用！ ② できればこの先は（軌道が変わらないなら） そのまま再生してほしい... こうして動きの繋ぎポイント（①）を見つけても 次の検索フレームで②を再生するとは限らない。 そこで続きのフレームがコスト入札合戦で優位になるように バイアス値が設定される （通常、続きのフレームはそのままでもマッチする可能性が高いため、僅か なバイアスでかなり優位になる） ループアニメーションに属するポーズを バイアスする設定もある バイアスは 劣後させるのにも使われるのじゃ

ポーズ検索データベース編集画面では、 クリップから解析された軌道や足骨の位置を 視覚的に確認できる この解析内容や重みづけはスキーマの チャンネルで定義されている 「軌道チャンネル」 デフォルト 0.4秒前～0.7秒後まで4点の位置や速度を追跡 デフォルト 「ポーズチャンネル」 foot_lとfoot_rの位置と速度を追跡 このデフォルトで 十分ロコモーションに 対応可能なのじゃが…

デフォルトのスキーマ設定では、 振り向きランと、横走りの区別がつかない このような場合に Heading Channelを追加して向きの追跡を 強化したりする 他に足の交差に強い クラッシュレッグチャンネルなど、 さまざまなチャンネルが存在。 チャンネルは自作することも可能

ところで

さっきの結果はこうだったが GIF

ストレーフィングが入るとこうである たとえば、 斜め15°前方に進む場合に、真正面に進むクリップ が最も近しいモーションとして適用されたりする モーションマッチングではブレンドスペースと同じ ことはできないため、結果として・・・ GIF 足滑り警察だ！お前は滑っている！

足滑り警察に捕まらないための アニメーションワーピング の 組み込み

■UE用語 「アニメーションワーピング」 ランタイムでアニメーションを微加工して 別の動きにする機能の総称

ワーピング 三銃士を連れてきたよ！ ブレンドスペース的な処理をしないMMでは欠かせない機能！ Orientation Warping Stride Warping Steering 足運びの向きを変える 別名Strafing Warping モーションの歩幅を変える 実験機能 GIF Epic内製タイトル GIF 公式サンプル 60分チュートリアル で採用 60分チュートリアル で採用 公式サンプル で実験中！

詳しくは・・・ https://www.docswell.com/s/EpicGamesJapan/ZY3PDK-UE_CEDECKYUSHU2022_UE5Animation

• https://www.docswell.com/s/EpicGamesJapan/ZY3PDK-UE_CEDECKYUSHU2022_UE5Animation

各種ワーピングの組み込み方 ワーピングはMotion Matchingノードの出力と相性がよくない ※MMノードの出口に繋げるのは、 あまりよくないとされている ブレンドスタックで選択されている各クリップのブレンド前に適用したい これを行うには、Motion Machingノードをダブルクリック して、「ブレンドスタックグラフ」を開きます

ブレンドスタックグラフでの組み込み 詳しくは公式サンプルの ブレンドスタックグラフを参照

ワーピングの適用度調整 ワーピングは 適用したくないときもある （例：Orientはモーションの動きが直線的 じゃないと美しく処理できない） 公式サンプルでは カーブトラックでON/OFFを制御

ワーピング組み込み結果 GIF GIF

モンタージュ と モーションマッチング

モンタージュ（≒単発再生のクリップ）は 「モーションマッチングの 外側」にある問題 モンタージュはMMの恩恵を受けられない？ 実は、モーションマッチングにモンタージュを照会することで 繋がりやすい再生開始フレームを示唆してもらうことはできる

例えば・・・ 「アイドルからの走り攻撃」アニメーションを 歩きながら再生すると？ モーションマッチングとの照会なし GIF 左は一瞬アイドルが挟まるが 右は一応繋がっとるのお～ モーションマッチングとの照会あり GIF 動画で見ると「間違い探し」レベルの違いだが、 実際にプレイすると、左の手触りは許されない

モーションマッチングとの照会なし モーションマッチングとの照会あり ■左足が前のとき、攻撃開始すると… 普通に再生を実行すると、足配置が「右前／左後」に クロスフェードしてしまう。そのため、足も滑るし、 動きも一瞬止まる 照会すると、動きが繋がるフレームまで出だしをカッ トする！ ズレは最小で済み、動きも止まらない！ ▲モンタージュの1フレ目 もう繋ぎモーション作らんで いいんかのう～？

③照会に成功すると有 効なAnimMontageが 得られるので… 組み込み方法 ②候補のモンタージュ を送る ①PoseHistoryノード にタグを打っておき、 ここに書く ④示唆された開始時間と 再生速度をPlay Montageに送る 公式サンプルのCBP_SandboxCharacterクラスにある 「Try Traversal Action」（の下の方）を参照

Montage側の調整 モーションマッチによる 再生開始位置調整を受け 入れる範囲をマーク

Montage側の調整 Pose Search: Motion Matched Branch In DB格納外であるモンタージュなどでは、「遷移入りを許す範囲」を このAnim Notify Stateでマーキングし、DBを指定する 要は出だしの一定区間を 指定すればよいんじゃな

おまけ 追加テクニック 「早期ブレンドアウト」 GIF 条件に応じて、モンタージュの再生を キャンセルすることで、不要な硬直時 間をなくすテクニック （結果として、モーションマッチングに早く制御を返せ る） GIF 短い

公式サンプルが独自にBPで作成したAnim Notify Stateで実現される。 詳しくは、おかずさん（@pafuhana1213）のブログをチェック！ GIF https://pafuhana1213.hatenablog.com/entry/2024/08/12/144524

• https://pafuhana1213.hatenablog.com/entry/2024/08/12/144524

閑話休題 なぜ、足は 滑るのか？

多くのゲームでは、キャラクターのアタリをカプセルで単純化しており、 ゲームプログラムでカプセルの向きと座標を更新する設計を採用している キャラクターはカプセルの中に親子付けされた、見せかけのものであり、 ホログラムのパントマイマーをカプセル内に浮かべている状態に等しい

✖キャラが手足を動かすから、カプセルが動く 〇カプセルの動きにあわせて、キャラが手足をバタつかせる GIF この後付けの演技が、カプセルの運動と矛盾したと き、安っぽさが生じる

「プログラム主導」の実装においては、 中の人の演技でカバーできないほど、カプセル側の運動が非現実的なものになると どのような技法を採用しても、動きの繋がりの破綻を避けることは難しい GIF

自然な演技で足を絶対に繋げる既知の方 法 前RUN モーション主導の座標更 アニメーションに記録された運動（ルート 新 START モーション, RM）だけでキャラクターを 動かせば、カットシーンと同等の精密さが 得られ、足も滑られない。 前RUN LOOP この「モーション主導」のやり方では、 ゲームプレイコード側でカプセルの向き、 座標を一切動かさない。 前RUN LOOP 前→左 PIVOT 左横走り LOOP 左横走り STOP 極論、移動命令を出す代わりに、 「クリップ再生命令」を並べる感じじゃな

自然な演技で足を絶対に繋げる既知の方 法 前RUN 部分的なRMの採用 START キャラクターの運動ステートによって、プロ グラム主導とモーション主導を切り替え ・移動開始、その場ターン、ピボットター ン、停止などはモーション主導（RMを使用） ・最高速度に達したら、プログラム主導に切 り替える 前→左 PIVOT 左横走り STOP

自然な演技で足を絶対に繋げる既知の方 法 前RUN RMの弱点の克服 START アニメーション主導の決め打ち動作の柔軟性 の欠落は、移動／回転量を取得したうえで、 ・速度を微調整 ・回転運動をプログラムの希望にホーミング 走り 左横 OP ST することで緩和できる 前→左 PIVOT 現在「プログラム主導」のモードを維持しつつ、 上述の実装とほぼ同じ結果を半自動で得られる 「ルートオフセット」という機能を実験開発中

Experimental ルートモーションオフセッ ト 前→左 「カプセル主導」のプログラムで加減速・回転しつつ 「アニメーション主導の」演技を取り込む機能 PIVOT 先述のピンポイントRM切り替えとほぼ同じ結果を半自 動で得られる 前→左 PIVOT GIF

ルートモーションオフセット機能 ・カプセル側はゲームチックにき びきびと回転、移動 ・メッシュ側は100%追従せず、 ・ルートモーションで回転、移動 を実施する GIF

しかしこの機能はまだ万能ではない... 蟹歩き中、足をクロスしたところで動き を止めてみた。 本来なら、軸足（右）を固定して、左足 を半歩繰り出して、立ちポーズに戻りた いところだが… 滑っとるの～ GIF

止まったでえ～ え、もう半歩 左に行ってよ！ MMは完全「カプセル主導」であり、モーション側に カプセルを追加動作させる権限がない。 このシチュエーションでは、足が滑ってしまう。 今は通信プレイもあるし、カプセルがある座標で 静止したら、それがすべてじゃ。難しいのう～ GIF

アニメーションと操作性の両立に関するお勧めの資 料 https://www.slideshare.net/slideshow/game-creators-conference-2019-keiji-kikuchi/139200610#1

• https://www.slideshare.net/slideshow/game-creators-conference-2019-keiji-kikuchi/139200610#1

チューザー(Chooser)による データベースの切り替え

その動き、 混ぜるな危険 Q.しゃがみ歩きと立ち走りを一緒のデータベースに突っ込むとどうなりますか？ GIF A. 加速するまでに「しゃがみ歩き」と マッチングが起きてしまい、一瞬姿勢が凹みます 腰骨位置追跡の重みを高めれば... とかいうレベルじゃなさそうじゃのう

モーションマッチングにおける アセットフィルタリング問題 関連性のないクリップを大量にデータベースに登録すると 「い、意外な動きが見つかった・・・クリエイティブだぜえ」となるより、 単に視覚的エラーの種になることの方が多い Epic Gamesでは、 データベースを用途によって分けるする方法を採用・推奨 でも、どうやってDBの切り替えを行えば？

ステートマシン、再びですかぁ？ ３つのノー 生産性 パフォーマンス 品質 ・遷移ワイヤーの管理 ・MMノードごとのブレン ドスタックグラフ再構築 ・遷移中、MMが2つ動作 ・ハイ/ローエンド版でス テート構成を変えづらい MMノード同時稼働を避け るためのブレンド技法を 使うと、品質ダウン

解決策： アニムグラフの構成は保ち、 MMノードの更新時にロジックを実行して、 動的に参照データベースを切り替える そして・・・ 適切な参照データベースの決定には、 新機能の「チューザー」が便利です

Choosersとは… たくさんの横並びの候補から… たった一つを選び出す仕組み

Choosersの考え方 条件を列に・・・ スピード 選 択 肢 を 行 に ・ ・ ・ 検索！ 動き出しか 加速中か 走りのDB 450～ 650 いいえ はい 歩きのDB 0.001～ 450 いいえ はい 停止のDB 0～ 650 いいえ いいえ 動き出しのDB 0～ 650 はい いいえ 停止のDB ←上記いずれでもなかった場合（フォールバック） 検索機能付きデータテーブルみたいな？ 表の記述から検索までがChoosers!

Choosersの 特徴 条件を指定したクラスや構造体の メンバ変数に直接バインドできる スピード 動き出しか 加速中か 走りのDB 450～ 650 いいえ はい 歩きのDB 0.001～ 450 いいえ はい 停止のDB 0～ 650 いいえ いいえ 動き出しのDB 0～ 650 はい いいえ 停止のDB ←上記いずれでもなかった場合（フォールバック） 出力はオブジェクトタイプであれば なんでもよい

Choosersの利点 バリエーション パラメータ次第の選択肢を データ表に記述するだけで保守できる テック寄りアニメーターなら保守可能！ 選択肢に付随する条件は、 ABPの変数などに自動バインドできる 選択肢の種類（チューザーの出力）は、 オブジェクト型なら何でもよい

Chooser用のテーブルを作ろう！ + Add コンテンツブラウザから、+Add > Misc > Chooser Tableで、 Chooser用のテーブルアセットを追加 Table Settingsで… Chooserの条件に値 を提供するクラスや 構造体を選択 出力オブジェクト型 =この表で扱う選択 肢の型を指定

テーブルの編集 条件を追加するにはここを 選 択 肢 を 追 加 す る に は こ こ を 条件列にコンテキストで指定した クラスや構造体のメンバー変数を 直接バインド可 また、詳細において、全条件に当てはま らなかったときに選出される 「フォールバック」を設定できます

Evaluate Choosersは「Evaluate」することで、選択肢から一つ （モードによっては複数）の結果を返します 詳細は「60分チュートリアル」や「公式サンプル」の MMノード > On Update関数グラフを参照！

DB切り替え時のポーズ遷移について ■切り替えてもスムーズ デフォルトでは、切り替え後のDBでもっともマッチするポーズが見つかるまで 現在再生中のポーズを維持する 参考 ・この挙動は、 「Interrupt Mode」で切り替え可

ポーズ検索正規化セット 2つのDBにまたがってポーズの入札が行われる際の DB設定の違いによる、ポーズのコスト評価の偏りを防ぐ ■つまり…？ ポーズ検索正規化セットを作って、 相互切り替えが生じるデータベースを全部登録すればOK!

さて、、、

モーションマッチングの魅 力 伝わりましたでしょうか

それでは

現実篇

現実篇① モーションマッチングを 制御する

ステートマシン／ブレンドベースの欠点は、 一つ一つは100%意図通りに手動で緻密に動かせるが、 全体管理が破綻していくということだった 一方、 モーションマッチングを使い始めると、 機械が意外なマッチングを選択したうえで、 結果もダメという悩みに直面することになる

GIF 「混ぜたくないクリップがブレンドされる」問題と、 「ベストマッチングが行われない」問題は区別したい 問題の切り分けポイント: 意図しないモーションがブレンドされているのか？ DBのメンツは良いが、メンツ内のマッチングがイマイチ? クリップの選定はよいが、ブレンドが雑なのか？

意図しないモーションがブレンドされてキモイ結果に！ 対策 →データベース（DB)の分割 この順番で 見直そう！ DBのメンツは良いが、メンツ内のマッチングがイマイチ →スキーマの見直し 対策 →データベース単位のバイアス設定 →クリップ単位のバイアス（奥の手....ほどほどに） クリップの選定はよいが、ブレンドが雑 →専用Anim Notify Stateによる区間調整 対策 →ワーピングのON/OFF制御

意図しないモーションがブレンドされてキモイ結果に！ 対策 →データベース（DB)の分割 この順番で 見直そう！ DBのメンツは良いが、メンツ内のマッチングがイマイチ →スキーマの見直し 対策 →データベース単位のバイアス設定 →クリップ単位のバイアス（奥の手....ほどほどに） マッチングはうまくいったが、ブレンドが雑 →専用Anim Notify Stateによる区間調整 対策 →ワーピングのON/OFF制御

データベースの分割の現実的提案 参考 Epic内製タイトル 公式サンプル 運動スタイルと運動ステートの概念でクリップを整理し、 それぞれにデータベースを作成 運動スタイル しゃがみ 運 動 ス テ ｜ ト 歩き 走り ダッシュ Idle 〇 〇 Start 〇 〇 〇 〇 Loop 〇 〇 〇 〇 Pivot 〇 〇 〇 〇 Stops 〇 〇 〇 〇

意図しないモーションがブレンドされてキモイ結果に！ 対策 →データベース（DB)の分割 DBのメンツは良いが、メンツ内のマッチングがイマイチ →スキーマの見直し 対策 →データベース単位のバイアス設定 →クリップ単位のバイアス（奥の手....ほどほどに） マッチングはうまくいったが、ブレンドが雑 →専用Anim Notify Stateによる区間調整 対策 →ワーピングのON/OFF制御

スキーマのカスタマイズの一案 振り向き走りとストレーフィングが同じDBに格納されている場合 →Heading Channelを追加 足交差のあるDB（歩き、走り） →Crash Leg Channelを追加 非常に高速な移動スタイル（ダッシュ・スプリント） →Velocity Channelを追加 軌跡をより長く追いかける →キャラクターの移動スタイル（歩き、走り、ダッシュなど）に応じて スキーマを分け、移動速度に応じて、履歴時間の幅を変更 速い＝過去・将来ともに若干長め、遅い＝過去・将来ともに若干短め

データベース単位のバイアス設定 継続ポーズコストバイアス ・同じ演技をなるべく続けたい場合→下げる ・場繋ぎモーションが多く、良い演技にどんどん飛 び移りたい場合→下げない ループ所属ポーズコストバイアス ・ループ演技がたくさんあり、安定再生したい→下げる ・今のループから早抜けして、 積極的に場繋ぎモーションに移したい→上げる つまり・・・？

例: StartとStopは、 一旦その演技に入ったら次のループまで続けてほしい ● ● Idle Start Loop Pivot Stop Continuing Pose 標準的 下げる 標準的 標準的 下げる Loop 標準的 ゼロ 標準的 標準的 標準的 Continuing Poseバイアス→デフォルトより下げる（-0.03とか） ループバイアス→デフォルトより上げる（ゼロとか） 奥の手としてPose Cost Bias系のAnim Notify Stateで クリップ単位、区間単位で追加バイアスも可能じゃが 沼なのでお勧め出来ないのじゃ

意図しないモーションがブレンドされてキモイ結果に！ 対策 →データベース（DB)の分割 DBのメンツは良いが、メンツ内のマッチングがイマイチ →スキーマの見直し 対策 →データベース単位のバイアス設定 →クリップ単位のバイアス（奥の手....ほどほどに） マッチングはうまくいったが、ブレンドが雑 →専用Anim Notify Stateによる区間調整 対策 →ワーピングのON/OFF制御

Anim Notify State による区間調整 参考 Epic内製タイトル 公式サンプル 特にStopモーションで活用！ Pose Search Block Transition … MMはこの区間のポーズを入札に参加させない つまり、この区間からアニメーションの再生は開始されない マッチ除去区間 遷移入り（ジャンプイン）ブロック区間 ←必然的にループからの遷移の編集点はこの幅のどこかになる Pose Search Exclude From Database … MM上、この区間のポーズは「ない」ことになる 元データをトリミングしているのと同等の効果得られる

Orientation Warping のON/OFF制御 動きがおかしくなる原因はMMではなくWarpingの場合もある デバッグで確認し、ON/OFFの制御を追加しよう しゃがみ 歩き 走り ダッシュ Idle OFF OFF Start ON ON ON OFF Loop ON ON ON ON Pivot OFF OFF OFF OFF Stops OFF OFF OFF OFF Orientation Warpingを利用すべきDB ただし、ストレーフ（横走り）ありのゲームを想定 Orientation Warping利用可 ただし Future Velocityは利用非推奨 長回しでないなら、 クリップにON/OFFカーブ付けるより DBにタグ付けた方が手っ取り早い

おまけ：「_START」系がうまくいかない？ 「動き出し」の動作の後に、ループを数回含めてやや長回しにするとよい このへんのどこかで ループ用クリップにマッチングできる 従来の動き出し ループ すでに最短時間でクリップを作成済みの場合は、 Anim Compositeで合成しちゃうとよいぞよ ループ

現実篇② モーションマッチングの 縦マルチ対策

モーションマッチングはローエンドと相性が悪い モーションマッチの要求 ローエンド機の泣き所 大量のDBのメモリ常駐 少ないメモリ搭載量 高負荷のポーズ検索(※) 低いCPU処理能力 ※DBに含まれるポーズ量に比例して負荷が高まる 対策 ・DBへの登録クリップ数削減（e.g.ハイエンド16方向→ローエンド8方向） ・リッチ演技DBをローエンド版から削除（e.g. アークスタート） ・MMを優先度の高い演技に集中させ、それ以外は旧機能でカバー （正面ダッシュはステート／ブレンドで切り替えるなど）

公式サンプルでのデータベースLODの変更 みっちり 0=Dence版（ハイエンドAAA想定） ほどよい データベースLODの変更 1=Sparse版（それ以外） (0=高密度、1=低性能機向け低密度） を切り替えることが可能

LOD変更の実装内容 軽！ 手 お 「『DB切り替え用チューザー』を出力するチューザー」で Dence版DBセットとSparse版DBセットを切り替えているだけ

参考 公式サンプルでは、Dense版とSparse版で同数のDBセットを用意し、 一部のDBを低密度（登録モーション数が少ない）版に差し替えている ■Dense版 ■Sparse版 23DB 23DB うち8DBを低密度版に差し替え Run Loop 16モーション Run Loop 14モーション Run Pivot 132モーション Run Pivots 42モーション

参考 内製プロジェクトでは、ハイエンド版とローエンド版でDB数を変え、 全DBの中身も低密度版としている ■ハイエンド版 ■ローエンド版 33DB 16DB

現実篇③ 品質担保のための 「最小」アニメーション数の考察

注意点：公式サンプルのSparse版は結構攻めてる ● 弊社内製タイトルの 「ローエンド」版DBを凌駕するデータ量 ● 一部DBは弊社内製タイトルの ハイエンド版DB相当のデータ量を持つ ● Sparse版と同じレベルのことをやれば品 質は十分と思われる ● 逆にいえば「最小」ではない 公式サンプルは足交差をケアしているため データ数が倍増するケがあるのじゃ

スタートラインのモーション数の案 運動スタイル ストレーフィングあり しゃがみ 運 動 ス テ ｜ ト 歩き 走り なし ダッシュ Start 4方向(※) 4方向 4方向 正面3方向 Loop 8方向(※) 8方向 8方向 - Pivot 4方向✖LR 4方向 4方向 - Stops 4方向✖LR 4方向 4方向 1 遅い動きは、左右をケアしないといけない ※足が繋がらない移動方向があれば、LR対応を追加 振り向き走りがある場合、 45°ずつ徐々に拡張 最終的には8方向分を目指す

まとめ

まとめ ● モーションマッチングは『フォートナイト チャプター 5』において、全機種対 応で導入された実績のある新機能です ● ブレンド前提のクリップ編集、ステートマシンのマイクロマネジメントといっ た負荷が緩和されます ● 「Your First 60 Minutes With Motion Matching」と「Game Animation Sample」で学習を進めることができます ● プログラムで動かすキャラクターの運動性能と、作成したモーションの運動が 近しいときに最大の効果を発揮します ● ● プログラム駆動の動きとアニメーションの動きの乖離を埋める技術も開発中 足の滑りを完全に解消することはまだできていません

ご清聴 ありがとうございました Special Thanks 岡田 和也さま