カーブエディターを使った道の制作フロー

カーブエディターを使った 道の制作フロー カーブエディターを使った道の制作フローについての発表をはじめます。 この発表では、オープンフィールドゲームにおける道の制作に焦点を当てて、RE ENGINEで開発したカーブ編集ツールと それを用いた制作フローについて紹介をします。 ©CAPCOM 1

道の表現方法 まず最初に、対象となる道の特徴と要件について整理します。 2 ©CAPCOM 2

道の特徴と機能 ・全体が連結 わだち 起伏が多い 分岐と合流 ・NPCの誘導 ・マップ表示 描画方法 道形状のメッシュ 太さが均一でない ＋ 地形ハイトマップ この発表では、主に舗装されてない自然地形の道について扱います。 自然地形の道は、都市の道と比べると起伏が多く、太さも均一でないためシンプルな形状で表現しにくいという特徴があります。 3 そして、車輪が通るような道にはわだちがよく見られますが、これも道のカーブに沿って曲がらないと不自然に見えてしまいます。 これらを踏まえて、道の描画はベースとなる地形ハイトマップの上に、道の形状をしたメッシュを被せて表現するという方針を取り ました。 また、データ的な側面について言うと、道には分岐したり合流したりする箇所がたくさんあります。 そして、フィールド上の道はほとんど全て繋がっているため、エリアごとにデータを分割するといった管理形態を取りにくいという 点も挙げられます。 他にも、NPCが道に沿って歩くように誘導したり、マップ画面に道を表示する機能も必要になる可能性があります。 ©CAPCOM 3

道アセットのデータ構造 3次ベジェ曲線を接続したグラフ構造 頂点（ポイント） ・道幅 ・向き ・フォールオフ 辺（セグメント） ・カーブの強さ ・メッシュ種類 ・タグ情報 これらを扱うための、エンジンにおける道アセットのデータをこのように定義しました。 道アセットは全体を一つのグラフ構造で管理します。 それぞれのポイントが道幅や向きなどの情報を持ち、セグメントが3次のベジェ曲線を表現します。 道の種類など追加で使用するデータは、セグメントにタグ情報として持たせています。 ©CAPCOM 4 4

道アセットのデータ構造 異なる作業者間のアセット差分はIdを使ってマージ "PointsData":[ { "Id":"2f89cb70", "Width":10.0, ... }, { "Id":"f6db770c", "Width":10.0, ... }], "SegmentsData":[ { "Id":"38ade50e", "StartPointId":"2f89cb70", "EndPointId":"f6db770c", ... }] 具体的なアセットの中身は、このような構造になっています。 全てのポイントとセグメントが一意なIdを持っていて、セグメントがポイントをIdで参照します。 複数の人が同時に道アセットを編集してコミットした時は、Idを使ってアセットがマージされます。 したがって、全く同じ場所を編集しない限りは競合が起きない仕組みになっています。 ©CAPCOM 5 5

道の編集ツール 続いて道の編集ツールについて説明をします。 6 ©CAPCOM 6

SplineEditor ランタイム上で 道データの配置と編集 SplineEditorはランタイム上で道データを編集するためのエンジン機能です。 エディターの基本機能をいくつか紹介します。 7 ©CAPCOM 7

SplineEditor の基本操作 道の追加 移動と回転 道幅の操作 ベジェ操作 まず、道を追加するにはフィールド上にポイントを配置して、セグメントを引いていきます。 接続時には、向きの自動補正を行うことで、滑らかに繋がるようにしています。 8 ©CAPCOM 8

SplineEditor の基本操作 道の追加 移動と回転 道幅の操作 ベジェ操作 配置したポイントは、マニピュレータで動かしたり回転することができます 9 ©CAPCOM 9

SplineEditor の基本操作 道の追加 移動と回転 道幅の操作 ベジェ操作 道幅の編集はポイントの持つハンドルを動かして操作します。 このとき２点選んで間のポイントを選択し、まとめて道幅を調整するといった使い方ができます。 10 ©CAPCOM 10

SplineEditor の基本操作 道の追加 移動と回転 道幅の操作 ベジェ操作 カーブの緩やかさを調整するには、ベジェハンドルを操作して制御点までの長さを動かします。 このとき、ショートカットキーで対称操作に切り替わります。 11 ©CAPCOM 11

SplineMesh コンポーネント メッシュを変形 カーブに配置して描画 次に、SplineMeshコンポーネントについて説明をします。 これは、セグメントに割り当てたメッシュをカーブ上に配置して描画する機能です。 SplineMeshで作ることのできる配置について、いくつか説明をします。 ©CAPCOM 12 12

SplineMesh の配置プロパティ メッシュの種類ごとに出現比率を設定 普通の柵 比率：100 壊れた柵 比率：15 1つのセグメントに対して複数のメッシュを割り当てると、それらがランダムな順番で配置されます。 このとき、メッシュごとに異なる出現比率を設定することで、たまに壊れた柵が出てくるような配置を作ることができます。 13 ©CAPCOM 13

SplineMesh の変形タイプ 変形あり カーブに沿って頂点を曲げて配置 見た目の破綻 なし 計算コスト 高 有効な配置：道、川、洞窟 など 変形なし カーブ上にアフィン変換で配置 見た目の破綻 あり 計算コスト 低 有効な配置：柵、電柱、敷石 など また、SplineMeshでは変形のオンオフを切り替えることができます。 変形を有効にすると、カーブに沿ってメッシュが頂点ごとに曲げられます。 変形を無効にすると、メッシュの頂点は動かさずにアフィン変換のみでカーブ上に配置されます。 道を配置する時は、インスタンスの頂点同士がぴったり重ならないと見た目が破綻してしまいます。 そのため、基本的には常に変形ありで曲げていくことになります。 14 一方で、道の脇に置く柵や電柱、敷石などのメッシュは必ずしもぴったり重なる必要がありません。 このようなメッシュは、変形をオフにすることで軽量な配置方法に置き換えることが可能です。 ©CAPCOM 14

道のデータ変換 ここまでで、道の編集方法とツールの機能について紹介をしました。 ここからは、編集した道アセットを描画に最適な形式へ変換するための、エンジンの提供するベイク機能について説明をします。 15 ©CAPCOM 15

道の描画表現 道幅 フォールオフ カーブに沿ったメッシュ ＋ 掘り下げ 地形ハイトマップ 最初の方に、道の描画はハイトマップとメッシュを組み合わせて表現すると説明をしました。 このとき、道と地面の境界部分が目立たないように、道のカーブ情報をハイトマップに焼き付ける処理が必要になります。 16 ©CAPCOM 16

ハイトマップへのベイク カーブからの距離に応じてブレンド 道幅 フォールオフ 道幅 掘り下げ幅 掘り下げ 掘り下げ Pow ブレンド フォールオフ Cos ブレンド これは、道メッシュの上に地面が突き抜けてこないように、地面を少し掘り下げる処理と、道から離れるにつれて地面の高さに馴染 むようにブレンドする処理に分かれます。 17 内側の掘り下げる部分では、メッシュの種類ごとに掘り下げる幅の広さや、なだらかさを調整できるように、pow関数でブレンドす ることにしました。 外側は地面の高さまで滑らかに遷移させたいので、cos関数でブレンドをしています。 ©CAPCOM 17

ハイトマップへのベイク カーブからの距離に応じてブレンド カーブからの距離計算 道幅 𝒑 掘り下げ幅 d𝒄 𝑡 d𝑡 𝒑−𝒄 𝑡 𝒄 𝑡 各ピクセルからカーブ上の最近接点を ニュートン法で計算 掘り下げ Pow ブレンド フォールオフ Cos ブレンド 𝒑−𝒄 𝑡 ∙ d𝒄 𝑡 =𝟎 d𝑡 ブレンド処理は道の中心からの距離を使って計算します。 距離の計算はハイトマップの各ピクセルについて、カーブ上の最近接点を求める方程式を、ニュートン法を使って解くことで求めて 18 います。 ©CAPCOM 18

SplineMesh をゲームに持ち込める？ 動的変形のパフォーマンスへの影響 処理コスト メモリ 描画メッシュ 変形処理 VRAM消費 元メッシュのみ 物理メッシュ 変形処理 物理メッシュ BVH構築処理 道情報 読み込み制御 続いてSplineMeshの変換ですが、その前にSplineMeshをそのままゲームに持ち込むとどうなるかについて説明します。 まず、メッシュをカーブに沿って曲げる処理のコストがそのままゲームに乗ることになります。 19 一方で、描画時に動的変形することで、VRAMの消費が元のメッシュの分だけで済むため、この点についてはメリットがあると言え ます。 しかし、物理用のメッシュについてはこのメリットが消える上に、通常は事前に行われる、BVH構築の処理コストも追加でかかって きます。 また、ゲーム内で道全体の描画範囲をうまく調整しながら読み込み制御を行うというのも、やはり簡単ではありません。 ©CAPCOM 19

SplineMesh をゲームに持ち込める？ 動的変形のパフォーマンスへの影響 処理コスト メモリ 描画メッシュ 変形処理 VRAM消費 元メッシュのみ 物理メッシュ 変形処理 SplineMeshの使用は開発時のみ 物理メッシュ BVH構築処理 配置した結果を事前ベイク 道情報 読み込み制御 全体として見ると、SplineMeshを直接ゲームへ持ち込むには課題が多いため、今回は配置した結果を使って、事前にベイクするもの としました。 20 ©CAPCOM 20

SplineMesh をゲームに持ち込める？ 動的変形のパフォーマンスへの影響 処理コスト メモリ 描画メッシュ 変形処理 VRAM消費 元メッシュのみ 物理メッシュ 変形処理 SplineMeshの使用は開発時のみ 物理メッシュ BVH構築処理 ベイク方法 A) メッシュ出力 B) プレハブ配置 C) ジョイント変換 配置した結果を事前ベイク 道情報 読み込み制御 エンジンでは、ベイクするために次の３通りの方法を提供しています。 それぞれについて説明します。 21 ©CAPCOM 21

変換方法A．メッシュ出力 読み込む広さごとに固めてメッシュ出力 SplineMeshを正確に表現可能 インスタンス数に比例したVRAM消費 一つ目は、変形結果をFBXメッシュに出力する方法です。 ゲーム内でメッシュをロードする広さに合わせた区画を指定して、その範囲内にあるSplineMeshのインスタンスをメッシュに固めて 22 出力します。 曲げた形状をそのまま出力するので、見た目の劣化はありません。 しかし、全ての頂点が別々にメモリ確保されるため、インスタンス数に比例してVRAMの消費量も大きくなるという問題が挙げられ ます。 ©CAPCOM 22

変換方法A．メッシュ出力 メッシュの種類ごとに別々に出力 １つのメッシュに結合して出力 また、区画には複数の種類のメッシュが入っている可能性があります。 この場合、メッシュの種類ごとに別々のアセットとして出力する方法と、全てを1つのメッシュに結合して出力する方法が考えられ ます。 23 ©CAPCOM 23

変換方法A．メッシュ出力 メッシュの種類ごとに別々に出力 １つのメッシュに結合して出力 元のマテリアル接続を維持 マテリアル接続を束ねる 描画LODがバラバラに 同一LODで描画 変換処理が複雑 メッシュ間のLOD基準を 揃えておく必要あり 別々に出力した場合、元のメッシュとマテリアルの関係をそのまま維持できるので、運用しやすいというメリットがあります。 しかし、描画時にメッシュ同士で異なるLODが選択された時に、チグハグな見た目になってしまう可能性があります。 24 結合して出力した場合は、常に同じLODで表示されるため、この問題は起きません。 ただし、この方法はメッシュとマテリアルの紐付けを束ねる処理が必要になります。 これは変更検知や変換過程での事故につながりやすく、運用コストが高いです。 また、メッシュごとに作るLODの基準も、事前に揃えておく必要があります。 ©CAPCOM 24

変換方法B．プレハブ配置 元メッシュのトランスフォームに置き換える（変形なし限定） インスタンシング描画されるため軽量 SplineMesh プレハブ配置 続いて、プレハブを使用した変換方法について。 これは変形が無効、つまり曲げないで配置しているとき限定のオプションで、各インスタンスの配置情報を取得する機能を用意して 25 います。 これを使ってSplineMeshをプレハブの配置に置き換えることで、インスタンシング描画を利用できるようになります。 ©CAPCOM 25

変換方法C．ジョイント変換 メッシュのジョイント変形でSplineMesh形状を近似 元メッシュ形状を使うことでVRAMを節約 描画コストと近似精度のトレードオフ 最後にジョイント変換についてです。 これはメッシュを曲げながら配置しているものの、VRAMの使用量がネックになっていて、FBXメッシュへのベイクを許容できない 26 というケースを想定しています。 この場合の回避策として、SplineMeshの変形情報をジョイントにベイクすることで、メッシュのスキニング描画に置き換えるという 手段を提供しています。 この方法は、スキニングを使う分ランタイムでの描画コストは増えますが、インスタンスごとにVRAMを消費しなくて済むというメ リットがあります。 ただしジョイントでの変形はあくまで近似計算になるため、ジョイントの割り方やカーブの曲がり具合によっては見た目が破綻する 可能性もあります。 ©CAPCOM 26

データ変換フローまとめ ハイトマップ ハイトマップ ベイク ベイク 変形 あり 背景アーティスト SplineMesh 道を編集 Yes No VRAM 優先 Yes プレハブ配置 No パッケージ メッシュ出力 ジョイント変換 WayPoint ベイク ここまでが、現在エンジンでサポートしている、道データの変換処理についての説明でした。 以上の内容をデータ変換フローの一例としてまとめます。 アーティストが道を編集したとき、まずハイトマップをベイクします。 SplineMeshは、変形して無ければプレハブ配置に置き換えます。 変形している場合、VRAM優先でないならメッシュに出力し、VRAM優先ならジョイントに変換します。 また、NPCを誘導するためのWayPointアセットもマクロを使ってベイクします。 ©CAPCOM 27 27

アセット管理の課題 扱う道アセットが大規模に ポイント数：約18,000 セグメント数：約19,000 道全体の走査処理が重い • アセット読み込み、保存 • フラスタムカリング • ベイク処理 など ツールを快適に使うには１アセットでの管理は限界 アセットの分割管理 最後に今後の課題を説明します。 実際に開発したゲームで作られた道アセットの規模は、ポイント数が約18000、セグメント数が約19000と、事前の想定を上回るサ 28 イズになりました。 結果として、アセットの読み込みや描画時のフラスタムカリングなど、道全体を走査する処理が重く、ツールを快適に使うことが難 しい状況になってきました。 これ以上の規模を1アセットで管理していくのは限界があるため、今後は分割管理に移行していくことを考えています。 ©CAPCOM 28

ワークフローの課題 道の形状を変更 パッケージに反映するには 全世界の道の再ベイクが必要 高コストな変換フロー により ゲームの動作チェックに支障 また、ワークフローの観点でもまだ課題が残っています。 例として、SplineMeshで曲げている元のメッシュ形状に変更を加えたケースを想定します。 29 このとき、変更の影響は曲げられた全ての道形状に及ぶので、これをパッケージに反映するには、全世界の道メッシュをベイクし直 す必要があります。 これは場合によっては、ゲームの動作チェックをする際の障害にもなり得るため、ワークフローにおける課題であると考えています。 ©CAPCOM 29

ワークフローの解決策 単一の汎用表現 場所に合わせた表現 ツール 編集表現 ゲーム表現 SplineEditor SplineMesh Mesh SplineMesh Mesh SplineEditor デカール モジュラー配置 今回は、汎用性の高いSplineMeshのみを使った運用だったので、この問題を避けることができませんでした。 今後はデカールやモジュラー配置など、変換を必要としない表現も含めて、場所に合わせた手段を選べるようなワークフローを模索 30 したいと考えています。 ©CAPCOM 30

以上で発表を終了します。 ありがとうございました。 31 ©CAPCOM 31