エンジン上でのライブペイントツールの作成とその取り組み

エンジン上での ライブペイントツールの作成と その取り組み ©CAPCOM 1

はじめに ゲームエンジン上でのテクスチャペイントツール • ビジュアルの調節作業を大幅に効率化させることが可能 「ゲームエンジンの上からテクスチャを塗れる」といった機能は様々な価値を生み出せます。 例えば、このような感じで地上の配置物をレイアウトしたとして、その上から材質の塗り分けを行うまでの一連の作業を 2 シームレスに行えるようになるとしたらいかがでしょうか？ このようにゲームエンジンは、ゲームの最終的なビジュアルが確認できる唯一無二の開発環境であり、そこでペイントを行えること は主に景観のブラッシュアップ作業で大きな意味を持つことになります。 ©CAPCOM 2

はじめに エンジンでテクスチャペイントを作る上で欠かせない視点 テクスチャはエンジンでなくても作れること エンジンでペイントするという結論に至る前には 多くのDCCソフトウェアの選択肢が並んでいる エンジンのペイントツールに求められている要件は 単にリッチなテクスチャを作れるだけではない ただし、このようなツールを作るにあたって欠かせない視点があります。 それは！・・・テクスチャはエンジンじゃなくても作れるということです。 3 身も蓋もないのですが、事実としてエンジンでペイントするという結論に至る前には多くのDCCソフトウェアの選択肢が並んでいた ことを忘れてはいけません。 潤沢なデザイナーツールが提供されている現代において、ただリッチなテクスチャを作るだけならばそれらで事欠くことはないで しょう。 そのため、エンジンでペイントツールを作るにあたっては、その環境で動かすメリットに最大限フォーカスされた機能性を持つこと が求められます。 ©CAPCOM 3

はじめに 本講演では・・・ RE ENGINEのテクスチャペイントツールの実例をもとに • どんなことが出来ているか • どんな設計方針になっているか を紹介します 今回の主役 • RE ENGINEの汎用テクスチャペイントツール • プロトタイピング期間：約2カ月 本講演では、RE ENGINEでのテクスチャペイントツールの運用例をもとに、どのような機能を提供しているのかといった点と それらを満たすにあたってどのような設計方針になっているかといった実装の話、以上の２つのテーマを通して知見を共有していけ たらと考えています。 4 その前に今回の主役に関してもかるくご紹介させていただきます。 こちらにあるのがRE ENGINEの汎用テクスチャペイントツールであり主に基礎の設計には2カ月という期間で開発されたものとなっ ています。 まぁそこからアップデートを続けて現在の状態に至っているためこの辺りの時期感は目安として見ていただけますと幸いです。 ©CAPCOM 4

RE ENGINEのペイントで実現していること ではカジュアルな話題として、本ツールで提供している機能紹介を通じてエンジンペイントで出来ることを共有していけたらと思い ます。 5 ©CAPCOM 5

最終ルックという環境に特化したペイント いつでも、何にでも編集を開始することが出来る汎用性 • シーンの再生を問わずライブペイントを行える • 特殊なセットアップは不要 まずは前述の通り、最終ルックで確認できるという特徴は本ツールでも特に力を入れているポイントです。 例えば先ほどお見せした動画がございましたが、こちらは実はゲーム本編を再生中にペイントしている様子となっていました。 6 どういうことかというと、本ツールはペイントするにあたって編集対象をサンドボックス化しており様々な環境で堅牢に動くように なっています。 更には編集を行うための事前セットアップも要求しないため、シーンが再生状態であろうとなかろうと、気になった時にすぐ編集し てペイントし、そして編集が完了すれば塗っていたテクスチャは保存され、実行シーンで静的テクスチャとして仕上がりを確認する ことが出来ます。 このあたりはRE ENGINEの掲げるラピッドイテレーションとの親和性が高く、非常に高度なライブペイント機能を実現させることが 出来たポイントですね。 ©CAPCOM 6

最終ルックという環境に特化したペイント 複雑なシェーダ開発ほどエンジン上でイテレーションを組めると便利 チャンネルカラーによる レイヤー合成 フローマップの ペイント ノイズの重みを 利用した合成 また、最終ルックを確認しながら塗れるメリットはゲームの再生中にとどまりません。 先ほどご紹介させていただいたレイヤーペイントなどもそうですが、他にもフローマップであったり、ノイズの重みを利用したブレ 7 ンドなどなど・・・ シェーダが複雑になればなるほどそのデバッグや変更にあたって確認や調整したい部分は増えてしまうものです。 特に快適な編集環境を外部に設けようと思ったら2重保守は避けられず、イテレーションの上でもこれらをエンジン上で塗れること の価値は大きいと言えるでしょう。 ©CAPCOM 7

最終ルックという環境に特化したペイント 複数枚のテクスチャやマテリアルの同時編集も実現 これらを踏まえて本ツールではマテリアル編集機能との連携も強化させており、複数枚のテクスチャやマテリアルの横断的な編集を 行うことも可能となっています。 8 前述の通り、編集中のゲームオブジェクトはサンドボックス化されているため、実行シーンの上からもマテリアル情報の変更を即時 反映させることが出来、これによって、マテリアルのパラメータを実際に調節し、テクスチャを変更し、更にはその変更したテクス チャをペイントするといったことにかけてまで、一連の作業を非破壊的かつ一切中断することなく編集する仕組みを作りました。 ©CAPCOM 8

画枠に依存しないペイント 最終シーン編集という目的に耐えられる広範囲のメッシュへの対応 スキニングメッシュにも セカンダリUVにも Meshletにも また、最終ルックというシーンで使用されるからには、その塗る対象のメッシュも最終シーンの多様性に耐えうるものであることが 求められます。 例えばギミックなどの姿勢のついた対象を考慮するならSkinMeshに塗れたら便利ですよね。 9 他にも、シェーダが複雑であればあえてセカンダリUVへ塗りたいという要望も出てきますし、また、時代は変化し、昨今のトレンド としてはMeshletとなった対象物も増えてきています。 本ツールでは、それらのメッシュフォーマットに逐次対応しており、基本的に制限なく塗れる体制を整えています。 ©CAPCOM 9

画枠に依存しないペイント 対象や目的に合わせてブラシアライメントを切り替え可能 UV Spaceでも Screen Spaceでも Object Spaceでも また、当然メッシュのフォーマット以外に、最終ルックではその形状や規模も多種多様です。 そのためブラシアライメントも目的に合わせて幅広く選択肢を用意しています。 10 例えばUV上に直接塗るものや、スクリーンスペースに塗ってから物体に投影するといったもの、オブジェクトスペースに吸着するも のなどなどを一通り揃えており、そのすべてを、どのフォーマットのメッシュにも使用することが可能となっています。 ©CAPCOM 10

画枠に依存しないペイント いずれの組み合わせでもすべての合成ペイントをサポート 例えばFlowMapBlendの場合でも 平面でも 複雑曲面でも さらに、これらのフォーマットやアライメントのバリエーションに対して、ペイントの用意している合成アルゴリズムも全て依存関 係なく行えるようにしています。 11 例えばFlowmapのような特殊なブレンドモードの場合でもこの法則は適用され、これをテクスチャ座標系に直接塗っても、複雑曲面 に対してUV展開しながら塗っても、おなじアルゴリズムを適用することが可能な仕組みとなっています。 このように、フォーマットやブラシアライメントの存在にとらわれない汎用なペイントツールであるという点も重視しています。 ©CAPCOM 11

拡張機能との連携 実装するマテリアルによっては特別なツール機能が必要になる 普通のパレットで IDを塗るのは難しい・・・ 例）色で材質IDを管理しているマテリアル もちろん単純な機能の汎用化ではカバーできない領域もあります。 例えば以下のように、１枚のテクスチャの色で材質のIDを管理しているようなマテリアルを想像してください。 12 １マテリアルで様々な質感を出せるためこれは非常に便利ですが、肝心のテクスチャを普通のパレットで塗ることを考えると・・・ 少々厳しい作業環境なのではないでしょうか。 このように、作成されたマテリアルによっては、逆に目的に特化した機能を提供しなければならなくなることもあります。 ©CAPCOM 12

拡張機能との連携 単純な汎用化で対応できない部分はマクロとの連携でカバー マクロ：独自のバッチ処理だけでなく GUIを持ったツールも開発できる拡張機能（Python） マクロを使用して IDから色を設定できる 拡張パレットを実装 そんなときには、マクロ機能を利用してペイントを拡張するツールが作成可能です。 マクロとはRE ENGINEの拡張機能でありタイトルのエディタ上から様々なバッチ処理だけでなく簡易なツールを作ることも可能な機 13 能となっています。 マクロからは本ツールにアクセスすることも可能となっているため、目的にあわせた機能を、独自に追加することが出来るわけです。 今回の場合は、材質を選択することで対応したIDの色を選択できるツールをマクロで作成しました。 色から材質を選ぶのではなく、材質のボタンを押して色を設定できる方が直感的ですね。 ©CAPCOM 13

拡張機能との連携 単純な汎用化でカバーできない部分はマクロとの連携でカバー エンジン上で完結した マテリアルワークフローを作れる ▶タイトル主導でこれらを行える 例）地形材質用のペイント拡張ツール（BIOHAZARD RE:4 ） こちらのツールはBIOHAZARD RE:4で使用されたものであり、実際に使用している様子がこちらのようになります。 ごらんのとおり、インタラクティブな部分はペイントツールの共通機能を使用したまま、目的の独自パレットだけマクロで拡張させ 14 られているのがお分かりいただけるかと思います。 この仕様をツールの機能として実装することは可能ですが、注目すべきはエンジン上で完結したマテリアルワークフローを作れる点 にあります。 言い換えれば、実装をタイトル主導で行えるということであり、これは仕様変更に対して柔軟に対応出来たり 協力企業と作業を行う上でも、専用ツールを介してスムーズに工程が共有できることを意味しています。 また、特化した機能を詰め込みすぎてエンジンのツールが過度に複雑化することも防ぐ上でも役に立つでしょう。 ©CAPCOM 14

他エディタへの組み込み 塗るという機能を様々な目的に転用しやすくしている １．作業の省略がしやすい ▶ペイントツールの当たり前を揃えたところ から開発がスタート出来る ２．作業の分担がしやすい ▶ツールとコア実装で作業分担がやりやすい 例）Shellfurのグルーミングツール さて、ここまではエンジンの上からペイントツールを触って得られるメリットとなりましたが、実際にエンジン上にペイントツール の実装コードがあればそれを拡張させて他のエディタに組み込むことも可能となってきます。 15 実際に本ツールの内部処理は他のエディタ向けにも拡張して使用することが考慮された設計となっており、例えば、今回のRE:2023 の講演「レンダリング新機能ダイジェスト」にて紹介されているShellfurのグルーミングツールも本ツール派生のエディタの１例と なっています。 このように既存のペイントツールの拡張でエディタを作るとメリットがいくつかあり、大きなものを挙げるとこのような感じです。 まず１点目としてはショートカット、ヒストリーや保存といったペイントに関する「あたりまえ」が実装されたところから開発を始 められる点です。 これが非常に見落としがちなポイントなのですが、このペイントにおける「あたりまえ」というものは結構多くあり、そこの議論が 省略されるとことで本来の目的に必要な機能に要望が集中しやすくなるという点は単純に工数を削減する以上に重要な要素となって きます。 ©CAPCOM 15

他エディタへの組み込み 塗るという機能を様々な目的に転用しやすくしている １．作業の省略がしやすい ▶ペイントツールの当たり前を揃えたところ から開発がスタート出来る ２．作業の分担がしやすい ▶ツールとコア実装で作業分担がやりやすい 例）Shellfurのグルーミングツール またもう一点挙げると、編集対象にテクスチャという汎用なアセットを介することでツールとコアの実装が分離され、互いの実装を 阻害しにくいといった点が挙げられます。 16 こちらも逆に言えば開発が大規模化しても双方の待ちになりにくくユーザビリティに関して十分な期間をもって開発にあたれました。 このように、ペイントツールのコード転用に関しては工数のショートカットだけでなくよりエディタの高機能化を実現するための手 段としても有効となるわけです。 ©CAPCOM 16

実装にあたっての注意点 とはいえエンジン上でペイントツールを作る際には幾つか注意すべき点があるため実際に作成する際に突き当たった課題やその解決 に関して触れていきましょう。 17 ここからちょっとだけ実装寄りのお話になります。 ©CAPCOM 17

実装にあたっての注意点 ペイントツールはアセットに間接的にしか関与しない テクスチャ メッシュ 汎用性と機能追加で起こる「組み合わせ爆発」を防がなければいけない ▶この２つの特徴をどう分けるかが重要 では、実装するにあたりペイントツールにはある一つの特殊事情があることを共有しておかなければいけません。 それは、扱うアセット全てに間接的にしか関与できない点です。 18 ペイントに関与するアセットを挙げさせていただきますと支持体であるテクスチャと、画枠であるメッシュがあるわけですが どちらもペイントツールからランタイム上でのふるまいの変化を制御出来ず外的要因によりさまざまな最適化が行われ続けます。 ここで発生する最大の懸念が汎用性と機能追加の組み合わせ爆発となります。 最終ルックを調節できるというメリットは、同時に実行シーンに近い状態のアセットを対象に塗らなければならないという足かせでもあり、 ペイントツールでは汎用性への対応コストはとりわけ無視できない要素です。 一方でツールとしても当然機能性は伸ばしていきたいところですが、これらを作っていくにあたって、汎用性への対応が重荷となってしまうと、 本来のポテンシャルを損ないかねません。 だからこそ、外的要因で増え続けるサポートコストと機能を増やすときの実装箇所を如何に分離できるかが重要なポイントとなってきます。 それでは先ほど挙げたテクスチャとメッシュで、それぞれ対策を考えていきましょう。 ©CAPCOM 18

テクスチャの対応方針 パーサしてバイナリデータにするところから完全に迂回する ネイティブデータ テクスチャアセット 可逆変換を意識した 共通フォーマットの テクスチャバイナリに変換 従来のコンバートフロー BC圧縮など非可逆の問題が発生するため そもそもペイントでは使用しにくい まずはテクスチャの問題から見ていきます。 本来のエンジンでもテクスチャを読み込んでシェーダリソースに変えるコンバートフローを持っているのですが 19 従来フローでネイティブデータ化されたテクスチャは最適化のためBC圧縮などの非可逆的な処理がされており、ランタイム上にある 情報だけでペイントですることが難しいといった問題が発生しています。 こちらに関してはパーサの段階から迂回して共通フォーマットのテクスチャバイナリとしてツールに読み込んでいます。 力技ですがこれで独自バイナリに変換するので以後はテクスチャ本来のフォーマットや最適化を意識する必要を排除することが出来 ます。 ©CAPCOM 19

メッシュの対応方針 メッシュ依存はレンダリングパイプラインを使用して切り分け • ジオメトリシェーダ以前と以後で処理を分離する ここからは全メッシュで共通 頂点 シェーダ ジオメトリ シェーダ ピクセル シェーダ 実現したい ペイント処理 （Pick、投影、デバッグ描画など） 一方でメッシュの方はまた少し事情が異なり特に直接的な編集対象ではないという点は無視できないでしょう。 これには悪い面と良い面があり、悪い面を言えば変形などを考慮し始めればランタイム上のメッシュデータを直接扱わなければなら 20 ない点であり 逆に良い面としてはテクスチャのように可逆性を担保してまで全体の入出力を迂回する必要もないという点です。 本ツールではレンダリングパイプラインによる汎用化を利用することでメッシュの違いを吸収するという戦略を取っています。 ベーシックな手段だとは思いますが、あえて説明すると新しいメッシュのフォーマットに対応したくなった際には、まず頂点シェー ダまでとりあえず頑張って実装し、残りは共通処理で実行することで対応コストを抑えようという考え方となります。 これはスキンメッシュであれば事前にコンピュートシェーダで必要な情報を収集しておくといった事前処理を含んだりするので見た 目ほどスマートな設計が出来るわけでは無いです。 ただ、こうすれば新しいフォーマットが増えた場合とペイントに新しい機能を追加するときの対応を分離することが出来るのでメッ シュ依存を切り分けられるのが嬉しいポイントです。 ©CAPCOM 20

ペイント処理の流れ ただ、一言でペイントといっても様々なシェーダ処理の組み合わさったものです。 これらが無秩序に混在してしまうとせっかく立てた切り分けの戦略も上手く機能しなくなってしまいます。 ペイントの処理フローを見ることも重要な視点となります。 ©CAPCOM 21 21

ペイント処理の流れ 処理フェーズが以下の３つに分離 Pick ブラシマップの作製 合成 本ツールの場合では主に塗るという処理を以下の３つにフェーズを分離しています。 それでは一つづつ紹介していきましょう。 22 ©CAPCOM 22

編集対象のPick まずはブラシを置くところから・・・ Pick：マウスカーソルの上にある情報を取得すること Pick ブラシマップの作製 合成 まずはPickです。 Pickという処理に関してざっくり認識を共有させていただきますが、マウスカーソルやペンタブのポインタの上にある情報を取得す 23 ることを指します。 塗る前に、まずどこを塗ればいいのか分かるところから始めないといけないですよね。 ©CAPCOM 23

編集対象のPick レンダリングパイプラインで実装できるPick処理 • ピクセルシェーダを利用して衝突判定を取る 目的座標の描画が実行されたら GPUバッファに書き込み （ピクセルシェーダ） Pick用シェーダを走らせる Pick完了（ブラシ座標確定） 見ての通り、こちらの処理はメッシュのフォーマットに大きく依存します。 そのため、レンダリングパイプラインを用いてPickを行えると嬉しいです。 レンダリングパイプラインを用いたPick処理の基本的なアイデアとしては次のような感じです。 24 まずこちらのようにPick用シェーダを走らせてみましょう。 そうすると、もしマウスやペンタブといったポインターが塗りたいメッシュの上に存在している場合、そのスクリーン座標上で実行 されるピクセルシェーダが最低１つは存在することになります。 そのため、それぞれのピクセルシェーダで描画座標がポインターの座標と一致するかどうかを比較し、そして、一致していればGPU バッファに今持っているセマンティクスの情報を書き込みます。 あとはそのGPUバッファを読み込めばPick成功という流れです。 ©CAPCOM 24

編集対象のPick レンダリングパイプラインで実装できるPick処理 • このままだと重なる面で複数回Pickが走ってしまう ここをPickする場合 カメラ座標上で 複数回ピクセルシェーダが実行される しかし残念なことに、こういったアイデアはそう簡単には通用しないものです。 このまま実装してしまうと、面が重なる場所ではピクセルシェーダが複数回走ってしまい、実際のPickの結果は不安定となってしま 25 います。 ピクセルシェーダは並列に実行されるので、構造体として最前面の情報を取得しようとすれば少しだけ工夫が必要です。 ©CAPCOM 25

編集対象のPick レンダリングパイプラインで実装できるPick処理 • このままだと重なる面で複数回Pickが走ってしまう • 事前にDepthを用意し、Early Zで処理が簡略化できる 事前にDepthを取得 Early Zで 同処理を実装 Early Z ピクセルシェーダの実行前に 深度テストを行う機能 曖昧性のあったピクセルシェーダを 事前カリング可能 本ツールではDepthを事前取得しておき、Early ZでPick用シェーダを描画することで回避しています。 Early Zとはピクセルシェーダの実行前に深度テストを行うGPU機能で主にピクセルシェーダの負荷を下げるために使用されるもので 26 すが、深度負けしたピクセルシェーダを実行しないという特徴は今回の目的を解決する上でとても都合がいいですよね。 こうすることで最前面以下のピクセルシェーダが全てカリング対象となり、その結果Pickを安定させることが可能となります。 先にDepthを取得するということのコストに関してですが、塗っているテクスチャのハイライトやブラシカーソル等といったデバッ グ描画により結果的にカリングが必要になってくるので相殺することも可能です。 ©CAPCOM 26

ブラシマップの作製 そのまま合成する前に・・・ ブラシマップ ブラシの衝突情報をラスタライズしたもの Pick ブラシマップの作製 合成 さて、続きましてブラシマップの作製を行います。 前工程でPickを行い、その情報からUV座標が取得出来たのであれば、そのままテクスチャをターゲットステートとして扱い、ブラシ 27 テクスチャをラスタライズすれば確かにペイントは可能です。 ただ、本ツールではそれらを行う前にブラシの衝突情報をブラシマップという専用のリソースビューに焼き付けています。 本工程はそのブラシマップを作製するフェーズとなります。 ©CAPCOM 27

ブラシマップの作製 ツール要件に応えていくと結果的に中間バッファがあると便利 コンピューティング的には 正しいペイント もちろんこの工程をスキップして直接合成を行うことは可能ですが、実際にツールの機能性を担保する上ではここでやっておくべき 処理が結構出てきます。 28 具体例を挙げてみましょう。 以下にコンピューティング的には正しいペイントの例を示しました。 この処理結果、確かに「塗る」という要件に関しては、正しい計算で行われたものですし、実際に最終結果としてこのような処理が 要求されるシーンも多いでしょう。 ですが、実際に多くのペイントツールを見ると、もう少し異なる動きをしていることが分かるかと思います。 ©CAPCOM 28

ブラシマップの作製 ツール要件に応えていくと結果的に中間バッファがあると便利 コンピューティング的には 正しいペイント ツール挙動として 求められているペイント 比べてみたら分かるように、実際にはより塗りムラが少なく、単純なアルファの０～１よりもその間を塗ることに長けた挙動を実現 させる必要があります。 塗りムラは時に良い味を提供してくれるものですが、狙って出せなければツールとしては意味がありません。 29 このように、シミュレーションではなくツールとして見た際、ペイントに要求される挙動にはまた異なる精密さが求められるわけで す。 これらの挙動を実現するために幾つか処理が必要です。 代表例をいくつか挙げていきましょう。 ©CAPCOM 29

ブラシマップの作製 ムラの無いペイントのために・・・「点列情報の中割り」 • これをしないとフレームレートで塗る濃さが変わってしまう コレではだめで こうあるべき！ 1フレームに行われる分だけ 「中割り」した結果が必要 まずはムラのないペイントをするために必要な処理としてスタンプの中割り処理が挙げられます。 なぜなら、こちらのように現状の１フレーム１スタンプだと、スタンプの密度が細かい際にフレームレートで塗る色の濃さが変わっ てしまいます。 30 この問題を解決するためにはこのように移動距離に伴う点列の中割りが必要です。 このように１フレーム内で行われているスタンプの合成結果が全部描画されないとだめですよね。 本ツールでは、コンピュートシェーダで座標を補完した後、インダイレクト描画を用いて一括ラスタライズすることで高速に処理し ています。 ©CAPCOM 30

ブラシマップの作製 重ね書きしやすいペイントのために「ストロークマップへの統合」 1フレームの 処理結果を統合して 1ストローク分の 処理結果を作る 次に調節しやすいペイントの概念として、ストロークマップへの統合も重要です。 処理としてはこのように１ストローク、要するにマウスを押して離すまでの合成結果を複製した更に別のリソースビューに合成し続 31 けています。 これにより、１回のストローク中で塗れる量の上限値を設定することが出来るため、より重ね塗りがしやすくなります。 １ストローク分の情報を保持するために別のリソースビューの用意が必要となるので、ブラシマップ作製を独立したフェーズにした からこそ、このようにして実装できる処理となります。 ©CAPCOM 31

編集対象に合成 ブラシマップと編集元テクスチャの合成を行う Pick ブラシマップの作製 合成 さて、前項でブラシマップを作製できたため、そのブラシマップを用いて、乗算、加算といった色の合成ルールをもとに編集対象に ブレンドしていきましょう。 32 ©CAPCOM 32

編集対象に合成 ここを切り替えるだけで様々な合成処理を実現できる • 乗算、加算、減算、ベクトルとして正規化して合成 • ブラシマップを別処理にした影響で合成は１ch 乗算ブレンド フローマップブレンド （ブラシマップとストローク方向ベクトルの合成） こちらは基本的にコンピュートシェーダを用いており、編集元のテクスチャとブラシマップを合成します。 このペイント処理フローの弱点としてブラシマップ作製が分離されたフェーズとなっているため、合成元のテクスチャが１ｃｈに限 33 定されてしまうという問題があります。 具体的にどんな制約が発生しているかというと、ブラシテクスチャそのものに色を付けるといった合成処理が不可能となっています。 しかしその代わり、こちらの処理は他のフェーズから完全に切り離して考えることが可能であり、ブレンド処理を増やすときに考慮 する実装を１か所に抑えることが可能です。 また、前述した問題を除けば、1chだとしても付与情報との組み合わせが出来るため、右図のようなフローマップブレンドなども問 題なく行うことが可能です。 出来ることが制限されてしまうのは勿体ないですが、最初に言ったように直接色を塗るような目的であればDCCソフトウェアに優れ たものがたくさんあるため、ここでは張り合わずにエンジンペイントのユースケースを活かした設計を目指しこの方針を選ばせてい ただきました。 ©CAPCOM 33

UV展開への対応 この構成では複雑にUＶ展開されたメッシュを塗ることは難しい Pick ブラシマップの作製 合成 さて、Pickしてから塗るまで網羅してきたわけですが、このままでは複雑なUV展開がされたメッシュのペイント結果はあまり芳しい ものではありません。 34 実際にこれらを綺麗に塗る上ではもうひと手間が必要となります。 ©CAPCOM 34

UV展開への対応 UV展開された空間にブラシマップを転写する 複雑なUVをもったメッシュを塗ることが可能となる Pick ブラシマップの作製 UV展開への対応 合成 UV展開された ブラシマップ ということでUV展開への対応というフェーズを解説しましょう。 具体的には直前のブラシマップ作製の段階でメッシュのUV空間に転写するという作業を行っていきます。 こちらのフェーズが独立しているというよりはブラシマップ作製を拡張するようなイメージですね。 ©CAPCOM 35 35

UV展開への対応 このフェーズが無くてもペイントで一定の価値を示せる この工程なくして 複雑UVを塗るのは不可能だが・・・ 地続きなUVを塗る範囲では そこまで必要な概念ではない さて、この工程を最初から追加しなかった理由ですが、端的に言ってこれが無くてもペイントエディタとしての要件はおおむね満たせるか らです。 36 確かにこの工程を無視して複雑なUVに塗った結果は前述のとおり散々なものです。 しかし、レイアウト作業などで用いるメッシュを対象とする場合、それらは大抵地続きであり、シームの問題が顕在化しにくい点には触れ ておかなくてはなりません。 思い出してほしいのは、エンジンでのライブペイントが作り出せる価値というものはDCCに出来ないワークフローを実現できることにあり ます。 その点を考えたら単純に複雑なUVを塗れるという特徴は技術的な面白さに比べてかならずしもインパクトが比例しないという点が否めず、 さらに、この工程を削るかどうかはブラシマップ作製のフェーズにメッシュ依存の処理が混ざるか混ざらないかの分岐点にもなってきます。 コスト対効果を狙ったら複雑なUVペイントをサポートしないという戦略には理があるでしょう本エディタでもこの機能は初期段階ではサ ポートしておらず、あとから構築したものとなります。 ©CAPCOM 36

UV展開への対応 メッシュに依存するから・・・ レンダリングパイプラインで実装できるUV転写 こうなるはずのメッシュを ジオメトリシェーダで 位置とUVを入れ替え ピクセルシェーダで ブラシマップ合成 一方で、複雑なUVを塗れることで出来ることは確実に増加します。 例えば前述したグルーミングツールなどに代表されますが、複雑曲面を塗れると対象をプロップスやキャラクターまで広げることが 37 可能になり、対応することによって初めて実現の見通しが立つツールやワークフローも多いです。 ということでUVペイントの具体的な実装も説明させていただきたいと思います。 もう説明不要かと思いますがこちらの工程はメッシュ依存そのものです。 そのため、全体的にレンダリングパイプラインで何とか実現させていきましょう。 大まかに説明すると以下の通りで、ジオメトリシェーダで頂点位置とUVを入れ替えて、ピクセルシェーダでブラシマップの最終合成 を行うといった処理を行っていきます。 ©CAPCOM 37

UV展開への対応 ここでの合成方法で若干挙動が変化する スクリーンスペース オブジェクトスペース ここでの合成方法なのですが複数ありまして、前述していたブラシアライメントのスクリーンスペースとオブジェクトスペースはこ ちらで分岐しています。 38 どちらにも得手不得手があるので実装方法も踏まえて簡潔に説明してみます。 ©CAPCOM 38

UV展開への対応 スクリーンスペース合成 • 既存のブラシマップ＋アルファで実装する ブラシマップを スクリーンスペース に描画し UV空間に 転写 シャドウアクネと同じ アーティファクトが発生 まずはスクリーンスペース合成から見ていきましょう。 こちらはスクリーンと縦横比が同じ画像にブラシマップを通常通りラスタライズし、それとデプスマップの交差判定を取ることでUV に転写する合成方法です。 39 既存のブラシマップ作製処理にプラスアルファで実装できるため実装を拡張しやすく、アルゴリズムにおいてはシャドウマップとお よそ同じものが使用可能となります。 ただ、塗り余りが起きやすいのと、アルゴリズムがシャドウと同じだけのこともあり、アーティファクトもシャドウと同じ問題が発 生し、それらを抑える処理も必要となります。 ©CAPCOM 39

UV展開への対応 オブジェクトスペース合成 • ラスタライズにあたる部分を置き換える ブラシマップ段階で 交差判定を行う 限界角を塗っても 綺麗に処理してくれる もう一方がオブジェクトスペース合成ですね。 実装としては、ラスタライズにあたる処理をそのまま置き換える形となっており、ブラシの中割情報とピクセルシェーダで取得でき たワールド座標の距離で交差しています。 40 スクリーンスペースに比べて入り組んだ曲面を塗るのに適したペイント方法となっていまして、良くも悪くも深度で比較しないので 境界を塗った時のアーティファクトも目立ちにくいのが特徴です。 ©CAPCOM 40

UV展開への対応 これだけだとシーム（UV境界）を塗れない 求められる実装 : シームからの塗り広げ （エッジパディング） １．UVの島より 外側が塗られること ２．ただし・・・ 隣のUVまで 侵入しないこと シームを塗りきることが出来ない さて、UV転写が終わり、これだけで済めばよいのですがそうは問屋が卸しません。 このままだとUVの縫い目、要するにシーム上を塗りきることが出来ず、こちらのように塗り余りが発生してしまいます。 41 こちらはラスタライズ精度に問題があるというよりはMipmapやバイリニアフィルタなどのテクスチャのサンプル手段から来るもの が主原因であり、UV転写の工夫では解決しません。 そのためさらにひと手間が必要となります。 具体的に言えば、UVの島からペイントが侵食してくれる必要があります。 ここではそれをエッジパディングと呼ばせていただきます。 エッジパディングに求められる要件を挙げてみると以下の2点が挙げられます。 １つ目はUVの島の外側に任意ピクセル分ペイントが侵食すること。 ２つ目はその伸ばしたパディングが隣の島の領域に侵入しないことです。 ©CAPCOM 41

UV展開への対応 レンダリングパイプラインで実装できるエッジパディング処理 • ジオメトリシェーダでポリゴン毎にパディングを貼っていく 1トリゴン毎に パディングを生成 深度で 切り捨て 実際の実行結果 ではエッジパディングを作っていきましょう。 UV投影と同じくこちらもメッシュ依存なのでレンダリングパイプラインで解決させていきましょう。 42 実装の基礎的なアイデアを共有するとこんな感じです。 まずジオメトリシェーダを用いて全トリゴンに対してポリゴンを伸ばし、これを深度で切り捨てることで島同士の干渉を防ぎます。 それを行った結果が右のようになり、目的通りエッジパディングの構築に成功しているのが見て取れるかと思います。 ©CAPCOM 42

UV展開への対応 レンダリングパイプラインで実装できるエッジパディング処理 • いくつか条件が揃えば問題点が目立ちにくいエッジパディングが作成可能 全パディングが平行に沈み込んでいること パディングの伸長方向を４方向に拘束すること まぁさすがにここまで問題はシンプルではなく、何も考えずに等方向に伸ばすと各トリゴンから伸ばしたパディングが互いに突き抜 けあってあまり上手く行かないです。 ここではいくつか条件を加えることでアーティファクトが目立たないパディングが作成できます。 43 本ツールでは主に２つを制約としています。 １つめは全パディングを平行に沈み込ませることで、２つめはパディングの伸長方向を傾き１の４方向いずれかのベクトルに拘束す ることです。 こうすることで頂点から出るすべてのエッジの傾きが１となり、パディングの伸長距離をピクセル単位で指定できるようになるだけ でなく角度の差で内側のポリゴンからパディングが突き抜けるという条件をなくせるためパディングの品質が向上します。 計算も三角形の内角は180度を超えないため、辺の垂線ベクトルのSignを取るといったシンプルな実装でパディング伸長方向を分散 させることが出来ます。 例外としてUV空間に対し水平垂直な辺だとSignではこの値は正しく出せませんが、その時は重心から頂点へのベクトル符号も組み合 わせるなどでも解決できるでしょう。 ©CAPCOM 43

UV展開への対応 今度こそOK！ これらの処理を入れてみた結果がこちらのようになります。 シームに関しても特に問題なく塗れるようになったのがお分かりいただけるかと思います。 44 ©CAPCOM 44

まとめ ゲームエンジン上でのペイントツールが出せる価値 • ビジュアルのブラッシュアップにおける効率の改善 • 他のツールとの連携によるワークフローの拡張 実装における課題 • 汎用性と機能追加の組み合わせ爆発への対策 • 依存性のある処理を如何に分割するかがペイントツールのポテンシャルを決める ご清聴ありがとうございました はい、それではまとめは以下のようになります。 ご清聴いただきありがとうございました。 45 ©CAPCOM 45