Search Unity

We’ve been hard at work on the Progressive Lightmapper since we first showed it at GDC in March. Please watch the video below for a quick introduction to what the Progressive Lightmapper has to offer so far:


The Progressive Lightmapper is an unbiased Monte Carlo path tracer – it can bake out lightmaps with global illumination (GI) inside the Unity Editor. For the last 40 years, the point at which realtime raytracing will become possible in a realtime application has been 5 years in the future and it still is. So for now the Progressive Lightmapper will exist as an alternative backend for baked lighting only.

What about Enlighten? Enlighten is here to stay. Enlighten provides realtime GI and this cannot currently be achieved with a path tracer.


The aim of the Progressive Lightmapper is to make the workflow for baking lighting for a scene much better. In the current Unity release changes to the scene require a new bake and the results can only be shown when the bake is done. What Enlighten brought to the table is the ability to change lights in realtime and see the results immediately. However, changes to parameters, materials or geometry still require a rebake during which you get no feedback.

When iterating on – for example – baked shadows or the level of bounced lighting, waiting minutes or even longer between being able to make informed changes can be very frustrating. This effectively limits the quality you can achieve with your baked lighting. With the Progressive Lightmapper you will get almost immediate feedback. A noisy result at first, but rapidly improving directly in the Scene View.


It has the added benefit of being able to prioritize the parts shown in the viewport – once they have finished it will continue baking the rest of the scene outside of the viewport.

In addition, the Progressive Lightmapper is in many cases more robust. It bakes out indirect lighting at full lightmap resolution so it is less prone to producing artifacts there. The setup is simple; provide a UV unwrap or let Unity create one and set the baking resolution. All your knowledge of traditional baking tools apply. Also, we can more easily predict when it will be done, so a reliable ETA on when the bake will finish is shown on the progress bar.

ETA prediction

Finally, when you think the result is good enough you can stop the bake and the lightmaps are created for you from the current state. So if you want to increase samples and allow Unity to add quality to the bake during some downtime, you can crank it up, and stop as soon as you’re ready to continue working.

What does it not do?

It is not a replacement for realtime GI. It only works for baking in the Unity Editor, so you cannot bake from within your game. This rules out baking GI for procedural scenes in-game, or the ability to change the lighting setup for time of day and baking on load. We want to nail the baking workflow in the Editor before we take it further.

Also, it is not necessarily faster than baking with Enlighten. If you setup your scene well for Enlighten it can be very fast, so we cannot guarantee that all scenes bake faster with the Progressive Lightmapper. However, the time between starting a bake and getting some visual feedback will be significantly faster with the Progressive Lightmapper.

Finally, it does not yet support any specific hardware such as a PowerVR Ray Tracing enabled GPU or a regular GPU. Right now it runs only using the CPU cores for baking. Again, for the initial release we will focus on the workflow.

When can I have it?

When it is ready. :) We are currently in a closed alpha phase testing out the feature with selected game developers. Once we are happy with it we will provide an open beta.

Until we’re ready to ship an open beta, we’d love to hear your feedback on what we’ve shown thus far. Sound off in the comments below!


This is a collaboration between Unity and Imagination Technologies, and we would like to thank the following people:

  • Jens Fursund
  • Luke Peterson


56 评论



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

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

  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

    十月 27, 2016 4:00 下午

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

      十月 6, 2016 7:58 上午

      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

      十月 4, 2016 8:55 上午

      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
    After .5 seconds of converging you can start baking lightmaps.

    1. Jesper Mortensen

      十月 3, 2016 11:40 上午

      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

      十月 3, 2016 8:17 上午

      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

      九月 30, 2016 9:38 下午

      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

        九月 30, 2016 9:33 上午

        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. Please say, it’s working properly with terrain trees!

    1. Jesper Mortensen

      九月 29, 2016 11:57 上午

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

      1. Thank you!

  13. Kevin Kwangho Lee

    九月 29, 2016 8:37 上午

    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

      十月 3, 2016 8:58 上午

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

  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

      九月 29, 2016 8:39 上午

      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

    九月 28, 2016 6:10 下午

    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

    九月 28, 2016 5:19 下午

    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: and
      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

        九月 30, 2016 7:36 下午

        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

      九月 28, 2016 4:15 下午

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

      1. 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

          九月 29, 2016 8:49 上午

          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

          九月 29, 2016 9:23 上午

          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: (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

        九月 28, 2016 4:44 下午

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

          九月 29, 2016 9:10 上午

          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

        九月 29, 2016 8:56 上午

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

      九月 29, 2016 8:58 上午

      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.