生成したメッシュにも、スケール、形状、動き、読み込み、インタラクションについての判断が必要です。まず使用予定のエンジンとゲーム内カメラを基準にし、生成直後のデータを保存したうえで、編集可能なデジタルコンテンツ制作（DCC）ファイルで修正します。実行用のエクスポートは別にバージョン管理し、出荷したアセットから元のデータをたどれるようにしてください。
以下の工程を、アセット、エンジン、対象ハードウェアに対する受け入れ確認として使ってください。クリーンアップ前に制作要件を定め、何が確認を通過したかを記録します。見栄えのよいターンテーブル表示も役立ちますが、それだけではキャラクターが適切に変形するか、小物でいっぱいの部屋がパフォーマンス予算に収まるかはわかりません。
1. 元データと実行時の要件を定める
承認済みのリファレンス、生成手順、入力と出力に関する権利、想定寸法、インタラクションでの役割、担当者を記したアセット記録を作成します。クリーンアップ前に、未加工のメッシュとテクスチャを保存してください。作業用コピーをBlenderまたは選択したDCCにインポートし、あらゆる方向から、ワイヤーフレーム表示とマテリアルの各チャンネルで確認します。背面と底面も、生成ツールの正面プレビューと同じくらい入念に確認してください。
プロジェクトの単位、向き、原点、命名規則を設定します。ピボットは、ゲーム内でオブジェクトを回転させたり取り付けたりする必要がある位置に置きます。キャラクターでは、スキニング前にレストポーズとスケルトンを合意しておきます。制作ファイルは出荷用エクスポートとともに保管し、スケールとピボットの修正を元データに記録してください。そうした判断が実行時コードにしか残らない状態にしてはいけません。
2. 残すべきジオメトリを判断する
ゲーム内カメラの距離でシルエットを確認します。勝手に作られた開口部、融合した部品、交差するシェル、浮遊する断片、逆向きの法線を修正してください。描き込まれたディテールのうち形状に反映すべきものと、ベイクした法線マップで代用できそうな高密度の幾何学的ディテールを探します。独立して動く必要がある部分は分離しておきます。
自動クリーンアップは必要な箇所にだけ適用します。開いた面、重なった衣服、薄い板状ポリゴンを意図的に使うデザインもあり、すべてを閉じた形状にすると損なわれる場合があります。コリジョン用メッシュと表示用メッシュでは要件が異なります。リメッシュは表面を再構築する際にUV、シェイプキー、その他の制作情報を変える可能性があるため、実行前にコピーを保存してください。
3. 簡略化か計画的なリトポロジーかを選ぶ
背景の静的な小物なら、シルエット、シェーディング、UVが保たれる限り、慎重な簡略化で対応できる場合があります。話したり頻繁に変形したりするキャラクターには、通常、関節や表情に合わせて設計したトポロジーが必要です。制作要件で必要とされる箇所に応じて、肩、肘、膝、口、まぶたの周囲にループを作り、その変形をテストします。サービスが出力する四角形中心のメッシュも、同じ慎重さで確認してください。
修正済みの高密度な元データはベイク用に保存します。低ディテールのメッシュは別に承認し、削減によって何が変わったかを確認してください。細いストラップ、取っ手、曲線的な輪郭には特に注意が必要です。DCCでの面数と、実行用にエクスポートしたジオメトリを記録します。エクスポート時には、マテリアル、UV、シェーディングの境界で頂点が分割されることがあります。
4. 想定する編集に対応したUVを作る
チェッカーテクスチャでUVレイアウトを確認します。伸び、ディテール密度のばらつき、小さすぎるアイランド、意図しない重なりを探してください。シームは修復しやすく、想定カメラからアーティファクトが見えにくい位置に置きます。共有または左右反転したアイランドが適するアセットもありますが、個別のベイクや非対称の模様には専用の表面領域が必要な場合があります。
テクスチャの寸法は、画面上で必要な情報量とシーン全体のメモリ予算から決めます。顔のクローズアップと遠くの木箱に、自動的に同じ割り当てをするべきではありません。フィルタリングと低いミップレベルに備えて、アイランドの周囲に余白を設けます。トポロジーが変わった場合は、最終的なUVに合わせてテクスチャを再ベイクするか修復してください。以前のアトラスはもう適合しないかもしれません。
5. PBRマテリアル一式を再構築して検証する
ベースカラーと照明を分離します。描き込まれたハイライトは、動的な照明の下では不自然に見えることがあります。メタリック、ラフネス、法線のチャンネルを中立的な光で確認し、その後ゲームの照明でも確認してください。シェーダーの色空間と法線マップの規約、チャンネルのパッキング、透過モードを確認します。生成ツールがPBRマテリアルをうたっていても、これらの確認は実施してください。
有効な場合は、修正済みの元データから承認済みの実行用メッシュへディテールをベイクします。シーム、ベイクケージ、投影エラー、低ディテールのシルエットを確認してください。法線マップでは欠けた輪郭を復元できません。アセット群に利点がある場合は、互換性のあるマテリアルとアトラスを再利用します。三角形数だけでなくマテリアルスロットとドローコールも数え、後のアートディレクション変更に備えて編集可能なテクスチャの元データを保存してください。
6. リグを作成し、スキニングを確認する
動くキャラクターには、合意済みのスケルトンを作成または調整し、ボーンの向き、階層、命名を確認します。自動生成のリグにも同じ確認を行ってください。肩、腰、指、衣服の交差部分のウェイトを調整し、想定される動きを誇張したポーズでテストします。変形後に承認済みのキャラクターデザインを再確認してください。修正によっても見た目は変わる可能性があります。
ボーンの影響数とスケルトンの複雑さに関するエンジンの制限を確認します。必要な表情や補正用シェイプは作成し、生成された顔に最初から含まれていると思い込まないでください。装備や分離した髪のパーツなどの取り付け要素を確認します。今後のアニメーション制作に必要なレストポーズ、バインド情報、リグのコントロールは元ファイルに保存してください。
7. 実際に使うアニメーション一式を検証する
待機、歩行、方向転換、手を伸ばす動作、座る動作など、制作要件で求められるゲーム内アクションをテストします。床との接触、足滑り、手の位置、めり込み、スケールの変化を確認してください。移動にルートモーションを使うか、エンジン側で制御するトランスフォームを使うかを決め、その設定のまま遷移とループをテストします。
リターゲットでは、インポートした動きをキャラクターの最終的な体型で確認します。スケルトン名が一致していても、オフセットや接触が正しいとは限りません。リグレッションを発見できる小規模なアニメーション確認用シーンを保存し、エクスポート後に出荷用クリップをテストしてください。ループ境界のフレームを比較し、短いプレビューでは見逃し得る跳びを見つけます。
8. LODとコリジョンプロキシを作成する
アセットの想定用途に合わせて、詳細度（LOD）の異なるバリエーションを作成します。段階的にディテールを減らし、シルエットを維持しながら、切り替え時に気になる変化がないか確認してください。ジオメトリ削減と並行して、マテリアルとテクスチャの簡略化も計画します。キャラクターと繰り返し配置する小物では異なる方針が必要な場合があります。距離や投影サイズのしきい値は、シーンの実測結果から選んでください。
想定するインタラクションに合わせて単純なコリジョンプロキシを作ります。キャビネットならボックスと少数の可動形状を使えます。キャラクターでは、表示用の全三角形ではなく、プロジェクトのキャラクターコントローラー形状を使う場合があります。プロキシの命名と配置には一貫性を持たせます。エンジンで部品の開閉、ナビゲーション、物理挙動をテストしてください。生成時に予期しない内部面が残った箇所は、特に注意が必要です。
9. 実行用アセットをエクスポートし、検証・最適化する
Webで配信する場合、必要な機能をエンジンがサポートしていれば、GLBまたはglTF 2.0は有用な実行用形式です。マテリアル、スケルトン、選択したアニメーションを意図してエクスポートします。DCCのプロシージャルノードが、対応するマテリアルデータまたはベイク済みテクスチャになっていることを確認してください。Khronos glTF Validatorを実行し、エラーと警告を確認したうえで、インポートした結果を元データと比較します。
glTF Transformまたは同等のツールでエクスポートを調べ、未使用の内容を削除し、必要に応じて重複を統合します。メッシュ圧縮の選択肢は、ローダーの対応状況とデコード負荷を踏まえて比較してください。実行環境が対応している場合は、KTX2/Basisなどのテクスチャ圧縮を使います。未最適化のエクスポートを保存し、最適化後に見た目とアニメーションを再比較してください。ファイルサイズは受け入れ判断の一要素にすぎません。
10. シーン全体を対象デバイスでテストする
出荷用アセットを、想定インスタンス数、照明、影、アニメーションを備えた代表的なゲームプレイ状況で読み込みます。ネットワーク転送量、デコード時間、メモリ、フレームの挙動を個別に測定してください。背面、LODの切り替え、コリジョンの前提が確認できるカメラ距離とインタラクション状態をテストします。DCCやエディターのプレビューに加えて、リリースビルドと初回読み込みの挙動も確認してください。
モバイル性能が重要な場合、受け入れ確認には対象デバイスの実機を使ってください。デスクトップブラウザーのエミュレーションでレイアウトや機能の問題を発見できても、特定のスマートフォンの熱挙動やGPUの制約は再現できません。デバイス、ブラウザー／OS、シーン構成、測定値を記録します。シーン全体での負荷が予算を超えるアセットは修正または不採用とし、修正の影響を受ける確認を再実行してください。
11. 受け入れ済みアセットと確認資料をまとめる
元ファイル、修正済みテクスチャ、権利記録、最適化済みの実行用ファイル、命名とピボットの規則、確認資料を納品します。どのアニメーション、コリジョン状態、デバイスが確認を通過し、どれが未検証なのかを明記してください。受け入れ結果をアセットのバージョンと一緒に保存し、後の再生成で承認済みメッシュが知らないうちに置き換わらないようにします。
保存した元データを使い、今後の修正にかかるコストを見積もります。特に主要キャラクターでは、人によるクリーンアップが最初の生成より長くかかる場合があるため、その作業も記録してください。見た目、動き、インタラクション、パフォーマンスの要件がすべて満たされた時点で、アセットを受け入れます。
重要な決定事項
- 未加工の出力、編集可能な元データ、実行用エクスポートを別々に保存する。
- リトポロジー、リギング、スキニングを別個の制作作業として扱う。
- 破壊的な変換の後に、マテリアル、シルエット、アニメーションを再確認する。
- 対象デバイスの実機で、シーン全体をプロファイリングする。
- 受け入れ結果を納品したアセットのバージョンと一緒に保存する。
外部のモデル関連コミュニティやコンテンツ公開サイトには、露骨な表現を含むコンテンツが掲載されている場合があります。出典へのリンクは新しいタブで開きます。このガイドでは、リンク先のプレビューを読み込みません。