【メモあり】ダイナミックな変更を可能にするCyllista Game Engineのオープンワールド向けプロシージャル背景制作ツールと描画機能

2021/11/14 Cygames Tech Conference

Transcript

2. 皆様こんにちは。本日は「ダイナミックな変更を可能にする Cyllista Game Engine のオー プンワールド向けプロシージャル背景制作ツールと描画機能」と題しまして、発表させて いただきます。 株式会社Cygames、Cyllista Game Engine チームでグラフィックスエンジニアをしてお ります、林と申します。 本講演では Cyllista Game Engine の機能の中から、オープンワールド背景制作に関連する ツールと描画機能についてご紹介します。 それではまず、これからご説明する機能を用いて作成したシーンの動画をご覧ください。 1
3. 2/82 2
4. 本発表の内容 3/82 • Cyllista Game Engine の機能紹介 – オープンワールドに対応したゲームエンジンの事例として • テレイン関連のツールと描画機能 • フォリッジ関連のツールと描画機能 • アジェンダ 1. Cyllista Game Engine 2. オープンワールドゲーム制作における要求 3. テレインシステム 4. フォリッジシステム 本発表の内容は、Cyllista Game Engine の機能紹介です。 オープンワールドに対応したゲームエンジンの事例として、テレインおよびフォリッジ関 連のツールと描画機能について紹介します。 特に広大なワールドを持つゲームを制作している開発者の参考になる情報が少しでも提供 できれば幸いです。 アジェンダは、 1.Cyllista Game Engine について 2.オープンワールドゲーム制作における要求 3.テレインシステム 4.フォリッジシステム の4つになります。 なお、本セッションの内容はすべて開発中の機能についてであり、今後のエンジンやゲー ムの開発に合わせて変更、改善を行う可能性がありますのでご了承ください。 3
5. Cyllista Game Engine 4/82 まず、Cyllista Game Engine について、簡単に紹介します。 4
6. Cyllista Game Engine 5/82 • Cygames 内製で開発しているゲームエンジン – PC, ハイエンドコンソール向けに開発中 – Project Awakeningで利用 • エンジン目標 – 制作者が最大のパフォーマンスを発揮できる – ハードウェアが最大のパフォーマンスを発揮できる • 過去のCEDEC講演 – Cygamesにおける次世代ハイエンドコンソール向けゲームエンジンの開発 [TAG17] – Python による大規模ゲーム開発環境[OKI20] Cyllista Game Engine は、Cygames の内製ゲームエンジンです。 新規タイトルである Project Awakening の開発に使用しており、対象ハードはPCおよび今 世代のコンソールゲーム機です。 エンジンの大目標は2つあります。 1つめは、製作者が最大のパフォーマンスを発揮できる、こと 2つめはハードウェアが最大のパフォーマンスを発揮できる、ことです。 内製の強みを生かし、根本の部分から、我々の開発チームやゲームタイトルの仕様に最適 化したエンジンにする、ということです。 過去の講演資料とフォローアップ記事が Cygames Engineer Blog に掲載されていますの で、よろしければご覧ください。 また、本セッションで言及する参考資料については、公開予定の本資料の最後にリストし ます。 5
7. オープンワールドゲーム 制作における要求 6/82 それでは、機能の説明に入る前に、オープンワールドゲーム制作における要求について整 理します。 6
8. オープンワールドゲーム制作における要求 7/82 • 制作効率 – 広大なレベルをカバーするテレインの効率的な編集 • 昨今はタイトルにより 4km ~ 32km もの広さ – 一度に大量のフォリッジ配置 • レベルのほとんどの地域で植生が必要 – 高速イテレーション • レベル作成の試行錯誤 • リアルタイム反映 – 非破壊ワークフロー • 変更を要素ごとに元に戻すことができる • ある要素の更新が別の要素の自動更新を促す 昨今のオープンワールドゲームはレベルが非常に広いため、高い制作効率が求められます。 広大なレベルをカバーするテレインを、効率的に編集できる必要があります。 また、テレインの上に大量のフォリッジを効率よく配置する機能も求められます。 そして、ゲームプレイや景観を洗練していくために、高速な試行錯誤のイテレーションも 行える必要もあります。 また、非破壊ワークフローも求められています。 編集時に変更を要素ごとに素早く元に戻せたり、ある要素の更新によって、別の要素が自 動更新される、といったことが必要です。 最も単純な例としては、テレインの高さを下げたとき、その上に配置したフォリッジが浮 いたままにならず、テレインにフィットする、というような動作です。 7
9. オープンワールドゲーム制作における要求 8/82 • 描画効率 – 広大な地形を効率よく描画 • 近景/遠景ともに – 大量のフォリッジを効率よく描画 • 近景/遠景ともに • ゲーム中の高速な動的更新 – インゲームでのテレイン形状の変更 – インゲームでのフォリッジ配置や状態の変更 ツールの機能面だけでなく、最適化された描画処理も必要です。 広大な地形を、近景と遠景ともに効率よく描画する必要があります。 これはもちろん地形だけでなく、フォリッジについても同様です。 テレインであれば遠景の解像感、フォリッジであれば描画インスタンス数と、どれだけ遠 距離まで描画できるかで、ゲーム画面の品質が大きく変わります。 そして、ゲームの仕様によっては、ゲーム中の高速な動的更新が必要になる場合がありま す。 ゲーム中にテレインやフォリッジが変更できれば、ゲームデザインの幅が広がります。 例えゲーム中の変更をしないとしても、編集中にリアルタイム変更できれば制作効率の上 で非常に大きなメリットがあります。 8
10. Terrain System 9/82 ここからは、以上のような要求に答えるために制作した機能の、具体的な説明に入ります。 まずはテレインシステムです。 9
11. テレインシステム 10/82 1. データ構成 2. 基本編集ツール 3. テレインレイヤー 4. プロシージャルペイント 5. テレイン描画 テレインシステムについては、 1.データ構成 2.基本編集ツール 3.テレインレイヤー 4.プロシージャルペイント 5.テレイン描画 の順で説明します。 10
12. テレインシステム 11/82 1. データ構成 2. 基本編集ツール 3. テレインレイヤー 4. プロシージャルペイント 5. テレイン描画 まずはテレインのデータ構成を見てみましょう。 11
13. セクター分割 12/82 • 編集とストリーミングの単位 – セクター毎に地形等の情報を保持 • ハイトマップ • マテリアルIDマップ • フォリッジ密度マップ etc. – ストリーミング • カメラ中心 • 11x11の範囲 128m 128m テレインの編集とストリーミングの単位は、セクターと呼ぶ128メートル四方の領域です。 セクターごとに、地形等の情報を保持しています。 この情報は、ハイトマップ、マテリアルIDマップ、フォリッジ密度マップなどです。 そして、このセクターに対応するアーカイブが、カメラを中心にストリーミングされます。 開発の現時点で、ロードされるのは11x11セクターの範囲です。 12
14. セクター選択ツール 13/82 他ユーザーが 編集中 自分が編集中 • セクターを選択して編集を開始 – 編集用メモリ確保 – 編集状態マークを表示 • 他のユーザーの編集状態を表示 – ユーザー同士での競合を回避 • その他様々な機能 – 頻繁に編集するセクターのブックマーク – D&Dによるカメラ移動 – 3Dビュー上のグリッド切り替え – LOD情報のクックをトリガー(後述) テレイン編集の際は、レベルエディタのセクター選択ツールでセクターを選択し、編集を 開始します。 チェックマークの表示により他のユーザーのチェックアウト状態がわかるようになってい ます。 セクター選択ツールには、その他にも様々な機能があります。 例えば、 ・セクターのブックマーク機能 ・カメラアイコンをドラッグアンドドロップすることで、3Dビュー上でもカメラを移動す る機能 ・3Dビュー上のセクターグリッド表示の切替 などです。 テレインのLODデータの生成をトリガーすることもできます。テレインLODについては後 述します。 13
15. 14/82 ハイトマップ • 解像度 257x257 ( 0.5m / pixel ) • フォーマット – アセット: 32bit EXR – ランタイム: R16_UNORM ハイトマップ ハイトマップを用いたテレイン描画 セクターが持つデータをもう少し詳しく見てみましょう。 セクターごとのデータの中で、テレインの最も基礎となるデータはハイトマップです。 解像度は257x257で、ハイトマップのテクセル当たり0.5mの精度です。 テレインを描画するメッシュの頂点にテクセルが対応するため、256でなく257になってい ます。 値の精度は 32bit、EXR フォーマットのアセットとなっています。 ランタイムでは R16_UNORM フォーマットです。 圧縮していない理由は、解像度が257と半端なのと、圧縮するとセクター境界で値の不一致 が起こり、接合しなくなることがあるためです。 14
16. 15/82 データ構成：マテリアルIDマップ • マテリアルの ID を格納 • シェーダーで ID からマテリアル配列を参照 • 解像度 257x257 ( 0.5m / pixel ) • 8bit 無圧縮 ( 0 – 255 ) マテリアル描画結果 マテリアルIDマップ マテリアル配列 次にマテリアルIDマップです。 スプラットマップと呼ばれることもあります。 名前の通り、テレインのマテリアルのIDを格納しています。 テレインのシェーダでこのマップを参照して取得したIDをインデックスとして使用し、テ レインマテリアルの配列を参照します。 解像度はハイトマップと同様です。 圧縮で値が変わることは許されませんので、無圧縮の8bitフォーマットです。 15
17. 16/82 データ構成：その他 • エコトープマップ – 最も粗いレベルのマテリアル分布分け – 例) 森林地帯、砂漠地帯、湿地帯、雪山 – 解像度 129x129 ( 1.0m / pixel ) – 8bit 無圧縮 ( 0 – 255 ) • 色むらマップ – マテリアルの塗り分けとは別にでも色のムラを出すのに使用 – 解像度 132x132 ( 約 1.0m / pixel ) – BC1 フォーマット その他のデータとしましては、最も粗いレベルで地域の特性を塗り分けるためのエコトー プマップもあります。 例えば、森林地帯、砂漠地帯、湿地帯、雪山といった大きな単位で塗り分けます。 解像度は129x129で、8bit無圧縮です。 また、色むらマップも存在します。 マテリアルIDマップで塗り分けたテレインマテリアルとは別に、地面の色むらを出すのに 使用しています。 カラーを格納したマップであるため、BC1圧縮しており、その関係で132x132の解像度に なっています。 16
18. テレインLOD 17/82 • Terrain Quadtree [MOOR18][WEMA17][WID12] – テレインのLOD用 • 各種マップの低解像度版をQuadtree 上位ノードが保持 – 2km単位のラージセクター内をQuadtree 化 – セクター選択ツールから、またはナイトリーのジョブで生成 ラージセクター Quadtree 2km 2km ここまでは128mのセクターについて説明しました。 128mセクターは cyllista game engine における基本的な編集とストリーミングの単位で すが、もうひとつクオドツリー形式のデータ構造があります。 クオドツリーはLODデータを格納する目的で使用します。 各種マップの低解像度版を、より広い領域をカバーするクオドツリーの上位ノードが保持 します。 ワールド全体が2km四方のラージセクターに分割されており、各ラージセクターの中がク オドツリーとなっています。 クオドツリーが持つLODデータの生成は、セクター選択ツールからエンジンユーザーがト リガーしたとき、或いはナイトリーで実行されるジョブで行われます。 17
19. テレインLOD 18/82 • Quadtreeは5段階 – セクター (LOD0: 128m) • 近景用 • 基本編集単位 – 中間 (LOD1, 2, 3: 256m, 512m, 1km) • 中景用 • クック時に生成 – ラージセクター(LOD4: 2km) • 最遠景用 • クック時に生成 • 常駐 クオドツリーは5段階となっています。 葉のノードにあたるLOD0は128mセクターで、近景の描画にはこちらが使われます。 セクターは11x11の範囲が読み込まれる、と説明しましたが、11x11の範囲で読み込むの はコリジョンにも使用するハイトマップなどで、描画にのみ使用するデータはもっと狭い 範囲のみ読み込んでいます。 LOD1, 2, 3 は中間距離で読み込まれます。LOD1, 2, 3のデータはLOD0から自動生成され ます。 最遠景用のLOD4は2kmのラージセクターにあたり、メモリに常駐しています。 18
20. テレインシステム 19/82 1. データ構成 2. 基本編集ツール 3. テレインレイヤー 4. プロシージャルペイント 5. テレイン描画 次に、テレインの基本編集ツールについて簡単に説明します。 19
21. 地形編集ツール 20/82 ツールボックス スカルプト マテリアルペイント フォリッジ配置 編集を リアルタイム反映 編集セクターを選択 編集はすべてレベルエディタ上で行います。 編集の際は、まず画面の左側に表示されているセクター選択ツールで、任意のセクターを 編集状態にします。 次に、画面右上のツールボックスでツールを切り変えます。 例えば、ハイトマップを編集する際は、スカルプトツールを選択します。 そして、画面中央の3Dビュー上で実際の編集作業を行います。 20
22. ハイトマップ編集 21/82 • スカルプト機能 –上げ下げ –平坦化 –スムージング –グレースケールマップによる任意形状のブラシ では、各編集ツールについて紹介します。 最も基本的な編集機能として、ハイトマップのスカルプト機能があります。 テレインの上げ下げ、平坦化、スムージング、グレースケールマップによる任意形状のブ ラシなど、一般的な機能を持っています。 21
23. スカルプトのリアルタイム反映 22/82 • 編集中にコリジョン更新 –テレイン、フォリッジ共に • 地面の上のフォリッジ配置にも即座に反映 スカルプト結果は、もちろんリアルタイムに3Dビューに反映されます。 テレインの変形だけでなく、テレイン上のフォリッジの配置にも、即座に反映されます。 22
24. パスツール 23/82 • 道、川を引くツール • ハイト、テレインマテリアルの加工 • デカール配置 次は、道や川を引くためのパスツールです。 パスを引くと、パスに沿ってハイトマップやマテリアルIDマップの内容が更新されます。 谷のような道を引く場合、ハイトをパスに沿って下げつつ、道用のテレインマテリアルを 塗る、という動作をします。 また、パスに沿ってデカールを配置する機能があります。例えば、道の上に轍を付ける、 といった用途で利用します。 23
25. メッシュスタンプ 24/82 • 任意のメッシュの形状をテレインに転写 • 山岳のスケールから小さな段差のスケールまで利用 • 様々な形状のスタンプ用メッシュを用意 次にメッシュスタンプです。 任意の形状のメッシュをテレインハイトマップに対して転写する機能です。 山岳のような大きなスケールから、ちょっとした段差のような小さなスケールまで幅広く 利用できます。 背景アーティストは様々な形状のスタンプ用メッシュを用意し、共有しています。 適用範囲が広範囲にわたっても高速に動作するように作られており、背景アーティストか らの評判が良い機能です。 24
26. テレインシステム 25/82 1. データ構成 2. 基本編集ツール 3. テレインレイヤー 4. プロシージャルペイント 5. テレイン描画 次に、テレインレイヤーについてです。 25
27. テレインレイヤー 26/82 • テレインの任意の範囲(矩形)をレイヤー化 –山岳等の広範囲からのコピーペースト –マテリアルまで含めた移動、複製 –任意の数をスタック可能 –マスクに従ってブレンド ここまでの機能だけで、広大なワールドの地形を作成することは困難です。 そこでメッシュスタンプを発展させ、テレインレイヤーと呼ぶ機能を作成しました。 テレインの任意の範囲を別レイヤー化し、好きな場所に移動してベースの地形と合成でき ます。 山岳等の広範囲でも使用可能です。 メッシュスタンプの編集対象はハイトマップのみですが、テレインレイヤーはテレインマ テリアルまで含めて移動、複製できます。 また、任意の数のテレインレイヤーを重ねて配置可能で、ブレンドはマスクに従って行い ます。 左の画像がマスク適用前、中央と右の画像はそれぞれ別のマスクを適用した状態です。 26
28. テレインレイヤーを移動する動画 27/ xx 実際にテレインレイヤーを動かしている様子を見てみましょう。 レイヤーの移動に伴い、ハイトとマテリアルが更新されるのがわかると思います。 27
29. 各種マップのランタイム合成 28/82 ② ベースハイトマップと合成 ① 入力ハイトマップ生成 ③ 点群配置と描画 ランタイム ハイトマップ 入力テクスチャ + トランスフォーム + マスクテクスチャ テレインレイヤー メッシュスタンプ パスツール ベース ハイトマップ アセットを直接 入力として使用 必要なら ベイク パスをメッシュ化して ハイトマップに変換 ハイトマップに変換 必要に応じて フォリッジ点群 再生成 最終結果 セクター ここまで見てきたテレインレイヤー、メッシュスタンプ、パスツール、の3機能は、ランタ イムで各種マップを合成することで実現しています。 ここではハイトマップに焦点を当てて説明します。 図の「①入力ハイトマップ生成」で、各ツールの入力をハイトマップに変換します。 テレインレイヤーは、ハイトマップそのものを保持していますので、①では特に何も行い ません。 メッシュスタンプとパスツールは、メッシュやパスの形状に応じたハイトマップを生成し ます。 「②ベースハイトマップと合成」では、セクターの持つベースハイトマップと、①で生成 した入力ハイトマップを合成し、最終的なランタイムハイトマップを生成します。 地形がフィックスした際には背景アーティストが各ツールの結果をベースハイトマップに ベイクする作業を行い、このランタイムの合成過程は不要となります。 「③点群配置と描画」では、合成済みのハイトマップに対してフォリッジ配置処理を行い ます。フォリッジ配置処理については後述します。 28
30. テレインシステム 29/82 1. データ構成 2. 基本編集ツール 3. テレインレイヤー 4. プロシージャルペイント 5. テレイン描画 次はプロシージャルペイントについてお話しします。 29
31. マテリアルIDマップ編集 30/82 • ブラシツールで地道にペイント？ –手動ペイントだけでは物量的に困難 • 地形が変更されたらやり直し 草マテリアルを塗る 崖マテリアルを塗る 広大なマップを全部手動で塗り分ける？ ➡ テレインの形状等に応じて自動でペイント ハイトマップの編集と同様、ここまでで紹介した基本的なブラシツールやテレインレイ ヤーによるコピーペーストのみで、すべての領域のマテリアルを塗り分けることは現実的 ではありません。 また、開発中に地形が変更されると、例えば崖の位置が変わるなどしますので、塗り直し が必要となります。 そのたびに手動での修正を行うと膨大な工数がかかります。 この問題を解決するために、テレインの形状などに応じて、広範囲にわたる任意の領域を 一度に自動ペイントする機能を実装しました。 30
32. 分布 31/82 Cavity Flow Roughness Height Slope • 分布 : 形状をパラメータ化 – 地面の傾き、高さ、凸凹具合、etc… – 2Dグレースケールマップ – Compute Shader で実装 このペイント機能について少し詳しく説明します。 この機能は「分布」と呼ぶマップを生成します。 一般にはアルファ、或いはマスク、と呼ばれるものです。 地形の傾き、高さ、凹凸といった情報をハイトマップを元に算出し、2Dのグレースケール マップ化します。 この処理はGPUで行います。 画像は cyllista game engine でサポートされている分布の例です。 右上の Height は、地面の高さ情報そのものです。ハイトに対して、例えば200m～300m まで、といったような範囲を指定して分布とします。 ・左下のCavityは地形のへこみを表します。 ・Flowは水が流れた場所を表す分布です。水が流れるようなシミュレーションを実行して 生成します。 ・Roughnessは地形の凸凹度合いを表します。局所的な高さの変化が激しい場所ほど値が 大きくなります。 ・Slopeは傾きです。指定した一定の角度の範囲でフィルタすることによって分布とします。 31
33. ルールとルールセット 32/82 • ルール – 分布 + マテリアル • ルールセット – ルールの集まり – ルールセットに基づいて 自動ペイント これらの分布と、分布の値が高い部分にペイントするマテリアルを組み合わせたものを、 ルールと呼んでいます。 ルールに基づき、例えば傾斜の強い場所を崖のマテリアルで自動ペイントする、といった ことが可能になります。 複数のルールをまとめたものをルールセットと呼びます。 ルールセットを定義することで、複数のルールをまとめて1操作で適用し、一括で自動ペイ ントできます。 32
34. ルールセット 33/82 ルールの組み合わせで複雑な結果を得ることが可能 ペイント前 自動ペイント結果 Cavity Slope ルールセット内のルールの組み合わせを変えることで、複雑な結果を得ることが可能です。 図の例では、Cavity と Slope それぞれの分布に別のテレインマテリアルをアサインしてい ます。 ここでは1ルールにつき1分布しか使用していませんが、1つのルール内で複数の分布を組み 合わせて使用することもできます。 ルールセットは背景アーティストがレベルエディタ上で定義します。 ルールはある程度柔軟に組み合わせられます。 各分布に対するパラメータやルールの組み合わせを変えることで、リアルタイムにテレイ ンマテリアルの変化をプレビューできます。 33
35. ルールセット 34/82 • エコトープごとにルールセットを定義 – エコトープマップは手動ペイント • ペイントされていない部分のみを更新 – 手動ペイント部分や確定済みの場所を除外 – 再ペイントしたい領域はブラシ等でクリア ルールセットA ルールセットB またルールセットはエコトープごとに定義します。 エコトープを塗り分けておくことで、雪山と砂漠、といったまったく景観の異なる地域の 自動ペイントが可能になります。 自動ペイントは、手動ペイントで作りこんだ部分を上書きしないように、手動ペイントし ていない部分にのみ行われます。 自動ペイントしなおしたい場合は、その領域をブラシや塗りつぶしツールでクリアしてお きます。 34
36. ※プロシージャルマテリアルの動画 35/ xx では実際にプロシージャルペイントしているところを見てみましょう。 ルールセット内のいくつかの分布パラメータを変更してリアルタイムプレビューを行って います。 35
37. テレイン編集フロー 36/82 ①大枠の地形作成 ④地形の詳細作り込み ⑤区画の移動 ②エコトープ作成 利用ツール 作業フロー ③大枠のマテリアル割当 ハイトマップインポータ メッシュスタンプ テレインレイヤー ペイントツール プロシージャルペイント スカルプトツール ペイントツール メッシュスタンプ パスツール テレインレイヤー テレイン編集ツールのまとめとして、テレインの編集フローを見てみます。 図は、作業フローと、各作業段階で利用するツールの対応を示しています。 「①大枠の地形作成」では、ハイトマップインポータ、メッシュスタンプ、テレインレイ ヤーを主に使用します。各ツールで山などの大きな単位を扱います。ハイトマップイン ポータは説明していませんでしたが、これは外部ツールからのハイトマップをセクター単 位に分割して取り込むためのシンプルなPythonスクリプトです。 「②エコトープ作成」では、大まかな地域をエコトープマップに塗り分けます。こちらは 手動ペイントです。 「③大枠のマテリアル割当」では、エコトープごとに、プロシージャルペイントでマテリ アルIDを塗り分けます。 「④地形の詳細作り込み」では、細かいハイトスカルプト、マテリアルペイント、段差な どでの小規模なメッシュスタンプの利用、パスツールで道を引くなどの作り込みを行いま す。この段階でも小規模な範囲でテレインレイヤーを使用することがあります。 「⑤区画の移動」では、ゲームデザインの変更などがあった場合に、例えば拠点周辺を丸 ごとテレインレイヤー化して再配置する、といったことも行います。 テレインの上に乗っているスタティックメッシュを、テレインレイヤーエンティティとグ ループ化することで、地形とメッシュをまとめて移動することが可能です。 もちろん、これらの作業は一方向に進むのではなく、行ったり来たりを繰り返します。 36
38. テレインシステム 37/82 1. データ構成 2. 基本編集ツール 3. テレインレイヤー 4. プロシージャルペイント 5. テレイン描画 ここまでは編集ツールの話題でしたが、ここからは少し描画処理について紹介します。 37
39. Terrain Quadtree 描画 38/82 • Terrain Quadtree 描画 – Quadtree各段階に対応するサイズのメッシュを描画 – ロード状態と距離に応じてLODレベルを決定 – フラスタムカリングして描画 データ構成で説明した通り、テレイン描画はクオドツリーの持つデータを用いて行います。 カメラからの距離に応じてクオドツリーの最適なレベルが選択されます。 描画に使うメッシュは、各段階に対応した粗さのグリッドメッシュです。 ロード状態と距離に応じて、使用するクオドツリーノードを決定し、ノードの持つハイト マップやマテリアルIDマップといったデータを参照します。 画像は、ビューフラスタムカリングが行われた上で、描画に使用されたクオドノードを表 しています。 38
40. ③カリング判定 ①レベルNの ノードが対象 Terrain Quadtree 描画 39/82 • 表示するノードレベルの判定 – 子のロード状況に応じて自身のカリング状態を決定 – 子ノードに対して再帰的に判定 – スモールセクター(LOD=0)はそれ以上分割されない ②ロード状況チェック 子ノードが すべてロード済み 子ノードが 一部ロード済み 子ノードが未ロード レベルN全体をカリング 4分割し、子がロードされて いる部分をカリング 分割せずそのまま表示 N ④N-1を 同様に処理 N-1 表示するノードレベルの判定について、もう少し詳しく見てみます。 画面下の図をご覧ください。 まず、左下の①でレベルNのノードから処理を開始したとします。5段階のクオドツリーで は、最初はN=4、つまり一番粗いレベルから処理を開始します。 次に「②ロード状況のチェック」を行います。子ノードのロード状況は、すべてがロード 済み、一部がロード済み、すべてがロードされていない状態、の3パターンが考えられます。 「③カリング判定」では、それぞれの状況に応じたカリング判定を行います。 上段の、子ノードがすべてロード済みの場合、レベルNの粗いノードはカリングされ、レベ ルN-1のより詳細な子ノードを表示候補とします。 中段の、子ノードの一部がロード済みの場合、レベルNの中で子ノードがロードされている 緑の部分はカリングされますが、残りの青い部分は描画に使用されます。この部分的なカ リングを行うために、レベルＮのグリッドメッシュはあらかじめ4分割されています。 下段の、すべての子ノードがロードされていない場合は、青で示されたレベルNの領域をそ のまま描画に使用します。 ④では、より詳細なデータを使うと判定された緑の領域に対して、さらに詳細なレベルに 分割してカリングを行うか否かの判定を、①に戻って再帰的に実行します。 39
41. マテリアルブレンディング 40/82 • 上下方向の投影のみでは斜面のテクスチャが伸びる – 傾斜が急になるほど顕著 – 改善するには、横方向からの投影も必要 では次にマテリアルブレンディングに話題を移します。 テレインにテクスチャをマッピングする時、上下方向に投影したマッピングでは、斜面の テクスチャが伸びてしまいます。 これは、傾斜が急になるほど顕著です。 そこで、横方向からの投影も必要となります。 40
42. マテリアルブレンディング 41/82 • Triplanar Mapping [GOL17] – 伸び防止のためXYZ軸の3方向から投影 – 各軸の角度とサーフェス法線の角度を 重みとしてブレンド これを解決するシンプルな方法の一つは、Triplanar Mapping です。 XYZそれぞれの方向から投影してテクスチャUVを算出し、各軸の角度とサーフェス法線の 角度を重みとしてブレンドするマッピング方法です。 Cyllista game engine では、まずこの手法を導入して、テクスチャの伸びを回避しました。 Triplanar Mapping はよく知られた方法で、参考資料も数多く存在しますが、ベン ゴロス 氏のブログ記事に法線のブレンド方法も含めて詳しく解説されています。 41
43. マテリアルブレンディング 42/82 • ブレンド処理の処理負荷が高い – Albedo + NRO = 2テクスチャ • NRO = Normal/Roughness/Occlusionをパックしたテクスチャ – 4つの各頂点のリニア補間 = 4ブレンド • 頂点ごとに1マテリアル – Triplanar Mapping = 3ブレンド • 崖等のテクスチャ伸び防止 – 近景と遠景でタイリング数が異なる = 2ブレンド • リピート感軽減のために遠景はUVリピート数を減らす ➡ ピクセル当たり合計 2 * 4 * 3 * 2 = 48 サンプル TriplanarMappingを導入すると見た目は改善しますが、テクスチャサンプル数が多くなり すぎて処理負荷が高いという問題が発生します。 Cyllista game engine のテレインは Albedo テクスチャと Normal/Roughness/Occlusion をパックしたテクスチャの2枚をサンプルしていました。 そして、テレインの描画はグリッドメッシュを使用しているため、各頂点のマテリアルID がすべて異なる場合、周辺4頂点分、4セットのサンプルが必要です。 ここまでで、テクスチャ2枚 かける 4頂点分、で8サンプル必要になります。 さらに Triplanar Mapping が入ったことで、サンプル数がその3倍になりました。 そして、遠景のタイリングを軽減するために近景と遠景のUVリピート数を変えており、そ の間を補間するため、さらに2倍になります。 これすべて掛け合わせると、合計48サンプルとなり、処理負荷が高すぎて現実的ではあり ません。 42
44. マテリアルブレンディング 43/82 • Triplanar Mapping – 伸び防止のためXYZ軸の3方向から投影 – 各軸の角度とサーフェス法線の角度を 重みとしてブレンド • Biplanar Mapping [QUI20] – 3軸のうち、ウェイトの高い2軸を 採用してブレンド – ブレンド数を3→2に削減 – Triplanar Mapping と遜色ない結果 そこでまず、Triplanar Mapping に代えて Biplanar Mapping を導入しました。 こちらは Inigo Quilez 氏のWebサイトにある情報を元に実装しています。 Triplanar Mapping ではXYZ3軸方向からの投影を行いますが、Biplanar Mapping では3 軸のうち、サーフェス法線に近い2軸を選択してブレンドします。 結果は、Triplanar Mapping と遜色ありませんでした。 Biplanar Mapping に変えた結果、合計サンプル数は48から32に削減できました。 43
45. マテリアルブレンディング 44/82 • Biplanar Mapping Y軸一方向のマッピングとBiplanar Mappingの比較です。 上段が元の状態、下段がBiplanar Mapping導入後です。 左の列は半球が描かれたノーマルマップを張り付けて可視化したもので、右の列は最終的 なシェーディング結果です。 44
46. マテリアルブレンディング 45/82 • Stochastic Sampling [MOOR18][WYMC17] – 1ピクセルにつき最大4マテリアルのブレンド ➡ ウェイトに従って確率的に1マテリアル選択 – Biplanar Mapping ➡ ウェイトに従って確率的に投影方向を選択 BiplanarMappingだけでは、サンプル数の削減には十分ではありません。 そこで Stochastic Sampling を導入しました。 こちらは GDC2018 の Terrain Rendering in Far Cry 5 というセッションを参考にしてい ます。 1ピクセルにつき4頂点分のマテリアルをブレンドする代わりに、ウェイトに従って確率的 に1つを選択する、という方法です。 また、Biplanar Mapping をさらに最適化するために、2つの投影方向軸から1つを、ウェイ トに従って確率的に選択してしまうことにします。 確率的な選択に使用する乱数は、Morgan McGuire 氏の Hashed Alpha Testing という論 文に乗っているハッシュ関数を使用します。 このハッシュ関数でワールド座標に基づいて疑似乱数値を算出すると、カメラが動いても スクリーン上である程度パターンが安定します。 以上で説明した Stochastic Sampling は、遠距離では許容できる品質になります。 しかし、従来のアルファブレンドと異なりスムースなブレンドにはならないため、近景の、 特に色や明度の差が大きい場所では品質低下が目立ちます。 45
47. マテリアルブレンディング 46/82 • Biplanar + Stochastic + α – 近景(30mまで) • Biplanar Mapping – 2 * 4 * 2 * 2 = 32サンプル • XYZいずれかに垂直に近い面は その軸方向からのマッピングのみ – 2 * 4 * 1 * 2 = 16サンプル • 同一マテリアルの削減 – 2 * n * 1 * 2 = 4*nサンプル » n は 1 から 4 – 遠景 • 確率的に1つのマテリアルを選択 • 確率的に1つの投影方向を選択(Uniplanar) • 2 * 1 * 1 * 2 = 4サンプル そこで Far Cry 5 と同様に、近景と遠景でブレンド方法を分けることにしました。 カメラから30mまでは、品質を重視し Stochastic Sampling を使用しません。 ただし、サーフェス法線がXYZ軸に近く1方向からの投影で問題ないピクセルに関しては、 1方向分のみサンプルします。 また、バイリニア補間する隣接した4マテリアルの中で、同じマテリアルがある場合はその 分のサンプルを削減します。 カメラから30m以降に関しては、本来バイリニア補間する複数マテリアルも、複数の投影 方向も、両方、ウェイトに従って確率的に選択します。 このため遠景は4サンプルで済みます。 この他にも、FarCry5の資料で紹介されているようにスクリーンスペースタイルごとに必要 なブレンド方法を分類し、 負荷が最小となるシェーダをタイルごとに割り当てる方法の導入や、テクスチャサンプル のダイバージェンスを避ける最適化を予定しています。 46
48. Foliage System 47/82 テレインシステムについてはここまでです。 ここからはフォリッジシステムについて紹介します。 47
49. フォリッジシステム 48/82 1. プロシージャルフォリッジ配置 2. 点群生成とカリング 3. 頂点吸着 4. フォリッジレイヤの依存関係 5. 遠景フォリッジ 6. 他システムへの情報提供 フォリッジシステムについては、 1.プロシージャルフォリッジ配置 2.点群生成とカリング 3.頂点吸着 4.フォリッジレイヤの依存関係 5.遠景フォリッジ 6.他システムへの情報提供 の順で説明します。 48
50. フォリッジシステム 49/82 1. プロシージャルフォリッジ配置 2. 点群生成とカリング 3. 頂点吸着 4. フォリッジレイヤの依存関係 5. 遠景フォリッジ 6. 他システムへの情報提供 最初のトピックは、プロシージャルフォリッジ配置についてです。 49
51. フォリッジ配置：要件 50/82 • 広大なワールドに効率的にフォリッジを配置したい • 大半のエリアでは自動配置したい • 作り込みたいエリアは手動配置したい • テレインの編集をフォリッジ配置に反映したい • ゲームプレイ中の動的変更を可能としたい 画像差し替え予定 フォリッジの配置ワークフローを背景アーティストと検討したところ、いくつかの要件が 出てきました。 ・まず、広大なワールドに効率的にフォリッジを配置したい、ということが挙げられまし た。 ・大半のエリアで通用する、いわゆるいい感じ、の配置を自動で行う仕組みが求められま した。 ・ただし、拠点回りなど作りこみたいエリアでは、手動配置で自動配置の結果を上書き可 能にする必要もありました。 ・また、テレインの編集結果を元にフォリッジ配置が自動更新されるシステムが求められ ました。 ・そして、ゲームプレイ中に動的変更がしやすいシステムにできれば、ゲーム仕様の可能 性を広げられます。 50
52. プロシージャルフォリッジ配置 51/82 • 特徴 – GPUで配置 – ゲーム実行時にリアルタイム配置 – ルールで自動配置 • 配置のためのデータ – フォリッジマップ：密度、エコトープ – 地形マップ：ハイト、ノーマル、マテリアル – モデル：植生や石など任意のモデル – 配置ルールとパラメーター • フォリッジレイヤー – モデルと配置パラメーターのセット • フォリッジプリセット – フォリッジレイヤーの集合 Cyllista Game Engine では、これらの要件を満たすプロシージャルフォリッジ配置システ ムを実装しました。 配置処理はゲーム実行中にGPUで、リアルタイムに行われます。 また、配置はルールに基づいて行われます。 配置のためのデータとして、密度マップやハイトマップなどの各種マップや、配置モデル ごとのルールパラメータが参照されます。 ひとつのフォリッジモデルとそれに対する配置パラメータのセットを、フォリッジレイ ヤーと呼んでいます。 複数のフォリッジレイヤーの集合を、フォリッジプリセットと呼んでいます。 このプリセットは、エコトープごとに切り替えられます。 51
53. 配置用マップ 52/82 • 密度マップ – フォリッジ点群の配置密度を保持 – ペイントツールで手動編集 – プロシージャルペイントにも対応 – 4枚利用可能 • エコトープマップ – 大まかな景観の種類と範囲を表現 • 森林、砂漠、雪山、etc. • サブエコトープマップ – エコトープ内のバリエーション表現 • マテリアルIDマップ – テレインマテリアルIDを保持 配置用マップについて、説明します。 1つめは密度マップです。 ・密度マップは、フォリッジを配置する点の数を決定します。 ・ペイントツールで手動ペイントすることもできますし、プロシージャルペイント機能で ノイズのパターンなどを広範囲に適用することもできます。 ・密度マップは4枚まで利用可能です。各フォリッジレイヤーは、4枚のうちいずれかの密 度マップと関連付けられています。 2つ目はエコトープマップです。 テレインマテリアルのプロシージャルペイントで使用したマップと同じものです。 エコトープごとにフォリッジプリセットを切り替えられます。 3つ目のサブエコトープマップは、エコトープ内をさらに細分化するために使用します。 このマップはフォリッジレイヤーに対するフィルタとして機能します。 4つ目はテレインシステムが持つマテリアルIDマップです。 フォリッジレイヤーをマテリアルIDでフィルタするために使用します。 特定のマテリアルの上に、特定のフォリッジのみ配置を可能とします。 52
54. 配置用パラメータ 53/82 • 配置パラメータ – 配置間隔 – ランダムスケールと回転範囲 – 配置するテレインの高度と傾斜範囲 – 密度マップインデックス – 配置されるテレインマテリアル – 配置されるサブエコトープ …etc. 配置用パラメータは、配置間隔やランダムスケール範囲、配置場所の傾斜角度の範囲、配 置対象のテレインマテリアルやサブエコトープなど、多数存在します。 パラメータは、フォリッジレイヤーごとに指定します。 53
55. フォリッジ手動配置動画 54/ xx では実際に、手動でフォリッジを配置している様子を見てみましょう。 密度マップのインデックスを指定してブラシでペイントすると、その密度マップに関連付 けられた複数のフォリッジが配置されます。 後半は、テレインマテリアルをペイントすることで、そのテレインマテリアルに対応する フォリッジレイヤー、ここでは石のレイヤーのみが残る様子がわかります。 54
56. 密度マップのノイズペイント 55/82 • 各種パラメータを指定してペイント – サイズ – イテレーション数 – ゲイン – ディストーション …etc. • 複数のノイズを合成して作成 手動配置の他に、密度マップについてもプロシージャルペイント機能を作成しました。 ベースとなるノイズに対して、各種のパラメータを元にGPU上で加工処理を行い、結果を 密度マップに出力します。 複数のスケールの異なるノイズをテレインハイトに応じて選択的に合成するなど、より フォリッジ配置に特化した機能となっています。 55
57. 密度マップのノイズペイント 56/82 • セルノイズ（ボロノイ） – グリッドセルにランダムにポイントをランダム配置 – 各テクセルからポイントに対する距離フィールドを作成 – UVにディストーションを適用 – 閾値を指定して2値化 格子毎にポイント配置 距離フィールド化 ディストーション適用 2値化 使用するノイズについて、特定のフォリッジが集まった分布を実現するにはセルノイズが 使いやすいことがわかりました。 セルノイズを生成するにはまず、一定サイズのグリッドを考え、グリッドセルにポイント を1つずつランダム配置し、各テクセルから一番近いポイントまでの距離フィールドを作成 します。 あるテクセルから最近傍点までの距離を求めるには近傍の9セルを探索すればよいだけで、 シェーダで簡単、軽量に実装できます。 この距離フィールドに対して、ユーザの指定したパラメータに応じてUVにディストーショ ンをかけたり、2値化するなどの加工を行います。 56
58. テレインレイヤーと密度マップ 57/82 • テレインレイヤーに密度マップも保持 – フォリッジもまとめてコピーペースト・移動が可能 – 小規模~大規模な範囲まで有用 さらにフォリッジ配置を便利にするための試みとして、テレインレイヤーに密度マップも 保持するように機能拡張を行いました。 これによって、フォリッジもまとめてコピーペースト・移動が可能です。 小さな花畑ほどの範囲から、山1つ分のサイズまで、スケールを問わず利用可能です。 57
59. 58/ xx 密度マップまで含めたテレインレイヤーの移動動画 密度マップまで含めたテレインレイヤーが動作する様子を動画でご覧ください。 58
60. フォリッジシステム 59/82 1. プロシージャルフォリッジ配置 2. 点群生成とカリング 3. 頂点吸着 4. フォリッジレイヤの依存関係 5. 遠景フォリッジ 6. 他システムへの情報提供 次に、配置点群生成とカリングについて説明します。 59
61. 点群パターン 60/82 • 密度マップを点群に変換 – ランダムでなくDeterministicな配置 – 密度に関わらず偏りのない一様な分布 • 配置パターン – 事前生成した固定の配置パターン – 各点が2D座標と密度閾値(0~1)を保持 – 密度値が閾値を超える点を残す – セクターにタイリング – 配置間隔でパターンをスケール フォリッジの配置処理では、密度マップをフォリッジを配置する多数の配置点に変換する 必要があります。 ・配置は、ゲームを実行するたびに結果が変わるようなことがない、Deterministicなアル ゴリズムでなければなりません。 ・また、密度の値が同じなら、場所による偏りなく、一様に配置される必要があります。 右下の画像のようなイメージです。 （配置パターン） ・このために右上の画像のような事前生成した固定の配置パターンを用いました。 配置パターンの点はそれぞれ密度の閾値を持っており、密度マップの密度値が点の持つ 閾値を超える場合に、その点を配置点として残します。 ・配置パターンは128mセクターに対応しており、どのセクターも同じパターンを使用しま すが、実用上、タイリングに気づくことはありません。 ・また、フォリッジの配置間隔パラメータに応じて、パターンをスケールして使用します。 60
62. 点群生成 61/82 セクター カリング 点群生成 &ソート 点群 カリング 描画 描画フェーズ 点群生成フェーズ ビューフラスタム セクター 配置点群 1. ビューフラスタム内に存在するセクターを特定 2. 点群を生成してソート • 可視性が変わったセクターのみ生成し直し 3. 点単位にカリングして描画 参考資料 [MUI17] 次に点群の生成処理についてです。 点群生成ではまず、セクター単位のカリングを行い、ビューフラスタム内にあるセクター を特定します。 そして、カリングをパスしたセクターのうち、前回点群を生成したときから可視性が変 わったセクターを対象に、点群生成処理を実行します。 そして生成した点群は、描画処理をまとめやすいようにソートします。 最後に点単位にカリングし、描画を行います。 以上の処理は、すべてGPU上で行われます。 GPU上でリアルタイム配置するこの方式には、 ・オンメモリとなる点群バッファのサイズを抑えやすいこと ・ゲーム中の動的な密度マップ変更にも対応しやすいこと ・編集時の反映が極めて高速なこと が挙げられます。 一方で配置処理のGPU負荷がかかりますが、非同期コンピュートでコストを償却すること は可能です。 もしゲーム要件としてインゲームでの配置変更がなく、GPU負荷を少しでも減らしたい場 合は、最終的に点群をオフラインで生成しておくこともできます。 ここまでで説明した点群配置処理の作成にあたっては、GDC2017で発表された GPU- based Procedural Placement in Horizon Zero Dawn を参考にしています。 61
63. 点群ソート 62/82 • 点群生成はGPUで並列実行されるため結果は順不同 – フォリッジレイヤー単位でソートが必要 • カリングと描画がフォリッジレイヤー単位のため – 場合によってはセクター単位のソートも必要 • セクター単位でリードバックする必要があるレイヤー（コリジョンありの点群） • セクター単位で別マップにラスタライズ描画するレイヤー（ブッシュマップ） • ソートキー 1. フォリッジレイヤーインデックス（0～255、256種のフォリッジ） 2. アクティブセクターインデックス（0～120、11*11のロード済みセクター） • ２つのキーを1つに統合してソート • GPU Radix Sort [HAHO11] – ソートする値の範囲が限定されている場合に実用的 先ほど述べたソートについて、もう少し説明します。 ・このソートは、点群生成がGPU上で並列実行されるため、必要になります。 点単位のカリングと描画をフォリッジレイヤー単位で行うために、フォリッジレイヤーを キーにソートする必要があります。 ・場合によっては、セクター単位のソートも行います。 セクター単位でCPUにリードバックする必要があるレイヤー、例えば高さのある木などコ リジョンを持つフォリッジレイヤーがこれにあたります。 また、セクター単位で別マップにラスタライズ描画するレイヤーも該当します。 ソートキーは、フォリッジレイヤーのインデックスと、アクティブセクターのインデック スですが、2つのキーを1つに統合して一度にソートしています。 手法は GPU Radix Sort で、今回のようにソートキーの値の範囲が狭いケースに向いてい ます。 62
64. フォリッジシステム 63/82 1. プロシージャルフォリッジ配置 2. 点群生成とカリング 3. 頂点吸着 4. フォリッジレイヤの依存関係 5. 遠景フォリッジ 6. 他システムへの情報提供 次に頂点吸着についてです。 63
65. 頂点吸着 64/82 • 地面付近の頂点を地面までオフセット – 頂点シェーダでハイトマップを参照 • コリジョンは未対応 – コリジョンのあるメッシュは、ズレが目立たない範囲で利用 – 大きな木の根は、ハイトマップ側のコリジョン変形を検討中 ちょっとした機能ですが、配置したフォリッジが地面から浮かないように、ハイトマップ を参照して、頂点を地面に吸着させる機能があります。 下草はもとより、左の画像のような水辺の石にも使用しています。 現在はコリジョンの変形に未対応で、コリジョンがないメッシュで主に利用しています。 大きな木の根を地面に吸着させた場合はコリジョンがないと問題になるため、配置する木 の側でなくハイトマップ側のコリジョン変形を検討しています。 64
66. フォリッジシステム 65/82 1. プロシージャルフォリッジ配置 2. 点群生成とカリング 3. 頂点吸着 4. フォリッジレイヤの依存関係 5. 遠景フォリッジ 6. 他システムへの情報提供 次はフォリッジレイヤの依存関係についてです。 65
67. フォリッジレイヤの依存関係 66/82 • 例）高木の周り10m以内だけ低木を植えたい – レイヤー間に依存関係を持つ – 依存される側(高木)の点群をDependency Map にラスタライズ – 依存する側のレイヤー(低木)はDependency Map を参照 Dependency Map フィルタ後 フィルタ前 フォリッジを配置していると、フォリッジ間に依存関係を持たせたいことがよくあります。 例えば高木の周りだけ、低木を配置したい、といったケースです。 これを実現するために、Dependency Map と呼ぶ仕組みをサポートしました。 配置したフォリッジ点群を、フォリッジの半径を使用してグレースケールの Dependency Map にラスタライズし、別のフォリッジレイヤーはこのマップを参照して配置場所を限定 します。 Dependency Map はセクターごにと作成しており、セクター間にはシームができています。 しかし、Dependency Map 適用後の結果だけを見た場合、シームに気づくことはありませ んでした。 今後も様々な植生を持つ地域を増やしますが、もし問題になった場合は、シームが出ない ように対応が必要になるかもしれません。 66
68. フォリッジシステム 67/82 1. プロシージャルフォリッジ配置 2. 点群生成とカリング 3. 頂点吸着 4. フォリッジレイヤの依存関係 5. 遠景フォリッジ 6. 他システムへの情報提供 次に遠景フォリッジについてです。 67
69. 遠景フォリッジ 68/82 • アクティブセクター範囲外ではフォリッジ配置データがない – 必要なマップがロードされていない→ 点群を配置できない • レジデントマップ – 全セクター分割マップを一枚にマージ – 解像度はセクター単位マップの1/4 – ストリーミングなし、メモリに常駐 – Jenkins で毎日自動生成 ロードされているセクターをアクティブセクターと呼びます。 この範囲外では、密度マップ他、フォリッジ配置用のマップがメモリ上に存在しません。 そのため、遠景のフォリッジ表示には別のデータが必要になります。 現在は、レジデントマップと呼ぶマップで遠景用のデータを賄っています。 これは全セクターの各種マップを縦横1/4に落として1枚にマージしたマップで、オフライ ンで作成しており、常にオンメモリです。 つまり、現状ではフォリッジ用のマップについては遠景用LODが1段階しかありません。 縦横1/4だと広大なレベルではまだ大き過ぎ、メモリ使用量が多く、マップへのテクスチャ アクセスも非効率になります。 テレインシステムで説明した通り、ハイトマップやテレインマテリアルIDマップは、 Terrain Quadtree による複数段階のLODデータを持っています。 現在、フォリッジ関連のマップも Terrain Quadtree のペイロードとするように変更を進め ています。 68
70. フォリッジインポスター 69/82 • エンジン内のツールでインポスターテクスチャ生成 – アルベド、ノーマル、ラフネス、オクルージョン、透過色、厚み • Octahedral Impostors [BRU18] – 上半球の様々な角度からキャプチャ – キャプチャ時のカメラ方向を、八面体展開したUVに対応付け – 描画時は視線ベクトルで同様の計算を行いUVを決定 遠距離フォリッジの描画負荷削減のために、インポスターの対応も行いました。 フォリッジレイヤーを選択し、エンジン内でインポスターテクスチャを作成できます。 またフォリッジレイヤーごとにインポスターを使用した描画、つまりビルボードでの描画 に切り替わる距離を設定できます。 レジデントマップが使用される距離では必ずインポスターによる描画となります。アク ティブセクターのフォリッジは、距離によってメッシュとインポスターが切り替わります。 インポスターのキャプチャについては、Octahedral Imposter を実装しました。 Octahedral Imposter は水平方向からキャプチャーした絵だけでなく、上から見下ろした 視点に対応したキャプチャも行います。 しかし、方向が水平と垂直の2方向になるため、それぞれの角度に対応するためにキャプ チャ枚数が多くなりがちです。 キャプチャ方向数は、ゲームの要件として上空を飛行するか、または高い崖から森を見下 ろすような地形がどの程度あるかによって調整が必要です。 69
71. フォリッジシステム 70/82 1. プロシージャルフォリッジ配置 2. 点群生成とカリング 3. 頂点吸着 4. フォリッジレイヤの依存関係 5. 遠景フォリッジ 6. 他システムへの情報提供 フォリッジシステムの最後のトピックとして、他システムへの情報提供について説明しま す。 70
72. 他システムへの情報提供 71/82 • 点群の座標はゲーム実行時まで不明 • 描画以外の機能へ配置情報を提供 – 例）物理、サウンド、ゲームプレイ – 点群データはビデオメモリに存在 • メインメモリへの転送 (リードバック)が必要 フォリッジ配置点群の座標はゲーム実行時まで不明なため、これらの情報を他のシステム に提供するための仕組みが必要です。 ここで言う他のシステムとは、描画以外のシステム、例えばコリジョンシステム、ゲーム プレイシステム、サウンドシステムなどの事です。 フォリッジの配置情報は、これらのシステムにも必要とされます。 コンソール機とPCでは事情が違いますが、少なくともPCでは点群データはビデオメモリに 存在するので、メインメモリにリードバックする必要があります。 71
73. 情報提供： コリジョン 72/82 • 配置データを物理システムに提供 • コリジョンのあるフォリッジレイヤーはセクターロード時に 必ず点群配置&リードバック • 採集アイテムの配置も類似の仕組みで実現 描画以外の最も基本的な利用はコリジョンです。 配置されたフォリッジレイヤーのコリジョンメッシュと配置点の情報を物理システムに提 供します。 フォリッジを配置すると、即座にコリジョンメッシュが生成されます。 コリジョンのあるフォリッジの点群配置については、ビューフラスタムによるセクターカ リングは行われず、アクティブセクターがロードされた段階で必ず配置処理が実行されま す。 そのため、点群生成とカリング、のトピックで説明した配置セクターを決定するためのセ クターカリングは行われていません。 コリジョンのあるフォリッジレイヤーは、高さのある木や、大き目の岩などですので、点 群全体の数に占める比率は低く、セクターカリングなしでもそれほどメモリを圧迫しませ ん。 72
74. 情報提供： ブッシュマップ 73/82 • キャラクターがブッシュの中にいるか知りたい • ブッシュ属性のある点群をブッシュマップにラスタライズ • ハイトフィールドのコリジョンデータに埋め込み 次にブッシュマップについてです。 ゲーム仕様の関係で、キャラクターがブッシュの中にいるか知りたいといったことはよく あります。 そのような場合、ブッシュに対応するフォリッジレイヤーから生成された点群を、ブッ シュマップにラスタライズし、これをリードバックしてゲームプレイシステムに提供しま す。 ゲームプレイシステムに直接マップを提供することもできますが、本機能では物理システ ムが持つハイトフィールドのコリジョンデータに属性として埋め込んで渡しています。 73
75. 情報提供： 点群クエリー 74/82 • 指定した円の内にあるフォリッジ配置点を取得 • サウンドとゲームプレイで活用 • クエリー結果の点数は少量 – リードバックするデータ量を抑えるため 次に点群クエリーです。 座標と半径を指定し、その中にあるフォリッジ配置点の座標を検索する機能です。 画像は、デバッグ表示カメラ周辺の木のフォリッジレイヤーに対するクエリーを発行した 結果です。 クエリー結果の座標にワイヤーフレームの球が表示されており、木の位置が正しく取得で きていることがわかります。 点群クエリーは、このように結果の点数が少量のケースに向いています。 この例ではサウンドで木のざわめき音を出すために使用する他、ゲームプレイの要件でも 活用しています。 74
76. 機能とデータの関係図 75/82 編集ツール 対象マップ 出力 入力 入出力 ハイトマップインポータ メッシュスタンプ 手動ペイントツール プロシージャルペイント スカルプトツール パスツール テレインレイヤー ハイトマップ マテリアルIDマップ エコトープマップ 色むらマップ 密度マップ サブエコトープマップ テレイン描画システム フォリッジ配置システム コリジョンシステム サウンドシステム ノイズペイント 配置点群 利用システム Dependencyマップ ゲームプレイシステム フォリッジシステムの説明は以上です。 最後に、ここまでに説明したテレインシステムとフォリッジシステムの各機能と、データ の関係を整理します。 各ツールと、ツールが入出力するデータの関係は図のようになっています。 やや複雑な関係図ですので、まず各データについて関係するツール、という観点から見て みます。 75
77. 機能とデータの関係図 76/82 編集ツール 対象マップ 出力 入力 入出力 ハイトマップインポータ メッシュスタンプ 手動ペイントツール プロシージャルペイント スカルプトツール パスツール テレインレイヤー ハイトマップ マテリアルIDマップ エコトープマップ 色むらマップ 密度マップ サブエコトープマップ テレイン描画システム フォリッジ配置システム コリジョンシステム サウンドシステム ノイズペイント 配置点群 利用システム Dependencyマップ ゲームプレイシステム 編集ツールと対象マップの列をご覧ください。 ハイトマップを更新するツールは、ハイトマップインポータ、メッシュスタンプ、スカル プトツール、パスツールです。 マテリアルIDマップは、プロシージャルペイント、パスツール、手動ペイントツールで更 新されます。 色むらマップ、エコトープマップ、サブエコトープマップ、は現在のところ手動でのペイ ントのみです。 密度マップは、パスツール、手動ペイントツール、ノイズペイントツールで更新されます。 テレインレイヤーは、以上の様々なツールで更新されるすべてのマップに対応しています。 このように、現在は各ツールが固定的に各種のマップに対応しています。 この作りでは各ツールが高速に動作し、実用上も困るケースは少ないものの、やや柔軟性 が低い面もあります。 そのため現在、柔軟性を上げるために、 ・密度マップのノイズペイントの拡張 ・ノイズペイントとテレインマテリアルプロシージャルペイントの統合 ・出力先マップの柔軟な選択 の3つについて、対応を検討しています。 76
78. 機能とデータの関係図 77/82 編集ツール 対象マップ 出力 入力 入出力 ハイトマップインポータ メッシュスタンプ 手動ペイントツール プロシージャルペイント スカルプトツール パスツール テレインレイヤー ハイトマップ マテリアルIDマップ エコトープマップ 色むらマップ 密度マップ サブエコトープマップ テレイン描画システム フォリッジ配置システム コリジョンシステム サウンドシステム ノイズペイント 配置点群 利用システム Dependencyマップ ゲームプレイシステム 次に利用するシステムの観点から見てみます。 コリジョンシステムは、ハイトマップを利用します。 また、テレインとの衝突点の物理的な属性をサウンドシステムやVFXシステムに提供するた めに、マテリアルIDマップも利用します。 テレイン描画システムは、グリッドメッシュを描画するためにハイトマップを使用します。 また、テレインのピクセルの色を決定するためにマテリアルIDマップや色むらマップを使 用します。 図には書かれていませんが、描画距離に応じてセクター単位の各マップを直接使用するの ではなく、実際にはクオドツリーから適切なLODレベルのマップを取得して使用します。 フォリッジ配置システムは、配置点の高さと点群の粗密を決定するために、それぞれハイ トマップと密度マップを基本的なデータとして利用します。 また、エコトープマップを参照して利用するフォリッジプリセットを切り替え、大幅な植 生の変化を実現します。 そして、フォリッジプリセット内の各フォリッジレイヤーに対応した点群を配置する際、 フィルターのためにマテリアルIDマップとサブエコトープマップを参照します。 これにより、テレインマテリアルに合わせた草を生やしたり、同一エコトープ内での変化 をつけられます。 フォリッジ配置システムの生成した配置点群は、コリジョンシステムがコリジョンの配置 に利用したり、サウンドシステムがクエリーして環境音に使用するなどします。 フォリッジ配置システムの出力する配置点群はブッシュマップ化され、ゲームプレイシス テムの入力となります。 フォリッジレイヤ間の依存に使用しているDependencyマップはオンザフライで作られて 77
79. いますが、マップのメモリフットプリント、処理コスト共に高いため、点群配置の動的更 新が必要のない場所では、点群を事前に生成してアセット化する選択肢もあります。 77
80. 78/82 まとめ • テレインシステム –広範囲でも高効率に編集できるツールを整備 –テレインレイヤー等で非破壊ワークフローを推進 –マテリアルブレンディングやQuadtreeによるLOD等の最適化 • フォリッジシステム –プロシージャル配置により高効率かつ自然に見える植生分布を実現 –最適化したリアルタイム配置により製作時、ゲーム中の両方で 変更を即時反映 それでは本セッションのまとめに移りたいと思います。 Cyllista Game Engine のテレインシステムでは、オープンワールドの広範囲な地形であっ ても、効率的に編集できるツールを整備しています。 テレインレイヤー等で、非破壊ワークフローも推進し、イテレーションをしやすくしてい ます。 ツールだけでなく、描画負荷に関しても、マテリアルブレンディングにおけるいくつかの 工夫やQuadtreeによるLODといった最適化を進めています。 フォリッジシステムについては、プロシージャル処理を活用しています。これにより高効 率な作業を可能とし、自然に見える植生分布を作りやすいツールとなっています。 点群配置をGPUでリアルタイムに行うことで、制作時とゲーム中の両方で変更の即時反映 を可能としています。 78
81. 79/82 Cyllista Game Engine が掲げる指針に沿った機能開発 • ハードウェアが最大のパフォーマンスを発揮できる – オープンワールド前提の設計 – 継続的な最適化 – ゲームの要求を満たしつつ処理負荷を可能な限り低減 • 開発者が最大のパフォーマンスを発揮できる – ベイクや事前データの準備を極力減らし、ランタイム実行 – 機能の利便性、実行速度、メンテナンスのためのシンプルさを注意深くバランス – 我々のチームにとって最適な機能開発 まとめ 以上の開発にあたっては、Cyllista Game Engine が掲げる2つの指針に沿うことを常に念 頭に置いて、開発を進めています。 一つはハードウェアが最大のパフォーマンスを発揮できることです。 オープンワールドゲームを前提とした設計で、継続的に最適化を行っています。 我々のゲームの要求を満たしつつ処理負荷が可能な限り低減できる実装を選択しています。 もう一つは開発者が最大のパフォーマンスを発揮できることです。 ベイクや事前データの準備を極力減らし、ランタイムでのリアルタイム実行を推進してい ます。 1つめの指針を満たすために、最終的にはベイクするデータも増えると思いますが、少なく とも開発の途上においては生産性をより重視しています。 また、実装する機能仕様の策定にあたっては、機能の利便性、実行速度、メンテナンスの ためのシンプルさ、の3つのバランスを、注意深く取っています。 そして我々のチームにとってトータルで最適なエンジンとなるように、アーティスト、プ ランナー、エンジニアでコミュニケーションを密に取りながら開発を進めています。 79
82. 80/82 最高のエンジンで最高のゲームを 改善が必要な点も、導入したい最新技術も、尽きることはありませんが、チーム一同、最 高のエンジン、最高のゲームを目指して、日々開発にあたっています。 本セッションは以上となります。 ご清聴ありがとうございました。 80
83. References 81/82 [TAG17] 多胡 順司. Cygamesにおける次世代ハイエンドコンソール向けゲームエンジンの開発 ～最高のコンテンツを支えるゲームエンジン～. CEDEC2017 https://tech.cygames.co.jp/archives/3043/ [OKI20] 沖 幸太朗. Python による大規模ゲーム開発環境 ～Cyllista Game Engine 開発事例～. CEDEC2020 https://tech.cygames.co.jp/archives/3442/ [MOOR18] Jeremy Moore. Terrain Rendering in ’Far Cry 5’. GDC2018 https://www.gdcvault.com/play/1025480/Terrain-Rendering-in-Far-Cry [WEMA17] Guillaume Werle, Benoit Martinez. ‘Ghost Recon Wildlands’: Terrain Tools and Technology. GDC2017 https://www.gdcvault.com/play/1024029/-Ghost-Recon-Wildlands-Terrain [WID12] Mattias Widmark. Terrain in Battlefield 3: A Modern, Complete and Scalable System. GDC2021 https://www.gdcvault.com/play/1015676/Terrain-in-Battlefield-3-A [GOL17] Ben Golus. Normal Mapping for a Triplanar Shader. https://bgolus.medium.com/normal-mapping-for-a-triplanar-shader-10bf39dca05a [QUI20] Inigo Quilez. Biplanar Mapping. https://iquilezles.org/www/articles/biplanar/biplanar.htm [WYMC17] Chris Wyman, Morgan McGuire. Hashed Alpha Testing. I3D2017 https://casual-effects.com/research/Wyman2017Hashed/index.html 81
84. References 82/82 [HOOK21] JT Hooker. Boots on the Ground: The Terrain of 'Call of Duty’. GDC2021 https://www.gdcvault.com/play/1027463/Advanced-Graphics-Summit-Boots-on [WOH21] Eric Wohllaib. Procedural Grass in 'Ghost of Tsushima. GDC2021 https://www.gdcvault.com/play/1027214/Advanced-Graphics-Summit-Procedural-Grass [MUI17] GPU-based Procedural Placement in Horizon Zero Dawn. GDC2017 https://www.guerrilla-games.com/read/gpu-based-procedural-placement-in-horizon-zero-dawn [HAHO11] Takahiro Harada, Lee Howes. Introduction to GPU Radix Sort. http://www.heterogeneouscompute.org/wordpress/wp-content/uploads/2011/06/RadixSort.pdf [BRU18] Ryan Brucks. Octahedral Impostors. https://shaderbits.com/blog/octahedral-impostors 82