ライティング基礎|DCCとエンジンの差を切り分ける実践ガイド

「Maya でいい感じに見えていたのに、UE に持っていったら別物」──ライティングは、DCC とエンジンで最も差が出やすい領域です。原因はマテリアルでもメッシュでもなく、ライティングそのものの仕組みが両者で違うからです。本記事では、直接光・間接光・スカイの3要素/ベイクと動的の使い分け/プローブと HDRI/そして DCC とエンジンの差を切り分ける手順まで、現場で「光が違うんだけど…」と聞かれたときに即答できる粒度で整理します。
夕宮たいだふぁ……みんな〜、ライティングってほんと差が出やすいんだぁ。「Maya でキレイ→UE で別物」、最初みんなビックリするんだよぉ。今日はその仕組みを整理していこ〜。
1. なぜ DCC とエンジンで光が違うのか
ひとことで:使っているレンダラ・露出・色空間・ポストが、ぜんぶ別物だからです。
DCC(Maya / Houdini など)とゲームエンジン(UE / Unity)は、見た目は同じ「3D の絵を出す」道具ですが、ライティングの作り方は根本から違います。
- レンダラ:DCC は Arnold(Maya 標準)/ Karma(Houdini 標準)/ V-Ray(Chaos 社の業界レンダラ)などのオフラインレイトレーサ(光の経路を物理シミュレーションで追跡する高品質レンダラ)。エンジンはリアルタイムラスタライザ(三角形を画面ピクセルに変換する高速描画方式)+ハイブリッドレイトレース(一部だけレイトレースを使う複合方式)
- 露出:DCC は固定値、エンジンは Auto Exposure(自動露出)が標準
- トーンマッピング:DCC は線形出力か簡易マッピング、エンジンは ACES などの強いトーンマップが入る
- 色空間:sRGB と Linear の扱いが微妙に違う(CR-12 DCC→エンジンの色合わせ 参照)
- ポストプロセス:エンジンには Bloom / Tonemap / Color Grading が標準で乗る
つまり、まったく同じシーンを与えても 最終ピクセルに至るまでの処理が違う ので、見た目が一致しないのは当然です。「Arnold で見えたものを UE で完全再現する」発想ではなく、両者の差を体系的に切り分けて潰していく アプローチが必要です。
2. 直接光・間接光・スカイの3要素
ひとことで:シーンの光は「直接光・間接光・スカイ」の3層に分けて考えます。
下図のように、ライティングを構成する要素は次の3つに分けて捉えると整理しやすいです。


直接光(Direct Light)
光源から物体に直接当たる光です。Directional Light(太陽光のような平行光)/Point Light(電球のような点光源)/Spot Light(円錐状の指向性ライト)の3種が基本。直接光は影の発生源でもあり、シャドウマップを生成するのは原則として直接光の役目です。
間接光(Indirect Light / GI)
直接光が物体に当たって跳ね返り、別の物体を照らす光で、グローバルイルミネーション(GI)とも呼びます。部屋の隅が真っ黒にならないのは、壁や床に当たった光が跳ね返って影部分にも届いているからです。間接光の有無で、シーンの「奥行き感」が決定的に変わります。
スカイ(Sky / Environment Light)
空全体・周囲の環境から差し込む全方位光です。屋外なら青空からの拡散光、屋内なら窓やライトから漏れる環境光にあたります。HDRI(後述)はこのスカイの代替としてよく使われます。直接光・間接光に加えてスカイがあって、はじめて自然な見た目になります。



ていねいに整理するねぇ。「光がおかしい」ってときは、3要素のどれが足りてない/多すぎるか、で見るとわかりやすいんだぁ。
3. ベイク vs 動的:使い分けの判断軸
ひとことで:動かない光はベイク、動く光は動的、が基本配分です。
ライティングの計算は、事前計算(Bake)と毎フレーム計算(Dynamic)の2方式があります。それぞれの特性を理解して使い分けます。
ベイクの種類
ベイクライティングは、光と影の情報をテクスチャに焼き込む処理です。代表的なベイク対象は Lightmap(シーン全体の間接光・直接光をテクスチャ化/静的オブジェクトに適用)/AO(物体の凹凸が遮る環境光)/Shadow Map ベイク版(静的な影)の3種です。高品質な GI を計算できますが シーンを変えるたびに再ベイクが必要 で、ライト位置を1個動かすだけで数十分〜数時間の再計算が走ります。
動的(Dynamic / Realtime)
動的ライティングは毎フレーム再計算します。シーン変更に即座に追従しますが、計算負荷がフレーム時間に直接乗る のが代償です。動的ライト数の上限と最適化は CR-11 リアルタイム最適化チェックリスト で扱いました。
判断軸
下図のように、ベイクと動的は4つの軸で対比できます。


| 判断軸 | ベイク | 動的 |
|---|---|---|
| 動的変化への追従 | × | ◎ |
| 実行時コスト | ◎(ほぼゼロ) | △〜× |
| 品質(GI) | ◎ | △〜○(Lumen等で改善中) |
| メモリ | △(ライトマップ容量) | ◎ |
「動かない床・壁・建築物=ベイク」「歩き回るキャラ・動かせるオブジェクト=動的」が基本配分です。両者の中間に位置するのが、次のプローブ系です。



うぐぅ……どっち選ぶか、最初みんな迷うんだぁ。「動くか動かないか」で切り分けるのが基本だけど、半端に動くものはプローブ、って覚えとくと楽だよぉ。
4. ライトプローブ/リフレクションプローブ/HDRI
ひとことで:動的オブジェクトの光と映り込みを、空間の代表点から拾うのがプローブ系です。
ベイクは静的オブジェクトしか照らせず、動的ライトはコストが高い。その間を埋めるのがプローブと HDRI です。
ライトプローブ(Light Probe)
空間内の代表点に「その点に届く光の情報」を保存しておき、動的オブジェクトがその点を通るときに光情報を取得します。床や壁のライトマップを動的キャラに直接適用できないので、近傍プローブの光を補間してキャラの陰影を作ります。
容量が小さく、配置と再ベイクで間接光をある程度再現できる、というコスパの良い手法です。
リフレクションプローブ(Reflection Probe)
映り込み用のプローブです。プローブを置いた位置からのキューブマップを焼き込み、近くの金属やガラスの反射に使います。
ライトプローブが「拡散光」のためなら、リフレクションプローブは「鏡面反射」のためのものです。屋内の窓・湖面・金属パーツの近くに配置するのが定石です。
HDRI / IBL(Image-Based Lighting)
HDRI(High Dynamic Range Image)は、全方位を撮影した広いダイナミックレンジの画像です。これを環境光として使うのが IBL(Image-Based Lighting)です。
DCC では Arnold / V-Ray などで定番の照明方法で、屋外の自然光や複雑な室内光を1枚の画像で表現できます。エンジン側でも Skybox / Sky Light として読み込めますが、DCC の IBL とエンジンの Sky Light は微妙に挙動が違うので、後述の切り分け手順で確認します。


5. UE5 Lumen / Unity HDRP の概観
ひとことで:動的GIをリアルタイムで実用域に押し上げた、近年のソリューションです。
下図のような実機画面を見ると、近年の動的 GI が「事前ベイクしないのにここまで」というレベルにあることがわかります。
UE5 Lumen
Unreal Engine 5 で標準化された 動的グローバルイルミネーション です。シーン変更に即座に追従し、間接光・反射まで実時間で計算します。Software Lumen(GPU 計算ベース)と Hardware Lumen(RTX 系のレイトレース利用)の2モードがあり、品質と性能でトレードオフを選べます。
「ライトマップを焼かない」運用が現実的になったため、UE5 のシーン構築は従来とフローが変わりました。事前計算が消える代わりに、Lumen の品質設定とパフォーマンス予算が新たな調整点になります。
Unity HDRP / URP
Unity の HDRP(High Definition Render Pipeline)はハイエンド向けの描画パイプラインで、Realtime GI、Reflection Probe、Volumetric Lighting などを統合的に扱えます。URP(Universal Render Pipeline)はモバイル〜中堅向けで、軽量なライティングを志向します。
Lumen 相当の機能は HDRP でも一部の機能(SSGI、Reflection Probe の動的更新)で実現可能ですが、UE5 のような「即動的GI」の手軽さでは、現状 Lumen が一歩先行しているのが実情です。
既存ベイク技術との関係
動的 GI が来たから「ベイクは終わった」というわけではありません。モバイル・Switch などの軽量プラットフォームでは引き続きベイクが現役 です。プラットフォームと品質要件で、動的・ベイク・ハイブリッドを使い分けるのが現実的な落としどころです。



ほえ〜、ベイクなしでここまで動的にできちゃうんだぁ。すごいねぇ。でも、軽量プラットフォームではベイクも現役だから、両方使えるようにしとくのが大事なんだよぉ。
6. DCC↔エンジンの差を切り分ける手順
ひとことで:色空間 → ライト構成 → トーンマップ → ポストの順に潰します。
「DCC とエンジンで光が違う」ときの切り分けは、下図のような4ステップで進めます。順序を守るのが重要で、上位の問題を残したまま下位を直しても堂々巡りになります。


ステップ①:色空間(Linear / sRGB)
最初に確認するのは色空間です。テクスチャの sRGB / Linear 設定、レンダラのワーキングカラースペース(計算に使う色空間)、出力色空間が両環境で一致しているかを確認します。BaseColor が sRGB、ノーマルや Roughness が Linear、というのは大原則です。詳細は CR-12 DCC→エンジンの色合わせ(リニア・sRGB) で扱います。
色空間がズレていると、全体的に明るすぎる/暗すぎる/色が浅い といった大味な差が出ます。最も目立つ症状なので最初に潰します。
ステップ②:ライト構成
次にライトの構成を確認します。
- 直接光の数・強度・色温度(K)が両環境で一致しているか
- 間接光(GI)が両方でオン/オフ揃っているか
- スカイ(HDRI / Sky Light)が両方で同じ強度になっているか
DCC では IBL 1枚で済ませているシーンを、エンジンで Sky Light + Directional Light に分けて再現する場合、強度配分を意識的に揃える必要があります。
ステップ③:トーンマッピング
トーンマッピング(HDR → SDR への色域変換)は、エンジン側で常に何かが入っていると考えてください。UE は ACES Tonemapper が標準オン、Unity HDRP も同様です。一方 DCC(Arnold 等)は線形出力か簡易マッピングが多いです。
両者を完全一致させるのは難しいですが、エンジン側のトーンマッパーを「Linear」または「Off」に切り替えて DCC 側と並べると、レンダラ純粋出力レベルで比較できます。差の切り分け手段として有効です。
ステップ④:ポストプロセス
最後に、エンジン側のポストプロセスを確認します。Bloom / Color Grading / Auto Exposure / Vignette など、デフォルトでオンになっているポストが多いです。
ポストプロセスボリュームを すべて無効化 したシーンと比較すると、DCC との差が大きく縮まることがしばしばあります。逆に、ポストを意図して使い込んでいる場合は、その効果込みで「最終絵」を判定します。



ほら、順番に潰せば原因見つかるんだよぉ。一気にぜんぶ揃えようとせず、上から1個ずつ確認していくのがコツ。便利でしょ?
7. ハンズオン演習
ひとことで:同じシーンを Maya Arnold と UE で並べて、ライト1個ずつ追加しながら差を観察します。
1. Maya / Houdini と UE5 で、同じ簡単なシーン(床+壁+ボックス)を用意 2. ライトなし の状態で両方をレンダ/プレビュー → 真っ黒同士なら出発点として OK 3. Directional Light を1個 だけ追加 → 強度・色温度を一致させて比較 4. 間接光をオン → 両者の間接光の出方を比較(DCC は Arnold の Light Sampling、UE は Lumen / Lightmap) 5. HDRI / Sky Light を追加 → 強度差を確認 6. 各ステップで気になる差が出たら、ステップ①〜④の切り分け順で原因を探す
この演習で「どこで差が広がるか」を体感しておくと、本番制作時のトラブルシュートが一気に速くなります。
8. チェックリスト
ひとことで:ライティングを設計するときのセルフチェック項目です。
- [ ] 直接光・間接光・スカイの3要素を意識して構築している
- [ ] 動かない光はベイク、動く光は動的、の基本配分が守られている
- [ ] ライトプローブが動的キャラの軌道上に配置されている
- [ ] リフレクションプローブが反射対象の近くに配置されている
- [ ] 動的ライト数がプラットフォーム上限内に収まっている
- [ ] テクスチャの sRGB / Linear 設定が正しい
- [ ] DCC とエンジンで色空間設定が揃っている
- [ ] トーンマッピングの存在を意識して比較している
- [ ] ポストプロセスを切った状態でも比較している
- [ ] ベイク後にライトを動かす運用になっていない(再ベイク前提)
9. よくある間違い・トラブルシュート
ひとことで:露出・トーンマップ・色空間・プローブ未配置、が定番の事故です。
DCC の IBL とエンジンの Sky Light を同等とみなす
両者は「環境光」ですが、強度の単位や減衰モデルが微妙に違います。DCC の IBL の数値をそのままエンジンの Sky Light に入れても、見た目は一致しません。実機で目視確認しながら調整する 前提で運用します。
露出(Auto Exposure)の差を見落とす
DCC の固定露出と、エンジンの自動露出(Eye Adaptation)は、シーンの平均輝度で見え方が変わります。UE で「明るい場所と暗い場所で見え方が違う」のは Auto Exposure が働いているからです。比較時は Auto Exposure を一時的に Off にすると、純粋なライティング差が見えます。
トーンマッピングを意識しない
ACES などの強いトーンマッパーが入っているエンジンと、線形出力の DCC を直接並べると、色のコントラストが必ず違います。両者を比較するときは、エンジン側のトーンマッパーを Linear または Off に切り替えてください。
ベイク後にライトを動かす
ライトマップを焼いた後にライトを動かしたり、シーンに新しいオブジェクトを足すと、ベイク済みの光と実際のシーンが一致しなくなります。表面的には「壁の影が動かない」「新オブジェクトに間接光が当たらない」といった症状で出ます。ベイク後の変更は必ず再ベイク がルールです。
プローブ未配置のまま動的キャラを置く
ライトプローブを配置しないままキャラを置くと、動的キャラに間接光が届かず暗いまま・浮いたままになります。動的オブジェクトが通る経路には必ずプローブを配置してください。



ふぁ……ライティングの全体像、これでだいたい OK ……かなぁ。「光が違う」ときは、上から順に潰す。これだけ覚えとけば大丈夫だよぉ。
10. 次に読む記事
ひとことで:ライティングに関連する周辺トピックに進みましょう。
- CR-01 PBRの理論:マテリアルとライトの関係の基礎
- CR-11 リアルタイム最適化チェックリスト:動的ライト数・シャドウ解像度の最適化
- CR-12 DCC→エンジンの色合わせ:色空間の不一致が引き起こす絵の崩れ
- CR-04 ノーマルマップとタンジェント空間:陰影が割れる原因の切り分けに必須
- MY-I09 Arnoldで形状確認用のレンダリング:Maya 視点での Arnold ライティング詳細(公開準備中)








