次世代 NPR の輪郭線表現に迫る！リアルタイムベクトルストローク生成手法 StrokeGen を徹底解剖

Editor's Notes

• #1: 本日はお集まりいただきありがとうございます 「次世代NPRの輪郭線表現に迫る！リアルタイムベクトル生成手法StrokeGenを徹底解剖」と題しましてシリコンスタジオ株式会社川口が発表を始めさせていただきます 本日の講演は写真撮影・SNS OKです 資料も後日 CEDiL および弊社ホームページで公開いたします
• #2: 簡単な自己紹介です シリコンスタジオ株式会社の研究開発室に所属する川口龍樹と申します 2017年に入社してから、NPRフォトリアル問わずリアルタイムレンダリングに関する技術の研究開発に取り組んでいます それではよろしくお願いします
• #3: 今回紹介する StrokeGen ですが、これは “GPU-Driven Real-Time Mesh Contour Vectorization” という 2022年のユーログラフィクスで発表された論文の Unity 上でのプロトタイプ実装の名称になります 元のタイトルは長いので論文自体も含めて StrokeGen と呼ばせてください 論文から抜粋すると従来のオフラインのベクトル化手法よりも最大800倍高速で、 フルHD30万ポリゴンを1msで処理できるとしています 本公演ではこの StrokeGen について紹介します そして StrokeGen が、講演のタイトルにあるような、次世代のゲームNPRにおける輪郭線描画手法となり得るのかを考察してみたいと思います
• #4: 本日の講演の流れになります まず手法が用いる輪郭線という言葉について少し議論を行います 次に StrokeGen の概要とアルゴリズムの解説、 結果の紹介を行います 最後に課題と今後の展望についてお話しします
• #5: では StrokeGen の話を行う前に輪郭線について少し議論をしたいと思います
• #6: 輪郭線はその名の通り物体の輪郭の形状を表す線を意味します 英語では Contour もしくは Outline という単語で表されることが多いと思います 古めの論文だと近しい概念を指してシルエットラインという言葉も見かけます 日本語でアウトラインというと輪郭線とは違う印象を受ける方も居るかもしれません この絵が示す線をみて、一番外周だけを輪郭線ということもあれば、 内側の線も含めて輪郭線ということもありますし、区別してアウトラインという人もいると思います これら輪郭線をめぐる用語は、文脈や現場によって微妙に違うものを示しながら使われています StrokeGen が扱う輪郭線は Mesh Contour という用語を定義してそれに基づいています ですが本公演においては輪郭線をめぐる用語について、統一された認識を共有することが難しいこともあり、厳密に区別していない点ご了承ください
• #7: さて輪郭線に限らず「線」を表す言葉はたくさんあります ライン、というとあらゆる線を表します エッジ、鋭い形状に基づいた辺を表す言葉で直訳では線にはなりません が、画像処理で Edge detection は輪郭線抽出をですし、ジオメトリを構成する頂点を結ぶ線をエッジと呼ぶように、 CGにおいては線のニュアンスを多く含んでいます ストロークは、線そのものというよりは、線を描く動きや軌跡のニュアンスを含む言葉です 本公演のタイトルにも含まれる「ベクトルストローク」は輪郭線を構成する一本一本の線で、 その始点と終点への繋がりを持った点列としてのベクトルデータを示します ベクトルデータで表される線というとスプラインのようなパラメトリックな曲線を示すことがありますが、今回扱うのはあくまでただの点列です
• #8: 輪郭線について手法によっての違いにも触れておきます まずイラストにおいては輪郭線という言葉はあまり使われないかもしれません 線のみで描かれたイラストを線画といい、その中に輪郭やそれ以外の線が混在しています イラストにおける線画は、輪郭線が輪郭形状を表す線であるというような、単なる形状の情報を示すだけのものではありません 線に強弱や色を付けたり、あえて形状を無視した線を描くことで、 奥行き・明るさ・動きなど作者が表現したい効果を線画に仕込むテクニックが幅広く使われています もちろん、テクニックに限らず筆圧や手ぶれによって線画に、味が付いていることも多いです このイラストは一エンジニアの私が適当に描いたもので、アート的な意図は大して含んでいませんが、 右の均一で無機質な線に比べて、左の演出の付いた線からは、何かしらの形状以外の光や奥行きのようなニュアンスを感じ取ることができるかもしれません これらは単純にルール化出来るものではなく作者の画風やノウハウなどに基づいて様々な手法が採られており、 ゲームやアニメの輪郭線もこのイラストのような味のある線を目指している側面もあると思います
• #9: ゲームにおいても輪郭線は重要な要素になっています 特にノンフォト系のタイトルでは非常によく使われていて、先述のイラストにおける線画のような味のある輪郭線表現を目指していることも、どれほど実現できているかはさておいて、多いでしょう ゲームの輪郭線は大別して二種類、押し出し法・反転法と呼ばれるようなジオメトリベースものと、ソーベルフィルタなどを使う画像処理ベースのものがあります またジオメトリを配置したりテクスチャに線を書き込むのも一種の輪郭線表現に含むかもしれません これらの手法は実装が容易で処理が高速かつ結果に大きな破綻が生じにくいため、ゲームにおける NPR 表現の手法として幅広く利用されています しかしこれらは、繊細な線幅の制御を行ったり、元の形状からズレた線を描いたりすることが難しいため、均一で無機質な線になりやすく、イラストのような線の強弱やブレを含んだ線を描写する能力を有していません 押し出し法では折り目になった線を基本的には描画できないように、手法によって描けない種類の線があるといった制約も多いです 頂点カラーなどの仕込みで線に演出を付けることも多いです、表現の幅には限界があります 現在幅広く利用されていることからアニメ調の線を描くのに十分な能力を有しているとは言えますが、幅広い尖った NPR 表現を行うには能力不足な手法とも言えるかもしれません
• #10: 近年は全編フル3DCGのアニメも珍しくなく、オフラインのレンダリングでも輪郭線表現は非常によく使われています オフラインレンダリングでは輪郭線を描画するための時間的・画角的な制約がありません そのためフレーム単位のベクトルデータとして輪郭線を出力することができ、コンポの工程で線に多彩な演出を加えることができます そのためゲームでは見かけないような特徴的な線のカラーリングや動き、極端な強弱をもつアニメーションが作られています もちろん拘ればフレーム単位で調整してよりイラストのような味のある線を表現することも可能かもしれません しかしそもそもの作画のアニメでは、複数人のアニメーターが時間的に整合性のとれた線を描く必要があるため、3DCGでもそこから大きく外れた際だって特徴的な輪郭線を持つような絵を見かけることはあまりないと感じています
• #11: イラスト、ゲーム、アニメの輪郭線を、表現の自由度と動きがあるかどうかという二つの軸で見るとこのようになると思います まず表現の自由度で言うとイラストが圧倒的に自由度が高く、継いでアニメ、ゲームとなると思います 輪郭線に動きがあるという観点で見ると、イラストは動きませんしアニメは決まった動きしかありませんが、ゲームでは自由な視点・自由な挙動が許されています これは非常に雑な分類で輪郭線という事象についてもっと細かい事例で分類していくとそれだけで興味深い研究になりそうですが、 本題から外れますのでいったんこの分布であるとさせてください さて今回紹介する StrokeGen をこの分布に当てはめると、このあたりになるでしょうか StrokeGen はゲームで利用可能な輪郭線描画を、アニメやイラストの表現力に近づけることができる技術、又はその逆のアニメをゲームに近づける技術であると言えます 前置きが長くなりましたが、この StrokeGen、どのようなものなのか紹介していこうと思います
• #12: まずは StrokeGen の概要を説明します
• #13: 技術論文としての StrokeGen は、3Dメッシュから輪郭線のベクトルストロークをリアルタイム生成する手法を提案しています 論文のコントリビューション、つまり新規性としては まず従来 CPU でオフライン処理として行われていたベクトル化一連の処理をすべて並列化し、CPU-GPU 間のデータのやり取りを無くすことによるリアルタイム化を達成したことがあげられます StrokeGen によって生成されるベクトルストロークは繋がった点列のリストとして得られます ベクトルストロークなので表現としては 3DCG アニメの線に近しく、それをリアルタイムにできることが手法の一番の特徴です ベクトルデータをどのようにレンダリングするかは自由で、ドローイングソフトのようにパスに沿った筆のテクスチャを張ったり、 イラストソフトのようにブラシのテクスチャを連続したスタンプとして張ったりと、 今までのゲームにおける輪郭線では為し得なかった多彩な表現力を持っています
• #14: このリアルタイムベクトルストローク生成という技術に、 次世代のゲームの輪郭線表現としての可能性と魅力を感じ、 ここ1年ほど行ってきた調査内容を紹介したいと考えています 本公演では StrokeGen のアルゴリズム解説と結果紹介に加えて、 いくつか取り組んだ改造実装の説明、 そして StrokeGen が生成するベクトルストロークでどのような表現が可能なのか、検討したの結果を紹介していきます もちろんイラストのような多彩な線を表現するという点ではまだまだ課題は多いので、そのあたりの実用に向けた課題についての考察も行いました
• #15: これは論文中に紹介されている StrokeGen の結果の絵です 論文では動きやリアルタイム性は伝わりませんが、イラストソフト・ドローイングソフトのような多彩な線の表現が達成できることは分かります
• #16: さて StrokeGen における輪郭線の定義について触れておきます StrokeGen が扱うのは メッシュの輪郭線 Mesh Contour です これはある視点からオブジェクトを見たときに、そのエッジに着目して、 一つのエッジを共有する二つのフェイスが逆向きのとき、そのエッジは輪郭線である、という定義から得られます 輪郭線という言葉の範囲が広いので多少齟齬を感じる人もいるかもしれませんが、CGにおいてはわりと一般的な定義で古い論文等にもよく出て来ます メッシュを裏返して膨らませる、という押し出し法・反転法もこの定義における輪郭線を可視化していると言えます 偶然輪郭線に見えるからよく使われているというわけではないんですね
• #17: では StrokeGen の処理の流れについてまずは簡単に説明します StrokeGen の入力はゲームで使われるような三角形メッシュです これに対してプリプロセスで以降の処理に使うデータを始めに一度生成します 集めたデータに基づいて輪郭線となるエッジをラスタライズします ラスタライズされたピクセルは境界線を辿ることでループを作ることができ、ループから繋がった点列、つまりベクトルデータを抽出できます ベクトル化されたループはストロークとしては不十分な状態である為、最終的に描画したいストロークを抽出する処理を行います この時点で手法としての出力であるベクトルストロークが得られます ベクトルストロークの描画は任意とはなっていますが、公開実装である StrokeGen は描画まで一連の処理に組み込まれている為、その部分も含めて今回は紹介します
• #18: では StrokeGen アルゴリズムについて説明していきたいと思います 少し辛口のため、結果の絵に興味がある方はデモ・結果紹介まで少しお待ちください
• #19: 先ほど簡単に説明した StrokeGen の処理の流れを順に詳しく説明していこうと思います まずはプリプロセス、事前処理です 入力は輪郭線描画の対象とする単一スタティックメッシュで、出力は以降の処理で使う各種 GPU 用のバッファです 実行時に一度処理します ここで単一スタティックメッシュと言っているのは公開されている StrokeGen の仕様です 論文で紹介されているアルゴリズムの制約ではないため、後ほどアニメーションの対応する為の改造について紹介します 必要な情報は、頂点座標、三角形を作る頂点のインデックス、エッジを作る頂点のインデックス、一つのエッジを共有する2面の組のインデックス、頂点の法線、面の法線です Vpなどと書いているのは論文や実装内でつかわれている略称で、今回は示す意味がありませんが参考までに書いています 基本的に描画に使う頂点バッファとインデックスバッファの中身をそのまま取り出すだけで、実装方法によってはわざわざ別バッファとして取り出す必要は無いかも知れませんが、StrokeGenではこのような実装になっているのでそのまま紹介します 特殊なデータとしてはエッジ面インデックスとある、隣接面の情報で、これは普通は頂点バッファ等には保持されていないので、自分で計算してあげる必要があります 隣接情報の計算は軽い処理ではありませんが、アニメーション対応したとしても、メッシュトポロジーが変わるようなアニメーションで無ければ、一度計算するだけで大丈夫です
• #20: 前処理として動的な更新が必要な情報もあります それが面の向きと、面の向きから計算される輪郭エッジです スタティックメッシュであってもカメラは動きうるので毎フレーム処理します 面の向きは、各面について、現在の視点の向きと面の法線から表裏の向きを計算します 次に各エッジ毎に、その二つの隣接面の向きを見て、 表裏異なるものが、メッシュ輪郭線の定義に該当するので輪郭エッジとして保存します
• #21: 必要な情報を取り出せたら、ラスタライズの工程に移ります 入力は先ほど求めた輪郭エッジ、それに並列化ブレゼンハムのアルゴリズムを適用して、輪郭エッジのフラグメント、つまりピクセルを出力します 並列化ブレゼンハムは、線のラスタライズアルゴリズムとしてよく知られるブレゼンハムを並列化した手法です まず、入力の輪郭エッジの一方を始点、もう一方を終点としたとき、 そのスクリーン座標とラスタライズの解像度から、いくつのフラグメントで線が描かれるか数えるカウンティングパスを処理します 次に、始点終点の座標とフラグメントの個数から各フラグメントの座標を計算するジェネレーションパスを処理して、 ラスタライズが達成されます このラスタライズ工程では、各フラグメントに座標だけでなく、 ジオメトリアトリビュート、つまりデプスや法線、エッジの向きといった情報も一緒に保持しておきます ジオメトリ属性は、事前処理で作ったバッファから取り出します エッジの中間点では、パースペクティブコレクト、つまり3次元空間的に補間した値を使います ここで言うエッジの向きを、エッジベクトルと呼び、 その向きは面の表裏を定義する Winding order に基づいて表向き面のインデックスの順番で決まります
• #22: 得られた輪郭フラグメントは、StrokeGen の輪郭線の定義に基づいた、全ての輪郭エッジから計算されています そのため、表の面に隠される不可視のエッジも含んでいます そこで可視性を判定した輪郭ピクセルを計算します 輪郭線というものがオブジェクトの縁に定義されることから、ちょっとの視点の移動で簡単に隠れたり出て来たりすることが容易に想像できると思います そういった性質から、実は輪郭線の可視性は長い間 Challenging problem とされていて、非常に解決が難しい問題とされています 線の可視性だけに焦点を絞った研究も過去にいくつもあるようです StrokeGen では2段階のデプステストで安定した可視性の評価を行おうとしています
• #23: 二段階のデプステストの一回目はソフトウェア実装のソフトデプステストです シーンのデプスが別に描画されているとして、 輪郭フラグメントに付随するデプスとシーンのデプスを比較します 一対一の比較では安定性に欠けるようで、1フラグメントについてその周囲3x3のシーンデプスと比較して、2点以上よりフラグメントが前面ならテストをパスします このパスしたフラグメントを pseudo-vidible fragment、pv-frag と言います pv-frag は、輪郭が重なっていたりサブピクセルレベルのラスタライズをしたりすると、1ピクセルに複数存在できます スクリーンスペースで1ピクセル1輪郭フラグメントとするために、この pv-frag をピクセルサイズの点として、通常のラスタライズ描画をします 通常のラスタライズなので、ハードウェアのデプステストが行われ、最も最前のものが最終的に得られます その際ジオメトリ属性情報を bit で色にエンコードしてラスタライズ描画して、輪郭ピクセルの GBuffer を作ります この時点だとフレームバッファの形式で管理することになりそうですが、 実際には描画したものから、輪郭ピクセルの配列となるバッファを作成して、以降の処理も輪郭ピクセル単位で行います ー複雑な処理のメモー Fa は不可視を含むラスタライズしただけの輪郭 pv-frag はそこから 3x3 でデプステストして可視候補の輪郭で同じピクセルに複数ありうる Atomic 処理で（PixelSpinLock に最初にアクセスした）pv-frag を一つ採用 デプステストの結果として pv-frag を一つ選ぶのではなく、スクリーンスペースの per pixel で一つのユニークな輪郭ピクセルを持つための処理（Stamp は1ピクセル1つだけ） 　SpawnSplatStampFragment で Stamp に対応する座標を決定→ per stamp の処理（GBuffer→Stamp）で Stamp の座標から HW-test を経て描画された GBuffer の値を取り出す HW-depth test で Gbuffer を介して最終的に Stamp = Cp が得られる
• #24: ここまでの処理を CPU で再現実装したシミュレータに表します シミュレータは2Dのベクトル画像を入力に StrokeGen を再現したものなので、可視性やジオメトリ属性の処理は含んでいません ここまでは、少々複雑な話でしたが、可視性の処理を考えなければ、ジオメトリの輪郭のデータをラスタライズするだけです
• #25: ラスタライズ工程で輪郭線を形成するピクセル群、輪郭ピクセルが得られています ベクトル化の工程では、この繋がりを計算して、ベクトルデータとして扱えるようにします まず、入力は輪郭ピクセルで、これをピクセルエッジループという形式にします ここでピクセルエッジという概念を取り入れます ピクセルエッジは一つ一つのピクセルを面積を持った矩形と考えたとき、その周囲に向き付きのエッジを定義したものです ここでは時計回りのエッジを考えます ピクセルが白黒の二値画像の時、一方の色のピクセルエッジの向きに従って辿っていくとループを必ず形成するので、それをピクセルエッジループと呼びます 図で言うと黒いピクセルのピクセルエッジを辿るとこのようなループができます このピクセルエッジは、Potrace というベクトル化アルゴリズムの、原文中には直接出てこない言葉ですが、中核となる考え方です 輪郭ピクセルのピクセルエッジを繋いでいきループを作る処理を Contour Chaining といい、 Potrace のベクトル化アルゴリズムの考え方をベースに処理を行います
• #26: Potrace について紹介します Potrace は二値画像の境界をベクトル化するソフトウェア及びアルゴリズムの名前です ビットマップ画像の2x2領域のパターンを見て、あるピクセルのエッジが次どこに繋がるかを決定でき、それを画像全体で辿ることでループが得られます ここに示しているのは一例ですが、2x2のピクセルエッジの繋がるパターンは全16種類で、簡単にパターンマッチングができます
• #27: StrokeGen はこの Potrace の並列化を提案しています ピクセルエッジのパターンマッチングを、画像処理フィルタのように各ピクセル並列に 3x3 ずつ処理します 3x3 は中心ピクセルについて 2x2 が4つあるのでまとめてピクセルの周囲4つのエッジの接続関係を計算できます それを並列処理で、全輪郭ピクセルについて処理します 結果的に全ての輪郭ピクセルから、そのピクセルエッジのその前後の接続関係が決定し、輪郭線となる、ピクセルエッジループが得られます 元の Potrace においてこれは Path decomposition という処理に該当して、さらにカーブへの生成なども行いますが、 StrokeGen ではこのピクセルエッジループを作る処理だけを参考にしています さらに StrokeGen の実装ではさらこの処理をビットパターンを用いて効率的に処理していますが、 複雑なので今回は省略します
• #28: 公開資料にも含めるが、完全に個人用のメモ ビットパターンによるパターンマッチング
• #29: ラスタライズしたピクセルの周囲にピクセルエッジのループを作るという処理でした
• #30: Potrace の手法をベースにピクセルエッジループが得られました ループというように、ピクセルエッジの前後の接続情報を辿ると、1周するベクトルデータのようなデータです しかし、このループには接続順、つまりどこからループが開始するか、という情報が無いため、描画に使えるベクトルデータの体を為していません ピクセルエッジループをリニアな配列データに整列する処理としてシリアライズが必要です エッジループフラッティングとも言います ピクセルエッジループは、並列処理という特性から、各ノードがメモリ上にバラバラに配置された循環リンクリストになっています シリアライズではこれを接続順に並び替える、ランキング処理を行います 逐次処理であれば適当にループの開始位置を決めれば簡単な処理ですが、並列処理で行うには複雑で、 Parallel list ranking という問題になります StrokeGen では Loop breaking と List ranking で二処理で解決します
• #31: Parallel List Ranking を提起した Wyllie の方法を使います これは接続関係があるノード列に、並列処理で、番号を割り振る方法で、 Pointer jumping とも呼びます 反復処理で接続関係を、次、次の次、さらに次、とポインタをジャンプするように繋ぎ直しながらランクを更新する手法です もっと効率的な Parallel List Ranking の方法もあるようですが、 StrokeGen では最もシンプルな方法を実装しています 著者のXによるとランキングをより効率的なものに置き換えることで高速化できた、ともありました
• #32: この Pointer jumping を StrokeGen では2回使います 一つ目はループの切れ目、ここではシードといいます、赤矢印です、これを決める処理 二つ目は先にループ中の順番を決めるランキング処理です ループの切れ目を見つける処理は、Loop breaking といい、 ピクセルエッジそれぞれユニークな ID、ここではモートンコードを、割り振ってそれがループ中最大になる箇所を切れ目にするという処理です List ranking はそのまま Wyllie の方法を適用して、 Loop breaking で見つけたループの切れ目を基準に接続順を解決します 最終的にピクセルエッジループを、ひとつのリニアな配列上に、連続したデータとして新しく作ることができます 複数のループも、接続情報があるので、一つの配列上に並びます
• #33: Loop breaking の説明図です 興味がある方は公開する資料で詳しく見てください ポインタをジャンプさせながら max をとる処理を行うことで実現します
• #34: ランキング処理の図解です 後続ノードの値を加算しながらポインタを繋ぎ直す処理を反復することで、 ノード毎の並列処理でランキングを行います ーーメモーー ここでは循環リンクリストなので末尾はnilではない maxidの割り振りでは末尾は気にせず（存在しない）十分な回数反復してmaxidを行き渡らせる rankingでは末尾＝シードで先頭ノードを指し、シードではつなぎ直しをしない すべてがnilを指すまでやるのが普通だが、実装では十分な回数を固定値で与える（チェックしない）
• #35: ピクセルエッジにユニークな ID を割り振り、 Loop breaking でループ中最大のIDの位置をループの切れ目にします ここでは、最外周と内側二つのループがあります
• #36: 切れ目を見つけたらそれを基準にリストランキングでループの接続順を決定します 接続順が決まるとそれを繋いだ線のデータを得られます
• #37: シリアライズされたピクセルエッジループが得られました これから描画するためのストロークデータを作ります まず、ラスタライズされたデータが少しガタついているため、フィルタリング処理で平滑化します 同時に、ループの曲線当てはめ処理で、各点での接線ベクトル方向を推定します そして、ループから不要な箇所を削除するカリング処理、 カリングして、途切れたデータを改めてベクトルデータとして整形するセグメンテーション処理を行います
• #38: ベクトル化につかった Potrace は境界線をベクトル化する手法なので、 ピクセルエッジループは輪郭線に対して二重になっています 図：本来この黒い線をベクトル化したいのですが、ラスタライズされたピクセルの境界線なので、内と外の両側にループが得られています また、ループとずっと言っていますが、輪郭線は、ループでないような線も含みます つまりまだ描画するべき輪郭線になっていないので、描画するためのベクトルストロークを生成する必要があります [0:48]/[34:27]
• #39: これをカリング処理といい 入力はシリアライズ済みのピクセルエッジループ、出力はストロークセグメントです ストロークセグメントとはベクトルストロークのデータで、一つの配列上に、セグメント化、つまりストローク毎の境界情報を持ったデータです このカリングはオリエンテーションカリングといい、 フィッティングで推定したループ各点の接線方向と、輪郭ピクセルの向きで描画しない点をカリングする処理です 輪郭ピクセルの向きとは、ラスタライズ工程で説明したエッジベクトルで、エッジに隣接する表向き面の Winding order と同じ方向になります 接線とエッジベクトルの向きが、周囲数点に渡ってある程度同じであれば採用、それ以外は削除します そうするとちょうど輪郭線の切れ目になる位置で、ストロークが途切れるようになる、この論文の中で提案された、ヒューリスティックな方法です 図上：このように三叉路になる黒い輪郭線があると、ここまでの工程でループは3つが交わります ループの接線と、輪郭ピクセルの向きを比べると、輪郭線に対して、ループ中の線がそれぞれ一本だけ決まり、 三叉路の交差点、つまり輪郭線の可視性が変化する箇所は切れ目になります 輪郭線が途中で途切れる箇所もその周囲のループの向きと輪郭ピクセルの向きで正しく1本選ばれます
• #40: オリエンテーションカリングで、ループ中の点から描画するものだけが選ばれました 改めて描画するものだけの始点終点と点列の順番を求めます これはセグメントスキャンという処理で達成されます セグメントスキャンは配列中にセグメント、つまり区切りの情報があるときに、各セグメント毎に値をカウントする処理です セグメントスキャンの並列処理は NVIDIA の実装を参考にしているようです これにより、描画するベクトルストロークのデータが完成します
• #41: ループにフィルタリングをして全体を滑らかにして、 オリエンテーションカリングで描画する紫の点を選びます
• #42: ベクトルストロークが得られたので、描画は任意に実装出来ます 論文ではシンプルなスタイライズとして、点列からポリメッシュを生成して、 ドローイングソフトにある様なパス描画を実装しています 輪郭線の法線方向にメッシュを押し出すよう実装されていて、 このポリラインにテクスチャマッピングなどが可能になっています
• #43: 得られたベクトルストロークは自由にレンダリングできます 目安30分
• #44: ここまで StrokeGen のアルゴリズムについて説明してきました 次に実際の実装について触れたいと思います また StrokeGen の検証のために行った改造実装も合わせて紹介します
• #45: StrokeGen は Unity 上の論文のプロトタイプ実装です URP 上にカスタムのレンダリングパイプラインとして実装されており、内部の効率的な並列計算の関係で DirectX 12 限定で動作します サードパーティの依存関係として Odin Inspector を利用しています 公開されているプロジェクトでは設定済みなので特に手を加える必要はありませんが、 カメラ、描画対象のオブジェクトに専用のスクリプトを設定して、Render Feature にカスタムパスの設定を行います 実行すると Game 画面で輪郭線描画が行われます
• #46: 公開されているパラメータについても紹介します 数が多いので興味がある方は公開する資料をご覧下さい ほとんどはスタイライズ表現の為のパラメータです Orient Threshold はオリエンテーションカリングで、ループの接線とエッジベクトルでカリング判定する角度を調整します
• #47: ブラシリンクジャンプ回数は、リストランキングの反復数です 論文内で反復数は 2000x2000 程度の画面解像度で 18回あれば十分だと実験されています
• #48: 発表に含めず 事前処理で作る各種バッファをインスペクタ上で可視化する機能も用意されています 公開されている実装では動作しませんでしたが、実行時に処理するのではなく、 インスペクタ上のボタンでアセット化する処理を行おうとしている実装も見受けられました
• #49: 発表に含めず 線幅の制御にカーブをテクスチャ化してする専用機能も用意されています 輪郭線を描画するオブジェクトにはアルゴリズムに関するパラメータはありませんが、 アニメーションの検証用にオブジェクトを回転するような処理が含まれています
• #50: 発表に含めず StrokeGen は非常に複雑でコードの量が多いです アルゴリズムと関連するソースコードを簡単に列挙しました 興味ある方は公開される資料を見て、実際にソースコードを読み解く際の参考になればと思います
• #51: 以上は論文の内容です 次は私が、実際に StrokeGen のプロジェクトを動かし、検証するために行ったいくつかの改造を紹介します
• #52: まず Odin Inspector 依存の解消についてです StrokeGen は Github 上に誰でも利用できる形で公開されていますが、 UI 拡張のための有料プラグイン Odin Inspector を利用しているため、当然所持していなければ動きません 幸い、Odin Inspector はパラメータ回りの UI を使いやすくするための機能で、 StrokeGen のアルゴリズムに関わるものではありません 今回は Odin Inspector の機能を模倣した Custom Inspector を自作して動作するようにしました
• #53: ストローク描画にイラストソフトのブラシのようなスタンプ描画へ対応させました これは実装中に動作していない処理があったためそれを動くように修正しました ベクトルストロークの各点列をクアッドメッシュとして描画して、各クアッドにブラシテクスチャをマッピングできます
• #54: 公開されている StrokeGen はシングルスタティックメッシュのみサポートしています アルゴリズム上の制限ではないので、輪郭線描画のメインターゲットと考えられる、 キャラクターアニメーションでも動作するように改造を行いました まずシングルメッシュという点に付いては、一つのメッシュだけを対象と取るところを、 一つの GameObject を指定すると、その子のメッシュ全てを輪郭線描画の対象とするようにしました 全てのメッシュのデータは一つの大きなバッファに順次格納します アルゴリズム上、並列処理である為メッシュあるいはエッジを処理する順番は結果に一切影響はありません キャラクターアニメーションへの対応は、SkinnedMeshRender に対応することで達成されます Unity ではスキニング計算後の Vertex Buffer を GPU リソースとして取得する機能があるため、 それを利用して、動的更新が必要なものを Compute Shader で毎フレーム更新します スキニングでメッシュのトポロジーが変化するようなものでなければ、頂点座標と法線のみの更新で対応できます
• #55: また複数メッシュに対応の合わせてメッシュ毎に異なるパラメータを適用できるようにしました ラスタライズ時のジオメトリ属性にメッシュの ID を付与することで、 レンダリング時にメッシュ毎のパラメータを参照できるようになります ここでは線幅と色をメッシュ毎に設定できるようにしています
• #56: StrokeGen の輪郭線の定義を最初にしました 比較的一般的な定義とは言いましたが、実用で考えると機能として不十分です 輪郭線としてクリースエッジの対応を行いました クリースエッジとは折り目になっている線のことです これは一つの辺を共有する二つの面のなす角度が、閾値以下の時にそのエッジを輪郭線とみなすことで実現できます 事前処理でエッジがクリースと判定出来れば、以降は StrokeGen 本来の輪郭エッジと全く同じよう混ぜて処理できます また似たものとして、マテリアルの境界のエッジも対象とすることで境界線描画にも対応しました
• #57: リアルタイムのベクトルストローク生成手法としてどのような表現ができるのか、検証のためいくつかの表現を実装しました 結果はこの後スクリーンショットと動画で紹介します
• #58: ではその結果紹介に移ります
• #59: 結果を作るに当たってお借りしたアセットです ユニティちゃんと、法人ですが研究開発用途なのでミライ小町さんをお借りしました ありがとうございます
• #60: まず StrokeGen のプロジェクトをほぼ素の状態で動かした絵をお見せします スタティックメッシュの輪郭線が自由なカメラで描画できています パスにブラシのテクスチャを貼り付けることもできます ちらつきが気になる方も多いかと思いますが、これは最後、今後の展望の章で考察します
• #61: 次にキャラクターアニメーションに対応した結果です ちらつきが先ほどより気になるかもしれませんが、 キャラクターアニメーションに対してもテクスチャーマッピングなどストロークならではの表現はできています
• #62: あまりにちらつきが気になったため、安定性を高める検証も行っています 今回成果発表できるほどまとめられていないのですが、StrokeGen の安定性を高めるのは必須の課題です 細かい線のちらつきは以前ありますが、ある程度ちらつきを低減できています しかしテクスチャマッピングのちらつきは以前多いです
• #63: 改めて機能ごとに紹介します パスやスタンプ描画のテクスチャマッピングです ドローイングソフトやイラストソフトのブラシ設定のような形で、アート的な輪郭線表現ができます
• #64: 線にゆらぎを与えたり、線を増やす効果です テクスチャを使わずともラフスケッチ風の表現ができます 細かい制御が難しく、アニメーションさせると耐えがたいちらつきの要因になりますが、 ゲームにおける従来の輪郭線表現は、元となる形状から逸脱した線を描くことが非常に困難である為、 ストロークレンダリングならではの表現として中々期待が持てる機能ではあると思います
• #65: ゲームにおける従来の輪郭線表現は、輪郭線の特徴となる情報を可視化する手法であり、実際には線ではありません そのため、太い線を描こうとすると、アーティファクトや、そもそも描画できないといった制限があることも多いです ストロークレンダリングは、線を線として描画するので、パラメータで10ピクセルの線幅を指定すれば、 そのまま10ピクセルの線を描画できます 表現としてはぱっとしないですが、間違いなく従来法が苦手だった領域を、ストロークレンダリングだからこその方法でカバーできています
• #66: 線幅に強弱を付ける表現は、ゲームの従来の手法でもよく行われています ストロークレンダリングでも従来法と同じように、テクスチャや頂点カラーで線幅を制御して線画に味を付けることができます また得られたベクトルストロークのトポロジーを解析して曲率や線の位置に基づいて、 テクスチャのようなメッシュに固定された情報でない、線の入り抜きのような表現も可能になります
• #67: これはまだまだ実験段階なのですが、ストロークレンダリングとして、ストロークのみを描画することができます 左は草むらのようなものを、StrokeGen の作るストロークだけで表現したものです 右は、ミライ小町さんの髪にある明るい色の房をストロークレンダリングに置き換えたものです StrokeGen は、説明の中にあった輪郭線候補が二重に得られるという特性から、 一本だけのストロークを描くのが苦手なので、今回はカメラ固定で、板ポリのようなものをストロークのガイドとして置いて半ば無理矢理実装しています ストロークの表現が多彩なので、開発を突き進めると、ストロークのみで色々な絵を描けるようになるかもしれません
• #68: これは輪郭線にライティングの効果を施す演出です イラストの線画などを見ると、光が当たるところほど、淡い色で線幅も細くなるような表現をよく目にします 左はそれを模倣して、画面右上から光が当たっているとして、線の色と幅を変化させています また、NPR 表現におけるリムライトとアウトラインは実は近しい表現なのではという仮説から、 リムライトそのものをアウトラインとして描画してみた例が右側になります
• #69: 最後に動きに応答するようなストローク表現です モーションベクトルに基づいてアウトラインのみにモーションブラーのような効果を与えました これはいわゆるおばけブラー・カートゥーンブラーやスミアフレームという表現で、 アニメでは良く目にするもののゲームでは中々難しい効果を、アウトラインで表現することができます
• #70: 以上、ストロークレンダリングの表現例を紹介しました 従来法でも工夫次第で可能な表現も含んでいますが、ベクトルストロークであることで可能な表現は非常に多彩です ストロークレンダリングは、線を線として描画できる、同じ表現でも調整のしやすさなどの利便性は間違いなく上がると思います StrokeGen はあくまでストローク生成が本質ですが、それを使ってどのような表現ができるのかこそが重要だと思っています 今回はアーティストを挟まないでエンジニア一人で作業したため、 いまいち映えない画だったかもしれませんが、ストロークレンダリングの面白さを感じ取っていただければと思います
• #71: 結果の紹介としてパフォーマンスについても触れなければなりません まずは論文中で触れられている性能ですが、フルHD をコンシューマGPUで処理した結果です 処理をラスタライズとベクトル化に分けて示しています 処理時間としてはベクトル化が支配的です エッジ単位の処理なので形状が複雑になると重くなる傾向が確認できますが、 30万ポリゴンほどでも全体の処理を通して、2msも掛からないことが分かります ドラゴンが一番時間が掛かっていることから、単純なポリゴン数ではなく輪郭の複雑さ、 つまり表面が凸凹していると重くなりやすい傾向はあると思います
• #72: 説明したアルゴリズムは大分複雑で、処理の量も多いのにこの程度の処理時間で済むのは少し驚きです 論文ではそれは、輪郭の疎性で説明できるといっています このグラフはちょっと読み取りづらいですが、左は全体のメッシュの内の輪郭エッジの割合、右は描画するバウディングボックスの内の輪郭ピクセルの割合です 輪郭エッジは多くとも10％、30万ポリゴンなら数万エッジ、 輪郭ピクセルは4％程度、フルHDで8万ピクセルほどとかなり処理の量が少なくなります
• #73: アニメーション対応を含めた実装を、実際に動かしてUnity上のアナライザで確認してみました 数値が確認できる StrokeGen の主要な処理のGPU時間を抜き出すと、 おおよそ4万ポリゴンのキャラクタアニメーションで、トータル1.6ms 論文と遜色ない速度が確認できました アニメーション対応が大半なのは改善点です #ミライ小町 Vertices: 22,421 Edges: 47,776 Faces: 25,439 Triangles: 43,682
• #74: テクスチャマッピング利用時や別のアナライザの解析も載せておきます 共に先ほどの数値と大差ない結果が確認できました
• #75: パフォーマンスの考察です まず全体を通してリアルタイムレンダリングの手法として十分な速度が得られています StrokeGen の必要な輪郭線のデータのみを、Indirect 命令で動的に処理量を変えながら実行されるため、 よいパフォーマンスが得られています アニメーション対応は場当たり的な改造で実装したため、まだ最適化は不十分だと思っています 特に事前処理のバッファ管理回りは公開実装からさらに洗練できそうです ストロークを太くしたり、テクスチャマッピングを行ったりは、少なからずパフォーマンスに影響はあると思いますが、 今回の検証の限りは目に見えるほどの悪化は確認できず、十分実用的であると感じました また、今の実装は事前処理を起動時に行うのも問題で、細かく計測はしていないですが、 実行してから動き出すまで数秒は待つ必要があります 動的に更新しない部分は、計算結果をアセットとして使い回すような仕組みが必須です 今の StrokeGenの輪郭線は描画したいオブジェクトを指定する形式になっています これでは複数キャラや背景に同時に適用することが難しく、大規模なシーンでどのような絵やパフォーマンスが得られるかを検証が必要です アルゴリズム上の制約というわけではありませんが、バッファ管理等、大規模シーンへ対応するため大きな改造が必要です
• #76: 最後に手法の課題と今後の展望をお話しします 目標45分
• #77: 最初に投げかけた、StrokeGen はゲーム NPR における新しい手法となり得るのか、という議題ですが スライドには書きませんが現状はまだ NO でしょう たしかに StrokeGen は、従来のリアルタイム向けの輪郭線表現手法では為し得なかった表現が可能になり、 非常に期待が持てる技術です しかし、まだ課題が多く従来法をそのまま代替するようなものでないのも事実です 特に結果の動画でも確認されたように、ちらつき、つまり時間的な安定性は大きな課題です 時間的な安定性にも、StrokeGen そのものの安定性の課題と、 リアルタイムにスタイライズ表現を行うことへの時間的な一貫性の課題、二つがあります また、パフォーマンス面は十分なのものが得られていますが、大規模なシーンへの適用はまだ達成していないので、 メインキャラクターとそれ以外で、従来法と使い分けるように利用する仕組みを整備する必要があります
• #78: 結果の絵を少し見ます 初期フレーム 【色々戻しながら】 キャラクター自体は大して動いていないのに、線が出たり消えたりしていて非常に不安定なことが分かります
• #79: 次のフレーム 【色々戻しながら】 キャラクター自体は大して動いていないのに、線が出たり消えたりしていて非常に不安定なことが分かります
• #80: さらに次のフレーム 【色々戻しながら】 キャラクター自体は大して動いていないのに、線が出たり消えたりしていて非常に不安定なことが分かります
• #81: StrokeGen は僅かな入力形状の変化で、結果のストロークが変化しやすい、つまり時間的な安定性が低い手法です StrokeGenは説明した通り、ベクトル化に Potrace のアイディアを採用しています Potrace は境界線をベクトル化する手法です StrokeGen における Potrace への入力は、輪郭ピクセルです つまり輪郭線の境界線をベクトル化しており、当然二重のベクトル輪郭線の候補が得られています オリエンテーションカリングで最終的にストロークが1本得られますが、 手法を俯瞰してみるとどうにも歪、わざわざ二重の線を一度作り、不要なものを消す処理があることに無駄を感じます 実際結果を細かく見ていると、このカリングで消す、という処理が時間的な安定性をかなり損ねているように見えました 境界線ではなく、線を線としてベクトル化する手法に置き換えたり、 二重の線を消すのではなく一本に統合するような方法で改善できないか、議論の余地があると感じました 線のベクトル化 keywords：中間軸変換、チェーンコードアルゴリズム、ハフ変換
• #82: 輪郭線は3Dの形状を2Dに投影した結果現れる特徴量の一種で、 2D画像として見たときに、線のトポロジーは簡単に変化します このトーラスなどは上から見ると二つの円で輪郭線が表されますが、 ちょっと視点を下げると内側の円は途中で途切れてしまいます 均一な線ならこのようなトポロジーの変化は対して問題になりませんが、 テクスチャマッピングや入り抜き表現を考えると、視点でかってに線が切れたり増えたりするのは、ちらつきの原因になります 結果の動画でテクスチャマッピングをするとちらつきが激しくなった原因です リアルタイムにスタイライズ表現を行うことの時間的な一貫性をどう保つかは難しい研究課題です StrokeGen では線の可視性の変化する位置か、Loop breakingで適当な位置にストロークの開始位置が決まりまるため、 時間的な一貫性は全く考慮されていません フレーム間で線の変化を追跡して激しくチラつくようなことが無いように抑制する仕組みが必要です 線の時間的な変化に関する研究は過去にもたくさんあり、それらの StrokeGen への適用は重要な課題です
• #83: 前述二つの問題に関連しますが、 StrokeGen はリアルタイム用途であるため、オフライン手法で使えるような手動での細かい調整が全く適用できないという課題もあります ゲーム用途を考えると、自由なカメラで、意図した表現を、安定して得られなければ全く使えません カットシーンであってもフレーム単位の調整なんてしたくありませんし、アーティストの、入り抜きをこの辺に固定したい、 というようなふわっとした要求を良い感じに安定して反映できる仕組みが必要です どんな表現を、どの程度の自由度で、どのような方法でアーティストが調整するのか、 ツールとしてのアーティストへのアプローチ方法も重要になっていきます 例えば、ストロークの為す角度でストロークを分断すると、ある程度アニメーションに対して安定することが分かります あるいはアーティストの指定したガイドで入り抜きの位置を制御する方法も考えられます これはマウスの位置に追従するような実装ですが、キャラクターの骨の位置に追従するように入り抜き位置を固定できたら、 アニメーションに対して安定した結果が得られるかもしれません
• #84: StrokeGen のベクトル化がスクリーンスペースである為、線の繋がりが不自然になりやすいことも論文中に指摘されています オフライン手法とのストロークの分断のされ方にも言及しています 確かに、繋がっていない輪郭線がスクリーンスペースの解像度では繋がってしまったり、 本来繋がっているべき線が隠れていることで分断されてしまうのは、大きな課題であると言えるかもしれません
• #85: 発表に含めず その他の課題も上げます 得られるストロークがあまり綺麗でないことが上げられます ストロークを延長してみる効果を実装してみたところ、ストローク末端の形状が綺麗でないため、全体的に変な結果が得られませんでした これもオリエンテーションカリングで不安定に描画しない点を選んでいることが関係していると思います また、実際の輪郭線からストロークがズレる問題もあります ピクセルエッジが、ピクセル周囲に定義されることからズレる現象と、 フィルタリングによって輪郭の角が取れてしまう現象があります フィルタリングにエッジ保存フィルタを実装してみましたが、シミュレータ上ではうまく行くものの、 実際のシーンではまだ有効な結果が得られていません そもそもフィルタリングの視覚的効果があまり感じられないため、 線のちょっとしたがたつきは専用のアンチエイリアシング処理を用意するなどで対応するべきかもしれません
• #86: 以上 StrokeGen の手法と表現を紹介してきました 現在はこの StrokeGen をどのように実用化できるかを研究開発しています 今回紹介した結果の絵の中にも、StrokeGen のアイディアをベースに再構築した新しい手法のものが含まれています まだ発表できるほど体裁がまとまっていないのですが、何かの機会でまた紹介できたらと思います 改善点として、アルゴリズムと表現の改善があります アルゴリズムは何度も言ったように安定性の向上が欠かせません また従来法と共存できるようなシステムを構築する必要があります 大規模シーン対応を考えると、高速化もさらに必要かもしれません 表現面は色々考えられますが、ニーズを調査して表現を拡充していきたいです 今回試せなかったものとして、線だけ描画できる利点から、アップスケーリングやアンチエイリアシングはかなり有効な効果が得られると思っています ツールとしての機能拡充も重要です 論文の著者も発展させた手法を開発中のようです とても面白い技術なので今後この発展の動向に是非注目してみてください 興味もたれた方がいたら是非御意見等も頂戴いただけると嬉しいです
• #87: ご清聴、ご視聴ありがとうございました 質疑応答に移りたいと思います