Search Unity

3 月の GDC で初めて皆さんにお見せしてから、プログレッシブライトマッパーの開発に尽力してきました。以下のビデオをぜひ、ご覧ください。現在クローズドアルファ版のプログレッシブライトマッパーを簡単にご紹介しています:

プログレッシブライトマッパーとは?

プログレッシブライトマッパーとは、モンテカルロ法を利用したアンバイアスなパストレーサーで、Unityエディター内のグローバルイルミネーション(GI)を使ってライトマップをベイクします。(エディター内でどのように見えるかデモがご覧いただけますので、この文章を読み進めていただく前に、ぜひ動画をご覧ください)

過去 40年間、リアルタイムのアプリケーションでリアルタイムのレイトレースが可能になるのは5年先だと言われ続けており、今でもそう言われています。今のところプログレッシブライトマッパーは、ベイクしたライトだけに使用できる代替の処理手法となります。

それでは、Enlightenはどうなるのかというと、それはそのまま残ります。EnlightenはリアルタイムGIを提供できます。これは現時点でパストレーサーではできません。

なぜプログレッシブライトマッパーなのか?

プログレッシブライトマッパーは、シーンでライトをベイクするワークフローを改善することを目的としています。現在のUnityリリースでは、シーンに変更があると新しいベイクが必要で、その結果はベイクが完了したときにしか表示されません。Enlightenによってリアルタイムでライトの変更ができるようになり、即座にその結果を見られることができるようになりましたが、パラメーター、マテリアル、ジオメトリは依然、再ベイクする必要があり、その間は結果を見ることができません。

開発中のイテレーションが進むと、例えば変更を加え、それを確認してさらに変更を加えていくような作業を繰り返し行っていく際に、影や反射した光をベイクして、変更を加え、それから数分以上待つ、となると、待ち時間が長いほどフラストレーションがたまる作業になります。そのため、繰り返しのイテレーション作業によって品質を上げられるはずなのに、ベイクしたライティングで作業を行うことでそれが思ったように品質を上げられない結果となってしまいます。

ここでプログレッシブライトマッパーを使うと、ほとんどその場でフィードバックを得ることができます。ノイズのある結果が最初に現れますが、シーンビューで直接、クイックに作業できることで品質が上がっていきます。

interactive

また、プログレッシブライトマッパーは、ビューポートに表示される部分が優先されてベイクされるという利点があります。その部分のベイクが終わると、ビューポート以外のシーンのベイクを続けて行います。

さらに、プログレッシブライトマッパーはより安定して動かすことができます。というのも、プログレッシブライトマッパーは反射光などの間接的なライティングをフルライトマップ解像度にベイクするため、そこでアーティファクトは生成されにくくなります。設定も簡単で、UVをアンラップで用意するか、Unityでそれを作成し、「Baked Resolution」を設定することですべて、今までと同じようにベイクのツールを使用できます。また、ベイクの予定終了時間(EST)がプログレスバーに表示され、いつ処理が終了するのかを簡単に予測することができるようになります。

ETA prediction

最後に、結果が良ければベイクを止めることができ、現在の状態からライトマップを作成できます。ですから、休憩中に走らせておきサンプル数を増やしてベイクの品質を上げておくこともできます。そして作業を再開する準備ができたら止める、などということもできるのです。

プログレッシブライトマッパーができないこと

プログレッシブライトマッパーはリアルタイムのGIに取って代わるものではなく、Unityエディターでのベイクにだけ有効で、ゲーム内からベイクすることはできません。そのため、ゲームのプロシージャルなシーンでGIをベイクすることや、ライティング設定を時刻に基づいて変更し、読み込み時にベイクすることはできません。私たちはリアルタイムのGIを目指して先へ進む前に、Unityエディターのベイクのワークフローを確立させたいと考えています。

また、プログレッシブライトマッパーは、Enlightenでベイクするより必ず早くなるというわけではありません。シーンの設定を上手くすれば、Enlightenはとても早くできるので、プログレッシブライトマッパーを使えばすべてのシーンがより早くベイクできるとは限りません。ただし、ベイクをし始めてから何らかの視覚的なフィードバックを得るまでの時間は、プログレッシブライトマッパーの方が飛躍的に早いと言えます。

最後に、プログレッシブライトマッパーは、PowerVR Ray Tracingが有効なGPUや一般的なGPUのようなハードウェアをまだサポートしていません。現在は、ベイクをするためにCPUコアだけを使用しています。繰り返しの強調になりますが、最初のリリースではワークフローの改善に注力します。

いつ、プログレッシブライトマッパーを使えるようになりますか?

準備でき次第リリースしたいと思っています。現在、クローズドなアルファ版で、限られたゲーム開発者によって性能をテストしているところです。納得いく結果が得られたら、オープンベータ版を配布します。
オープンベータ版の準備が整うまで、皆様のフィードバックを心からお待ちしています。ページ下のコメント欄にご意見ご感想をお寄せください。

謝辞

プログレッシブライトマッパーはUnityとImagination Technologiesの協力によって開発されました。ご協力いただいた以下の方々に感謝の意を表します。

  • Jens Fursund
  • Luke Peterson

 

imagination_logo_primary_rgb

56 コメント

コメントの配信登録

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

  1. This looks like a great upgrade. Will this new system support baking indirect lighting + AO only?

    1. Jesper Mortensen

      11月 21, 2016 9:01 am

      Both lightmappers will work seamlessly with the new mixed lighting system. This will offer a mode using baked indirect + AO in conjunction with realtime lights and shadows or realtime lights with baked shadows. See more details about the new mixed lighting system here: https://goo.gl/rQhBsH

  2. Wow, this will be a game changer. Please release a BETA version! I’ve been waiting for this for over a year!

  3. Someone who needs Unity's answer ASAP

    10月 27, 2016 4:00 pm

    Hello Unity, This is a long question but please read and answer me.

    I am making a huge map which includes 610 terrains and tons of buildings, what i do is that I use World Streamer asset to stream these objects from HDD when needed and when it is not needed, it destroys the objects and the terrains so everything is fine But the question is about the light mapping process. As it turns out, World Streamer requires a secondary scene (which is named “Working Scene”) with all the objects and all the terrains be there, So that it makes the main scene from the secondary scene. So all the objects and all the terrains should be present in the work scene, which means it is impossible to bake light maps for each of the objects in the scene using Enlighten, My question is, Can this new lightmap baking technique bake lightmaps of that huge scene or not? if no, what do you recommend me to do for it.

    1. Jesper Mortensen

      11月 21, 2016 9:00 am

      The new lightmapper designed such that any object can be baked semi-independently. It needs only to have geometry that can affect it, their albedo, emission and transparency texture data in memory in order to bake said object. So provided that the memory can accommodate this data, it should work out-of-the-box; lightmapping the objects incrementally.

  4. Looks excellent. Highly wanted feature.

  5. what will happen if i hit play during progressive baking?
    will it pause until i exit play mode then continue baking? or will start all over from start?

    1. Jesper Mortensen

      10月 6, 2016 7:58 am

      It will stop the baking and use the results as is. Then when exiting playmode it will pick back up where it left off.

  6. is this baking light solution editor only?

    1. nevermind that was said clearly lolz

  7. Have you considered using the Embree CPU ray tracing kernels for speeding up the ray tracing part?

    1. Jesper Mortensen

      10月 4, 2016 8:55 am

      We are using Embree under the hood.

      1. Thanks, that interesting. Embree has a ray stream interface which should provide an additional speed boost? Are you using this interface or pure single ray tracing?

  8. Why do you chose to map the solution to the geometry in iteration 1? That’s your bottleneck and the reason why it’s so sluggish.
    Instead, use screen space stochastic sampling like so https://twitter.com/EthanShulman/status/750185906724802560
    After .5 seconds of converging you can start baking lightmaps.

    1. Jesper Mortensen

      10月 3, 2016 11:40 am

      We are going to move all post-processing such as compositing, filtering, dilation over to the GPU. This should make it faster. We will consider updating partial lightmaps. But since we are not in screenspace the problem is less straightforward. We generally have to update many more texels than there are screenspace texels, and the lightmap texels you see on-screen live in many different atlases.

  9. Hello. Will this new lightmapper be able to bake directional lightmaps that interact with normal maps? Like Enlighten can, and Beast used to.

    1. Jesper Mortensen

      10月 3, 2016 8:17 am

      Yes, it will support both non-directional and directional lightmaps.

      1. That’s good news! Thanks.

  10. “Right now it runs only using the CPU cores for baking”???? that´s bad

    1. Jesper Mortensen

      9月 30, 2016 9:38 pm

      After we have feature parity we will definitely look into using hardware to speed things up. What we have now, despite the limitation of running on CPUs, is an awesome workflow.

  11. Want to see:

    1. There should be NO BLACK SPACE on a lightmap. Use nearest neighbour colors and pad around the edges of islands, and fill black space in a similar way (as Beast did), so even low-res lightmaps will look good.
    2. Alternative to “scale on lightmap”. Let us just specify a resolution per object, so we can force a single object to use a 512 map. Atlas them all later.

    1. Also, this padding should be added to Enlighten too. I know you don’t make games, but it near impossible to use Enlighten for a serious game because of this.

      1. Jesper Mortensen

        9月 30, 2016 9:33 am

        Yes, 1 we will definitely fix and we will prioritize it higher. For 2 we will have to look into if that can be introduced in a sensible way.
        With the progressive lightmapper it is quite easy to scale the lightmaps interactively. The lightmap visualization in the Lighting Panel->Object Tab is interactively updated now as you drag the Scale in Lightmap slider so you can quite easily get to the right resolution. You do not have to wait for a bake to see the resolution as it progressively updates while adjusting the parameter.

  12. Andrei Surin

    9月 29, 2016 10:24 am

    Please say, it’s working properly with terrain trees!

    1. Jesper Mortensen

      9月 29, 2016 11:57 am

      Well this we are fixing for both baking backends right now.

      1. ANDREI SURIN

        9月 29, 2016 2:08 pm

        Thank you!

  13. Kevin Kwangho Lee

    9月 29, 2016 8:37 am

    It looks cool! Is progress lightmapper totally new lightmap engine for baked lightmap? I’m seriously struggling with enlighten lightmap engine during developing mobile game. enlighten really sucks for baked lightmap work. It has too many problem like slow baking time and dilation problem that cause texture leak with uv seam.

    1. Jesper Mortensen

      10月 3, 2016 8:58 am

      We will provide some better documentation and tutorials on optimizing Enlighten for both realtime and baking going forward. The dilation issue is on the roadmap and we will handle it shortly.

  14. Great addition, not all scenes require real-time GI and quick iteration is key to achieving pleasing results.

  15. This looks cool. Thanks for your effort to improve this workflow.

    You mention that Enlighten can be fast if set up properly. Can you point to any documentation or blog posts that describe how to properly set up an Enlighten bake, either for realtime or baked GI. Thanks.

    1. Will Goldstone

      9月 28, 2016 7:58 pm

      Hi Ben we’re actually working on this exact tutorial, shows how to get an environment setup properly, taking it’s bake time from around 7 hours to around 2 minutes. Looking forward to sharing this soon, we’re working on it now, and will get it live as soon as we can.

    2. Hey Ben, we published a blog post focusing on that when we released the Courtyard demo: https://blogs.unity3d.com/2015/11/05/awesome-realtime-gi-on-desktops-and-consoles/

  16. This looks really useful!

    I hope the Auto bake option is not going to cause stuttering in the editor, like it’s doing with the current light-mapper. “micro-stutters” that cause the editor to freeze for a moment, due to auto-bake, makes working in the scene during this time really unsatisfying.

    Thanks for all the recent update videos/posts as well, I really appreciate that.

    1. Jesper Mortensen

      9月 29, 2016 8:39 am

      Yes, we always do our best to avoid this issue. The problem is balancing allocating resources to smoothly running the editor and baking lightmaps, which is a computationally expensive operation (and memory heavy). Finding that fine line on all possible hardware configurations is hard. The obvious solution is of course running the baking on a server and we are looking into this.

      1. Another solution is to transfer that responsibility to us. Give us advanced settings on max #threads or process priority etc… and you can be sure that within a week the forum will be beaming with perfect blends.
        THEN and only IF there is still a need from the community, you can perfect your automagic.
        This way you move resources to what matters to the community: performance.

  17. Louis-Nicolas Dozois

    9月 28, 2016 6:10 pm

    Looking forward to this feature as I’m sure I’ll get plenty of use out of it.
    I have a few questions of my own…
    -Will we, one day, be able to bake to vertices? This is both useful for low-end hardware, for obvious reasons, but for high end hardware too, where vertex counts sometimes rival texel counts.
    -Since you are, basically, writing this lightmapper yourselves, any way you could include better solutions for dealing with seams? Like, say, inter-UV island blurring or proper colour extending beyond UV borders?

    1. Hey Louis-Nicolas,

      “Be able to bake to vertices” – it is on our radar, but it comes with it’s own set of problems and limitations, so just adding it is not an easy call. We are in a position to easily prototype it now though, but no promises. :)

      “Inter-UV island blurring” – on the roadmap. It will happen when we’re closer to feature parity with Enlighten-based baking.

      “Proper colour extending beyond UV borders” – actually, this just requires a small tweak in how we composite lightmaps. Filling the background is done during the lightmap import stage and the background texels just need to be marked as such in the source EXR file. I’ll poke back when this is in the build. :)

  18. Daniel Weinbaum

    9月 28, 2016 5:19 pm

    Looks pretty rad! Three questions:

    1. Can I bake only ambient and leave direct light to a dynamic directional light.
    2. Will it work with multi scene?
    3. Will I be able to multiply the lightmap against a color in the shader?

    1. Hey Daniel,

      “1. Can I bake only ambient and leave direct light to a dynamic directional light.” – yes, but this is not specific to the new lightmapper, but rather to the mixed mode lighting rewrite. Please see:
      https://forum.unity3d.com/threads/mixed-mode-fixes-and-lighting-window-preview-1-try-it.424991/ and https://forum.unity3d.com/threads/mixed-mode-fixes-and-lighting-window-preview-2-mix-harder.430308/
      This will be supported in the progressive lightmapper soon.

      “2. Will it work with multi scene?” – yes. No changes here compared to how it works with Enlighten. But a few fixes in that area are coming in separately.

      “3. Will I be able to multiply the lightmap against a color in the shader?” – not related to the progressive lightmapper really. You can do that by e.g. modifying the Standard shader.

      1. Daniel Weinbaum

        9月 30, 2016 7:36 pm

        Thanks very much for the answers!

  19. Seems great, no doubt!

    One question – will there be a possibility to select to which UV channel to bake?
    It would be useful even for the case that one wants to make baked textures inside the “source” 3D modeling software, which usually provides better control&flexibility of the result than Unity built-in system…

    And in general – would the Standard Shader finally allow to set the UV channel, tiling and offset *individually* per each texture (it means per occlusion map, normal, emission…) as it is common in 3D modeling sw (and was often in pre-Unity 5 shaders…)?

    But anyway, thanks for your invention and continuous effort!

    1. Hey Ivan,
      “Will there be a possibility to select to which UV channel to bake?” – currently there is a clash with the detail maps in the Standard shader, so we will allow for some control to resolve that.

      1. Hello Kuba, thanks for the explanation!

  20. This is a great addition. But please add GPU support to the light-mapper!

    1. Jesper Mortensen

      9月 28, 2016 4:15 pm

      Yeah, we will look at that once we nail the workflow completely.

      1. Alan Mattano

        9月 28, 2016 4:51 pm

        Or multiple CPU since looks like are there with not much use. Also can be nice a smooth progress. Instead of updating ones a second, that update 15 frames per second with blur low quality first that progressively is more define, but with correct color, tone, luminosity since first-shot. Can be rendering random pixels and blurred. And note explanation, of maximum level size. As for example, I think this can’t be used in a 100.000u x 100.000u scene at the moment.

        1. Jesper Mortensen

          9月 29, 2016 8:49 am

          The reason we only update as infrequently as we do is not down to how we bake the texels. We do roughly what you describe. It’s mostly down to the overhead of compositing, filtering and presenting the lightmaps. And when you make bigger changes to the scene we have to update some backend data structures. Moving some of these steps to the GPU should make things more smooth.
          However, the tone and overall look of the lighting is correct even early on while it is still noisy. We have considered filtering more early on and lessening the filtering as the lightmaps converge and we will experiment more with this. Currently, you can do that manually by adjusting the filtering options, which also react interactively.

        2. Jesper Mortensen

          9月 29, 2016 9:23 am

          Our solution scales well to large scenes. Path tracing has the nice characteristic that it scales linearly in the number of texels you feed it and each texel scales sub-linearly in the scene complexity. So you get something like O(numTexels*log2(numTriangles)). This looks something like the purple line in this diagram: https://goo.gl/30MQuk (making the crude assumption that texel and triangle count increases at the same rate).
          So with batch baking we could still bake such a scene while focussing and progressively updating a few lightmaps in the area where you are iterating currently. The beauty is of course that you can get the scene lighting right first and then do the longer bake of the whole thing when you are confident that it looks like you want it to.

    2. Yes, please. Add support for CUDA rendering. I have a last gen GPU and still have to wait hours for bakes

      1. Matthew Etheridge-Letto

        9月 28, 2016 4:44 pm

        Great start, But some of us badly need GPU or network rendering, I have a lightmap I have no generated yet due to the fact after 17 hrs it was not even half done. :( Keep up the great work!

        1. Alan Mattano

          9月 28, 2016 5:20 pm

          Yes, Mortensen! a Network sharing GPU and CPU can help us to bake faster when we need power. in this way I can share CPU cores when I’m not using it. As for example a slider with how many CPU to share, a button on off to connect to the sharing network and other slider for how many CPU are use in my pc for making the rendering. SETI is an example. A counter of how much power we share. In this way the counter can go down when we need to bake.

        2. Alan Mattano

          9月 28, 2016 5:28 pm

          Also thinking better, when is summer, since there is 35° at night and 45° long bad hot day and I do not want to use my CPU for 20 hs in my room. So asking the other hemisphere that in that case it will be in winter can help all us in preserving CPU and temperature distribution. In winter I need to hot my room, I can turn off the electric stove and use a little bit of CPU sharing power to maintain room temperature. Is not less expensive but reduce impacts.

        3. Jesper Mortensen

          9月 29, 2016 9:10 am

          Would be interesting testing how the progressive lightmapper deals with your scene. The nice thing about path tracing is that it relies on ray tracing, which scales really well to larger scenes.
          LAN (Network) baking is on the roadmap with pretty high priority.

      2. Jesper Mortensen

        9月 29, 2016 8:56 am

        We are looking into supporting various HW solutions to speeding up baking. But first we want to make it as fast as possible on the CPU – and make the workflow really shine.

  21. Jon collins

    9月 28, 2016 4:04 pm

    Just this week we were discussing in the office about baking and the uncertainty of how long it would take, we’re working on some intricate scenes and we’re never quite sure how far along the bake is till its done. This will be an awesome tool for dev iterations, and getting a feel when addressing certain aspects of the scene we’re working on.
    Looking forward to seeing it.

    1. Jesper Mortensen

      9月 29, 2016 8:58 am

      I was a bit surprised myself of how much a reliable ETA means. It also helps identifying problems early on when you’ve cranked up some setting too high.