3d-asset-production

3D アセット制作

このスキルは、ほかのアーティスト、エンジン、ビューアー、マーケットプレイス、コンフィギュレーター、ゲーム、AR アプリ、レンダラーで実際に使えるよう、アセットを仕上げるためのものです。入力には、生成されたメッシュ出力、フォトグラメトリ、NeRF/GSplat 由来のメッシュ、スキャンデータのクリーンアップ、スカルプト、CAD 由来のポリゴン書き出し、手作業でモデリングしたジオメトリ、またはキットバッシュのドラフトが含まれる場合があります。出力は、予測可能なジオメトリ、スケール、マテリアル、テクスチャマップ、必要に応じた LOD、来歴を備えた、文書化および検証済みのアセットパッケージです。

ユーザーがアセットの準備、リトポロジー、クリーンアップ、最適化、ベイク、UV、PBR テクスチャ、LOD、リグへの引き継ぎ、静的メッシュの納品、スケルタルメッシュの準備、ゲーム用アセット、ウェブ用アセット、GLB/glTF/USD/FBX 書き出し、DCC からエンジンへの納品、または 3D モデルの QA を依頼した場合に使用します。

以下には使用しないでください。

• 特定の 3D 生成プロバイダーの選定や、そのプロバイダー向けのプロンプト作成。
• 環境、ショット、レベル、または構成済みシーン全体の構築。
• モーションキャプチャーセッションの実施や、モーションキャプチャーの演技の解決。
• 厳密な CAD、公差を考慮した製造、BIM 準拠、またはシミュレーション用のエンジニアリングジオメトリ。
• キャラクターの演技指導。ただし、このスキルでは、リギングやアニメーションへの引き継ぎに向けてメッシュを準備できます。

まず納品要件を確認する

トポロジーに手を加える前に、アセットを使用する側を明確にします。美しいメッシュでも、受け取り側のエンジンでテクスチャを読み込めない、単位スケールが間違っている、またはリギングチームがバインドできない場合は、納品に失敗しています。

以下の要件を確認するか、推定してください。

• アセットの役割：ヒーロープロップ、背景プロップ、アバターのボディ、モジュラー衣服、武器、乗り物、スキャンアーカイブ、AR 製品、ウェブコンフィギュレーターのアイテム、シネマティックアセット、マーケットプレイスアセット、モバイルアセット。
• 対象となる使用環境：Blender、Maya、Houdini、Unreal、Unity、WebGL/three.js/Babylon、USD パイプライン、DCC への引き継ぎ、カスタムランタイム、マーケットプレイス。
• ファイル形式：ソース DCC ファイル、.glb/.gltf、.usd/.usda/.usdc/.usdz、.fbx、テクスチャアーカイブ、プレビュー画像、検証レポート。
• ランタイム予算：三角形数、頂点数、マテリアル数、ドローコール／サブメッシュの目標、テクスチャ解像度、圧縮テクスチャ形式、LOD 数、メモリ／ダウンロードサイズ、対応拡張機能。
• 空間要件：実世界の寸法、単位系、軸／上方向の規約、ピボット、原点、境界、スナップポイント、ソケットポイント。
• マテリアル要件：PBR ワークフロー、色空間、テクスチャチャンネルのパッキング、透明度モード、法線の接線基底、レンダラー固有のシェーダー要件。
• アニメーション要件：静的メッシュ、スケルタルメッシュ、ブレンドシェイプ／モーフターゲット、クロス／ヘアの引き継ぎ、変形範囲、最大ボーン影響数、ルートボーン、命名規則。
• 権利要件：入力ソース、ユーザーの権利、第三者の参照資料、スキャンの同意、生成物の利用条件、商標／ロゴ、帰属表示、ライセンス、配布地域。

対象の要件が不明な場合は、推測してよいという意味ではなく、リスクとして扱います。ユーザーが予算を指定できない場合は、根拠のある基準値を設定し、提案予算として明記してください。

根拠の種類

このスキルでは、以下の 3 種類の主張を扱います。

• 文書化された事実は、公式仕様、ベンダーマニュアル、規格、またはプロジェクト文書に記載された情報です。出典はソースノートに示します。
• 実証的な観察は、繰り返し確認できる制作上の知見であり、ユーザーの実際のアセットと対象ランタイムで検証する必要があります。
• 制作上のヒューリスティックは、実務的な既定値です。普遍的なルールではないため、納品要件に応じて変更してください。

判断の基準となる文書化された事実

• glTF 2.0 は、API に依存しないランタイム向けアセット配信形式であり、オーサリング形式ではありません。シーンの記述を、JSON とバイナリバッファーおよび画像リソースの組み合わせ、または単一のバイナリーコンテナーである GLB として表現します。出典：Khronos glTF 2.0 仕様。2026-07-11 確認。https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html。
• glTF は、+Y が上、+Z が前、-X が右の右手座標系を使用し、直線距離の単位にはメートルを使用します。出典：Khronos glTF 2.0 仕様。2026-07-11 確認。
• glTF のコアマテリアルは、メタリック・ラフネス PBR です。ベースカラーのテクスチャーは sRGB、メタリック・ラフネスのテクスチャーデータはリニアで、緑チャンネルにラフネス、青チャンネルにメタルネスが格納されます。法線テクスチャーはタンジェント空間で、リニアです。出典：Khronos glTF 2.0 仕様。2026-07-11 確認。
• glTF のスキニングには、JOINTS_n と WEIGHTS_n 属性を使うリニアブレンドスキニングが使用されます。関節とウェイトのセットが 1 つの場合、頂点ごとに最大 4 つの影響を設定でき、JOINTS_n と WEIGHTS_n のセットは一致している必要があります。出典：Khronos glTF 2.0 仕様。2026-07-11 確認。
• glTF のノード変換には、行列または TRS のいずれかを使用できます。アニメーション対象のノードでは matrix を使用できません。アニメーションでは、translation、rotation、scale、または morph target weights を対象にします。出典：Khronos glTF 2.0 仕様。2026-07-11 確認。
• glTF Validator は、JSON／GLB の正しさ、内部参照、バイナリバッファー、NaN などの使用禁止のアクセサー値、アクセサーの範囲、スパースアクセサー、アニメーションデータ、画像、および複数の拡張機能を検証します。出典：KhronosGroup/glTF-Validator README。2026-07-11 確認。https://github.com/KhronosGroup/glTF-Validator。
• USD は、DCC パイプライン全体で 3D シーン記述をスケーラブルに交換、合成、レイヤー化、オーバーライド、整理できるよう設計されています。USD では、モデル、ジオメトリ、シェーディング、アニメーション、プライマリ、ペイロード、参照、バリアント、アセットメタデータを表現できます。ただし、USD 自体は高性能なリギングシステムではありません。出典：OpenUSD Introduction。2026-07-11 確認。https://openusd.org/release/intro.html。
• Unreal Engine の FBX パイプラインでは、スタティックメッシュ、スケルタルメッシュ、アニメーション、モーフターゲット、マテリアル、テクスチャー、および複数の LOD をインポートできます。また、Unreal は FBX 2020.2 をインポートパイプラインで使用すると説明しており、異なるバージョンの FBX でエクスポートすると互換性の問題が発生する場合があります。出典：Unreal Engine FBX Content Pipeline。2026-07-11 確認。https://dev.epicgames.com/documentation/en-us/unreal-engine/fbx-content-pipeline。
• Unreal のスケルタルメッシュアセットには、ビジュアルメッシュのジオメトリとスケルトンのボーンデータが含まれます。通常、外部の DCC ソフトウェアで作成し、FBX としてインポートします。出典：Unreal Engine Skeletal Meshes documentation。2026-07-11 確認。https://dev.epicgames.com/documentation/en-us/unreal-engine/skeletal-mesh-assets-in-unreal-engine。
• Unity のモデルファイルには、メッシュ、アニメーションリグ／クリップ、マテリアル、テクスチャーを含めることができます。Unity が主にサポートするモデルファイル形式は FBX です。ほとんどの場合、DCC からプロジェクトへ FBX を直接エクスポートすることを推奨しています。出典：Unity Manual, Importing a model。2026-07-11 確認。https://docs.unity3d.com/Manual/ImportingModelFiles.html。
• Unity のリグインポート設定では、アニメーションタイプとして None、Legacy、Generic、Humanoid を選択できます。Generic リグでは、Unity がルートノードを必要とします。スキンウェイトは、頂点ごとのボーン影響数とパフォーマンスに影響します。出典：Unity Manual, Rig tab Import Settings reference。2026-07-11 確認。https://docs.unity3d.com/Manual/FBXImporter-Rig.html。
• meshoptimizer では、メッシュのインデックス化、頂点キャッシュ最適化、オーバードロー最適化、頂点フェッチ最適化、量子化、簡略化、圧縮、解析ツール、および glTF 関連ツールを利用できます。推奨されるコアパイプラインでは、インデックス化の後にキャッシュ最適化、任意のオーバードロー最適化、フェッチ最適化、量子化、フィルタリング、任意のシャドウインデックス化を行います。出典：meshoptimizer README。2026-07-11 確認。https://github.com/zeux/meshoptimizer。

通常通用する制作上のヒューリスティクス

• 最も高性能なDCCではなく、最も制約の厳しいターゲットに合わせてアセットを仕上げます。モバイル向けWebGLビューアーとUnrealの両方がターゲットの場合、通常はウェブ側の予算がジオメトリ、マテリアル数、拡張機能、テクスチャサイズを制約します。
• 編集可能なソースファイルを保持し、ランタイム用の派生ファイルを書き出します。ユーザーがフラットな交換用パッケージを明示的に希望している場合を除き、GLB/FBX/USDZだけを唯一の信頼できるソースにしないでください。
• 下流の処理で必要な場合に限り、セマンティックメッシュを分割します。対象となる処理は、マテリアル割り当て、ソケット、破壊表現、アニメーション、コリジョン、オクルージョン、ユーザーによるカスタマイズ、カリングです。生成されたフラグメントごとにすべてを分割すると、通常はランタイム性能とアセットの使いやすさが損なわれます。
• ターゲットが別のトポロジーを明確に要求していない限り、リアルタイム配信にはインデックス付き三角形メッシュを優先します。コンシューマーが対応していない場合は、カーブ、サブディビジョン、ヘア、プロシージャルモディファイアー、高ポリゴンのスカルプトデータをランタイム書き出しではなくソースパッケージに保持します。
• ハイポリゴン、生成、スキャン済みのソースから、クリーンなローポリ／ミッドポリのレンダーメッシュにディテールをベイクします。ランタイムアセットでは通常、ノイズの多い高密度トポロジーではなく、法線、アンビエントオクルージョン、曲率／キャビティ、マテリアルマップに高周波ディテールを持たせます。
• 簡略化の際は、シルエット、変形領域、接触面、ソケット、UV／マテリアルの境界を維持します。内部の平坦な領域や、視覚的に隠れる裏面から優先的に削減します。
• 変形では、三角形数そのものよりも、規則的なエッジフローと安定したウェイトが重要です。クリーンなループを持つやや重いメッシュのほうが、過度にデシメーションしたメッシュよりもアニメーションに適している場合があります。
• ヒーローアセットは、実際のターゲットエンジン／ビューアーにインポートして確認します。バリデーターの合格は必要ですが、見た目の一致を保証するには不十分です。

受け入れ時のトリアージ

修復方法を決める前に、ソースを分類します。

生成メッシュの出力

一般的な特徴：テッセレーションの不均一、パーツの融合、非多様体のくぼみ、ノイズの多い法線、不定なスケール、UV設計の欠如、マテリアルロジックではなくベイク済みカラー、もっともらしいシルエットに対して機械的な構造が弱いこと。

最適な手順：

1. ソースアーカイブを凍結し、分かる場合は生成プロバイダー／モデル／設定を記録します。
2. メッシュがコンセプト参照用、高ポリゴンのベイク元、直接クリーンアップする候補のどれに当たるかを判断します。
3. トポロジーが混乱していても形状に価値がある場合は、デシメーションだけで済ませず、リトポロジーします。
4. 承認済みの表面の見た目からUVとPBRマップを再構築します。
5. 生成ツールのビューアーで目視するのではなく、インポートして検証します。

キャプチャまたはスキャンの出力

一般的な特徴：高密度、穴、スキャン時の影、アルベドにベイクされたテクスチャと照明、壊れやすい薄い表面、スケールのずれ、スキャン台／床のゴミ。

最適な手順：

1. 生のスキャン／フォトグラメトリーソースを保持します。
2. 実測した特徴やキャリブレーション用オブジェクトから実寸スケールを設定します。
3. ゴミを取り除き、物理的に妥当な箇所に限って欠損ジオメトリを再構築します。
4. 用途に応じて、クリーンなリトポロジーを作成するか、最適化されたデシメーションを行います。
5. 新しい照明に反応させる必要があるアセットでは、テクスチャから照明の影響を除去します。

モデリングまたはスカルプトの出力

一般的な特徴：意図がより明確で、未適用のトランスフォーム／モディファイアーがある可能性、高ポリゴンの隠れたディテール、重複するUVシェル、未対応のプロシージャルマテリアル。

最適な手順：

1. 意図したトランスフォームとモディファイアーのみを適用／書き出しします。
2. 役立つ場合は、非破壊レイヤーを含むオーサリングファイルを保持します。
3. ランタイムターゲット向けに、高ポリゴンまたはプロシージャルのディテールをマップにベイクします。
4. 書き出し後に、法線、タンジェント、UVセット、ピボット、単位スケールを検証します。

CAD 由来のポリゴン出力

共通する特徴：設計意図は正確ですが、テッセレーションが適切でなく、パーツやマテリアル ID が多数あり、微細なベベル、N ゴンやトリムの変換アーティファクトが生じ、実世界の単位が使われています。

最適な方法：

1. ポリゴン変換後の製造精度を保証しないでください。
2. ライセンスで許可されている場合は、CAD を由来情報や参照用として保持してください。
3. 表示距離に適した弦誤差と角度の許容値でテッセレーションしてください。
4. ランタイムで可能な場合は、繰り返し使われるパーツを結合するか、インスタンス化してください。
5. マテリアルを、レンダリング可能な PBR の近似表現として再構築してください。

ジオメトリとトポロジの修復

目標は理論上完璧なメッシュではなく、意図したレンダリング、変形、コリジョン、LOD、編集の各タスクを支えるトポロジを備えたメッシュです。

最低限の修復チェックリスト：

• UV、マテリアル、ハードノーマル、タンジェント、カラー、スキニングの境界に必要でない重複頂点を削除してください。
• 隠れた不要物、孤立した断片、意図しない内部シェル、面積がゼロまたはほぼゼロの三角形を削除してください。
• アセットの意図に応じて、非多様体エッジ、自己交差、反転した法線、開いた穴、一貫しない頂点の順序を修正してください。
• シルエットや鏡面反射の見え方を決めるハードサーフェスのサポートループやベベルを保持してください。
• 変形する領域や鏡面反射の強い表面では、細長い三角形を避けてください。
• マテリアル境界と UV シームは意図的に設定し、名前を付けて記録してください。
• 法線は意図的に使ってください。平面の機械表面にはフラット法線、連続する曲面にはスムーズ法線を使い、シェーディング設計の一部である場合はカスタム法線やウェイト付き法線を使ってください。

リトポロジーの判断：

• アセットを変形させる必要がある場合、きれいなベイクを行う場合、予測可能な LOD をサポートする場合、対称 UV を使用する場合、またはカメラで近くから確認される場合は、リトポロジーを行ってください。
• アセットが静的で、スキャンされたもので、ほぼ有機的な形状で、変形せず、編集のしやすさより元のディテールが重要な場合は、デシメートしてください。
• 生成された機械のパーツが融合しているなど、見た目はもっともらしくても物理的に一貫性がない場合は、作り直してください。

トポロジの QA：

• シェーディング表示にワイヤーフレームを重ね、近距離と遠距離から確認してください。
• 対象の FOV と距離でシルエットを確認してください。
• コントラストの高い HDRI またはスタジオ照明でスムージングをテストしてください。
• エクスポートとインポートを往復した後に、表面に裂け目がないことを確認してください。
• 変形するアセットでは、承認前に極端な屈曲やひねりのポーズをテストしてください。

スケール、軸、原点、ピボット、命名

スケールの誤りは、物理演算、アニメーション、カメラのフレーミング、ライティング、AR 配置、UI への適合に波及するため、修正コストが高くなります。

次の項目を設定し、記録してください。

• 単位の基準：メートル、センチメートル、または対象エンジンの単位。
• 実寸：バウンディングボックスと主要な寸法。
• 向き：上軸、前方軸、正面の規約、および形式変換の有無。
• ピボット／原点：面に置く小道具には底面中央、物理演算に使う小道具には重心、ドアや車輪にはヒンジ点、武器やツールにはグリップ点、キャラクターには対象の指定がない限り両足の間の床面にルートを設定してください。
• トランスフォーム：対象のパイプラインで作成時のトランスフォームが必要な場合を除き、エクスポート前にスケールと回転を適用して固定してください。
• 命名：オブジェクト、マテリアル、ボーン、ソケット、UV セット、テクスチャ、LOD には、安定した ASCII 名を使用してください。自動生成された意味不明な名前や重複したマテリアル名は避けてください。

glTF で納品する場合は、文書化された座標系と単位の規約、すなわち右手系、+Y が上、+Z が前方、単位はメートルであることを覚えておいてください。作成に使用する DCC やエンジンで異なる規約を使う場合は、エクスポーターとインポーターによる変換を明示的にテストしてください。

UV 戦略

UV は、テクスチャ解像度、シーム、ベイク、マテリアルの再利用を実現するための仕組みです。

アセットの役割に応じて UV レイアウトを選択します。

• 固有のヒーローアセット：ベイクした PBR マップ用に UV0 を重複しないよう配置し、テクセル密度を統一します。ペイントしやすいようにシェルを整列させ、背面や折り目、マテリアルの切り替わり部分にシームを隠します。
• タイル可能なマテリアルアセット：UV0 には繰り返し可能な座標を使用できます。エンジンで必要な場合は、ライトマップまたはベイクしたマスク用に、重複しない 2 つ目の UV セットを作成します。
• ミラーリングしたキャラクターまたはプロップ：左右対称のアルベドやラフネスにはミラーリングを使用できますが、判読可能なロゴ、非対称なダメージ、タンジェント空間の法線マップ、ベイクした AO には問題が生じるおそれがあります。必要に応じてミラーリングした領域を分割またはオフセットします。
• モジュラーキットのパーツ：スナップしやすい UV、モジュール間で統一されたテクセル密度を使用し、プロジェクトですでに採用されている場合はトリムシートを使います。
• スキャン由来のアセット：安定した再投影ができるように展開します。再ライティングが必要な場合は、アルベドからベイクしたライティングやシャドウを除去します。

UV の QA：

• ベイク用 UV セットに意図しない重複がないこと。
• 最終的なミップチェーンとテクスチャ解像度に対して十分なパディングがあること。
• 同時に表示されるサーフェス間でテクセル密度が統一されていること。
• シームが、すでにジオメトリ、マテリアル、または視認性によって隠れる位置にあること。
• チェッカーテクスチャで、深刻な伸び、反転したアイランド、またはスケールの異なるシェルが確認されないこと。
• 対象エンジンが、マテリアル、ライトマップ、デカール、またはランタイムエフェクトに必要なすべての UV セットを認識すること。

PBR マテリアル、ベイク、テクスチャのパッケージング

ソースに含まれていた内容ではなく、対象のシェーディングモデルに合わせてマテリアル出力を作成します。

一般的な PBR マップセット：

• ベースカラー／アルベド：サーフェスカラーのみを含めます。対象が意図的にライティング済みテクスチャを求めている場合を除き、ベイクした直接光は含めません。
• 法線：対象がオブジェクト空間またはワールド空間の法線を求めている場合を除き、リアルタイムアセットにはタンジェント空間を使用します。
• ラフネス：微細なサーフェスの反応を表します。妥当な変化を保ち、汎用的な汚れマップとして使うことは避けます。
• メタリック：通常、実金属と誘電体をマテリアル領域ごとに二値で表します。混在テクセルまたは対象固有のマテリアルを表す場合を除き、安易なブレンドとしてグレーのメタリックを使うことは避けます。
• アンビエントオクルージョン：間接的な遮蔽の乗算値またはマスクです。アルベドに強い直接シャドウをベイクしないでください。
• エミッシブ：作成した発光色／強度を表します。対象のシェーダーがアンリットである場合を除き、ライティングの代用にはしません。
• 不透明度／アルファ：ソートと深度の挙動が異なるため、カットアウト／マスクかブレンドかを意図的に選択します。

ベイクの手順：

1. 最終ベイクの前に、ローポリメッシュ、スムージンググループ／カスタム法線、UV、ケージを確定します。
2. テクスチャリングに必要な法線、AO、曲率、厚み、位置、ID／マテリアルマスク、および高さ／ディスプレイスメントをベイクします。
3. 歪み、波打ち、投影漏れ、ケージの交差、ミラーリングしたタンジェントのシームを確認します。
4. トポロジー、UV、または法線を変更した場合は再ベイクします。変更が局所的であり、検証済みの場合を除き、メッシュの変更を隠すために法線マップを修正しないでください。
5. カラースペースとチャンネルのパッキングを文書化したうえでマップを書き出します。

glTF 固有のマテリアル納品：

• glTF／GLB を納品する場合は、基本の交換用マテリアルとしてメタリック・ラフネス方式を使用します。
• コアの metallicRoughnessTexture では、ラフネスを G に、メタリックを B にパックします。
• ベースカラーとエミッシブは sRGB 入力として扱います。法線、オクルージョン、メタリック、ラフネスの各データは、glTF の規則に従ってリニアとして扱います。
• 必要な glTF 拡張機能を記録します。拡張機能なしではアセットを適切に読み込めない、または描画できない場合を除き、拡張機能を必須として指定しないでください。

マテリアルの QA：

• 少なくとも 1 つのニュートラルな HDRI と、1 つの直接光／キーライトのセットアップでテストします。
• 対象のレンダラーで、ソースとエクスポート後のレンダリングを並べて比較します。
• タンジェント空間の法線の向き、特に緑チャンネルの規則と、ミラーリングした UV のシームを確認します。
• 透明マテリアルが、想定する対象で適切にソートされることを確認します。
• インポート後もテクスチャのファイル名とマテリアルスロット名が維持されることを確認します。

LOD と最適化

LOD の作業は、三角形ポリゴンを減らすだけではありません。マテリアル、タンジェント、スキニング、コリジョンの挙動を安定させながら、視覚的な情報をどの程度失うかを制御する作業です。

LOD の計画：

• LOD を生成する前に、ターゲットプラットフォームと画面サイズのしきい値を定義します。
• LOD 間でマテリアルとテクスチャを共有するか、アトラスのバリエーションを使うか、距離に応じてマテリアルスロットを統合するかを選択します。
• 内部表面のディテールよりもシルエットを優先して維持します。
• スケルタルアセットでは、関節、顔や手、アタッチメント、布の境界を保護します。
• モジュラーアセットでは、共有境界を固定するか、グループをまとめて簡略化して、隣接パーツ間の隙間を防ぎます。

リアルタイムメッシュの最適化は、多くの場合、次の順序で進めます。

1. トポロジーをクリーンアップして頂点を溶接し、メッシュをインデックス化します。
2. UV、法線、タンジェント、頂点カラー、マテリアル ID、スキンウェイトを確定します。
3. LOD を生成するか、ヒーローアセットや変形するメッシュにはアセット固有の手動 LOD を使用します。
4. ランタイムで効果が得られる場合は、頂点キャッシュと頂点フェッチ向けにインデックス順を最適化します。
5. ターゲット距離で視覚的に検証した後にのみ、量子化または圧縮を行います。
6. 圧縮や拡張機能を使用した後に、ターゲットエンジンまたはビューアーで検証します。

目安となる予算は、カメラまでの距離、プラットフォーム、シェーダーのコスト、プロジェクトのスタイルに大きく左右されます。ユーザーが予算を指定していない場合は、普遍的な数値ではなく範囲を提案します。

• Web／モバイル向けの背景プロップ：単一マテリアル、小さなテクスチャ、積極的な LOD、GLB のサイズを優先します。
• Web／モバイル向けのヒーロー製品：シルエットとマテリアルの品質を維持し、まず非表示／内部のジオメトリとテクスチャ数を減らします。
• PC／コンソール向けのヒーロープロップ：シルエットとベイクの品質のために多くのジオメトリを使用できますが、マテリアルスロットとテクスチャメモリは引き続き制限します。
• シネマティック／オフラインアセット：高解像度のソースと USD／マテリアルの受け渡しを維持します。ランタイムでの圧縮は重要でない場合があります。

利用可能な場合は、アナライザーとターゲット環境でのプロファイリングを使用します。meshoptimizer のアナライザーでは、頂点キャッシュ、頂点フェッチ、オーバードローの挙動を推定できますが、同ツールのドキュメントにもあるように、正確なパフォーマンスはターゲット GPU で測定する必要があります。

静的メッシュの準備状況

静的メッシュパッケージは、配置、インスタンス化、コリジョン、ライティング、レンダリングにすぐ使用できる状態にしておく必要があります。

静的メッシュの準備状況チェックリスト：

• スケール、向き、ピボット、トランスフォームが正しいこと。
• メッシュがクリーンで、意図しない非多様体のレンダリングアーティファクトがないこと。
• マテリアルスロットとマテリアル名が意図どおりであること。
• サーフェステクスチャ用の UV0 があること。ライトマップ、マスク、デカール、またはターゲット固有の要件用には追加の UV を用意します。
• エンジン側で生成する必要がある場合は、コリジョンメッシュまたはコリジョンに関する注記があること。
• マテリアルスロットの対応関係が安定した LOD があること。
• 必要に応じて、ソケット／アタッチメントのマーカーがあること。
• カリングと配置に適したバウンズと原点であること。
• プレビュー用サムネイル／レンダーとインポート時の注記があること。

スケルタルメッシュとリグの引き渡し準備

このスキルは、リギングやインポートに向けてアセットを準備するものであり、リガーの代わりにはなりません。

スケルタルメッシュの準備チェックリスト：

• メッシュのトポロジーが、肩、肘、膝、口、目、指、布の折り目、機械のヒンジ周りの変形ループに対応している。
• 対称性が意図的に設定されており、非対称のジオメトリには明確な名前が付けられ、適切に配置されている。
• ボーンの命名、階層、ルート、スケール、向きが、受け取り側のリグ規格に準拠している。
• バインドポーズ／レストポーズが記録され、エクスポートされている。
• スキンウェイトが正規化され、負の値がなく、対象の影響数制限内に収まっている。
• 非表示のデブリやヘルパーメッシュに、意図しないウェイトが設定されていない。
• ブレンドシェイプ／モーフターゲットのトポロジーと名前が一致し、エクスポート後も維持される。
• 補正シェイプ、しわマップ、布／ヘアカード、ソケット、アタッチメントポイントに名前が付けられ、納品されている。
• 変形テストでは、Aポーズ／Tポーズだけでなく、想定される最大可動範囲をテストしている。

glTF スキニングでは、JOINTS_n と WEIGHTS_n のセットがペアになっていること、ジョイントインデックスが有効であること、ウェイトの合計が選択したコンポーネント型に対して有効であることを確認してください。Unity では、None／Generic／Humanoid の選択とルートノードの動作を決めてください。Unreal では、FBX のスケルタルインポート、Skeleton アセットの作成、必要に応じたモーフターゲットのインポート、アニメーションとの互換性を検証してください。

リグ引き渡しパッケージ：

• バインドポーズを含むクリーンなメッシュのソースファイル。
• ベイクに使用した場合は、別途ハイポリ／スカルプトのソース。
• テクスチャマップとマテリアル定義。
• ボーン／メッシュの命名ガイド。
• 変形に関するメモと既知の問題箇所。
• エクスポート設定と対象エンジンのインポート設定。
• DCC とエンジンでの検証スクリーンショット。

フォーマットの選択と相互運用

人気ではなく、維持する必要がある要素に基づいてフォーマットを選んでください。

glTF / GLB

アセットをランタイム配信、Web、AR プレビュー、軽量な交換、または幅広いビューアーとの互換性に使用する場合に選びます。単一ファイルで引き渡す場合は .glb を優先し、テクスチャとバッファーの分離がアセット管理に役立つ場合は、外部リソースを使用する .gltf を選んでください。

強み：

• コンパクトなランタイムアセットの配信。
• 座標、単位、マテリアルの挙動が定義されている。
• PBR のメタリック・ラフネスの基本仕様。
• Web／ビューアーのエコシステムが充実している。
• 検証ツールがある。

リスク：

• オーサリング用フォーマットではありません。多くの DCC 固有のモディファイアー、シェーダー、制約、プロシージャルシステムは維持されません。
• 拡張機能のサポートはビューアーによって異なります。
• リグやアニメーションの挙動は、エンジンによってインポート結果が異なる場合があります。

USD / USDZ

アセットが、合成を行う DCC／映画／VFX パイプラインに属し、参照、バリアント、レイヤー、ペイロード、primvars、マテリアルネットワーク、または USDZ による AR プラットフォーム向けパッケージ化が必要な場合に選びます。

強み：

• 強力な合成およびオーバーライドモデル。
• 大規模な制作パイプラインにも対応します。
• モデル、ジオメトリ、シェーディング、アニメーション、アセットメタデータ、参照、バリアント、ペイロードを格納できます。
• 高忠実度の制作向け交換レイヤーとして役立ちます。

リスク：

• USD は汎用的なリギングシステムではありません。
• マテリアルネットワークとスキーマへのレンダラーおよび DCC の対応状況は異なります。
• 名前空間の変更によって下流のオーバーライドが壊れる可能性があるため、安定した prim パスが重要です。

FBX

対象の DCC／エンジンのパイプラインで、特に Unity や Unreal のワークフローにおいて、スタティックメッシュ、スケルタルメッシュ、アニメーションクリップ、モーフターゲット、またはレガシーな相互運用に FBX が必要な場合に選びます。

強み：

• 一般的な DCC／エンジン間の橋渡しになります。
• メッシュ、スケルトン、アニメーション、ブレンドシェイプ／モーフターゲット、マテリアル／テクスチャを、さまざまな程度で保持できます。
• Unreal と Unity はどちらも、FBX を中心としたモデルのインポートワークフローを公開しています。

リスク：

• バージョンとエクスポーターの違いが重要です。Unreal のパイプラインでは FBX 2020.2 が指定されています。
• マテリアルの変換は近似的なものになることが多いため、必ず対象エンジンでテストしてください。
• 軸、単位、プリ／ポスト回転、アニメーションのベイク設定によって、わずかなインポートエラーが発生する場合があります。

ソース DCC パッケージ

ユーザーが今後編集する必要がある場合に使用します。ライセンスと受け取り側のツール環境が許す場合に限り、.blend、.ma／.mb、.max、.hip、.c4d、.spp、.ztl、またはプロジェクト固有のファイルを含めます。

長所：

• 制作レイヤー、モディファイアー、ハイポリゴンのソース、リグ、プロシージャルマテリアル、編集可能なコンテキストを保持できます。

リスク：

• 交換形式よりも互換性が低くなります。
• 商用ソフトウェアやプラグインが必要になる場合があります。
• 未使用の参照やライセンス対象のアセットが誤って含まれることがあります。

納品パッケージのパターン

本番環境で使用できるスタンドアロンアセットを納品する場合は、次のようなパッケージを用意します。

• source/：編集可能なソースファイル、高ポリゴンのソース、ベイクケージ、許可されている場合はスカルプトまたはスキャンの参照資料。
• export/：最終版の .glb、.gltf、.usd／.usdz、.fbx、または対象固有のインポートファイル。
• textures/：わかりやすい名前、解像度、カラー空間、チャンネルパッキングを設定した最終マップ。
• previews/：ニュートラルレンダー、ワイヤーフレーム、UV チェッカー、エンジン／ビューアーのスクリーンショット。
• docs/：readme、寸法、予算、座標規約、エクスポート／インポート設定、権利／来歴、既知の制限事項。

ユーザーがファイルを 2 つだけ、または最終アセットを 1 つだけ明示的に求めている場合も、必要に応じて同じ情報を readme のセクション、アセットのメタデータ、または回答の概要に含めてください。

検証と QA

検証は、構造、ビジュアル、本番利用の 3 層で行います。

構造検証：

• 対象の DCC／エンジン／ビューアーでエラーなくファイルを開けること。
• glTF/GLB が glTF Validator に合格し、エラーがなく、許容される警告のみであること。
• 完全な検証や引き渡しの前に glTF/GLB パッケージをトリアージする場合は、利用可能であれば同梱の Python プリフライトヘルパーを実行します：python scripts/inspect_gltf.py path/to/asset.gltf または python scripts/inspect_gltf.py path/to/asset.glb。安定した JSON を出力し、プリフライトエラーが見つからない場合は 0、検証結果が見つかった場合は 2、読み取り／解析／コンテナの運用上の失敗が発生した場合は 3 で終了します。
• USD を usdview または対象の USD コンシューマーで開けること。prim パス、バリアント、参照、ペイロード、マテリアルバインディングが解決されること。
• 正しいスケール、法線、UV、マテリアルスロット、スケルトン、モーフターゲット、アニメーション設定で、正確な対象エンジンのバージョンに FBX をインポートできること。
• テクスチャリンクが相対パスであるか、必要に応じてパッケージ化されていること。
• ファイルの欠落、絶対ローカルパス、隠れた依存関係、未対応の拡張機能がないこと。

同梱の scripts/inspect_gltf.py ヘルパーは、範囲を限定したプリフライトであり、適合性バリデーターではありません。.gltf JSON または GLB v2 コンテナの JSON チャンクを安全に読み取り、GLB ヘッダー、宣言された長さ、チャンクの順序、チャンクの切り詰め、JSON チャンクの解析、最初の BIN チャンクとの関係を確認します。また、シーン、ノード、メッシュ、プリミティブ、マテリアル、テクスチャ、画像、アニメーション、スキン、カメラ、アクセサー、バッファー、bufferView、サンプラーを一覧表示し、絶対パス、パストラバーサル、ルート外のパス、スキーム／クエリ／フラグメントを含む URI、存在しないローカル外部バッファー／画像 URI を拒否します。データ URI を記録してサイズを検査し、デフォルトシーン、シーンノード、ノードのメッシュ／スキン／カメラ／子ノード、メッシュのプリミティブアクセサー／マテリアル／モーフターゲット、マテリアルのテクスチャ情報、テクスチャ／画像／サンプラー、バッファー／bufferView／アクセサー、スキン、アニメーションのサンプラー／チャンネルに関する一般的なインデックス参照ミスを検出します。

プリフライトに問題がなかった場合も、必ず Khronos glTF Validator で完全な glTF の正確性、バイナリアクセサーデータ、画像コンテンツ、スパースアクセサー、拡張機能の動作、NaN／Infinity と数値制約、スキーマ全体を検証してください。その後、受け取り側の DCC、エンジン、またはビューアーにアセットをインポートし、ビジュアル／マテリアル／アニメーションの QA を行います。プリフライトに問題がなかったということは、パッケージの構造が妥当であり、ローカル依存関係を安全に読み取れることを示すにすぎません。

ビジュアル検証：

• カメラとライティングを合わせて、ソース、DCC からのエクスポート、対象へのインポートを比較します。
• ベイクのクローズアップ、シルエット、ハードエッジ、透明度、デカール、発光マテリアル、ミラーリングされた領域を確認します。
• UV チェッカーとテクスチャ密度を確認します。
• 対象の距離で LOD の遷移を検証します。
• スキャンデータでは、リライティングを想定している場合に、アルベドに不要な影やハイライトが含まれていないことを確認します。

本番利用の検証：

• クリーンな対象プロジェクトにアセットを配置します。
• ピボットの位置、スケール、スナップ動作、ソケット、バウンディングボックスをテストします。
• 必要に応じてコリジョンをテストします。
• メモリ／ダウンロード／ビルドサイズが予算内であることをテストします。
• スケルタルアセットの場合は、アニメーションの変形、ルートの動作、リターゲティング、モーフターゲットをテストします。
• 別のマシンまたはクリーンなワークスペースで、納品パッケージから再インポートします。

一般的な不合格要因：

• 実寸スケールまたは軸の向きが間違っている。
• 絶対パスが原因でテクスチャが見つからない。
• 対象環境で見える、非多様体または自己交差によるレンダリングアーティファクトがある。
• マテリアルが、ベイク済みの代替手段なしで、未対応のプロシージャル機能／シェーダー機能に依存している。
• ノーマルマップのタンジェントが一致せず、継ぎ目や光の反転が発生する。
• テクスチャの色空間が間違っている。
• LOD 間でマテリアルスロットの順序が変わる、または切り替わりが著しい。
• リグのウェイトが対象の制限を超えている、または正規化されていない。
• スキャン／生成／サードパーティの入力データについて、権利／来歴の記録がない。

権利、同意、および来歴

すべてのアセットには、制作時の来歴記録が必要です。

次の項目を記録します。

• ソースの種類：生成、スキャン／撮影、モデリング、購入、クライアント提供、オープンアセット、社内ライブラリ、CAD 由来。
• ソースの所有者、およびライセンスまたは利用条件。
• 生成した場合は、生成プロバイダー／モデル／設定と日付。
• 実在の物件、人物、作品、ブランド製品、またはプライベートな空間をスキャンした場合は、撮影場所／日付、および同意／許諾の状況。
• 第三者の参照物、商標、ロゴ、ラベル、特徴的な製品形状、および権利処理の状況。
• 人物を描写するアセットの場合は、肖像、生体認証、または個人データに関する問題。
• 実施した変更：リトポロジー、テクスチャの塗り直し、マテリアルの再構築、ポリゴン削減、形式変換、最適化。
• 再配布の許可、および帰属表示の要件。

パッケージをすっきりさせるためだけに、著作権表示、クリエイターのメタデータ、またはライセンスファイルを削除しないでください。来歴が不完全な場合は、配布許可が確認されていないアセットとして表示してください。

例：生成した椅子を Web 対応の GLB にする

これは一例であり、必須の手順ではありません。

制作目的：生成したモダンなラウンジチェアのメッシュを、Web の製品コンフィギュレーター用アセットに変換します。

入力と制約：

• ソース：28 万トライアングル、頂点カラーあり、使用可能な UV なしの生成 OBJ。
• ターゲット：GLB を使用する WebGL ビューアー、ダウンロードサイズ 8 MB 未満を目標、2 種類のカラーバリエーション、製品の高さ 0.82 m、静的メッシュ。
• 必須事項：バリエーションごとに GLB を 1 つ、ニュートラルなプレビュー画像、来歴に関する注記。

ワークフロー：

1. ソース OBJ をアーカイブし、取得できる場合は生成ツール、プロンプト、シード／設定、日付を記録します。
2. ターゲット寸法を測定し、椅子の高さが 0.82 m になり、座面が床面に接するようにモデルをスケーリングします。
3. シルエットが整った静的なローポリメッシュとしてトポロジーを再構築します。マテリアルの分離が必要な場合に限り、クッションとフレームを分けます。
4. クッションの下にある内部の隠れた面や、融合した不要なジオメトリを削除します。
5. 重複のないシェル、均一なテクセル密度、クッションの縁やフレームの背面に隠れるシームを備えた UV0 を作成します。
6. 元のハイポリソースから、クリーンアップしたメッシュに法線と AO をベイクします。
7. PBR マテリアルを作成します。ファブリックのベースカラーと粗さの変化を設定し、メタルフレームの metallic を 1 にして、参照画像に合わせて粗さを調整します。
8. glTF のメタリック・ラフネステクスチャをパックし、粗さを G、金属度を B に設定します。ベースカラーは sRGB として、データマップはリニアとして書き出します。
9. ビューアーがサポートしている場合は LOD1／LOD2 を生成するか、実行時の簡略化を利用します。含める場合は切り替えをテストします。
10. GLB を書き出し、glTF Validator で検証します。
11. 実際の Web ビューアーで GLB を開き、スケール、マテリアルの反応、テクスチャのシーム、ファイルサイズを確認します。

期待される結果：

• エラーなく読み込める GLB です。正しいスケールで表示され、ファブリックと金属の PBR マテリアルが整っており、ダウンロードサイズの上限内で製品のシルエットが保たれています。

想定される失敗：

• 生成メッシュでクッションが物理的に不自然に交差しており、手作業での再モデリングが必要です。
• 頂点カラーの見た目をクリーンなアルベドに直接変換できず、テクスチャの塗り直しが必要です。
• 過度な簡略化によって、椅子の脚やクッションのシームが損なわれます。
• ビューアーが、エクスポーターで使用された glTF 拡張機能に対応していません。

有意義なバリエーション：

• AR 用では、実寸の検証をより厳密に行い、必要に応じてプラットフォーム固有の USDZ を追加します。
• デスクトップのヒーロービュー用では、テクスチャ解像度を上げ、ベベルのディテールを保持します。
• 大規模な製品カタログ用では、すべての椅子でピボット、命名、テクスチャのパッキング、マテリアルのバリエーションを標準化します。

例：フォトグラメトリーの彫像をエンジン用プロップに変換する

これは例であり、必須の手順ではありません。

制作の目的：フォトグラメトリーで作成した彫像のスキャンを、Unreal と Unity で使える静的プロップに変換します。

入力と制約：

• ソース：2,200 万三角形のスキャン、16k のディフューズテクスチャ、不均一な照明、張り出し部分の下に穴があります。
• 目標：Unreal/Unity 用の FBX とテクスチャ、3 つの LOD、コリジョンプロキシ、台座を含む高さ 1.4 m。
• 必須事項：美術館の所蔵品を正確に複製したというライセンス上の主張は行いません。権利が確認されるまでは、内部でのビジュアライゼーションに限ります。

ワークフロー：

1. 元のスキャン、カメラセット、再構築メタデータを保持します。
2. 撮影許可を確認し、権利の確認が済んでいない場合は、再配布のステータスを内部使用のみと明記します。
3. 測定した台座の高さを基準にスケールを設定し、台座の底面中央にピボットを置きます。
4. 床やテーブルの不要な部分を除去し、彫像が連続しているはずの箇所の穴を埋めます。
5. リトポロジーまたは制御されたデシメーションでクリーンなレンダーメッシュを作成し、顔、手、シルエット、彫刻されたエッジを保護します。
6. ベイクしたマップ用に UV0 を作成し、対象のエンジンやプロジェクトで必要な場合はライトマップ用に UV1 も作成します。
7. ディフューズテクスチャのライティングを除去するか、ベースカラーを塗り直して、撮影時の影やハイライトを取り除きます。
8. スキャンからレンダーメッシュにノーマル、AO、曲率をベイクします。
9. シルエットを保ちながら LOD を生成し、両方のエンジンで切り替わりを検証します。
10. ゲームプレイに必要な範囲で台座と本体に合う、シンプルな凸形状またはカスタムのコリジョンプロキシを作成します。
11. 対象エンジンの設定で FBX をエクスポートします。クリーンな Unreal プロジェクトと Unity プロジェクトにインポートし、スクリーンショットを撮影します。

期待される結果：

• 適切なスケール、安定したマテリアル、コリジョン、LOD を備え、内部使用に関する権利のステータスを文書化した静的プロップのパッケージです。

起こりやすい失敗：

• ベースカラーにベイクしたライティングが残り、エンジンのライティング下で不自然に見えます。
• 細い指や彫刻されたエッジが LOD で崩れます。
• FBX のインポートで単位変換が正しく設定されず、彫像が 100 倍大きく、または小さくなります。
• Unity と Unreal ではマテリアルのインポート時に粗さやメタリックの扱いが異なるため、エンジン固有のマテリアル調整に関する注記が必要になります。

有意義なバリエーション：

• 美術館でのアーカイブ用途では、高解像度の USD/ソースパッケージを保持し、クリーンアップを控えめにします。
• モバイル向けでは、マテリアルスロットを減らし、テクスチャセットを小さくします。
• シネマティック用途では、オフラインレンダリング向けにディスプレイスメントまたはハイポリのソースを保持します。

例：リグ受け渡し用のキャラクター衣装メッシュ

これは一例であり、必須の手順ではありません。

制作目的：既存のヒューマノイドキャラクターにリギングするため、生成されたジャケットメッシュを準備します。

入力と制約：

• ソース：生成されたジャケットメッシュ、95k トライアングル、リグなし、ジッパー／ボタンは粗い状態、既存のキャラクタースケルトンに使用する想定です。
• ターゲット：DCC でのリギング受け渡しと FBX テストインポート。ランタイムでは頂点ごとのボーン影響数を最大 4 にします。
• 必須要件：肩、肘、胴体のひねり、襟周りで、きれいに変形すること。

ワークフロー：

1. バインドポーズでジャケットを承認済みのキャラクターボディに合わせ、位置合わせを確認してからトランスフォームをフリーズします。
2. 開いた襟や袖口に必要な場合を除き、隠れた内側のジオメトリを削除します。
3. 肩、肘、袖口、裾、襟の周囲にループを設けてリトポロジーします。ジッパー／ボタンを剛体として扱う、または交換する場合は、別メッシュのままにします。
4. 衣服の縫製ラインや隠れた裏側に沿ってシームを設け、UV を作成します。
5. ハイポリ／生成ソースから、布の織り目や縫い目のディテールをノーマル／AO マップにベイクします。
6. メッシュ／マテリアルに jacket_body、zipper_teeth、button_L/R、mat_jacket_fabric など、予測しやすい名前を付けます。
7. ボディまたはガイドリグからスキンウェイトを転送／試作し、正規化してターゲットの影響数上限に収めます。
8. 腕上げ、肘曲げ、胴体のひねり、しゃがみ、襟と頭部の接触をテストします。
9. ソース DCC ファイル、FBX テスト書き出し、テクスチャ、バインドポーズのメモ、ウェイトに関する問題箇所、リギング上の前提条件を納品します。

期待される結果：

• 予測どおりに変形し、リガーがメッシュ／マテリアル／ウェイトの構成を把握しやすい、リギング対応の衣装アセットです。

起こりやすい問題：

• 生成されたしわが不規則なトライアングルとしてモデル化され、変形時に崩れます。
• ボタンが布と一体化していて、スキニング時に引き伸ばされます。
• UV が縫い目をまたいで伸び、布の織り目がずれて見えます。
• ボーン影響数の上限を超えている、または転送後にウェイトが正規化されていません。

有意義なバリエーション：

• クロスシミュレーションでは、最終的なスキニング用トポロジーではなく、布パネルを分けたまま、ソルバーに適したトポロジーを維持します。
• ヒューマノイド以外のリグでは、ヒューマノイドを前提とした条件を、プロジェクトで実際に使用するスケルトンとルート要件に置き換えます。
• シネマティックのクローズアップでは、ソースの受け渡し時にディスプレイスメントや、より高解像度の布ディテールを追加します。

ソース注記

特に記載がない限り、ソースは 2026-07-11 に確認済みです。

• Khronos glTF 2.0 仕様：https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html.
• KhronosGroup glTF Validator：https://github.com/KhronosGroup/glTF-Validator.
• OpenUSD 入門：https://openusd.org/release/intro.html.
• Unreal Engine FBX コンテンツパイプライン：https://dev.epicgames.com/documentation/en-us/unreal-engine/fbx-content-pipeline.
• Unreal Engine スケルタルメッシュ：https://dev.epicgames.com/documentation/en-us/unreal-engine/skeletal-mesh-assets-in-unreal-engine.
• Unity マニュアル、モデルのインポート：https://docs.unity3d.com/Manual/ImportingModelFiles.html.
• Unity マニュアル、Rig タブのインポート設定リファレンス：https://docs.unity3d.com/Manual/FBXImporter-Rig.html.
• meshoptimizer README：https://github.com/zeux/meshoptimizer.