Search Unity

2019. 2버전에서는 Lightmap Static 플래그를 Contribute Global Illuminating 플래그로 교체했습니다. 또한 전역 조명을 라이트맵 또는 라이트 프로브 중 선택하여 받을 수 있는 기능을 도입했습니다. 이 변경사항을 통해 베이킹 성능, 씬 조명 품질 등을 크게 향상시킬 수 있습니다. 자세한 내용은 아래를 참조하시기 바랍니다.

라이트매핑 및 라이트 프로브

전역 조명에는 빛이 광원을 떠나 표면에서 표면으로 바운스되는 방식을 계산하기 위한 복잡한 계산 과정이 필요합니다. 런타임 중에 많은 비용이 드는 계산 과정을 추가하지 않고는 보통 이를 정확하게 수행하기 어렵습니다. 일반적으로 이런 복잡한 계산을 편집(Edit) 모드에서 미리 계산하면 품질 저하 없이 문제를 해결할 수 있습니다.

일단 씬 내의 여러 오브젝트와 광원이 상대적으로 정적인 상태를 유지하며 변형 또는 회전하는 등 외형과 관련된 프로퍼티가 변경되지 않는다고 가정합시다. 이 가정을 바탕으로 하여 라이트매핑이라는 기술을 통해 광원을 계산할 수 있습니다.

과거에는 정적 오브젝트를 표시하기 위해 Lightmap Static 플래그를 제공했습니다. 이 기능의 이름은 개발 당시에는 적절했지만, 정적 오브젝트만 라이트맵을 사용한다는 뜻을 담고 있습니다. 하지만 정적 라이트맵은 씬에 전역 조명을 저장하기 위한 다양한 방식 중 하나일 뿐이며 단점도 있습니다. 이 부분에 대해서는 곧 자세히 다루도록 하겠습니다.

전역 조명에 라이트매핑 방법을 사용할 경우, 정적이 아닌(혹은 동적인) 오브젝트는 전역 조명에 기여할 수 없습니다. 따라서 나중에 이동하는 오브젝트에 대해 전역 조명을 계산할 경우, 처음에 조명이 비춘 위치에서만 조명이 유효하게 됩니다. 이는 기존 라이트매핑이 지닌 커다란 한계입니다.

라이트 프로브를 사용하면 동적 오브젝트도 다른 정적 오브젝트로부터 전역 조명을 받을 수 있습니다. 라이트 프로브는 모든 방향으로부터 오는 공간 내 광원의 위치 정보를 담고 있습니다. 이 광원은 “스피리컬 하모닉”이라는 특별한 값으로 인코딩됩니다. 런타임 동안 동적 오브젝트는 월드 내에서 이동하면서 주위의 라이트 프로브로부터 값을 받을 수 있게 됩니다. 이를 통해 동적 오브젝트는 로컬 조명을 받아 주변의 조명 조건과 알맞게 통합된 상태로 나타나게 됩니다.

기술적으로 보면 정적 오브젝트가 라이트맵 대신 라이트 프로브를 사용하지 못할 이유가 전혀 없습니다.

왜 라이트 프로브를 사용하는 것이 좋을까요?

불필요한 텍셀 비용

라이트매핑이 필요한 오브젝트는 언래핑되어야 하며 라이트맵에 공간을 확보해야 합니다. 해상도에 따라, 라이트맵으로 투사되는 각 오브젝트에는 특정한 양의 텍셀이 배정됩니다.

예를 들어, 공간 단위당 1텍셀의 라이트맵 해상도에서는 단위 큐브(치수 1x1x1) 하나가 각 면마다 1텍셀을 차지합니다. 따라서 총 6텍셀이 됩니다. 이러한 경우 라이트매퍼는 각 텍셀을 기준으로 월드 포지션에 도착하는 광원을 계산해야 합니다. 이를 위해 광원을 찾을 때까지 광선을 쏘고 바운스를 반복합니다. 사용되는 텍셀이 많을수록 결과를 계산하는 데에 필요한 작업량이 늘어나며, 작은 오브젝트가 많은 씬에서는 작업량이 더 많아집니다. 따라서 작은 오브젝트를 언래핑, 차팅(charting), 라이트매핑할 때 주로 라이트맵 베이크가 실패하거나 지나치게 오랜 시간이 소요됩니다.

라이트맵 해상도가 1로 설정된 경우 1텍셀을 차지하는 단위 큐브

조약돌, 파편 등의 작은 오브젝트나 전선, 기둥 등의 가느다란 오브젝트의 경우 “불필요한 텍셀(waste texel)”이 발생하기 쉽습니다. 이러한 텍셀은 오브젝트의 전체적인 룩에는 그다지 기여하지 않으면서 계산 시간을 늘리며 라이트맵 공간을 차지합니다.

가느다란 오브젝트는 1~2개의 픽셀이 오브젝트의 길이 주변으로 래핑되어 언래핑이 발생하므로 룩에는 거의 영향이 없습니다. 마찬가지로 작은 오브젝트는 주로 라이트맵에 여러 개의 텍셀을 생성하지만, 화면상 오브젝트의 크기를 고려해 볼 때 최종적인 룩에 많은 영향을 미치지 않습니다. 결과적으로, 시각적으로 중요하지 않은 텍셀로 인해 많은 계산 시간과 라이트맵 공간이 필요하게 됩니다.

라이트 프로브로 손쉽게 조명을 적용할 수 있는 작은 오브젝트들

위와 같은 작은 오브젝트를 정적이 아닌 상태로 만들어 라이트맵 계산에서 제거하면 라이트맵 생성에 소요되는 시간을 최적화할 수 있습니다. 이를 통해 라이트맵 공간을 점유하여 계산해야 하는 텍셀의 수를 줄일 수 있습니다. 하지만 이러한 오브젝트가 씬 내 조명에 상당한 영향을 미치는 경우도 있습니다. 예를 들어 색상이 매우 밝은 오브젝트나 발광 머티리얼로 이루어진 오브젝트가 정적이 아닌 경우 씬의 전역 조명에 기여하지 않게 되어 원하는 조명 결과를 구현할 수 없습니다.

이러한 유형의 오브젝트를 처리하려면 두 가지 방법이 있습니다. 베이킹 시간과 라이트맵 공간이 더 많이 소모되더라도 오브젝트를 라이트매핑하여 씬에 영향을 주도록 하거나, 전체적인 룩과 전역 조명 품질을 포기하고 오브젝트의 영향을 적용하지 않을 수도 있습니다. 이 문제를 어떻게 해결할 수 있을까요?

라이트 프로브 사용

2019.2버전에서는 오브젝트가 씬에 조명을 기여하는 동시에 라이트 프로브로부터 전역 조명을 받을 수 있는 기능을 추가했습니다. 이 기능은 인스펙터 창의 Mesh Renderer에 추가된 드롭다운 메뉴를 통해 사용할 수 있습니다.

전역 조명 기여 및 수신 옵션(Contribute Global Illumination/ Receive Global Illumination)

여기에서 메시 렌더러가 라이트맵(이전에는 정적 오브젝트의 유일한 옵션) 혹은 라이트 프로브(이전에는 동적 오브젝트의 유일한 옵션)로부터 전역 조명을 수신할지 여부를 선택할 수 있습니다.

Contribute Global Illumination 플래그를 사용하면, 라이트매퍼의 전역 조명 계산에 오브젝트가 포함됩니다. 오브젝트가 항상 정적인 상태라는 가정은 그대로 유지되지만, 이제는 필요한 조명의 정확도에 따라 오브젝트가 라이트 프로브 또는 라이트맵을 사용할지 여부를 명시적으로 제어할 수 있습니다. 전역 조명에 기여한 다음 라이트 프로브로부터 전역 조명을 수신하는 오브젝트는 여전히 주위 환경에 영향을 미칩니다. 예를 들어 긴 가로등은 그림자를 드리우고 그림자 주변의 라이트맵에 대한 계산이 이루어지며, 가로등의 발광 머티리얼은 주위의 씬을 밝히게 됩니다.

새 기능의 장점

이제 새로운 기능을 통해 문제가 되었던 작은 오브젝트와 가느다란 오브젝트를 손쉽게 최적화할 수 있습니다. 메시 렌더러의 Receive Global Illumination 필드를 Light Probes로 설정하면 오브젝트는 라이트맵의 공간을 차지하지 않게 되어 해당 텍셀로 인해 라이트매퍼가 불필요한 작업을 할 필요가 없게 됩니다.

라이트 프로브를 사용함으로써 얻게 되는 부가적인 장점은 언래핑에 많은 시간이 소요되는 정확한 UV가 필요하지 않다는 점입니다. 라이트 프로브를 사용했을 때 외형은 잘 표현되지만 전혀 이동, 회전하거나 변경되지 않는 동적 오브젝트가 있는 경우 여기에 Contribute Global Illumination 플래그를 적용할 수 있습니다. 이를 통해 오브젝트가 베이크 시간을 증가시키지 않고도 주위의 라이트매핑된 오브젝트에 영향을 미칠 수 있습니다. 처리 속도가 증가하면 메모리 사용량을 줄이고 생산성을 향상시킬 수 있습니다.

결론

이제 동적(또는 정적이 아닌) 오브젝트에 라이트 프로브로 조명을 적용할 수 있습니다. 이를 통해 전역 조명 계산에 포함된 오브젝트가 라이트 프로브로부터 간접 조명을 받을지 혹은 라이트맵으로부터 받을지를 지정함으로써 라이트맵의 텍셀 사용량을 줄일 수 있게 됩니다. 따라서 전체적으로 라이트맵의 계산 시간을 크게 줄이고 메모리 사용량을 낮추며 런타임 성능을 향상시킬 수 있습니다.

전역 조명을 최적화하는 더 많은 방법은 유나이트 2018 세션을 참고하시기 바랍니다.

13 코멘트

코멘트 구독

코멘트를 달 수 없습니다.

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

  2. 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 오후

        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. 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 오전

          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. Indeed, vertex baking has been captured internally as something we’d definitely like to have. Absolutely agree.