blender-image-to-3d

Blender 画像から3Dへ

1枚以上の参照画像から、段階ごとのゲートを通過してゲームアセットを完成させます。 各ゲートは、ビューポートを見て問題なさそうだと判断するのではなく、同じカメラと ゲームプレイ時のピクセルサイズで参照画像と比較したレンダリング結果を使って通過します。 このワークフローで最も無駄になりやすい作業は、誤ったプロポーションの上にディテールを 追加することです。そのため、シルエットの合格まではディテールを追加しません。

ここでいう「完璧」には定義があります。references/delivery-and-acceptance.md の 受け入れチェックリストに合格し、比較シートでフェーズごとの許容範囲を超える測定上の ずれがなく、参照画像に示されていないすべての寸法や面が「推定」として記載されている ことです。1枚の画像から推定せざるを得ない場合は、その旨を明記してください。推測した 背面を事実として提示してはいけません。

実行環境

• Blender 4.2 以降（5.2 までで使用）、ヘッドレスで実行します：blender --background --python <script> -- <args>。 Blender 5.x では、これらのビルドが使用する API がいくつか変更されています。 references/blender-5-notes.md に、実行時、ベイク、レビューに関する変更点や注意事項をまとめています。 バイナリは一度だけ解決します：$BLENDER_BIN、次に PATH 上の blender、最後に /Applications/Blender.app/Contents/MacOS/Blender の順です。macOS または Windows では、Workbench のレンダリングに GPU は不要です。GPU のないヘッドレス Linux マシンでは、review_render.py に --engine cycles を渡してレビューしてください。
• MCP サーバー（execute-Python ツール）経由で稼働中の Blender セッションを使うこともできますが、必須ではありません。インスペクションに便利です。その場合も、番号付きスクリプトで構築し、同じマスターファイルを保存して、ビルドの再現性を保ってください。稼働中のセッションでは、コマンドラインの代わりに exec(open(path).read()) でスクリプトを実行し、その関数を呼び出します。
• すべてのモデリングは、assets/build_template.py をコピーした <asset>/build/NN_<phase>.py に bpy コードで記述します。各スクリプトはマスターを開き、自身が所有するものを削除して再構築し、保存します。どのフェーズも安全に再実行できます。定数はメートル単位で測定し、由来となった参照ビューを示すコメントを付けるか、# inferred と記します。
• スキルスクリプト（すべて -- --help を受け付けます）：

スクリプト	目的
scripts/init_master.py	マスター .blend：単位、コレクション、キャリブレーション用プロキシ、実寸大の参照平面、ゲームカメラ
scripts/review_render.py	固定ビュー、参照画像に合わせたカメラ、ゲームプレイ時のピクセルサイズ、ターンテーブル、ポーズフレームを使ったクレイ／シルエット／ワイヤー／チェッカー／マテリアルのレンダリング
scripts/compose_review.py	比較シート（参照画像、レンダリング、オーバーレイ、ゲームプレイ時のストリップ）に加え、シルエット IoU と幅プロファイルの数値を出力します。Pillow を使う標準的な Python スクリプトです
scripts/world_gate.py	正投影の参照ビュー向けに、ワールド座標に登録したシルエット IoU を算出します。カメラは参照マットの正確なワールド範囲を映すため、スケールと配置の誤差も反映されます
scripts/validate.py	トポロジー、トランスフォーム、UV、ウェイト、アーマチュア、ソケット、コライダー、命名、トライアングル予算を検証します。FAIL の場合は終了コード 1 を返します
scripts/bake_maps.py	HIGH から LOW へのノーマルマップと AO、ベースカラー、ラフネス、メタリックをベイクし、納品用マテリアルを再構築します
scripts/export_delivery.py	asset-manifest.json と animation-contract.json を含めて GLB/FBX をエクスポートします
scripts/roundtrip.py	空の Blender にエクスポートをインポートし、読み込まれた内容を報告して確認用レンダリングを作成します

Phase 0 の前に、アセットのカテゴリについて references/categories.md を読んでください。 Phase 6 の前に references/rigging-animation.md を、Phases 1、5、9 の前に references/delivery-and-acceptance.md を読んでください。スクリプトが 5.x の API で失敗した場合や、 長時間のレンダリングやベイクを行う前には references/blender-5-notes.md を読んでください。

ゲートプロトコル（各フェーズの終了時に実施）

1. review_render.py を --ref-cam AZ EL LENS（フェーズ 0 で推定）と front,side,threequarter を指定し、フェーズで求められるモードで実行します。--gameplay-px は ゲーム画面上での対象の高さに設定します（デフォルトは 128）。
2. カメラに一致する参照ビューに対して compose_review.py --measure を実行します。シートと数値を確認します。 画像も見てください。数値は、目が見逃すずれを捉えます。 compose_review はバウンディングボックスで 2 つのシルエットを位置合わせするため、モデルの高さ不足や軸からのずれは検出できません。 正投影シートでは、クリーンアップした参照マット（ラベル、定規、床の線など、モデルに含まれないものを消去したもの）に対して world_gate.py も実行し、その数値がフェーズの許容誤差内に収まるようにします。参照画像の各ビューで差異がある場合（ケープが背面ビューより正面ビューで広いなど）は、両方に合わせようとせず、差異とビューごとの上限を逸脱事項として記録します。
3. 不一致は形容詞ではなく、測定値として記述します。「頭部が 12 パーセント高すぎる」「ホイールベースが 0.3 m 短い」「バンド 4 の幅が +0.06」のように記述します。ビルドスクリプトの定数を修正し、フェーズを再実行して、 再レンダリングします。すべての不一致がフェーズの許容誤差内に収まるまで繰り返します。
4. 比較シート、残っている逸脱事項、推測した内容をユーザーに提示します。承認を得てから続行します。質問しないようユーザーから指示されている場合は、許容誤差を満たした時点で続行し、シートを review/ に保存しておきます。ユーザーがライブビューポートで確認する場合は、再ビルドのたびにマスターをそこで再読み込みします。レンダリング時のみ非表示になるもの（衣装の下のマネキンなど）も、ユーザーのビューには表示されるためです。

許容誤差：ブロックアウトの IoU は 0.85、各バンド幅は参照との差が 0.05 以内（フォームではそれぞれ 0.90 と 0.03）。 ブリーフに記載された測定値における比率は、ブロックアウトで 5 パーセント以内、フォームで 2 パーセント以内です。 マテリアルは、マテリアルターンテーブルの移動するライトの下、およびゲームプレイ時のサイズでグレースケール表示したときに、 各役割を正しく判別できれば合格です。

フェーズ 0：参考資料を読み、概要を作成する

Blender を操作する前に、提供されたすべての画像を確認します。次の厳密な構成で <asset>/asset-brief.md を作成します。

ASSET      prefix and name (CH_, CR_, AR_, VH_, PR_, WP_, EN_)
CATEGORY   character | creature | architecture | vehicle | prop | weapon | environment, plus subtype (biped, quadruped, winged, wheeled, tracked, modular kit, hinged prop)
VIEWS      per image: view type (front, side, back, top, three-quarter, concept), estimated camera azimuth, elevation, lens (0 = orthographic), how much of the image height the subject fills, where the ground line sits
SCALE      real size along each axis with the evidence (human height, door, wheel, brick course, weapon grip); state the number used
PROPORTIONS 8 to 15 ratios measured in the image that the blockout gate will check (head heights, shoulder width to height, wheelbase to length, storey height to width)
PARTS      every part in construction and overlap order; for each: separate object yes/no, rigid/deforming/simulated, attaches to, moves about (pivot)
SILHOUETTE the 3 to 5 features that make it read at gameplay size
MATERIALS  per part: role (skin, scales, worn leather, painted metal, carved stone, glass), colour, roughness range, wear pattern
ARTICULATION rig family, joints or pivots, sockets needed, animation needs (none / idle only / full library)
INFERRED   every side, dimension or part the images do not show and the prior used to fill it
TARGET     engine, export format, budget tier from the table, game camera (elevation, distance, lens), subject height in pixels at typical gameplay distance

画像から判断できないことだけをユーザーに尋ねます。対象エンジンと形式、スケールの手掛かりがない場合の実寸、予算のティア、リギングとアニメーションが必要かどうか、ゲーム内カメラを確認してください。次のデフォルトを提示し、ユーザーが「そのまま進めて」と言った場合はそれを使用します。1 unit = 1 m、Blender では Z アップで対象は -Y を向く、GLB エクスポート、予算表の標準ティア、50 mm の三分の四俯瞰カメラ、対象の高さは 128 px、カテゴリーに変形がある場合のみリグを作成し、依頼がない限りアニメーションは作成しません。

フェーズ 1 の前に、すべての参考資料を <asset>/ref/ にわかりやすい名前のファイルとして保存します。スクリプトはディスク上の参考資料を読み込みます。また、会話に貼り付けられた画像は一時ファイルとして届くため、最初にそこへコピーしてください。

複数画像の参考資料：1 回の依頼で何枚でも画像を受け取ることができます。どの画像が正投影図で（寸法の計測に使用）、どの画像がパースのコンセプト画像か（シルエットとディテールのみに使用し、比率の確認には使用しない）を明記します。画像間で矛盾がある場合、寸法には正投影図を、表面のディテールにはコンセプト画像を優先します。どの情報にどの画像を使用したかを記載してください。1 枚の画像に複数のビューが含まれる場合（正面、側面、背面パネルやディテールの注釈があるターンアラウンド画像やモデルシートなど）は、各パネルにピクセル範囲を指定した独自の VIEWS エントリーを設けます。正投影パネルを、同じスケールと接地線を持つ個別のファイル（ref/front.png、ref/side.png、ref/back.png）に切り出し、init_master.py とゲートで使用します。表面のディテールには注釈を使用します。写真の場合は、パースの収束からレンズを推定します（望遠の商品写真なら長焦点レンズ、スマートフォンで撮影した写真なら 24～35 mm）。そのレンズに合わせて --ref-cam を設定します。

複数のアセットを対象とする依頼では、各カテゴリーから 1 つのアセット（キャラクター 1 体、クリーチャー 1 体、キットパーツ 1 点、乗り物 1 台）をすべてのフェーズに通し、まず承認を得ます。その後、実証済みのスケール、リグ、マテリアル、エクスポートのルールを残りのアセットに適用します。各役割にはそれぞれ固有のフォームと動きが必要です。リグのファミリーを共有しても、比率まで共通になるわけではありません。

フェーズ 1：キャリブレーションとマスターファイル

モデリングを始める前に基準単位を決め、その設定を維持します。1 unit = 1 m、Z アップ、前方は -Y、原点は地面との接点（乗り物は地面の中心、キットパーツはグリッドの角）とします。対象ゲームで別の論理単位を使う場合は、依存する値（移動速度、リーチ、セルサイズ、コライダー、カメラオフセット）をすべて、係数を記録したうえで変換するか、レンダリング時にのみマッピングするかを一度だけ選択します。ゲームプレイのメトリクスを古い単位のままにして、アセットだけを縮小してはいけません。

このファイル内のコマンドでは、例として 1.85 m の騎士（CH_Knight、Unity）を使用しています。アセット固有の値（名前、高さ、カメラ、予算、エンジン、推定リスト）はすべて概要から取得してください。

$BLENDER_BIN --background --python scripts/init_master.py -- \
  --out CH_Knight/CH_Knight_master.blend --name CH_Knight --height 1.85 \
  --ref-front ref/front.png --ref-right ref/side.png --ref-extra ref/concept.png \
  --subject-frac 0.88 --ground-frac 0.04 --cell 2.0 --cam-elev 50 --cam-az 30 --cam-dist 12 --cam-lens 50

これにより、コレクション（REF、HIGH、LOW、RIG_CTRL、RIG_DEF、COLLISION、SOCKETS、EXPORT）、メートル目盛り付きの目標高さの定規、グリッドセル、ドアのクリアランス、コリジョンカプセル、ゲーム内カメラ、実寸スケールで接地線が z = 0 にある立面状の参考画像が作成されます。すべてのアセットをこのキャリブレーションに通します。同じファイル内で同じスケールに揃えられていないヒーロー、敵、出入口は、エンジン内で互いに適合しません。

references/delivery-and-acceptance.md に従った命名規則：CH_Knight_Body_LOD0、DEF-upper_arm.L、SOCKET_hand.R、COL_torso、CUT_window。納品するものには .001 という名前を付けないでください。

フェーズ 2：ブロックアウトとシルエットのゲート

テンプレートをもとに build/02_blockout.py を作成します。まずは主要なボリュームだけを作ります。胴体、頭、骨盤、四肢を単純な形状で表現します。乗り物の場合は車体シェル、車輪、キャビン、キットパーツの場合は床、壁、屋根、開口部を作ります。手、足、顎、角、翼、ドア、砲塔などの付属パーツは、最初から別個のラフなオブジェクトとして作成します。関節の中心とピボットはこの段階で、ブリーフで測定した位置に配置します。後工程のすべてがこれらを基準に作られるためです。

重量とバランスを確認します。質量を支えられる足と腰、ランナーの前進する駆動ライン、四足動物の胸郭と骨盤、意図した動作を支えられる首と翼の付け根、車両の質量を支える車輪を確認します。衣装、装甲、外装、パネルは別個のボリュームとして追加します。武器の射程、手のクリアランス、ドアの開閉、アセットが取り得る最も極端なポーズや状態（攻撃、しゃがみ、旋回、ハンドル最大切れ角、ドアを開けた状態）でのシルエットを確認します。

クレイモードとシルエットモードでゲートを実施し、LOW コレクションで --show-ref を一度実行して、定規に対するスケールを確認します。テクスチャ、パーティクル、ラベルがなくても、ゲームカメラからカテゴリーを判別できなければなりません。複数アセットを扱う場合は、相対スケールでグレーボックスのラインナップをレンダリングし、役割の違いが色だけでなく、肩幅、頭の形、姿勢、立ち方にも表れていることを確認します。

$BLENDER_BIN --background --python scripts/review_render.py -- --blend CH_Knight/CH_Knight_master.blend \
  --out CH_Knight/review/02_blockout --collections LOW --views front,side,threequarter \
  --ref-cam 35 12 50 --mode clay --gameplay-px 128
python scripts/compose_review.py --ref ref/front.png --render CH_Knight/review/02_blockout/clay_front.png \
  --out CH_Knight/review/02_blockout/compare_front.png --measure --gameplay-px 128

フェーズ 3：形状

build/03_forms.py。作業順序は、主要な解剖学的形状またはボディのボリューム、次に二次形状（布のボリューム、装甲の構造、パネルの分割、モールディング）、最後に三次ディテール（折り目、損傷、リベット、毛穴、織り目）です。三次ディテールは、テクスチャ解像度とゲームカメラで再現できるスケールに限って追加します。大きなランダムノイズは形状を隠し、遠距離ではちらつきます。

有機的な形状：ブロックアウトを結合して一体化したベースを作成し（HIGH で高さの約 1/200 に設定したボクセルリメッシュ）、push で形を整えます。または、スキンチェーンのベースを維持し、半径と関節位置を調整します。ハードサーフェス：実際のパネル間隔、プレートの厚み、光を捉えるベベルを設けながら、ロフト、押し出し、回転、切り抜きを行います。重ねるパーツは、実際の重なり順にモデリングします。目、歯、爪、角、ガラス、ライト、膜は、個別のシェーディング、変形、関節動作が必要な場合は別個のままにし、エクスポート用コピーでのみ統合します。

衣装やパネルで覆われている部分も含め、完全なベースボディまたは船体をマスターに残します。エクスポート用コピーでカバー範囲に応じたカットを作成し、すべての装備の組み合わせで穴がないことを確認します。

キャラクター：references/categories.md のセクション 2 では、キャリブレーション済みブループリントに合わせた顔、手、首の接合部、下に着る衣服に合わせた装甲、ストランドヘアのコライダーとシェーディングについて説明しています。ビューポートに表示されるものをすべて確認しながら、首、手、すべての装甲の重なりを複数の角度から接写で確認します。メッシュの重なりテストでクリアランスを確認します。

ゲート：参照カメラおよびすべての固定ビューからのクレイレンダー、形状の許容範囲、さらに --turntable 8 によるクレイパスを確認します。ゲームプレイ時のサイズでもシルエットがフェーズ 2 に一致していなければなりません。形状によってシルエットが変わった場合は、参照を修正するのではなく、形状を修正します。

フェーズ 4：トポロジー

build/04_topology.py は、承認済みの形状をもとに、LOW の納品用メッシュを生成します。シルエット、関節の曲げ、顔の動き、布の折り目、パネルの縁、または素材の境界が必要な箇所にトポロジーを配置します。スカルプトを均一にリメッシュしても、変形に適したトポロジーにはなりません（Blender のリトポロジーに関するメモ：https://docs.blender.org/manual/en/latest/modeling/meshes/retopology.html）。実践的な手順は、すべての関節にループを設けたクリーンなベースケージを用意することです（Subdivision 1 のスキンチェーンメッシュにはすでにループがあります）。HIGH 形状に Shrinkwrap を適用し、Subdivision 1 を設定してから、関節や折り目のループを編集します。剛体パーツや瓦礫には制御された Decimate を使用できます。主役となる肩、手、顔、ヒンジ、シミュレーション対象の布には、意図的にループを設けます。

ソースはクワッドにし、納品時には三角形化します。ベイク後にシェーディングが変わらないよう、ベイク前に三角形化を固定してください。クリーンアップを実行します。重複頂点、孤立した島、面積ゼロの面、反転した法線、重なった内部シェルを取り除きます。布シート、ヘアカード、デカールは境界が開いていても問題ありませんが、衝突プロキシは閉じている必要があります。今の段階で lod_copy を使って LOD1 と LOD2 を作成し、輪郭を手作業で修正します。その際、頭、肩、武器、車輪、出入り口のシルエットを維持してください。

ゲート：予算ティアの三角形数を指定して validate.py を実行（終了コード 0、警告の内容を説明できること）、LOW をワイヤーモードでレンダリングし、フェーズ 3 のレンダリングとクレイ比較してシルエットが損なわれていないことを確認します。

$BLENDER_BIN --background --python scripts/validate.py -- --blend CH_Knight/CH_Knight_master.blend \
  --collections LOW,COLLISION,SOCKETS --out CH_Knight/review/04_validate.json --budget-tris 60000 --require-uv

フェーズ 5：UV、ベイク、マテリアル

build/05_materials.py。構造と見た目に合った位置にシームを配置します。顔、焦点となる衣装、主役となる表面には独自の領域を確保し、繰り返しのある縁や大きな表面にはトリムやタイル、小さな小道具にはアトラスを使用します。アセットファミリーごとにテクセル密度を統一します。関節、裾、顔、握り部分でチェッカーレンダーを使い、歪みを確認します。実用上の最低ミップレベルでパディングを確認します。

ブリーフで指定された役割（肌、乾いた骨、織物、使い込まれた革、腐食した金属、塗装された鋼鉄、彫刻された石、ガラス）をもとに、Blender でオリジナルのマテリアルを作成します（プロシージャルまたはペイント）。役割に合った粗さの範囲を設定します。すべての縁を白く囲むのではなく、構造や接触に沿ったエッジ摩耗を表現します。ベースカラーに方向性のあるライティングをベイクしないでください。その後、ポータブルなマップ一式をベイクして、納品用マテリアルを再構築します。

$BLENDER_BIN --background --python scripts/bake_maps.py -- --blend CH_Knight/CH_Knight_master.blend \
  --low LOW --high HIGH --res 2048 --maps normal,ao,basecolor,roughness,metallic \
  --out CH_Knight/textures --extrusion 0.02 --ray-dist 0.05 --margin 16 --samples 64 \
  --match-by-name --rebuild-material --save CH_Knight/CH_Knight_baked.blend

投影が隣接するパーツにまたがる場合（歯、重ね着など）は、名前付きグループごとにベイクします。透明なシェル（角膜、バイザー、ガラス）は --exclude-sources でソースから除外します。LOD0 をベイクします。LOD1 と LOD2 は、そのマテリアルとマップを再利用します（lod_copy で作成され、同じ UV レイアウトを使用しているためです）。LOD に独自の UV がある場合に限り、--all-lods を指定します。マニフェストに、各マップのカラー空間、法線マップの緑チャンネルの規約、チャンネルパッキングの内容を記録します。

ゲート：--turntable 12 を指定してマテリアルモードでレンダリングします（光源を表面上で動かします）。ゲームプレイ時のサイズでグレースケール比較を行い、チェッカーレンダーで関節に問題がないことを確認します。ノーマルマップを適用したターンテーブルで、ハードエッジと UV シームを確認します。

フェーズ 6：リギング

静的な小道具や可動部のないキットパーツの場合に限り、省略できます。それ以外の場合は build/06_rig.py を使用します。references/rigging-animation.md にあるリグファミリーをもとに、RIG_DEF に変形用スケルトン、RIG_CTRL にコントロールを設定し、すべてのヒンジ、車輪、ドア、砲塔に実際のピボットを設けます。SOCKETS には軸の規約（アタッチメントの前方が +Y、上方が +Z）に従ってソケットを設定します。変形するすべてのパーツを同じスケルトンにバインドし、ウェイトを正規化します。納品時の目標として、頂点あたりのインフルエンスを 4 つとし、剛体の装甲は 1 つのボーンに割り当てます。バインド前にスケールと回転を適用してください。クリーンアップ目的で Armature モディファイアーを適用してはいけません。

ゲート：極端なポーズのシートを作成します（参照ファイルに記載されたすべてのポーズについて、review_render.py --action <pose_action> --frame N を実行）。分離されたすべてのパーツが同時に見えるようにします。validate.py で、ウェイトが設定されていない頂点やインフルエンスが過剰な頂点がないことを確認します。各ソケットを、実際のアタッチメントを取り付けて少なくとも 1 つのポーズでテストします。

フェーズ 7：二次モーション

ブリーフでシミュレーションまたは二次モーションとして指定された衣服、チェーン、尾、翼、ケーブル、履帯、アンテナにのみ適用します。references/rigging-animation.md のセクション 6 に従い、レンダリング、シミュレーション、衝突の各表現を分離し、実際のクリアランスを確保したピン留めされた取り付け領域を設け、各頂点のモーションを制御する主体を 1 つにし、ボーンチェーンのフォールバックを用意します。ゲート：極端なポーズでレンダリングし、身体や武器への貫通がないことを確認します。また、フォールバックチェーンだけでも同じ衣服として認識できることを確認します。

フェーズ 8：アニメーション

依頼された場合にのみ実施します。build/08_anim.py またはライブセッションを使用します。意図的な範囲、ループフラグ、イベント用ポーズマーカーを設定した名前付きアクションを作成し、移動速度をタグ付けしたその場での移動アニメーションを用意します。上半身のレイヤーには参照ポーズとマスクを設定します。納品用には IK を変形用スケルトンにベイクし、ベイク前のマスターも保持します。ゲート：各クリップをゲームカメラで、ターンテーブルを使用せず短いシーケンスとしてレンダリングします。ループのつなぎ目でルートのドリフトやポップがないことを確認し、イベントのタイミングを animation-contract.json から読み取ります。

フェーズ 9：エクスポートと往復検証

マニフェストとともに、明示的に選択した要素（LOW、RIG_DEF、SOCKETS、COLLISION）をエクスポートし、空の Blender にインポートしてマニフェストと比較します。REF、HIGH、RIG_CTRL に属するものは一切納品しません。

$BLENDER_BIN --background --python scripts/export_delivery.py -- --blend CH_Knight/CH_Knight_baked.blend \
  --out CH_Knight/exports --name CH_Knight --format GLB --split-lods \
  --inferred "back of cloak from symmetry, sole tread generic" --engine unity
$BLENDER_BIN --background --python scripts/roundtrip.py -- --file CH_Knight/exports/CH_Knight.glb \
  --out CH_Knight/review/09_roundtrip --expect-height 1.85

ゲート：往復検証の終了コードが 0 であること（LOD ごとの三角形数、ボーン名、クリップの長さ、画像がすべてマニフェストと一致し、高さの差が 1 パーセント以内で、地面より下に何もないこと）。また、往復検証のクレイレンダーがフェーズ 3 のクレイレンダーと一致することを確認します。対象エンジンが利用可能な場合は、クリーンなプロジェクトにインポートし、実際の武器または衣服との組み合わせで全クリップを再生します。

フェーズ 10：受け入れと引き渡し

references/delivery-and-acceptance.md のセクション 4 にあるチェックリストを実行します。review/final/ を作成し、参照カメラと固定ビューの比較シート、ゲームプレイサイズのグレースケールストリップ、マテリアルのターンテーブル、極端なポーズのシート、validate.json、roundtrip.json を用意します。次の順序でユーザーに報告します。一致している点、残っている差異の測定値、参照で確認できず推測したすべての内容、使用した予算とティアとの比較、納品したファイルの正確な一覧。測定値が異なる場合は、アセットが参照と一致していると説明しないでください。

作業ルール

• 測定してからモデリングします。すべての定数はブリーフに基づくか、推測値として明記します。
• シルエットを形状より先に、形状をディテールより先に、トポロジーをテクスチャより先に、バインドをアニメーションより先に整えます。
• 各ゲートでレンダリングによる証拠を残します。ビューポートは証拠になりません。
• 1 ファイル、1 スケールとします。すべてのアセットを定規付きのキャリブレーションファイルに通します。
• 独立して動く、シェーディングされる、またはシミュレーションされる要素は分離し、エクスポート用コピーでのみ統合します。
• マスターは非破壊の状態に保ち、納品用コピーにモディファイアーを適用します。
• 別のスケルトンを想定するローダーに合わせるために、エクスポートを決して改名しないでください。マッピングを用意します。
• 参照で見えなかった部分を明記します。推測した背面は、マニフェストでも推測として扱います。