- Authors
- Name
- Youngju Kim
- @fjvbn20031
- はじめに
- 資産パイプラインの全体の流れ
- リアルタイムパイプライン: ゲームエンジンの世界
- オフラインパイプライン: 映画のレンダーファーム
- リアルタイム vs オフライン: 核心比較
- 最適化: リアルタイムを支える技術
- 交換フォーマット: glTFとUSD
- 協業: パイプラインは結局、人の流れ
- リギングとアニメーション: 資産に命を吹き込む
- ある資産の旅: 剣からゲーム内の武器へ
- パイプラインのよくある落とし穴
- 現代パイプラインの変化: 二つの世界の収束
- 資産管理: バージョンとキャッシュ
- おわりに
- 参考資料
はじめに
前の記事で私たちは形を作り(モデリング)、表面に質感をまとわせました(テクスチャリング・レンダリング)。しかし実際の作品一つが完成するまでには、これよりはるかに長い旅が必要です。モデルはUVを広げ、テクスチャをまとい、骨組みを備え、動きを覚え、ついに光のもとで一枚の絵や一本の映像になります。この一連の段階をまとめて**パイプライン(pipeline)**と呼びます。
興味深いのは、同じモデルでもそれがゲームへ向かうか映画へ向かうかによって、パイプラインの姿がかなり変わるという点です。ゲームは1秒に数十回も画面を描かねばならないので速度が絶対です。一方、映画は1フレームを数時間かけて計算してもよいので画質が優先です。この根本的な違いが資産を作る方法全般に影響します。
この記事では、3D資産パイプラインの全体の流れをまず見たうえで、ゲームのリアルタイム(real-time)環境と映画のオフライン(offline)環境がどう分かれるか、そしてその間で資産をやり取りするフォーマットと協業の方法まで幅広く扱います。
資産パイプラインの全体の流れ
まず一つの3D資産が経る標準的な段階を見ていきます。ゲームでも映画でも大きな幹は似ています。
3D資産パイプラインの標準的な流れ
[モデリング] 形を作る
│
▼
[UV展開] 表面を2Dに広げる
│
▼
[テクスチャ] 質感と色をまとわせる (PBRマップ)
│
▼
[リギング] 動けるように骨組み(skeleton)を仕込む
│
▼
[アニメーション] 骨組みを動かして動作を作る
│
▼
[レンダー] 光を当てて最終結果を出力する
各段階を簡単に押さえます。
- モデリング: メッシュで形を作ります。
- UV展開: テクスチャをまとわせるため表面を平面に広げます。
- テクスチャリング: ベースカラー・ラフネス・ノーマルなどPBRマップで質感を定義します。
- リギング(Rigging): キャラクターや動く物体に骨組み(スケルトン)と制御装置を仕込みます。人形の中に関節を入れるようなものです。
- スキニング(Skinning)/ウェイト(Weight): 各骨がメッシュのどの部分をどれだけ動かすか重みを決めます。
- アニメーション: 骨組みを時間に沿って動かして動作を作ります。
- レンダー: カメラと照明を設定し最終的な画像や映像として出力します。
ここで分かれ道が生まれます。最後の二段階、特にレンダーがリアルタイムかオフラインかによって、前段階の作業方法までさかのぼって影響を受けます。
リアルタイムパイプライン: ゲームエンジンの世界
ゲームはプレイヤーの入力に即座に反応して毎瞬間新しい画面を描かねばなりません。通常は毎秒30回、60回、あるいはそれ以上のフレームを途切れず作り出さねばならないので、1フレームを描くのに許される時間はわずか数ミリ秒です。この過酷な制約がリアルタイムパイプラインのすべての決定を支配します。
リアルタイムレンダーループ(単純化)
┌─────────────────────────────────────────┐
│ 毎フレーム(例: 16.6ms以内に完了) │
│ │
│ 入力処理 ──▶ ゲームロジック ──▶ カリング │
│ │ │
│ ▼ │
│ GPUドローコール提出 ──▶ シェード │
│ │ │
│ ▼ │
│ 画面に出力 │
└─────────────────────────────────────────┘
上の過程を1秒に数十回繰り返す
代表的なゲームエンジンにUnityとUnreal Engineがあります。両エンジンはリアルタイムレンダリング、物理、サウンド、入力処理などを統合提供し、資産を受け取って実際に動くインタラクティブな体験にしてくれます。
リアルタイム環境で資産を作るときは次の概念が核心です。
ポリゴン予算(Poly Budget)
画面に一度に描けるポリゴン数には限界があります。そこで各資産に使えるポリゴン数をあらかじめ決めておきます。これをポリゴン予算と言います。キャラ、小物、背景ごとに予算が異なり、この中で最大限よく見せるのがリアルタイムアーティストの核心的な力量です。
LOD(Level of Detail)
遠くにある物体は細かく描く必要がありません。そこで同じ物体を複数段階の精度で用意しておき、カメラとの距離によって入れ替えます。これをLODと言います。
LOD段階の切り替え
距離 使用モデル ポリゴン数(例)
──────── ──────────── ──────────────
近い LOD0(高密度) 20,000
中間 LOD1 8,000
遠い LOD2 2,000
とても遠い LOD3(低密度) 500
* 遠ざかるほど軽いモデルに替えて性能を確保
ドローコール(Draw Call)
CPUがGPUに「これを描け」と指示する一回の命令がドローコールです。ドローコールが多くなるとCPUがボトルネックになり性能が落ちます。そこで複数の物体を一つにまとめて(バッチング)ドローコール数を減らす最適化が重要です。
ドローコール最適化の概念
最適化前 最適化後(バッチング)
物体A ──ドローコール1──▶ 物体A ┐
物体B ──ドローコール2──▶ GPU 物体B ├─ドローコール1──▶ GPU
物体C ──ドローコール3──▶ 物体C ┘
ドローコール3回 ドローコール1回 (CPU負担減)
このほかにもテクスチャを一枚にまとめるアトラス(atlas)、ノーマルマップでディテールを代替する技法、同一素材でまとめることなど多様な最適化が動員されます。リアルタイム作業の本質は「限られた資源で最大限それらしく」です。
オフラインパイプライン: 映画のレンダーファーム
映画や高品質映像の1フレームは一度計算すれば終わりです。その代わり画質に妥協がありません。1フレームを描くのに数十分から数時間かかってもかまいません。90分のアニメ映画ならこうしたフレームが十数万枚必要なので、1台のコンピューターでは到底まかなえません。そこで登場するのが**レンダーファーム(render farm)**です。
レンダーファームの仕組み
[ジョブ提出]
ショット/フレームを作業単位に分割
│
▼
[スケジューラ/キュー] ジョブを複数ノードに分配
│
┌────┼────┬────┐
▼ ▼ ▼ ▼
ノード1 ノード2 ノード3 ... ノードN (数十~数千台)
│ │ │ │
└────┴────┴────┘
│
▼
[結果集約] 完成したフレームを集めて映像に
レンダーファームは多数のコンピューター(ノード)がフレームを分けて同時に計算する分散システムです。映画1本を作るとき1台で1000日かかる作業も、1000台に分ければ1日で終わります。オフラインレンダーは主にレイトレーシング・パストレーシング系を使い、反射・屈折・間接光・サブサーフェススキャタリング(肌のような半透明表面)などを物理的に忠実に計算します。
オフライン環境ではポリゴン数やテクスチャ解像度への制約がはるかにゆるいです。ディスプレイスメントで本物の起伏を作り、数億のポリゴンを動員し、8Kテクスチャを何枚も重ねてもかまいません。画質が最優先だからです。
リアルタイム vs オフライン: 核心比較
二つのパイプラインの違いを一目で整理すると次の通りです。
リアルタイム vs オフライン比較
項目 リアルタイム(ゲーム) オフライン(映画)
───────────── ────────────────── ──────────────────
フレーム時間 数ミリ秒 数分~数時間
レンダー方式 主にラスタライズ 主にレイ/パストレース
ポリゴン制約 厳格(ポリゴン予算) ゆるい
テクスチャ解像度 限定的 非常に高い
最適化の比重 非常に大(LOD/ドロー) 相対的に小さい
相互作用 あり(プレイヤー入力) なし(決められたカメラ)
目標 滑らかな性能 最高の画質
代表道具 Unity, Unreal Cycles, Arnold など
ただしこの境界も次第にぼやけています。リアルタイムエンジンの画質が急速によくなり、映画・ドラマの背景を巨大なLED画面にリアルタイムで映してその前で撮影するバーチャルプロダクション(virtual production)のような技法が増えています。またゲームでも部分的なレイトレーシングが導入され、二つの世界が互いに似てきています。これらの機能の対応範囲はハードウェアとエンジンのバージョンによって異なる場合があります。
最適化: リアルタイムを支える技術
特にリアルタイムパイプラインでは最適化は選択ではなく生存の問題です。先に見たLOD・ドローコールのほかによく使われる技法を整理すると次の通りです。
- カリング(Culling): 画面外にあるか他の物体に隠れて見えないものはそもそも描かず飛ばします。見えないものを描く無駄を防ぎます。
- テクスチャアトラス/圧縮: 複数のテクスチャを一枚にまとめ、GPUに優しい形式で圧縮してメモリと帯域を節約します。
- インスタンシング(Instancing): 同じ物体(木、草、群衆)を数千個描くとき、データを一度だけ送って位置だけ変えて繰り返します。
- ミップマップ(Mipmap): テクスチャを複数サイズであらかじめ用意し、遠くの表面には小さなテクスチャを使ってちらつきを減らし性能を上げます。
- ベイクされた照明(Baked Lighting): 動かない静的環境の影と間接光をあらかじめ計算してテクスチャ(ライトマップ)に焼いておきます。リアルタイムに毎回計算しないので軽いです。
フレーム予算の配分(概念)
1フレーム16.6msの中で
████████ レンダー(シェード/照明)
████ 物理/衝突
███ ゲームロジック/AI
██ アニメーション
█ その他
* どこか一つが予算を超えるとフレームが落ちる(カクつき)
オフラインでも最適化が全くないわけではありません。レンダー時間を減らすためにサンプル数を調整し、デノイザー(denoiser)でノイズを除去し、不要な光線計算を減らすなどの努力がなされます。ただしその切実さの度合いはリアルタイムとは比べものになりません。
交換フォーマット: glTFとUSD
複数の道具と人が資産をやり取りするには共通の言語、すなわち標準ファイルフォーマットが必要です。今日最も注目される二つを見ていきます。
主要な3D交換フォーマットの性格
形式 主な用途 特徴
────── ────────────────── ─────────────────────────
glTF リアルタイム・ウェブ 軽く速い転送に最適、
・ゲーム転送 PBR標準を内蔵
USD 大規模映画制作の協業 巨大シーンのレイヤー・合成に強い
FBX 汎用資産交換 長い業界標準、互換性が広い
OBJ 単純な形状交換 単純・古典的、アニメに弱い
- glTF(GL Transmission Format): Khronosグループが作った開放型フォーマットです。「3D界のJPEG」と呼ばれるほど軽く転送に最適化され、PBRマテリアルを標準として持ちます。ウェブとリアルタイム環境で広く使われます。
- USD(Universal Scene Description): ピクサーが開発・公開したフォーマットです。巨大な映画シーンを複数の人がレイヤーで分けて同時に作業し合成するのに強力です。大規模制作協業の標準として定着しつつあります。
- FBX: 長く資産交換の事実上の標準として使われてきたフォーマットで、互換性が広いです。
フォーマットごとに強みが異なるので、どこへ資産を送るかによって適切なものを選びます。ウェブビューアやゲームならglTF、映画協業ならUSDが自然な選択です。
協業: パイプラインは結局、人の流れ
大きなプロジェクトで一人がすべての段階をこなすことはまれです。モデラー、テクスチャアーティスト、リガー、アニメーター、ライティング・レンダー担当が各段階を受け持ち資産を引き継ぎます。だからパイプラインは技術であると同時に人々の間の約束です。
協業パイプラインの流れ
モデラー ──▶ テクスチャ ──▶ リガー ──▶ アニメーター ──▶ ライティング/レンダー
│ │ │ │ │
└─────────┴──────────┴─────────┴──────────────┘
バージョン管理 · 資産ライブラリ · 命名規則
* 一段階の結果が次の段階の入力になる
* 一貫した規則がないと資産がずれて作業が止まる
円滑な協業のためにはいくつかの約束が必要です。一貫した命名規則(ファイルとオブジェクト名を統一)、バージョン管理(誰が何をいつ変えたか追跡)、共有資産ライブラリ(繰り返し使う資産を一か所で管理)、そして段階間の検収手続きです。こうした約束がないと、どんなに腕のよいアーティストが集まっても資産が互いにずれて作業が止まります。
技術的パイプラインがデータの流れなら、協業パイプラインは人と責任の流れです。よいスタジオはこの二つをともにうまく設計します。
リギングとアニメーション: 資産に命を吹き込む
パイプラインの途中には、静的なモデルを動かす段階があります。それがリギングとアニメーションです。この段階がどう機能するかをもう少し見ていきます。
リギングの基本構造
[メッシュ] ── 外から見える形
│
│ 中に骨組みを仕込む
▼
[スケルトン] ── 関節を持つ骨の階層
│
│ 各骨がメッシュのどの部分を動かすか決める
▼
[スキニング/ウェイト] ── 骨とメッシュの結合の強さ
│
▼
[コントロールリグ] ── アニメーターが扱いやすい操作装置
リギング(rigging)はモデルの中にデジタルの骨組み(スケルトン)を仕込む作業です。人が骨格を持って動くように、3Dキャラクターも骨に沿って動きます。次にスキニング(またはウェイトペイント)で各骨が表面のどの部分をどれだけ引っ張るかを決めます。肘を曲げたとき肌が自然に折れるには、このウェイトがよく設定されていなければなりません。
最後にコントロールリグを作ります。アニメーターが骨を一つひとつ直接回すのは面倒なので、手や足のような直感的な操作装置を作っておきます。よくできたリグは人形劇の精巧な人形のようで、アニメーターが速く自然に動作を作れるようにしてくれます。
リアルタイムとオフラインはここでも分かれます。ゲームのキャラクターは骨の数と影響範囲に制約があり、一つの頂点が受ける骨の影響数を制限する場合が多いです。一方、映画はそうした制約がゆるく、非常に精巧な顔リグや筋肉シミュレーションまで動員できます。
ある資産の旅: 剣からゲーム内の武器へ
抽象的な段階だけではぴんとこないので、仮想の資産一つがパイプラインを通過する過程をたどってみましょう。ゲームに入る剣一振りを例に挙げます。
剣の資産のパイプラインの旅 (リアルタイム)
1. ハイポリ制作
スカルプティングで刃の傷、柄の革の目まで精巧に
2. ローポリ制作(リトポロジー)
ゲーム用にポリゴン予算に合わせた軽いメッシュ
3. UV展開
刃・柄・鍔を効率的に広げる
4. ベイク
ハイポリのディテール → ローポリのノーマルマップ・AOに焼く
5. テクスチャリング
金属の刃、革の柄、錆と汚れをPBRで
6. エクスポート
glTF/FBXで書き出しゲームエンジンにインポート
7. エンジン設定
LOD段階生成、衝突メッシュ指定、マテリアル接続
この旅の核心はハイポリとローポリの分業です。精巧なディテールはハイポリで作り、実際のゲームに入るのは軽いローポリです。両者をつなぐ橋がまさにベイクされたノーマルマップです。この構造のおかげで少ないポリゴンでも精巧な剣が画面に現れます。
同じ剣でも映画へ向かうなら旅は変わります。ポリゴン予算がゆるいのでローポリ段階を省略してハイポリをそのまま使うこともでき、LODや衝突メッシュのようなリアルタイム専用の段階も必要ありません。代わりに8Kテクスチャとディスプレイスメントでディテールを最後まで押し上げます。目的地が作業の姿を決めるということを、この一振りの剣がよく示しています。
パイプラインのよくある落とし穴
パイプラインを設計し運用するときによく経験する問題があります。あらかじめ知っておけば高価な再作業を避けられます。
- スケールの不一致: 道具ごとに基本単位(センチ・メートルなど)が異なり、資産を移すとき大きさが100倍違うことがよくあります。プロジェクト初期に単位の基準を決めましょう。
- 後手の最適化: 画質だけ追って終盤にポリゴン予算を超え、全面再作業になる場合です。目標予算を最初から意識して作りましょう。
- 命名規則の不在: ファイル名がばらばらだと自動化ツールが資産を見つけられず協業がこじれます。規則を文書に残しましょう。
- ベイクエラーの放置: ノーマルマップのベイクで生じた欠陥(ケージ問題、面の交差)を無視すると、最終画面に変な影や筋が現れます。ベイク直後に検収しましょう。
- フォーマット盲信: 一つのフォーマットがすべての情報を完璧に移すと仮定してはいけません。アニメーション・ブレンドシェイプ・マテリアルが欠落することがあるので、移した後必ず確認しましょう。
- バージョンの混乱: 誰がどのバージョンを使うか追跡しないと、古い資産で作業する事故が起きます。バージョン管理を習慣にしましょう。
これらの落とし穴の共通点は「初期の約束の不在」です。パイプラインは始めるときに決めた規則が最後までついてきます。単位、命名、予算、フォーマットについての約束をプロジェクト序盤に明確にしておけば、後で生じる大部分の問題を予防できます。
現代パイプラインの変化: 二つの世界の収束
先にリアルタイムとオフラインをはっきり区別しましたが、ここ数年でその境界は急速にぼやけています。二つの世界が互いの技術を借りてきて、新しい作業方式が生まれています。
リアルタイムとオフラインの収束
過去 現在
────────── ──────────
リアルタイム ── 明確な壁 ── オフライン
(速度) (画質)
▼ 境界がぼやける ▼
リアルタイム ─ バーチャルプロ ─ オフライン
ゲーム用RT導入
エンジンの映画級レンダー
共通フォーマット(USD)
代表的な変化が**バーチャルプロダクション(virtual production)**です。巨大なLED壁にリアルタイムエンジンで背景を映し、俳優がその前で演技しながらカメラで撮影します。カメラが動くとLEDの中の背景の視点もリアルタイムで追って変わり、まるで実際の場所にいるかのような画面をその場で得ます。かつては映画の領域だった作業に、ゲームエンジンのリアルタイム技術が深く入り込んだのです。
もう一つの流れは共通フォーマットを通じた協業です。特にUSDは映画・ゲーム・ビジュアライゼーションなど異なる分野が同じ資産の記述方式を共有するのを助けます。一つの資産を複数の道具と分野が一貫してやり取りできるようになり、パイプライン間の壁が低くなっています。
USDが協業を助ける方式 (概念)
レイヤーA (モデラー) ┐
レイヤーB (テクスチャ) ├── 合成(コンポジション) ──▶ 最終シーン
レイヤーC (アニメ) │ 各レイヤーは独立して
レイヤーD (照明) ┘ 修正・交換可能
ただしこうした機能とワークフローは急速に発展する領域なので、具体的な対応範囲とベストプラクティスは道具・エンジンのバージョンによって異なる場合があります。大きな流れは明確です。リアルタイムとオフラインは、それぞれの強みを保ちながらも、資産を共有し技術を借りてきて互いに似てきています。したがって今日の3D作業者は、どちらか一方だけに閉じこもるより、両方の考え方をともに理解する方が有利です。
資産管理: バージョンとキャッシュ
規模が大きくなるほど、資産を「どう保存し追跡するか」が作業速度を左右します。パイプライン後半でよく扱う二つの概念を見ていきます。
資産バージョン管理の流れ
剣_v001 ──▶ 剣_v002 ──▶ 剣_v003(現在)
(初稿) (修正) (承認)
│
ここで分岐可能
▼
剣_v003_variant(変形)
* 古いバージョンを消さず保存してこそ戻せる。
- バージョン管理: 資産の変更履歴を保存し、問題が起きたとき以前の状態に戻したり誰が何を変えたか追跡したりします。コードのバージョン管理と同じ原理ですが、容量の大きいバイナリファイルを扱うという特殊性があります。
- キャッシュ(Cache): シミュレーション(布、髪、群衆、流体)のように計算が重い結果をあらかじめ計算してファイルに保存しておくことです。毎回計算し直さず保存されたキャッシュを読み込んで作業速度を上げます。アレンビック(Alembic)のようなフォーマットがこうしたキャッシュ交換によく使われます。
シミュレーションキャッシュの活用
重いシミュレーション計算 (1回)
│
▼
[キャッシュファイルに保存] ── 結果を凍結
│
┌─────┴─────┐
▼ ▼
レンダー作業 別のシーンで再利用
(速く) (再計算不要)
このように大きなパイプラインは単に資産を作るだけにとどまらず、それを体系的に保存・追跡・再利用するシステムの上で回ります。よい資産管理は目立ちにくいですが、プロジェクトが大きくなるほどその価値が明確になります。
おわりに
3Dパイプラインはモデリングから始まりレンダーで終わる長い川筋のようなものです。その川は目的地によって二つに分かれます。毎瞬間新しく描かねばならないゲームのリアルタイムの世界は、速度のためにポリゴン予算・LOD・ドローコールのような制約と最適化を受け入れます。1フレームに時間をかけられる映画のオフラインの世界は、レンダーファームを動員して画質を最後まで押し上げます。
二つの世界は異なる価値を追求しますが、出発点である資産の基本は同じです。きれいなトポロジー、よく広げたUV、忠実なPBRテクスチャは、どちらへ向かっても良い結果の土台になります。そしてglTF・USDのようなフォーマットと明確な協業の約束が、その資産を人と道具の間で滑らかに流していきます。
どの道を選んでも、パイプライン全体を頭の中に描ける人は、自分の作業がどこへ向かうかを知って作ります。その大きな絵こそが、結局よい資産とよい協業を生む最も頼もしい土台です。