Search Unity

Unity 2019.2 では、Lightmap Static フラグが廃止され、Contribute Global Illumination フラグに差し替わりました。また、ライトマップとライトプローブのどちらからグローバルイルミネーションを受けるようにするかの選択も可能になりました。これらの変更は、ベイキングのパフォーマンスやシーンのライティングの質などに大きく影響を及ぼす可能性があります。これについて詳しく見ていきましょう。

ライトマッピングとライトプローブ

グローバルイルミネーションには、ライトが光源から照射された後にサーフェスからサーフェスへどのように跳ね返るかを算出するための複雑な計算が必要です。これを、ランタイムにおいて負荷の高い計算を加えることなく正確に行うのは、基本的に困難です。この問題を解決しながらもできるだけ高品質な結果を得るためのアプローチとして一般的なもののひとつは、高負荷な計算処理を、編集モードで実行される事前計算の段階で行うようにすることです。

これを行うためには前提として「シーン内のいくつかのオブジェクトと光源が相対的に同じ位置に留まり、変形せず、角度も変更されず、見た目に関わるプロパティも一切変更されない」ことが求められます。これを前提とした上で、ライトマッピングというテクニックを使ってライトの計算を行うことが可能となります。

Unity の Lightmap Static フラグは、このようなオブジェクトをマークするために提供されました。この機能名は、それが作成された当初は理に適っていましたが、静的オブジェクトのみがライトマップを使用するという意味も暗に含まれるものでした。しかし、静的ライトマップは、グローバルイルミネーションをシーン内に保持する数多ある方法のひとつに過ぎず、一定のデメリットもあります(これに関しては後述します)。

ライトマッピングのアプローチをグローバルイルミネーションに使用した場合、非静的(あるいは動的)オブジェクトは、(それらが静的であるという前提に反するため)グローバルイルミネーションに寄与することができません。後から動くことになるオブジェクト用にグローバルイルミネーションを計算すると、そのオブジェクトが元々照らされた位置でしか正しいライティング結果を得られません。これは、従来のライトマッピングの重大な制約のひとつです。

動的オブジェクトは、ライトプローブによって、他の静的オブジェクトからグローバルイルミネーションを受けることができます。ライトプローブは、全方向からのライトのサンプルが格納された、空間内における位置です。このライトは「球面調和関数」と呼ばれる特殊な値にエンコードされます。これによってランタイム中に、オブジェクトがワールド内を動き回る間、動的オブジェクトは周囲のライトプローブから値を受け取ることができるようになります。これにより動的オブジェクトは局所的なライトを受けられるようになり、周囲のライティング環境に正しく統合されて(馴染んで)見えるようになります。

技術的に、静的オブジェクトがライトマップの代わりにライトプローブを使用することの弊害となるものは何もありません。

使用しない理由があるでしょうか?

テクセルのコスト

ライトマップを使用しなければならないオブジェクトは展開されている必要があり、また、ライトマップ内にそのための領域が確保されている必要があります。ライトマップ内に投影される各オブジェクトは、解像度によって、一定量のテクセルを確保します。

例えば、ライトマップの解像度が 1 テクセル/1 ユニットの単位キューブ(寸法 1x1x1)は、各面に 1 テクセルずつを確保します。つまり、合計 6 テクセルとなります。ライトマッパーはこれらのテクセルのひとつひとつに関して、そのテクセルのワールド位置に到達するライトを計算する必要があります。この計算は、レイをキャストし、光源が発見されるまでシーン内でそのレイを跳ね返させ続けるという方法で行われます。使用テクセル数が多いほど、結果を計算するために掛かる処理量も増大します。小さなオブジェクトが多数あるシーンでは、この処理量の合計が結果的に大きくなります。事実、ライトマップのベイキングに極端に時間が掛かったり失敗に終わったりする場合の最も一般的な原因は、この種のオブジェクトの展開やチャート作成やライトマッピングです。

ライトマップの解像度が 1 に設定された状態で、ちょうど 1 テクセルを占領している Unity キューブ

小石やがれきなどの小さなオブジェクトや、ワイヤーやポールのような細いオブジェクトは、「無駄なテクセル」を発生させやすくなります。これらは オブジェクトの全体的な見た目には大きく寄与しないにも関わらず、計算時間を増大させ、ライトマップ内の領域を消費します。

細いオブジェクトは「オブジェクトの長さが 1 ~ 2 ピクセルで取り囲まれるため、見た目に与える影響が非常に小さくなる」ような展開をしばしば発生させます。これに類似して小さなオブジェクトは、ライトマップ内に、(そのオブジェクトの画面上でのサイズが小さいために)ほとんど(あるいはまったく)見た目に寄与しない幾つかのテクセルを生成する傾向にあります。結果として、ビジュアル的に重要性の低いテクセルのために、多くの計算時間が費やされるだけでなく、必要なライトマップ領域が増大することになります。

ライトプローブによって簡単に照らすことができる小さなオブジェクトの選択例

ライトマップの生成に掛かる時間を最適化する良い方法のひとつは、このような小さなオブジェクトを非静的にすることでライトマップの計算から取り除くことです。これにより(計算が必要となる)ライトマップの占有テクセル数が削減されます。ただし、これらのオブジェクトがシーン内のライティングに大きな影響を与えているケースも考えられます。例えば、非常に鮮やかな色の付いたオブジェクトや、エミッシブマテリアルの付いたオブジェクトが含まれる場合を考えてみてください。こうしたオブジェクトは Lightmap Static でなければシーンのグローバルイルミネーションに寄与することができません。結果として、目標とするライティング結果に対して重要な役割を担うオブジェクトの効果が欠如してしまうという場合もあります。

以上、この種のオブジェクトの扱い方として 2 つの選択肢があることが分かりました。つまり、(ベイク時間が長くなってライトマップ内の領域を無駄にする可能性があっても)この種のオブジェクトをライトマップしてシーン全体にその影響を含めるようにする選択肢と、あるいはその影響を無くして全体的な見た目とグローバルイルミネーションの質を犠牲にする選択肢です。この葛藤をどう解決すれば良いのでしょうか?

代わりにライトプローブを使用する

Unity 2019.2 では、オブジェクトにライトプローブからのグローバルイルミネーションを受けさせながらもシーンのライティングに寄与させることが可能になりました。これは、インスペクター内の Mesh Renderer の下に追加された小さなドロップダウンメニューから有効化できます。

新しいオプション ―「Contribute Global Illumination」(グローバルイルミネーションに寄与する)および「Receive Global Illumination」(グローバルイルミネーションを受ける)「

ここでは、メッシュレンダラーがライトマップからグローバルイルミネーションを受けるようにする(静的オブジェクトの場合の従来の唯一の選択肢)か、ライトプローブから(動的オブジェクトの場合の従来の唯一の選択肢)グローバルイルミネーションを受けるようにするかを選択できます。

Contribute Global Illumination フラグを有効にすると、そのオブジェクトがライトマッパーのグローバルイルミネーションの計算に含まれるようになります。オブジェクトは常に静的であるという前提は引き続きありますが、ライティングに求められる忠実度によって、オブジェクトがライトプローブを使用するかライトマップを使用するかを明示的に制御することが可能になりました。「Contribute Global Illumination(グローバルイルミネーションに寄与する)が、ライトプローブから Receive Global Illumination(グローバルイルミネーションを受ける)」オブジェクトは、やはりその周囲に影響を与えます。例えば「背の高い街灯が落とした影(シャドウ)が周囲のライトマップの計算に含まれ、かつ、この街灯に使用されているエミッシブマテリアルが周囲のシーンを照らす」ということです。

本機能を使用する

本機能が新しく追加されたことで、問題となる小さなオブジェクトや細いオブジェクトの最適化が非常に簡単に ― Mesh Renderer の Receive Global Illumination フィールドを Light Probes に設定するだけで ― 行えるようになりました。この設定をすれば、オブジェクトがライトマップ内で大きな領域を占有しなくなるので、これらのテクセルがライトマッパーに不必要に負荷を掛けることがなくなります。

ライトプローブを使用するもうひとつの大きなメリットは(展開に時間が掛かりがちな)本格的な UV が必要ないことです。ライトプローブの使用によって素晴らしい見た目になる動的オブジェクトで、一切動いたり回転したり修正されたりしないものがある場合には、そのオブジェクトに Contribute Global Illumination フラグを設定することも可能になっています。この設定を行うとそのオブジェクトは、ベイク時間を増大させることなく、ライトマップされた周囲のオブジェクトに影響を与えることができます。この時間の節約によって、使用メモリを削減しながらも生産性を向上させることができるのです。

まとめ

この革新によって、動的(あるいは非静的)オブジェクトをライトプローブで照らすことが可能になりました。このおかげで、グローバルイルミネーションの計算に含まれるオブジェクトに関して、間接光をライトプローブから受けるかライトマップから受けるかの指定が可能になったので、ライトマップ内のテクセル使用量が削減することができます。総じて、今回の変更によって期待される効果は、ライトマップの計算時間の大幅な削減、使用メモリの抑制、そしてランタイムのパフォーマンスの向上です。

プロジェクトのグローバルイルミネーションを最適化するこの他の方法をお知りになりたい方は、Unite 2018 で行われたこちらの講演動画をご視聴ください。

Unite Copenhagen が 9 月に開催されます

さらに詳細を学びたい方は、9 月に開催予定の Unite Copenhagen へぜひご参加ください。このイベントは、世界中から集まる何千人もの才能溢れるクリエイターやトップレベルの開発者と交流できる、またとない機会です!

学び、交流し、参加しよう

  • 何十もの技術系セッション、ポップアップ講演、基調講演で、Unity の最新機能、ヒントやコツ、ワクワクするような新情報が公開されます!
  • 楽しい交流イベントや「Unity at Night」パーティで業界のリーダー達と交流し、新しい友達を作りましょう。
  • ワークショップや質疑応答セッション、コミュニティイベントで Unity スキルをレベルアップさせ、キャリアの前進につながる人脈を開拓しましょう。

Unite Copenhagen についての詳細は Unity のウェブサイトでご覧いただけます。Unity の TwitterFacebook では最新のニュースを配信していますので、ぜひフォローしてください!

13 コメント

コメントの配信登録

コメント受付を終了しました。

  1. You can use thin round egg cold chinese noodles with sesame sauce recipe as an alternative.

  2. Benjamin Sims

    9月 19, 2019 5:45 pm

    The flag exists on terrain, however it is greyed out and Lightmaps is the only option for “Receive Global Illumination”. It would have been handy to have this option for terrain too.

  3. Can light probes be loaded additively from multiple scene now or are we still limited to a single set?

  4. Is this different from setting a renderers scale in lightmap to 0? I was under the impression that pre 2019.2 that made the object contribute to lightmaps while receiving its GI from probes

    1. Setting MeshRenderers to Lightmap Scale 0 would mean that these objects did not receive lighting, which is not desirable in many cases.

  5. “A good way to optimize the time it takes to produce a lightmap is removing these small objects out of lightmap calculations….”

    I don t agree with this construction.

    The best way to optimize baking time is to use a capable solution for bakeing like Bakery or Blender Cycles.
    It s lot s of factors faster and accurate.

    Second. GI for small objects and objects hard to unwrappe could be nicely baked to vertex color with both bake methods described above.
    The result should show much more quality like lit with lightprobes.
    Also “Lightmap space“ is abslotutely not an problem when lightmaps are propper virtualized.
    See actual Unreal VT Lightmap solution.

    1. Certainly removing objects which are good candidates for probe lighting will yield significant improvements to lightmapping performance. This is irrespective of which lightmapping solution you are using.

      Are you able to provide some benchmark Scenes to us in which Bakery or Cycles will give better performance using equivalent resolutions and sample counts. Perhaps then we can investigate. My own experience has actually been the opposite and by using the native lightmappers in Unity you will benefit from faster workflow and iteration.

      Vertex baking is something we would like to explore in the future.

      Reducing lightmap usage is beneficial whether you choose to stream your textures or not. More on this in the future.

      1. ImproveLighting

        8月 29, 2019 5:43 pm

        a detailed Benchmark on an open scene in HDRP i can share you can find here.

        Bakery 1.6.
        00h29m19s
        LightMap Quality *****

        PLM
        05h40m19s
        LightMap Quality **

        Enlighten+FG
        12h34m08s
        LightMap Quality *****

        more details here and some optimisation proposal multi gpu for the Bakery part… (click on view attachments for settings and results)
        https://forum.unity.com/threads/bakery-gpu-lightmapper-v1-6-released.536008/page-65#post-4763765

        To your questions.
        Lightmaps Size is mostly several 4k.
        See also Benchmark results provides above.
        In Blender Cycles there are also FullGI 8K bakes per material which are manually virtualized with depreated granite. 64k combines.

        1. FrakkleRogg

          9月 2, 2019 9:45 am

          From the timings you have there, I am inferring that you are comparing Bakery – which is built on top of Optix and utilizes the GPU – with the CPU progressive lightmapper. If you have selected the GPU lightmapper for your Scene and it falls-back to the CPU, there is a likelihood that you are reaching the VRAM limit of your card. We are working on a solution for this, but in the interim, you will likely be able to fix the problem by switching to 2K lightmaps or less.

          Regarding the Enlighten comparison: clearly a 12+ hr bake is not ideal. Enlighten has quite different content authoring requirements and it is likely that the Scene is not optimally setup for this back-end. Unnecessary charting will really hurt precompute times. In this case, assigning small objects to be Light Probe GI Contributors, as described in the blog post above, would really benefit your timings. See the tutorial here where we reduce precompute times from 7.5hrs to 2.26mins using simple techniques like this: https://learn.unity.com/tutorial/precomputed-realtime-gi-global-illumination#

          I fully believe you can achieve similar, if not faster, bake times using GPULM. Once you have these, the workflow improvements of not being locked out of the Editor or having to transfer assets back and forth between apps, should offer beneficial “quality of life” improvements.

      2. The future is now.

      3. Vertex baking is still a thing we want even on consoles, because it’s immune from bad UV or objects that can’t unwrap well (spheres, etc). You could use probes for these but that’s not that helpful for larger objects and proxy volumes aren’t that practical at times.

        Other than this I feel this currently discussed feature in this blog is a welcome addition (that I am currently using!) thanks!

        1. Jesper Mortensen

          9月 2, 2019 8:59 am

          While this is a neat feature in its own right the most important thing is that it decouples lighting with probes and lighting with lightmaps in the pipeline. This enables us to build new probe based workflows. More on this to come – keep tuned.

        2. FrakkleRogg

          9月 2, 2019 9:21 am

          Indeed, vertex baking has been captured internally as something we’d definitely like to have. Absolutely agree.