前記事→長年の疑問だった「Lightmap Bakingで何が原因で重くなるのか」問題、いい加減決着をつけるの続き
検証１２：ライトの種類でベイク時間が変わるのか
DirectLightを大量に置くことはないと思われるが（太陽が何個もないという意味）、他のライトは大量に置くことがある。
そういったわけで、Spot Light、Point Light、Area Light の3種類の比較を行った。
| ライトの数 | Spotベイク時間 | Pointベイク時間 | Areaベイク時間 |
|---|---|---|---|
| 1 | 0:00:17 | 0:00:18 | 0:00:18 |
| 16 | 0:00:17 | 0:00:20 | 0:00:20 |
| 64 | 0:00:20 | 0:00:29 | 0:00:28 |
| 100 | 0:00:20 | 0:00:33 | 0:00:32 |
| 150 | 0:00:20 | 0:00:40 | 0:00:41 |
| 200 | 0:00:21 | 0:00:48 | 0:00:47 |
| 256 | 0:00:21 | 0:00:58 | 0:00:54 |
検証結果
驚くべきことに、Spot Lightはいくら増やしてもベイク時間が増えないという結果となった。
流石に何かの間違いだろうと思って、500個1000個とやってみたが、それぞれ24秒、32秒という結果であり、ほぼ増えないという結果となった。
その後、Spot Lightの「Outer Spot Angle」（影響の範囲）を179度ぐらいの広角にすると、ベイク時間が伸びた。
つまりSpot Lightのベイクは影響範囲を考慮されており、限定して利用すればベイク時間が短縮できるという結論となった。
Point LightもArea Lightも影響範囲を限定すればベイクに支障はないと推察できる。
疑問：Progressive GPUでやっていたはずなのにいつの間にかCPUに戻ってることがある
「Progressive GPU」を選択してベイクしていたつもりがなかなか終わらなくて、もう一回見てみると「Progressive CPU」になってしまっている時がある。バグか？と思ったが、どうやら仕様らしい。
Note: If the baking process uses more than the available GPU memory, the process might fall back to the CPU Lightmapper. Some graphics drivers with virtual memory support swap to CPU memory instead, which makes the baking process slower.
(翻訳)注：ベーキング処理で使用可能なGPUメモリーを超える量を使用した場合、処理がCPUライトマッパーにフォールバックすることがあります。仮想メモリをサポートしているグラフィックスドライバーの中には、代わりにCPUメモリにスワップするものがあり、その場合、ベーキング処理が遅くなります。
VRAMを確保するために余計なアプリケーションを閉じて、Progressive GPUを使ってベイクするようにしよう。
まとめ
以上の検証結果から、広域マップのライトベイク設定は以下のようにしていく。
-
ベイクの前に余計なアプリケーションを閉じておく
-
影を落とす側（例えば樹木）はStatic、Cast shadows: On、Receive Global Illumination:Light Probesにする
-
影を落される側（例えば道路、地面）はStatic、Cast shadows: Off、Receive Global Illumination:Lightmapsにする
-
大量にライトを配置する際はSpot light を利用する。または影響範囲を小さめのライトを使う
-
Progressive GPU LightmapperをON
-
SceneビューではBaked Lightmapを表示させる
-
Max Lightmap Sizeを妥当なサイズに（512~2048あたり）する
-
Lightmap Resolutionを小さい値にして、Baked Lightmapビューで十分な解像度が出ているか確認しながら調整する
