Blender での Unity用3Dモデル制作ガイドライン

本ドキュメントは、Unity を用いて 3D のマルチプレイアクションゲームを開発するプロジェクト向けに作成した、Blender 製 3D モデルの制作ガイドラインです。

3D モデルは Blender で作成し、FBX 形式でエクスポートして Unity にインポートするワークフローを前提としています。

プロジェクトでは Unity 2022.3（URP: Forward Rendering Path）、Blender 4.5 を使用しているため、それ以外の環境では一部の内容が当てはまらない場合があります。

Unity エンジニアの視点から、実行時パフォーマンスや運用性を意識しつつ、3D アーティストがモデリング・リギング・アニメーションを行う際に守ってほしいルールや推奨事項を整理し、「なぜそのルールが必要なのか」という技術的背景もあわせて簡単に解説しています。

トランスフォーム

• Scale は必ず Apply する（優先度: 高🔴）

  • ⚙️ ゲーム用モデルは Scale=(1,1,1) が基本。法線・ライトマップ・コライダーの不具合を回避するため。
  • 負の Scale は使用しない。
  • ⚠️ ただし、Armature や、すでにボーンにバインド済みのメッシュについては、リグを組んだ後に Scale を Apply しないこと（リグ作成前に Apply を済ませておく）。

• Rotation は基本的に Apply する（優先度: 高🔴）

  • ワールド座標に合わせる必要はなく、ゲーム内での「基準姿勢」が Rotation=(0,0,0) になるように Apply する。
  • ⚠️ Armature や、すでにボーンにバインド済みのメッシュには Rotation / Scale を Apply しない。
    • リグを組む前に、メッシュ側の Rotation / Scale の Apply を済ませておく。

• Location は Apply しない（優先度: 高🔴）

  • ⚠️ Object > Apply > Location は基本的に使用しない。

  • 📝 オブジェクトの基準位置（Pivot）は Object > Set Origin で原点を移動して決める。

    • Transform の Location を 0 にそろえるために Apply Location を使うのではなく、Pivot を移動して「どこを 0 とするか」を決める。

  • 原点（Pivot）の基本ルール（置き方）

    • 基本: オブジェクトの中心など、ゲーム内で扱いやすい位置（優先度: 高🔴）
      • 📝 多くの場合、Object > Set Origin > Origin to Geometry で問題ない。
    • キャラクター・床置きオブジェクト: 底面の中心（優先度: 高🔴）
    • 壁掛けオブジェクト: 背面の中心（優先度: 低🔵）
    • 回転するもの: 回転軸（ヒンジなど）の位置（優先度: 低🔵）

  • FBX 書き出し時の位置

    • ⚙️ トップレベルオブジェクト は、その Location 情報を保ったまま FBX に出力される。
    • 📝 トップレベルオブジェクトが 1 つだけ の FBX として出力する場合は、Location=(0,0,0)（Alt+G）にしておくと、Unity 側で扱いやすい。
    • ⚙️ 複数のトップレベルオブジェクト を 1 FBX ファイルにまとめる場合、Blender ではワールド原点に「見えない親」が自動的に作成され、
      Unity ではその親が ファイルルートの GameObject（Position=(0,0,0)） になる。
      • もとのトップレベルオブジェクトそれぞれの Location は、その子オブジェクトの localPosition として保持される。

オブジェクトの統合・分割

• パフォーマンスを考えてオブジェクトの統合・分割を行う（優先度: 高🔴）

  • ⚙️ オブジェクト（Unity の Renderer コンポーネント付きのオブジェクト = Mesh Renderer / Skinned Mesh Renderer）が増えると、Draw Call (GPU への描画命令) が増える傾向 にある。
  • ⚙️ ある程度までメッシュを統合すると Renderer 数が減り、Draw Call が減ってパフォーマンスが上がる ことが多い。
  • ⚙️ ただし 大きく統合しすぎると、1 つのオブジェクトのバウンディングボックスが大きくなり、そのごく一部だけが画面に入っていても オブジェクト全体が描画対象 になり、フラスタムカリング（画面外のオブジェクトを描画しない最適化）の効率が下がってパフォーマンスが悪化する。
  • 細かいもの・常にセットで画面に表示されるものは統合し、離れていて同時に画面に入らないものは統合しない、という方針で考える。

• 同じ形・同じマテリアルのオブジェクトが繰り返される場合はメッシュ・マテリアルを共有する（優先度: 高🔴）

  • 📝 岩・木・柵など、ある程度の大きさで 同じ形が何度も登場するパーツ は、繰り返しの最小単位を 1 オブジェクトとして作り、リンク複製（Object > Duplicate Linked (Alt+D)）で配置する。
  • ⚙️ これにより、複数オブジェクトが 同じメッシュ・マテリアルを共有 することになり、ゲームの ビルドサイズ削減 と 実行時メモリの節約 に繋がる。
  • ⚙️ さらに、Unity 側で、同じメッシュ＋同じマテリアル を使用するオブジェクトに対して、必要に応じて GPU Instancing を有効にすることで、Draw Call を削減でき、パフォーマンス向上も期待できる。
  • ⚠️ リンク複製したオブジェクトは統合しないこと。リンク複製した繰り返しパーツを統合してしまうと、繰り返しメッシュを含んだ「大きな 1 メッシュ」になってしまうため、リンク複製の意味がなくなってしまう。
  • ⚠️ 一方で、 細かな装飾など、画面上で非常に小さく、ポリゴン数も少ないパーツ は、1 つ 1 つをリンク複製するよりも、まとめて 1 つのオブジェクトとして統合してしまった方が良い 場合が多い。
    • これは、GPU Instancing で Draw Call を減らせても、インスタンス数が多いと各インスタンスの Transform 計算や Culling 判定などの CPU オーバーヘッド は残るため。
    • 可能なら、ノーマルマップだけで凹凸を表現する など、メッシュそのものを置かない方法も検討する。

• プログラムで制御するパーツは分割する（優先度: 高🔴）

  • ドア、引き出し、レバー、回転するギミックなど、スクリプトやアニメーションで個別に動かす部分は必ず別オブジェクトとして分割しておく。
    • キャラクターのようにボーンで動かすものは、このルールとは別で扱う。

• コライダーを付与しやすい単位に分ける（優先度: 低🔵）

  • ゲーム内でよく触る／衝突判定が細かく必要なオブジェクトは、コライダーを付けたい単位でメッシュを分けておくと設定しやすい。
  • 可能であれば、Box / Sphere / Capsule などプリミティブなコライダーで近似しやすい形状単位 に分ける。
    • ただし、必要以上に細かく分割しすぎると管理コストが上がるため、ゲームプレイ上重要な部分に限定して分割する。

• オブジェクトの統合・分割のまとめ

  • プログラムで制御する部分は分割必須。
  • それ以外は、「ゲーム内での使われ方（大きさ・用途）」をもとに、以下を総合的に考え、適切な分割単位 を決める。
    • Draw Call 数（Renderer 数）
    • コライダーの付けやすさ
    • カリング効率

ユニット

• 「1 ユニット = 1 メートル」とする（優先度: 高🔴）
  • Blender でも Unity でも、1 unit = 1m を前提とする。
    • Blender 側は Unit Scale=1.0、Length=Meters を基本とする。
  • グリッドの 1 マス = 1m として扱う。
  • ⚙️ Unity の物理演算（Rigidbody / Collider / Gravity）は、「m・kg・秒」ベースで設計されている。
    • 現実的なサイズから大きくずれると、物理演算が意図通り動かないことがある。

軸（XYZ）と向き

• -Y を前とする（優先度: 高🔴）
  • Blender のワールド座標系は X = 左右 / Y = 前後 / Z = 上下 。
  • ⚙️ Unity のワールド座標系は X = 左右 / Y = 上下 / Z = 前後（+Z が前） 。
  • FBX エクスポート設定で Forward: -Z Forward / Up: Y Up / Apply Transform: ON を前提としている。
    • Blender で「-Y を前」として作成したモデルは、Unity では「+Z を前」とするモデルとしてインポートされる。(Unity 側では transform.forward がキャラクターの「前」を向く状態になる）
  • キャラクターから見て 右側 = Blender の -X 側となる。

マテリアル

• マテリアル数を最小限に抑える（優先度: 高🔴）
  • 「1 オブジェクト = 1 専用マテリアル」は避け、同じ質感・同じテクスチャセットをできるだけ使い回すことを基本とする。
  • ⚙️ Unity では、一般的に 1 Renderer × 1 マテリアルが、1 Draw Call（+1 SetPass Call）となる。
  • ⚙️ Dynamic / Static Batching や GPU Instancing が効けば、1〜数回の Draw Call で複数オブジェクトを描画できる。
    • そのような最適化は、同じマテリアルであることが前提となる。
  • ⚙️ Dynamic / Static Batching や GPU Instancing が効かなくても、マテリアルを共有することで、マテリアルの状態切り替え (SetPass Call) の回数を削減しやすくなる。

テクスチャ

• 広い面積に同じ模様を敷き詰める場合はタイリングを使う（優先度: 高🔴）

  • 地面・壁・天井・道路・岩肌など、広い面積で同じパターンを繰り返す部分は、タイル可能なテクスチャを使い、UV スケールで調整する。
  • ⚙️ これにより、高ディテールを比較的安価に実現でき、メモリの節約 ができる。

• UV 面積は情報量に応じて配分する（優先度: 中🟡）

  • 単色に近い部分や模様の密度が低い部分は、UV 面積を小さくする。
  • 文字やロゴ、細かな模様・傷などディテールが必要な部分には、より大きな UV 面積を割く。
  • ⚙️ こうすることで、同じテクスチャ解像度でも見た目の情報量を最大化 できる。

• アルファチャンネルの利用は最小限に（優先度: 中🟡）

  • ⚙️ 透明（Transparent / アルファブレンド） は深度バッファを使った最適化が効きづらく、重なりが多いと 描画コスト・オーバードローが増大 する。
  • ⚙️ 半透明オブジェクト同士が重なった場合、表示の問題（ソート順）も発生しやすい。
  • URP 用の既定シェーダーでは、半透明のままの影を落とすことができない。
    • ⚙️ 既定シェーダー (Lit) は、ForceNoShadowCasting となっており、シャドウマップ用描画パス参加しない。
    • ⚙️ 影専用の「見えないメッシュ(Cast Shadows: Shadows Only)」を置くことで回避可能。
    • ⚙️ Shader Graph で Transparent、Cast Shadows: ON で半透明の影を落とすオブジェクトの作成は可能。
  • ⚙️ メインライト以外の追加ライトの計算が不透明オブジェクトと比べて簡略化される（または適用されない）場合が多い。
  • 背景など、優先度の低いオブジェクトでは 極力アルファブレンドを使わない。
  • 透明が必要な場合でも、まずは Cutout（Alpha Clipping）で表現できないかを優先的に検討 する。
  • 半透明（アルファブレンド）の使用は、本当に必要な箇所のみ最小限に とどめる。

• テクスチャサイズは 2 のべき乗にする（優先度: 高🔴）

  • ⚙️ 512×512、1024×1024、2048×2048 など、2 のべき乗サイズ にすることで、ミップマップ生成と圧縮が最適化される。
  • ⚙️ 矩形テクスチャ（1024×2048 のように片方だけ大きいもの）も、基本的には 2 のべき乗同士の組み合わせを推奨する。
  • 📝 UI 専用テクスチャなど、一部の用途では非 2 のべき乗サイズも許容される場合があるが、3D モデル用の汎用テクスチャは 2 のべき乗を基本ルール とする。

オブジェクトの命名

• 以下は、オブジェクト・メッシュ・マテリアル・アーマチュアなどすべて に適用する。
• 半角英数 + 記号（_ - .）のみを使用する（優先度: 高🔴）
• 同じ種類のオブジェクトは、名前順でまとまるように命名する（優先度: 中🟡）
  • 例: Env_Rock_Small_01, Env_Rock_Small_02 のように、環境オブジェクト・種類・サイズ・番号の順にするなど。
• 左右・前後などは共通の略語を使う（優先度: 低🔵）
  • 左右: _L / _R（Blender のボーン名では .L / .R）
  • 前後: _F / _B

リグ・アニメーション

• Armature オブジェクトは Scale=1, Rotation=0 にそろえる（Object モード）（優先度: 高🔴）

  • リグを組む前に、Armature（とバインド予定のメッシュ）の Scale を (1,1,1), Rotation を (0,0,0) にしておく。
    • ⚙️ これにより、Unity 側でのポーズ・アニメの再生やリターゲット時に二重スケール・二重回転が発生せず、挙動が安定する
  • Armature オブジェクトの原点は、足の間の地面の位置（左右の足の真ん中・床の高さ） とし、Blender シーンではそこ（＝ワールド原点）を基準として作業する。

• ゲーム用リグは 1 頂点あたり最大 4 本を目安にウェイトを塗る（優先度: 高🔴）

  • ⚙️ Unity は設定（Project Settings > Quality > Skin Weights など）によって、1 頂点が持てるボーン数の上限（通常 4 本）を超えたウェイトは、小さいものから順に無視 する。
    • ⚙️ そのため、Blender では綺麗に変形していても、Unity 側では見た目が変わる場合がある。
  • 📝 Weight Paint モードで Weights → Limit Total… を実行し、Limit を 4 に設定して「1 頂点あたり最大 4 本」にそろえる。

• 各頂点のウェイト合計が 1.0 になるよう正規化する（優先度: 中🟡）

  • ⚙️ スキニングは「ボーン行列の重み付き平均」で計算されるため、各頂点のウェイト合計が 1.0 であることが理想。
  • ⚙️ 合計が 1.0 から大きくズレていると、Blender と Unity で正規化のタイミングや丸め方の違いにより、変形結果に差が出る可能性がある。
  • 📝 Weight Paint モードで Weights → Normalize All… を実行し、すべての頂点についてウェイト合計が 1.0 になるよう正規化する。必要に応じてブラシの Auto Normalize も併用する。

• キャラクターの Rest Pose（Edit モードのポーズ）は、Tポーズ or Aポーズで左右対称にしておく（優先度: 高🔴）

  • ⚙️ Rest Pose は「ボーンの基準姿勢」であり、Blender では Edit モードの姿勢、Unity では インポート時のスケルトンの基準姿勢 として使われる。ここが崩れていると、以後のすべてのアニメ・リターゲットの土台が歪む。
  • ⚙️ Tポーズ / Aポーズのように 腕を体から離したニュートラルな姿勢 にしておくと、
    • 肩・股関節・ひじ・ひざなどの関節が大きく曲がっていないため、ウェイトペイントの基準が分かりやすい。
    • 曲げたときの変形も素直になりやすい。
  • ⚙️ 左右対称にしておくことで、
    • X-Axis Mirror や Symmetrize、左右ウェイトコピーなど Blender のミラー機能が正しく使える。
    • 左右のボーン名（.L / .R など）と位置が対応しやすくなり、Unity の Humanoid 設定やアニメのミラー・リターゲットが安定する。

• キャラクターにはワールドの基準となる Root ボーンを 1 本用意し、その下にボーンを置く階層構造にする（優先度: 高🔴）

  • ⚙️ キャラクター全体の移動・回転（前進・回転など）と、体のポーズ（Hips や Spine など）の動きを分けて扱いやすくするため。

  • Root ボーン

    • 位置: Armature の原点と同じ、足の間の地面の位置に Head を置く。
    • ⚙️ Root ボーンはワールドの Z 方向（上）に真っ直ぐ伸びるように配置する（例: Edit モードで Head=(0,0,0), Tail=(0,0,1) とする）。

  • キャラクターを実際に移動させる（走る、歩く）アニメーションでは、Hips ではなく Root ボーンを移動・回転 させる。

  • ⚙️ Unity の Root Motion と相性が良い

    • Root ボーンに前進・回転の情報をまとめておくと、走りアニメなどを再生するだけで、Unity 側でキャラクターを自然に前進させやすい。
    • 概念的には「Root ボーンの動き ＝ キャラクター本体の移動・回転」として扱えるようにしておく。
    • ⚠️ Root ボーンにはウェイトを塗らない。
      • 役割の分離を明確にするため（Root はあくまで「キャラクター全体の基準点」）。
      • キャラクターがジャンプしたりしゃがんだりする際、「Hips」ボーンは上下に動くが、Root ボーンは地面（原点）に留まる。Root ボーンにウェイトが付いていると、メッシュが引き伸ばされるような不自然な変形が発生する。
      • Deform フラグを OFF にしておくことで Root ボーンがメッシュの変形には一切影響しなくなる。
        • FBX エクスポート設定で Only Deform Bones: ON にしても Root の子孫に Deform ボーンがあれば、Root ボーンもエクスポートされる。

  • ⚙️ Unity における Root Motion（Humanoid）の概要

    • Humanoid リグでは、Unity はアバター定義から「Body Transform（ボディトランスフォーム／キャラクターの質量中心的な姿勢）」を算出し、その位置・回転の変化から Root Motion を抽出する。
    • 毎フレーム、前フレームとの Root Transform の差分（Δ位置・Δ回転） を計算し、その差分を GameObject（キャラクター本体）の Transform に適用することで、Root Motion（アニメーションに基づく移動・回転） が生じる。
    • Animation Import の「Root Transform Rotation / Position (Y / XZ)」で以下を設定できる:
      • どの成分を Root Motion として GameObject に適用するか。
      • どの成分を「Bake Into Pose」としてボディ側のポーズに焼き込むか。

  • ⚙️ Unity における Root Motion（Generic）の概要

    • Generic リグでは Rig タブの「Root node」に指定した Transform が Root Motion の基準となる（多くの場合、最上位の Root ボーンを指定する）。
    • Unity はこの Root node の動きから Root Transform の変化量を取り出し、Humanoid の場合と同様に毎フレームの差分を GameObject の Transform に適用する（Apply Root Motion が有効な場合）。
    • Apply Root Motion が 無効 の場合、Root Transform の差分は GameObject には適用されないが、Root node 自体のアニメーション（ローカル位置・回転）は再生されるため、Root ボーンに平行移動のキーが入っていると「メッシュだけが移動して見える」ことがある点に注意する。

  • Root Motion を使わず その場で足踏みさせたいアニメ を作る場合は、Humanoid と同様に Animation Import の Root Transform Rotation / Position (Y / XZ) で Bake Into Pose を有効にする。

• 装備やアクセサリーを取り付けるためのプロップボーンを付ける（優先度: 低🔵）

  • わかりやすい命名で管理する（例: PROP_Hand_R など）。
  • Unity 側でこのボーンに GameObject（武器、エフェクト、UI など）を取り付けることで、装備やエフェクトの配置・向きを調整しやすくなる。
  • 📝 Deform フラグを ON にしてエクスポート対象に含める（エクスポート設定で Only Deform Bones: ON を想定）。
  • ウェイトは 0 のままで構わない（メッシュは変形させず、「位置の目印」としてボーン位置だけを利用してよい）。

• Deform ボーンと Control ボーンを名前で明確に分ける（優先度: 高🔴）

  • 「見た目を変形させるボーン（Deform）」と「操作・ポーズ用のボーン（Control）」を名前で区別する。
    • 例: DEF_ プレフィックス = Deform 用、CTRL_ プレフィックス = コントロール用。
  • Unity には基本的に Deform ボーンだけをエクスポート する。
    • Control ボーンは Blender 側でポーズ付け・アニメ作成に使い、必要に応じて Deform ボーンにアニメをベイクする。
    • 一方で、「ゲーム内で参照したい位置のマーカー的なボーン」（プロップ取り付け位置など）は、Deform フラグを ON にして Deform グループとして扱う（メッシュにウェイトを持たせる必要はない）。

• ボーンのスケールアニメーションは原則使用しない（優先度: 低🔵）

  • ⚙️ ボーンにスケールのキーが入っていると、そのボーン以下のメッシュや装備モデルにもスケールが伝播するため、想定外の拡大縮小や歪み が発生しやすい。
  • ⚙️ 回転＋親スケール＋子スケールの組み合わせによっては、せん断（シア）を含んだ変形 になり、エンジニア側で物理コライダーやヒット判定、エフェクトの位置合わせを行う際に扱いづらくなる。
    • スキンされたメッシュの形状に合わせて Mesh Collider などを毎フレーム更新する場合、メッシュの Read/Write を有効にしてメインメモリ上にコピーを保持し、毎フレーム再計算する必要がある ため、CPU パフォーマンスやメモリ使用量に影響する。
  • ⚙️ 非一様スケール（X/Y/Z が異なるスケール） は、法線を歪ませ、ノーマルマップやライティングが破綻 しやすい。
  • 可能な限り、回転＋移動ベースでアニメーションを組み、ボーンスケールアニメは特殊な表現（カートゥーン的なスクワッシュ＆ストレッチなど）に限定 する。

• アクションの開始フレームは1にそろえる（優先度: 中🟡）

  • アクションの長さ＝Endフレームとなり、アクションの尺が分かりやすく、管理がシンプルになる。
  • ⚙️ Unity では実際にキーフレームが打たれている範囲だけが意味のある動きとして再生されるため、開始フレームが 2 や 5 でも再生そのものは可能。

FBX エクスポート

• 基本方針: 1 パーツ = 1 FBX（優先度: 高🔴）

  • 木 1 本、柵セクション 1 つ、キャラクター 1 体など、ゲーム内の 1 パーツとして扱う単位ごとに FBX を分ける。
  • これにより、Unity 側でインポート設定や差し替えを行う際に、影響範囲を把握しやすくなる。

• Blender でエクスポートした FBX ファイルの構造

  • ⚙️ 1 つのトップレベルオブジェクト をエクスポートした場合、そのオブジェクト自身が FBX ファイルの最上位（ルート）となる。
    • ⚙️ そのオブジェクトの Location が、そのまま Unity 側での Position になる。
    • 📝 このため、「トランスフォーム」の指針に基づき、エクスポート前にオブジェクトの Location は (0,0,0) にしておく（Alt + G）ことが望ましい。
  • ⚙️ 複数のトップレベルオブジェクト をまとめてエクスポートした場合、Blender のワールド原点 (0,0,0) の位置にファイルルート（見えない親）が自動的に作られる。
    • ⚙️ もともとの複数のトップレベルオブジェクトは、そのファイルルートの子として配置される（このとき、各オブジェクトの Location が子の Position として保持される）。
    • ⚙️ Unity 側では、この「見えない親」が FBX ルートの GameObject（Position (0,0,0)）となる。

• エクスポート設定

  • Include > Object Types: Mesh と Armature のみに限定
    • Light, Camera, Empty など、Unity 側で使用しないものはエクスポート対象から外す。
  • Transform > Apply Scalings: FBX All
    • ⚙️ Unity 側で Scale=1 の GameObject として扱いやすくなり、0.01 スケールや 100 スケールといった補正を避けられる。
  • Transform > Forward: -Z Forward
  • Transform > Up: Y Up
    • ⚙️ Blender（Y Forward, Z Up）から Unity（Z Forward, Y Up）への座標系変換設定。
    • ⚙️ Blender の「前方（-Y）」を FBX 内部で「-Z」として書き出し、Unity 側で「前方（+Z）」として扱えるようにする。
  • Transform > Apply Transform: ON
    • ⚙️ これを OFF にすると Unity 側のルートオブジェクトに Rotation X = -90 といった補正回転が入るため、ON にして FBX 内部でジオメトリに変換を適用する。
  • Geometry > Apply Modifiers: ON
    • ⚙️ モディファイアを通した “最終結果のメッシュ” を、一時的に計算して FBX に書き出す。
    • Unity は Blender のモディファイアを理解できないため、エクスポート時にモディファイアを評価した結果のメッシュだけが必要となる。
    • ON にしても Armature モディファイアのみは未適用となり、スキニング情報が保持される。
  • Armature > Only Deform Bones: ON
    • ⚙️ この設定を ON にすると、Deform フラグが ON のボーンだけ FBX に書き出される。
    • IK 用ボーン・制御用ボーン（Control）など、Deform OFF にしているものはエクスポートされない。
  • Armature > Add Leaf Bones: OFF
    • ⚙️ ON のままだと、Unity 側に _end のような余計な末端ボーンが増え、スキニングや Humanoid 設定が煩雑になるため OFF にする。