三、ベイクの効率と効果の最適化
シーン作成の規模が大きくなっていることは、ベイク処理のプロセスへの影響：
1）ベイク処理の量の増加；
2）単一マップのベイク時間は大きくなってきて、ベイクはプログレスバーでフレーズする可能性もあります；
3）ライトマップ解像度の精度が変わらない場合、ライトマップの数量が大きいほど、メモリの使用も高い。
この三つの問題はGenerate Lightingのプロセスとかかわるため、Unityのライトデータを生成する計算プロセスを理解する必要があります。
3.1 Generate Lighting Process
Generate Lightingしている時、エディタの右下にはPrecompute Processがバックグラウンドでの処理の進捗状況が表示されます。
公式サイトによって紹介されたライトの計算プロセス：
単一シーンのベイクには、コストが高いのはマッピングライトの情報（5/11）とライトの計算（7/11）で、ベイク速度に影響を及ぼすのは主にUVの合理性とライトの計算精度です。
Unityは、Precomputed RealtimeGIを最適化するためのアセットと詳しいガイダンスを提供しています。原文を読むことをお勧めします。
このガイダンスはベイク速度を最適化するポイントを際立たせました。
Over the course of the document we will cover:
How to determine an appropriate lighting resolutionfor our Scenes.
What Charts are and how they affect our precompute times.
How to start the precompute process.
Using probe lighting to reduce the complexity of our lighting
Improving auto-unwrapped UVsgenerated by Unity’s Precomputed
Realtime GI.
What Clusters are and how they are used to generate globally
illuminated lighting.
Using Lightmap Parameters to fine-tune our lighting on a per-object
3.2 UV Charts、Lightmap UvsとClustersに対する理解
静的オブジェクトのライトを計算する時、Precomputed Realtime GIはまず一部のライトデータを計算してLighting Data Assetに保存します。これらのデータが実行している時に、一組の低い解像度のライトマップが生成されました；Baked GIはライトデータをオフオンラインでライトマップを生成します。リアルタイムのLightmapとベイクLightmapとは直接的な対応関係がなく、二つのオブジェクトは同じrealtime Lightmapにあってもいいです。二枚のBaked Lightmapには、Baked UVsとPrecomputed realtime UVsは異なっています。プレビュー画面からUV ChartingとLightmapが見られます。
1）UV Chartsを理解する
UV Chartは静的オブジェクトがライトマップのUVに対応しているところです。リアルタイムGIをプレ計算する時、毎Chartのピクセルでもライトを計算し、プレ計算の時間はChartの数量と大きくかかわっています。そのため、Chartsはどのように働くのかを理解するのは、ライトの計算時間の最適化に役立っています。
各オブジェクトのUV Chartsは一組のUV Chartによって構成され、各UV Chartは連続しているUVセグメントとなさっています。テクスチャのオーバーフローを防ぐために、UV Chainの間に0.5ピクセルのエッジが予約されています。最小単位は44で、各Chartには、少なくとも16のピクセルを占めています。例を挙げれば、ある11メートルのオブジェクトは、Lightmap Resolutionの解像度を1に設定した場合、一つのChartはライトマップに16のピクセルを占めています。50個のChartsでしたら、ライトマップに占めるピクセルは800になります。
左図：6個のUV Charts、少なくとも96ピクセルを示す；
右図： 1個のUV Chartに最適化される
2）UV Charting Control
UV Chartのパラメータは、静的オブジェクトのライトマップパラメータで調整できます。UnityのUVマッピング方法は直交しており、Unwrappingアルゴリズムは、UVフラグメントによって共有されているエッジと隣接するエッジを見つけ、それらをステッチすることにより、Lightmap UVsを簡素化します。
Max Distance最大距離（デフォルト値0.5）およびMax Angle最大角度（デフォルト値89）のパラメーターを変更することにより、UV Chartの数を減らすことができます。
Max Distanceは、設定された距離内でのUV shellの接続とステッチを表します。UVのエッジが設定されたMax Distance内にある場合、ステッチの対象と見なされます。Unityシステムのデフォルト値は0.5単位です（単位は1メートルなどのUnityシステム単位です）。オブジェクトが大きい場合は、パラメータ値を大きく設定できます。 値が大きいほどUVフラグメントは減少しますが、実際の状況に応じて考慮する必要があります。ライトマップでより多くのピクセルを占める必要があるオブジェクトの場合、より多くのUVフラグメントが必要になります。
Max Angleは、設定された角度範囲内でのUVシェルの接続とステッチを表します。UVエッジステッチと隣接するサーフェス間の角度も関連しています。同じエッジを共有する2つのサーフェス間の角度は設定されたMax Angleにある場合、ステッチの対象と見なされます。値が大きいほどUVフラグメントは減少しますが、値が大きすぎるとUVストレッチが発生する場合があり、適切な設定も必要です。
導入されたmesh数に対して、メッシュ数が多すぎるため、子Meshに分割されます。分割されたメッシュには異なる角度の法線を持ち、Chartsの分布にも影響します。Ignore Normalsがオンになっている場合（Precomputed Realtime GIのみがこのオプションの影響を受けます）、Chartsは分割されません。ほとんどの場合、メッシュを分割するためにChartsを分割する必要はありません。Ignore Normalsというオプションをオンにすることに注意してください。
Window> LightingのObjectタブで、Chartingプレビューを選択して、選択されたオブジェクトのChartの分布を確認できます。
SceneウィンドウのUV Charts可視化プレビューを使用すると、単一のオブジェクトのUVChartsの数を簡単に確認できるし、使用が適切かどうかを評価できるし、バランスを見つけることができます。
木の葉、低木などの小植物など、UVChartsで合併できない状況では、Light Probeを使用できます。
3）Clustersを理解する
計算を単純化するために、Unityは最初に静的シーンをClustersにボクセル化します。シーン内で、メッシュを介して静的ジオメトリの表面にマッピングしてライト計算に用いますClusters与UV Chartsには同様のライトマッピング方法がありますが、独立した機能です。
SceneウィンドウのClustering可視化プレビューモードを介して、Clusterの分布を確認できます。
上図の正方形のカラーブロックはClusterです
4）Generate Lightmap UV
ほとんどのオブジェクトに対して、UnityのGenerate Lightmap UVsのデフォルトパラメータを使用して、ライトマップを生成するUVを計算します。HardAngleパラメータ値は、オブジェクトの角度に応じて手動で調整して、過度のUV切断を防ぐことができます。
できるだけUntiyを使用してLightmaUVを生成してください。手動で処理されたUVフラグメントはライトマップに再配置され、Unityの自動UVよりも前処理に時間がかかります。Unityが自動的にUVを処理する場合、LightmapでUVフラグメントを1つずつ配置します。UnityのGenerate Lightmap UVsを使用しない場合、オブジェクト自体の２番のUV情報はライトマップのUV情報として使用されます。手動処理した合併UVレイアウトから、UVフラグメントを見つけて配置します。
UVを自動分割して理想的なUV分布を得ることが難しい場合があります。この場合、モデルの2番目のUVを手動で処理する必要があります。UVを手動で処理する場合は、UVフラグメントを減らして歪みのないことを維持することが必要となります。
Unityの自動的に生成したUVと3DSMAXの中にある手動処理した連続的な２番UVの効果の比較
２番UVを手動処理する時に注意してください：エクスポートされたオブジェクトに複数の子Meshがある場合、すべての子Meshには、２番UVを手動処理する必要があります。そうでなければ、Generate Lightmap UVsを選択しないと、２番UVのデータは得られなく、ベイク結果が黒くなります。例を挙げれば、ここの樹幹と木の葉が合併されて一つのオブジェクトとしてエクスポートされます。3DSMAXで樹幹の２番UVを変更するだけでは不十分です。また、木の葉もUnwrapして２番UVデータを生成する必要があります。
3.3ライトマップの占有ピクセルに影響を与えるパラメータ
単一のオブジェクトがライトマップで占めるピクセルは、複数のパラメーターの影響を受けます。UV Charting Controlのパラメーターが変更されない場合、主に、グローバルパラメータLightmap Resolutionと各オブジェクトのScale In Lightmapパラメーターの影響を受けます。
LightmapPaddingは、ライトマップにおけるオブジェクト間の間隔ピクセルを決定し、LightmapSizeは、単一のライトマップの最大サイズを決定します。ライトマップにはオブジェクトの対応するすべてのライトピクセルが収容されできない場合、複数のライトマップがベイク処理されます。
1）Lightmap Resolution
適切なLightmap Resolutionを選ぶのはとても重要です。それはシーンを制御するライトマップが総ピクセルで占める全局値です。公式に推奨されるLightmap Resolutionの値：シーンのスケールが世界単位（1 unit= 1メートル）と一致している場合、屋外シーンは0.5〜1、屋内シーンは2〜3、地形は0.1〜0.5です。1メートルを単位にして、豊かな屋内の小さなシーンでは、さまざまなライトとバウンスライトがあり、ライトマップの解像度を2〜3ピクセル/単位に設定できるため、より多くのライトの詳細が収容されます。大きな屋外シーンの場合、ゲームの世界の割合が大きくなります。オブジェクトの表面が数百メートルまたは数千メートルに達する可能性があります。同時に1つの表面にあるライトの種類が少なくなります。この場合、オブジェクトはライトマップの解像度を0.5〜1ピクセル/ユニットに設定でき、地形の場合は0.1〜0.5ピクセル/ユニットに設定できます。 古いバージョンのベイク処理テクノロジーでは、ベイク処理シャドーにはより高い精度が必要なため、リアルタイム解像度を10〜30に設定できます。混合ライトベイクモードでは、間接ライトとリアルタイムシャドーが推奨されます。これにより、ベイク処理シャドーの要件が多く軽減されます。 したがって、実際のシーンスケール、使用するベイクモード、およびベイク効果の要件を総合的に考慮して、適切な値を選択する必要があります。
2）Scale In Lightmap
面積の大きいオブジェクトは、ライトマップの精度とライトの計算精度を高く設定する必要があるという誤解があります。 実際、ライトマップの解像度が変わらない場合、ライトマップ上のオブジェクトが占めるピクセルもオブジェクトのサイズによって異なります。細かい小さなオブジェクトは、かえってより高い精度で設定する必要がある場合があります。
画面の左側は古い調整方法です。大きなオブジェクトのScale In Lightmapのパラメータを3または5に調整し、小さなオブジェクトのパラメータを0.5または0.1に下げます。これは手動でパラメータを変更することで不合理です。
画面の右側は新しいプロセスです。事前にScale In LightmapとLightmap Parameters配置をPrefabの中に保存して、シーンが構築された後、ライトの精度比がすでに形成されます。それでファイナルベイク結果に応じてシーンになる特別な条件を調整するだけで十分です。ほとんどのごく小さながオブジェクトを1つずつ調整する必要がないため、パラメータを手動で調整する手間が大幅に軽減されます。
全局Lightmap Resolutionに基づき、通用オブジェクトのScale In Lightmapを1に、特別な精度設定が必要なオブジェクトを分類によって規範を設定し、違っている精度比を設定します。たとえば、建物の壁の構造は単純で、光は主に低周波光であり、パラメータは0.5に下げます。都市の通りではより高いシャドーの精度が必要なので、パラメータは3に上げます。野生の植物が多数ある場合は、パラメータを0.5に低くします。細部のある主体オブジェクトの場合、パラメータを2に高くします。
Scale In Lightmapが調整前後のオブジェクトのライト精度を比較して、調整した後のライトマップのピクセルの占用分布がより合理的に見えます。
3.4 ライト精度の計算に影響を与えるパラメータ
影响ベイク时长的主要因素在于ライト精度的計算、主要是Lightmapping Settings上的参数配置。
ベイク時間に影響を与える主な要因は、ライト精度の計算であり、主にLightmapping Settingsのパラメータ構成です。
1）Indirect Resolution
ライトの計算は、Clusterを単位にして光を照射してライト情報を収集します。Indirect ResolutionはClusterの数に影響し、それを変更するとベイク処理の速度を向上させます。通常、ライト効果のデバッグ段階では精度を下げて最終的なライトパラメータを確認してから、またそれを上げてファイナルベイク効果を取得することをお勧めします。
2）Ambient Occlusion
Ambient Occlusion選択する時、オブジェクト間のオクルージョン関係が計算されます。シーンオブジェクトの数量が大きい場合、AO計算をオフにすることはベイク速度を向上させます。通常、ライト効果のデバッグ段階でオフにして最終的なライトパラメータを確認してから、またそれをオンにしてファイナルベイク効果を取得することをお勧めします。
3）Final Gather
Final Gatherが選択されている場合、Lightmapの解像度に従って、レイトレーシング（光線追跡法）を使用して、ライトバウンスを計算します。RayCountは、サンプリングされたライトによって計算されるレイの数を決定します。デフォルトは256です。値が大きいほど、ベイクプロセス中の計算時間が長くなります。常、ライト効果のデバッグ段階でオフにして最終的なライトパラメータを確認してから、またそれをオンにしてファイナルベイク効果を取得することをお勧めします。
4）Lightmap Parameters
Lightmap Parametersは、一組のPrecomputed Realtime GIのパラメータの集合です。さまざまな静的シーンオブジェクトに複数のパラメータのセットを設定できます。ベイク速度への影響は、主にResolutionとCluster Resolutionのパラメーターに反映されます。Resolutionは、ライト計算の精度に直接影響します。通常、0.1〜2にすることをお勧めします。Cluster ResolutionはClusterの数に影響します。通常、0.3〜0.6に設定することをお勧めします。値が大きいほど、ベイク時間は長くなります。ResolutionとCluster Resolutionは、ライト計算の精度を表します。Scale In Lightmapと違って、Lightmap Resolutionライトマップの解像度と最終サイズには影響しません。
Baked GIのBlur Radiusぼかし半径パラメータを調整することで、不十分なシャドー精度による効果を補正できます。
3.5シーンライトの管理和ベイク
モバイルプラットフォームのリアルタイムライトは厳密に制御する必要があります。初期段階ではシーンオブジェクトの分類と階層化を検討して、後の段階での光とシャドーの制御を容易にするようにしてください。実際の制作では、アーティストは問題を発見してから分類するかもしれません。仕様を事前に策定できるかどうかに関係なく、ベイクプロセスの非常に重要なステップであり、無視することはできません。
1）オブジェクトPrefabのライトパラメータを配置する
標準環境を構築し、モデルをインポートしてPrefabする時、標準環境でモデルの２番UVが妥当かどうかをテストし、モデルのUV ControlとLightmapパラメーターを調整し、通用規則に沿ってPrefabのScale in Lightmap値とLightmap Parameters配置をします。
Prefabに保存されているライトパラメータは、グローバルパラメータ、経験値と見なすことができます。シーンがPrefabを呼び出した後、ほとんどの場合、パラメーターを1つずつ調整する必要はなく、特別な状況を微調整して実際のシーンに適応するようにします。モデルのインポート段階では、モデルのUVをチェックし、オブジェクトのライトパラメータを配置すると、後期の大量なオブジェクトのライト配置の作業負荷を節約できます。
たとえば、町の街は、ベイクによって得られるシャドーの細部をサポートするのに十分な精度を必要とするため、Scale in Lightmapを3に設定し、Lightmap ParametersはHighを設定します。壁の構造は単純で、ライトは主に低周波光です。Scale in Lightmapは0.5に低下させることができ、Lightmap ParametersをLowに設定します。これらの特性に従って配置してください。
2）シーンオブジェクトの設計
オブジェクトを分類するのは、ライトの計算をすばやく割り当てることができます。これは、オブジェクトを管理したり、重複するオブジェクトを選択したりするのに便利です。たとえば、シーンの親ノードはEnvironmentであり、表示されているすべての静的シーンオブジェクトが含まれています。子レベルは、類似なサイズと構造のオブジェクトに従ってグループ化されるため、Staticパラメータの統一された設定が容易になり、後の最適化が容易になります。
3）ベイクライトの設計
通常、Directional Lightをメイン光源にして、マテリアル効果とシャドウを表現します、その属性はMixedです。シーンの原画概念にある色相と明度に従って、主光源の色と強度を事前に決定します。主光源のパラメータColorとIntensityはともにシーンの全体的な明るさを定めます。ColorBrightness*Intensity≈1を標準の参照値とされますが、同時に、周囲の環境光の平均明るさ、他の補助光の強度がシーンの明るさへの影響も考慮する必要があります
シーンの原画概念にあるシャドーの方向に基づいて主光源の角度を事前に決定し、極端な光の角度を使用しないようにします。例えば、地面に平行または地面に垂直な角度など、ベイク効果に不利です。
ライトのCullingMaskは、静的シーンオブジェクトと動的キャラクターが配置されているLayerに設定されます。CullingMaskを手動で設定する習慣を身に付け、Everythingの使用を避けてください。
主光源が1つしかない場合、ベイクには暗いコーナーが多くなり、シーン全体のトーンは比較的単一になります。通常、より良いベイク効果を得るために、ベイクフィルライトとして平行ライトを追加して、属性をBakedに設定し、平行光の方向、色、強度をよく決めます。ベイク補助用の平行ライトは2つ以下にする必要があります。平行光が多すぎると、ライトが複雑でアンリアルになり、さらに深刻な色のにじみの問題が発生します。したがって、同じ方向と色の平行光は一つだけを残ることをお勧めします。ベイク効果の色相は十分豊富ではない場合、後の色修正によって補うことをお勧めします。ColorGradingとLutのコストは、モバイルプラットフォームで許容範囲内です。
細部を表現するために他のタイプの補助ライトを追加し、シーンで光源が必要な位置でベイク処理するためのPoint Light、Area Light、およびその他のライトを追加します。
4）プリベイクとファイナルベイク
シーンの構築はほぼ完成した後、さらにディテールライティングを追加する必要があります。Enlightenの機能では、ライティングとライティングパラメータのみを変更すると、ライトマップをすばやくベイクできます。オブジェクトの追加、削除、変更は、リベイクと同じです。シーンオブジェクトが完全に決定されていない場合は、ベイクをデバッグする効率を改善する必要があります。
適切なRealtime Resolutionを選択し、ライトマップのおおよそのサイズを決定します。この段階では、特に的確である必要はありません。ライトマップの総数と占有率についてはあまり気にせず、最後のステップで微調整します。
グローバルに使用するために2セットのLightmap Parametersを設定します。
これらの2つのセットのパラメーターの違いは、主に、ベイク処理の速度に影響を与えるResolutionとClusterResolutionの値にあります。 シーンで配置されたLightmap Parametersは、これら2つのグローバル設定の影響を受けないことに注意してください。
左側：プリベイク；右側：ファイナルベイク
「プリベイク」は、第一のセットLightmap Parameters-LightmapPreBakeを使用します。Indirect Resolutionを下げ、AOとFinal GatherをオフにしてIndirect Resolution（間接ライト）計算の精度を下げます。これらのパラメータを調整すると、ベイク速度が速くなり、ライトマップのピクセル占有率が変化しないようになります。
「ファイナルベイク」では、第二のセットLightmap Parameters-LightmapFinalBakeを使用します。Indirect Resolutionを上げ、AOとFinal GatherをオンにしてIndirect Resolution（間接ライト）計算の精度を上げます。高配置のベイクマシンを使用して高精度のライト計算を取得します。
二つのベイク方法の比較
ベイクの結果からみれば、プリベイクでライトをデバッグするのは、効率がもっと高く見えます。ベイク効果に問題のあるオブジェクトをタイムリーに修正し（一部のエラーは、オブジェクトの法線と2番UVを修正することで解決できます）、ベイクに適さないオブジェクトをLight Probeに調整します。ライト効果を決定したら、ファイナルベイクを使用して、もっと多くのライトの詳細を取得します。ここは、Indirect Resolutionはライトマップのレイアウトに影響を与えるので、注意してください。最後の段階で、適切なリアルタイム解像度値を決定して、ライトマップのピクセル使用率を最大化するようにします。
公式マニュアルの例では、ベイク時間は7.5hrsから2.25minsに最適化されています。
3.6 他の問題
1）Light Probeの使用
Probe lightingは、リアルタイムライティングに近い技術であり、通常、キャラクターや非静的オブジェクトのライティングに使用され、実行時に高いパフォーマンスを発揮します。Probe lightingは球面調和関数を使用して、3D空間内の点の入射光をサンプリングします。これらの係数は、ストレージコストが低く、すばやく解凍されてシェーダーに使用されます。
Probe lightingの使用には制限があり、高周波光を計算することは困難であり、
特別な可視光放射範囲を計算するには精度が十分ではありません。低次の球面調和関数とパフォーマンスによって制限されるため、Probe lightingは大きなオブジェクトや複雑な受光には適していません。また、大きな平面や表面に凹状があるオブジェクトにも適していません。小さな凸状の物体には適しています。
ライトプローブを使用する利点：
LightProbeを使用すると、Lightmapのピクセル占有率を減らし、ベイク速度を上げることができます。シーンには、Lightmapに適さないオブジェクトがあります：複雑な構造の小さなもの、UVChartsの数が不合理なもの、ライトが単一なものなど
Lightmapの影響を受けないオブジェクトは、表示と非表示を最適化するのに便利です。
LightProbeの密度は、ライト計算の効率に影響します。オブジェクトの環境ライト状況に基づいて、プローブのレイアウトを行います。密度分布に注意を払う必要があります。LightProbeのコストは高くないが、Probeを配置する時、パフォーマンスの低下を考慮してください。密度が高すぎると、無駄が発生します。大幅な変更が必要な領域や、色をバウンスするために強い光が必要な領域に高密度のプローブを配置します。 同時に、簡易バージョンのLight Probeを作成して、ローエンドの画質に適します。
Light ProbeはLOD Groupの低精度モデルのライトにも用いられます。
Light Probeを設定しない場合、オブジェクトはFallbackのAmbient Probeライトを使用し、Ambient Probeサンプリングライトパネルに設定された環境光は、ユーザイーに表示しません。
2）Baked Reflection Probeの使用
特定の異なるエリアに対して複数の異なるReflectionCubeを作成します。
モバイルプラットフォームでのReflection ProbeのTypeは、通常、RealtimeではなくBakedを使用します。適切な解像度を設定します。Resolutionは、ベイク処理されたCubeの解像度を決定します。これは通常、256を超えません。Culling Maskを使用して、反射ベーキングに参加する必要のあるレイヤーを設定します。
Box Sizeの範囲の設定に注意し、複数の異なるReflectionCubeのエリアが重ならないようにしてください。エリアが重なると、オブジェクトの設定に従って混合されて、不必要なコストが発生します。GraphicsSettingsを使用してReflection Probes Blendingを無効にできます。
グローバルに使用するためのReflection Probeを作成し、Texture ShapeがCubeであるシーンの反射イメージをベイク処理し、Lightingパネルに配置することをお勧めします。シーン内のReflectionCubeは最適化中に無効にすることができ、Lightingパネルで配置されたCubemapがデフォルトで使用されます。
3）マルチシーン管理ライトマップ
適切な照明パラメータ設定の場合、シーン内のオブジェクトが多いほど、より多くのライトマップがベイク処理されます。同じ画面に描画されたオブジェクトは、多数の異なるライトマップを占める可能性があり、レンダリング中のメモリ圧力が増加します。マップサイズが2048サイズに達したら、大きなシーンをエリアに応じて複数のシーンに分割することをお勧めします。異なるエリアのオブジェクトのライトマップはシーンによって管理され、分割された小さなライトマップの数は制御され、シーンに沿ってローディングやとアンインストールします。
4）ベーキングハードウェア構成
最終ベーキングでは、より高い構成のハードウェアが使用されます。ベーキングマシンの推奨ハードウェア構成は、32コア256Gメモリです。
UWA Technologyは、モバイル/VRなど様々なゲーム開発者向け、パフォーマンス分析と最適化ソリューション及びコンサルティングサービスを提供している会社でございます。
今なら、UWA GOTローカルツールが15日間に無償試用できます！！
よければ、ぜひ！
UWA公式サイト：https://jp.uwa4d.com
UWA GOT OnlineレポートDemo：https://jp.uwa4d.com/u/got/demo.html
UWA公式ブログ：https://blog.jp.uwa4d.com