KLabのゲーム用キャラクターモデルを例に、LOD自動生成のステップを解説〜「自動LOD生成を可能にする3Dキャラクターパイプラインセミナー」レポート

5月21日（金）に開催されたボーンデジタル主催の「自動LOD生成を可能にする3Dキャラクターパイプラインセミナー」。KLab株式会社 Real-time Rendering Research Group（RRR）所属のクレメンス・ベルガー／Clemens Berger氏と忽帥（コツ・スイ）氏による、ゲーム用キャラクターモデルのLOD自動生成を実現するパイプラインの講座だ。前半はクレメンス氏によるLODの基礎的な説明とモデリングについて、後半は忽氏によるHoudiniを使ったスケールダウンとMayaのmGearを使ったリグなどの説明が行われた。

TEXT＿石井勇夫 / Isao Ishii（ねぎぞうデザイン）
EDIT＿小村仁美 / Hitomi Komura（CGWORLD）

●Information
「自動LOD生成を可能にする3Dキャラクターパイプラインセミナー」
開催日：2021年5月21日（金）
時間：17：00〜19：00
会場：オンライン
参加費：無料 ※事前登録制
参加対象：自動LODパイプラインに興味がある人
主催：ボーンデジタル

アーカイブ視聴はこちらから
※視聴にはクリエイターズIDの登録が必要です

LODの基礎と、LODの自動生成を意識したモデリング

前半は、3Dキャラクター・リードアーティストのクレメンス氏からLODの基礎とKLabでのキャラクターパイプラインの解説が行われた。LODとはLevel Of Detailのことで、1つのモデルに対して環境や条件に応じたディテールの調整を施す手法だ。大きく分けるとカメラからの距離でリダクションされるDistance LODと、プラットフォームに合わせてリダクションされるPlatform LOD（Per-Platform LOD）がある。通常はLOD0から数字が上がるにつれて、メッシュが粗くなっていくことが多い。

LODの作り方は、クオリティが高いがコストも上がってしまう「手動」でつくる方法と、コストは下がるがクオリティも下がってしまう「自動生成」の2種類がある。建築物などの変形しないスタティックなモデルは自動生成しやすいが、リギングされたキャラクターのようなダイナミックに変形するモデルは、手動での細かい調整が必要になる。

今回は、ダイナミックな変形をするキャラクターのLODでも、クオリティを保ちながら自動化するパイプラインを構築している。

▲キャラクターを使ったLODの図。右へいくほどローポリだ

今回の講座のサンプルモデルとして、Bodyは映像用モデルの流用、Headは新規制作されたものが使われた。パイプラインの特徴はHigh To Lowの制作フローと、リダクション前提のゲームモデルだということだ。

パイプラインはコンセプトアート、ハイメッシュ制作、ローメッシュ制作（ゲームメッシュ）、ベイク＆テクスチャ、リグ・スキン、ルック開発、スケールダウンの7工程となっている。

▲キャラクターモデルパイプライン。7工程ある

このパイプラインを基に、実際の作業の工程を時間軸で表したのがタイムラインとなる。パイプラインは1軸だが、実際の作業はチームで行うため、タイムラインでは並行に作業できる工程を加味して設計されている。

▲タイムラインでは作業を並行して行う前提だ

ハイメッシュのモデリングは基本的にZBrushで行われるが、今回のBodyはMayaのV-Ray用データがあったため、MayaからFBX形式でZBrushにインポートして作業が開始された。ZBrushへのインポートにFBXを使うのは、OBJ形式とちがいユニットスケールがあるため。また、ZBrushはユニットスケールがわかりにくいため、中間フォーマットは1種類にした方が良いという。

FBXはMayaからSubDivをかけずに書き出して、ZBrushの中でディテールを入れ込んでいく。パイプランでは利用するデータは初めからきれいにしておいた方が、後々トラブルの元にならないためだ。

Headはスケールを固定したZBrushファイルでゼロから制作された。DynaMeshを使いながら、美しい形をつくることに集中して作業している。その際、ディテールをどこまでスカルプトで表現するか、テクスチャはどこまで使うかなどをはっきりさせるのが重要だ。

スカルプトが終わると、LODの制作に入る。通常だとハイメッシュから各プラットフォームごとにLOD0を手動で作り、自動生成でそれ以降のLODが作られていく方法（アプローチ1）が考えられるが、この方法では作業コストが高くなってしまう。

▲アプローチ1のフロー

コスト対策としてDistance LODをPlatform LODとして流用する方法（アプローチ2）も検討されたが、この方法だと逆にクオリティの問題が残ってしまう。

▲アプローチ2のフロー。単純化されたが、その分プラットフォームごとの調整が難しい

そこで今回のパイプラインはLODAという、LOD0の前にベースを1つつくるアプローチが考えられた。メリットは手動で制作するのがハイメッシュとLODAのみということと、プラットフォームとDistance LODがデータ的に切り離されているのでクオリティアップが可能といった、アプローチ1と2の良いところを合わせたものだ。

▲LODAアプローチのフロー。自動生成でプラットフォームごとの対応が可能になる

ただしLODAアプローチでは、LODAをリダクションして自動でLOD0を生成するパイプラインのため、適切なLODAのモデリングが必須となる。

LODAはハイメッシュをリトポロジーしたローモデルで、アニメーションに対応するためきれいなトポロジーが必要だ。さらに、大幅なリダクションが前提なので「Quad Layout」でモデリングしていくことが非常に大事だという。

Quad Layoutは自動リダクションに向いたポリゴンの構成で、リダクションしていくとシンプルな四角ポリゴンになっていく。ハイメッシュをリトポしてベースメッシュを作るのはゲームも映像も同じだが、トポロジーの考え方はちがう。一見、映像用のリトポに比べるとトポロジーの流れを無視しているようにも見えるが、これはリダクションしてLODを自動生成していく前提のモデリングだからだ。

▲Quad Layoutのモデリング。リダクションしていくとシンプルになる

また、Quad Layoutでは自動リダクションを考慮して、「アイテムごとのリトポ」ではなく「まとめてリトポ」が推奨されるとのこと。

▲モデリングはパーツごとに細かく分けずに、1つにした方が自動リダクションではトラブルがない

具体的な制作フローとしては、LODAを作るにはLODBというモデルを使う。LODBはハイメッシュをリトポしてポリゴン数を減らしたモデルだ。これをZBrushにインポートしてSubDivideし、さらにProjectALLしてLODAを作っていく。「この方法はシンプルなQuad Layoutでディテールを出していくことが可能です」とクレメンス氏は語る。

▲ハイメッシュをリトポしてLODBをつくり、それにハイメッシュをプロジェクションするなどしてLODAをつくる

一見すると映像用データで行う普通のリトポと変わらないように見えるが、耳のメッシュを見るとちがいがわかるだろう。Quad Layoutでは、ポリゴンの流れよりも自動リダクションがしやすいような単純化がされている。

▲顔の正面から見ると、映像で使うリトポに近い印象を受ける

▲左は映像で使うようなリトポだが、自動リダクションでは破綻してしまう。右は自動リダクションしやすいようにフラットでシンプルに作られている

UVもLODBで制作する。ゲームでは、PCからモバイルまで幅広く使われるため、ピクセル密度を均一にせず、あえて顔だけピクセル密度を高めている。このような作業もLODBの段階だと作りやすく、テクスチャ密度も考慮しやすい。

ベイクとテクスチャはSubstance Painterで行う。LODBからLODAへのReprojectはZBrushで行うため、ハイメッシュもローメッシュもZBrushで管理するのが良いだろう。また、Substance Painterでの作業のためにIDマップを出しておくと便利だということだ。

▲まとめてリトポするので、Substance Painter用のIDマップは必須だ

Houdiniを使った自動リダクションによるスケールダウン

後半はリガー・テクニカルアーティストの忽氏による、リギングやスキニングの解説だ。映像とちがってゲーム開発ではリギングとスキニングを分けて考えられるので、同じDCCツールを使わなくても良く、各ソフトの良いとこ取りが可能となっている。

そのためツールや手法の選定が重要になってくるが、今回のリギングではMayaのmGearが、スキニングはHoudiniが選定された。

リギングでmGearを選んだ理由は、ガイドからワンクリックでリグが生成できるという簡易さ、自作コンポーネントが作れる拡張性、ヒューマンエラーの回避しやすさ、仕様を管理しやすいことなどが理由だ。

特にmGearは最近ゲーム業界向けの機能が充実してきていて、Zupへの対応やUnreal Engine用のプリセットが用意されるようになった。また、Joint Orient Offsetやネーミングルールのカスタマイズなど、ゲーム開発に嬉しい機能も充実している。今回は使わないが、スキニングやアニメの機能もある。

▲mGearの操作画面。Mayaのプラグインとして使用する。ここでは足のみセットアップしている

▲mGearでビルドをしたところ。使い勝手はかなり良い

スキニングはHoudiniで行うが、理由はBiharmonic Captureの精度の高さとプロシージャルアプローチの処理の容易さからだった。

Houdiniで18.5から実装されたkineFXは、リギングとアニメーションのフレームワークおよびツールセットだ。FBXanimimport SOPとFBXskinimport SOP、FBXcharacterimport SOPが追加され、FBXの入出力が容易になった。

前半でも使われた、スキニングされていないBodyのモデルをインポートしてノードが組み立てられているが、これらを紐解くかたちで解説が進められた。

▲スキニングされたHoudiniデータ

まず、メッシュとボーンを別々のノードでインポート。揺れモノ用のボーンは削除している。草摺（腰の衣装）は一度メッシュから外し、後ほど追加する。

▲草摺は外してスキニングする

Houdiniはバインドをキャプチャと呼び、Bone Capture Linesというノードを使って下準備をする。

次にBone Capture Biharmonicを使ってスキニングをするのだが、その際メッシュの体積が必要なので、BodyをRemeshして三角ポリゴン化したあとTet Conformをする。Tet Conformはメッシュの中に4面体をぎっちりと作って敷き詰めて、体積を算出するノードだ。このとき、ボーンも一緒に埋め込んでおく。Bone Capture Biharmonicはボーンとメッシュとの距離やメッシュの体積を基にバインドを計算していく。

▲Tet Conformでメッシュの中に4面体をぎっちりと作って敷き詰めたところ

▲メッシュの中に赤い色のボーンが通っている。このボーンからメッシュまでの距離は四辺形のエッジをたどって算出していく

▲スキンウェイトをビジュアライズしたところ

その後、アニメーションをインポートして、キャプチャを確認。いわゆるスキニングの品質は一発目としてはかなり高い。特に指を見てみると、お互いに干渉していないのがわかるだろう。

▲指を動かしたところ。隣の指に干渉していないのがわかる

分離しておいた草摺は、先ほど作ったBodyのBone Capture Biharmonicから情報をAttribute Transferを使って転写してスキニングしている。ノードを使うHoudiniの特性を活かしたスキニング方法だ。

▲転写してウェイトをビジュアライズしたところ。ノードをつなげるだけで、ここまで可能だ

これらのメッシュをMergeしてアニメーションして確認。Smoothなどで微調整していき、最後はROP FBX Character Outputでエクスポートする。

次に、これらのモデルのポリゴンやインフルエンスを自動で削除してスケールダウンしていくしくみを作っていく。

手法としては、独自のRetentionアトリビュートをスキンウェイトから生成して、PolyReduce SOPでポリゴンを削減、Capture Correct SOPでインフルエンス数を削減するという方法だ。

まず、必要な補助トポロジーを残しつつポリゴン数を削減するには、規則性を見つけ出す必要がある。この規則から、削除したいものとしたくないものを数値化したRetentionというアトリビュートをつくり、PolyReduce SOPによるポリゴンリダクションとCapture Correct SOPによるインフルエンス削除の参考にした。

▲Retentionの考察。必要度によってリダクションを変えている

実際にモデルに組み込まれた独自のKLab_Character_Reductionの中身を見てみると、インフルエンスの削減、ポリゴンの削減、Retentionの設定の三部構成になっている。

▲Retentionの具合をビジュアル化したもの。Retentionはスキンウェイトをみて、どれくらい変形するかをみる。赤いところほど変形具合が大きく、かけ持ちとなっている

▲RetentionアトリビュートをOFFにしたところ。指を見ると曲がりそうにないところもある

▲RetentionアトリビュートをONにしたところ。指の節にエッジが増えた

スキンインフルエンスの削減にはCapture Correct SOPが使われた。インフルエンスの数はモバイルでは3から2、PCだと4程度というように、プラットフォームによって変わっていく。このノードにはノーマライズのスイッチもあるので、頂点の合計値を1に設定することもできる。

忽氏は「Houdiniの処理はHADにしてバッチ処理が可能なため、大量のキャラクターやアセットにも適用できる」と自動化におけるHoudiniの強みを説明した。

▲スキンインフルエンス数の増減の図

最後に、ルック開発についてクレメンス氏から説明された。

今回のパイプラインでは、最終的なアウトプットはUnityを利用している。ルックを大きく左右するのはシェーダだが、現在ではPBRで共通化しているためソフト間でルックは大きく変わらなくなってきているという。テクスチャマップの処理はSubstance Painterの書き出しプリセットを利用すれば基本的に問題はない。

▲ソフトごとのプレビューのちがい。大きく変わらないのがわかる

ただしPBRはHDRが基本で、最終的にゲームエンジンでカラーを補正する必要がある。今回のUnityではトーンマッピングをはじめ、ブルーム、ビネット、ボケなどを足して仕上げられている。

こういった処理をテクスチャでやってしまうと、統一感が損なわれてしまうので、テクスチャではカラーグレーディングはしない方が良いとのこと。

▲データをインポートしたままでポスプロなしの描画。面白みにかける画だ

▲ポスプロして仕上げたもの。魅力的な画になっている

パイプラインはプロジェクトのニーズによって変わっていく。作業ステップはモデルによって変わり、作業ステップによって使用ソフトも変わるので、万能なパイプラインは存在しない。「目的をはっきりした上でパイプラインの構築が必要」だとクレメンス氏は語る。

例えば今回のパイプラインは自動LOD生成を目標としたもので、ポリゴンリダクションで品質が落ちないようにノーマルマップに頼っている。しかし、アングルによってはシルエットが破綻してしまう。これらはトレードオフとなり、例えばプロダクトの詳細な紹介するような案件では使えるパイプラインではない。パイプラインの得意不得意を意識するのが重要ということだ。

開発パイプラインでは全ての作業ステップが緊密に関係しているので、より良いパイプラインの開発のためには各ステップの理解が必要だ。十分な理解の上で開発すれば、最適化を進めて、クオリティを維持したままのコスト削減が可能となるだろうと締めくくった。

アーカイブ視聴はこちらから
※視聴にはクリエイターズIDの登録が必要です