Search Unity

開発中のプログレッシブライトマッパーのご紹介

, 9月 28, 2016

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 replies on “開発中のプログレッシブライトマッパーのご紹介”

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

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

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.

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?

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

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

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.

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.

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.

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

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.

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.

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.

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?

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. :)

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?

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.

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!

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.

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

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!

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.

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.

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.

Comments are closed.