Search Unity

Alright everyone, it’s the preview video that you’ve all been waiting for… Lightmapping in Unity 3!

Senior QA Specialist Samantha Kalman and Demo Team Artist Roald Høyer-Hansen have put together a great introduction of how Beast has been seamlessly integrated into Unity. We hope you enjoy the preview video and are looking forward to all the beautiful scenes people will create using Unity 3’s new lightmapping features!

[vimeo clip_id=”13361651″ width=”640″ height=”360″]

53 replies on “Unity 3 Feature Preview – Beast Lightmapping”

apple iphone repairs uk…

[…]Unity Technologies Blog » Blog Archive » Unity 3 Feature Preview – Beast Lightmapping[…]…

Additional note: In my 3D rendering program I could create a lightmap for all static items, throw onto them, in Unity I´d turn “cast shadows” off, turn “receive shadows” on, add a light to the scene and .. voilá .. static baked things with realtime shadows for my character.

This must be possible to do in BEAST?

I´ve got a mental blockage, perhaps you could help me.

Just imagine this scene. I´ve got my hallway (corridor) in a hospital scene. Things like chairs, tables trollies etc. are static, they don´t have to move. Let´s go further and place a couple of little objects i.e. books, water glasses, flowers, small things on the tables.
My character (3rd person view) walks around the scene, casting a realtime shadow.

To increase performance, the static objects shouldn´t cast dynamic shadows, just the baked ones (even if the camera is close up to them).

Now somebody told me that this wasn´t possible. He said that the dual lightmapping switches real lights on when the camera is close and turns lightmapping on when objects are far away.

But it must be possible somehow..Otherwise whem I´m close to this table object EVERY little thing casts a realtime shadow???


[…] they received from Unity3D (Merry Christmas Adobe).   I do wonder how Unity’s physics, Beast Light mapping and shaders will translate, but I’m guessing those are the fruits they intend to dangle in […]

i have more than 10 object in my scene ,for lightmapping i have unwarped 2nd channel uv wher all my scene object will genrate lightmap in a single map , but in unity3d 3 i can’t genrate lightmap detail in a single map how to solve this problem i need my lightmap with a single texture… me plz

[…] August 2010 in ° Programme / Tools / PlugIns In diesem Preview auf die kommende Version der Game-Engine Unity 3.0 gibt Samantha Kalman eine kleine Übersicht zur Beleuchtung von Unity-Szenen mit dem neuen […]

When will Unity 3 be available? We are doing an architectural project in Unity and we really can’t wait for this! :)

Please give us a date!

@Johan: regarding using other renderers to bake lightmaps in Unity:

It’s actually not hard to take an arbitrary lightmap renderer and integrate it with Unity, because everything that’s needed to extract the scene from Unity into the renderer and then get the lightmaps back and make them work in the scene is exposed to editor and runtime scripting. So you have access to scene hierarchy, meshes, materials, textures, etc. Once you have the lightmaps back, you can import them into Unity in HDR, assign to proper objects and they will be automatically picked up by the built-in shaders, as all of them support lightmaps. So I won’t be surprised if a VRAY fan from the Unity community will make a fully automated integration sometime soon. ;)

What I think is more interesting, is how will lightmaps baked in Beast compare in the eyes of Unity users to lightmaps baked in other renderers. Even though VRAY is a very good renderer, it’s primarily targeted at making camera renders for architectural visualizations. Beast was build from ground up to render lightmaps for games, so the Illuminate Labs team had the chance to learn on a bunch of big games some nice techniques that in the end make for better lightmaps. So I’m betting on Beast :D

@Johan – A scene is definitely not limited to a single lightmap as that would be sort of silly ;)

The UVs are packed across multiple textures (in the case of the demo in this video, 60 lightmap textures for the entire scene) of various sizes to get the best use of the texture space.

That’s brilliant – and does sound like it would solve the problem with color-bleeding yes. Thank you both for your answers. And even though you can bake using a third-party renderer using Open-CL, I’m betting the benefits from the alignment of lightsources, auto-calculated blending-levels, etc (not to mention the fact that using beast, you won’t have to assign 100+ lightmap-textures to materials by hand in your secene), will make the unity+beast pipeline faster than say 3dsmax+vrayRT-GPU – even if the GPU-bake is potentially 40x faster (3x nVidia480GTX vs 6-Core 3.33GHz in vray-RT 2 beta). The workflow-pipeline almost makes it look too easy to create good looking content, so great work indeed :P

I’m still however concerned with the fact that it seems like the demo uses a single large atlas to store all scene UVs packed = all ‘object-lightmaps’ combined as one texture. Even if you max it out at 4096×4096, there’s potentially a limit for how large a scene you can make before you start noticing a degrade in quality in the bake. Or is this just an option? is there/will there be support for ‘per object’-stored lightmaps as opposed to only a single giant atlas of lightmap-data?

Keep up the good work!

Beast works fully on the CPU (so no CUDA/OpenCL) and it distributes the work in a smart way among as many cores as it makes sense for a given scene/bake configuration. So most scenes will render 8 times faster on an 8-core machine than on a 1-core machine.

@Ashkan: the island demo could be easily baked in under 20 minutes, because – even with all the trees – the scene is not that complex and doesn’t require multi-bounce GI (although I would definitely use a sky light and a single bounce GI). More complex scenes that require longer GI rendering like Dark Unity or the new Boot Camp demo can render for an hour up to a couple of hours on the highest quality settings (and on an 8-core machine).

the lighting is great. the demo is not as good as we thought. does the demo use the unity’s locomotion system when the soldier climb up steps and …
does it take several hours to bake great lightmaps for big scenes like unity 2.0’s island demo

@Johan: we bake two lightmaps; one with full illumination, and another with indirect illumination only (this one can also include any lights that are “only for baking”, and won’t be used at runtime). Then up close, we use realtime lighting + the indirect lightmap. Far away, we use the full lightmap. And cross blend between those over some distance. So up close all the color bleeding and GI works because it’s in the indirect lightmap. And you get normal maps + specular for the direct illumination.

I’m not sure if Beast right now utilizes CUDA/OpenCL; I guess it does not. It does utilize as many CPU cores as you have though.

How does or will the dynamic blending between lightmapped and realtime lighting handle nuances and shifts in color and contrast? My thinking is: wouldn’t it be pretty obvious if you blend between baked and realtime-lighting in a scene with heavy color-bleeding and/or ambient occlusions; or does realtime lighting work in conjunction with a diffuse-color projection-map (i.e a secondary lightmap with colors and/or ambient-occlusions in it)?

I mean, simply blending between lightmapped and realtime-lighting wouldn’t be as noticeable in a “realistic” [read: beige/brown desert-warzone type of scene] scene like the demo here, while applying this technique to a scene with a lot of intense colors and colorbleeding, I suspect one might see a clear difference between foreground (realtime) and distance (baked) – or am I mistaken here?

Oh, and one more question: is the baking-process utilizing the GPU (Cuda or Open-CL)?

Regardless, way to go both Unity and Illuminate Labs! Might not have to use vray for my lightbaking any more ;) Keep up the good work!

@Dave: This is a full-featured version of Beast that Unity users are getting!

Having said that, we’ll be working on even more workflow improvement features with Illuminate Labs, and will roll those out in 3.x.

@ValentinW :

Yep! It does :) Didnt have time to show all of the features in this vid, but hopefully Ill be able to make some small tutorials soon, showcasing different features more in detail.

Looks very pretty but I just want to make sure:
Does Beast in Unity3d 3 work with semi-/transparent materials too?
Lets say stained glass for cathedral windows? :-)

I’m pretty sure UDK doesn’t have Beast (confusing, I know, since the full license of Unreal 3 appears to); they use a custom Epic-made lightmapper called Lightmass.

@Dave Chan

As I havent tried PureLight yet, I cant really say anything about it, but after having a look on your website I must say Im impressed :) It looks really powerful and seems to have a lot of features.
The main thing I like with the Beast implementation in Unity though is that it
s so extremely easy to use. You just import your models/scenes and do everything inside of Unity. It just works! No need to export your models to a different format/program and re-export from that one into Unity.
You can also tweak the texel resolution of your objects separately, so you have a lot of control over the final result, and youll have access to some more advanced functions by using an .xml file.

Im 137% sure there will be a lot of beast features and other useful workflow improvements in Unity 3.x, but the current implementation has changed my workflow drastically. I used to do all my baking inside of 3dsmax, but no more. I can do all that + more in Unity 3.0 now :)

I realize I am biased here, but I’ll offer my 2 cents. It looks like you can get some good quality results with Beast and I really like the texel resolution overlay. I still have to say though that I prefer the realtime preview and workflow that we offer compared to the setting the quality low and rendering a preview that way. I am also curious to see if you can set different lightmap resolutions on different objects.

As for UDK, I don’t think there is Beast support explicitly. The full featured version of Beast is not cheap and they don’t have an indie pricing model as far as I know, unless you consider $10,000 to be cheap. So, getting Beast with Unity is pretty cool. I would assume that it’s not the same full featured version you get with a commercial license, but even then it’s a good deal bundled with Unity.

@Robbson: The scene has 4000 draw calls without sPVS, and 500 draw calls with PVS. Thats a nice improvement but the bigger the scene gets, the bigger the improvement is.

sPVS is not a dynamic occlusion culling solution, it’s a precomputed visibility solution. This makes it extremely fast at runtime. For static objects, the runtime overhead of objects that are not visible is practically zero.
It also means that it works great on the iPhone. The great thing about it, is that you dont need to spend time setting up zones and portals in your level. Instead you just place a volume where the camera is and sPVS figures out the visibility completely automatically for you.

Dynamic objects like characters can be occluded by the visibility system too. Anyway, we will do a sPVS intro later.

Yes, this is how Umbra’s sPVS works in theory and successfully in other engines like the UDK. But even there you still use zones and portals defined by the game designer.In case of Unity it would be great to have something like a before/after comparison of one scene. Compile it in Unity 2.x and Unity 3.0, now let us see the benefit (put deferred lighting aside).

Umbra’s sPVS definately makes a huge impact on performance. There is actually several key technologies in 3.0 together that provide radically better performance on big scenes.

1. sPVS lets you create very big scenes rendering only what’s visible which means that your performance is dependent only on the amount of objects that are visible, instead of what is in the scene.
2. Static Batching allows you to use lots of small objects without increasing the number of draw calls. This is important for occlusion culling, since smaller bounding volumes and smaller objects means less vertex count.
3. Deferred lighting makes using a lot of realtime lights much faster

When you use those techniques together Unity 3.0 has a massive performance boost.

On iPhone/iPad/Android lightmapping will work slightly differently as there are no dynamic shadows on those devices.

Well, the beast thing looks incredible and adds a lot of atmosphere to a scene. But I’m a little bit disappointed from the sample game in the end which doesn’t look so much AAA like previous screenshots suggested. And there are so many slow downs in this demo so I wonder if the new occlusion culling can really speed up larger scenes. Hopefully there will be a blog entry related to this feature in the future. Those speed issues held me off from using Unity in the past (remembering the ultra slow Avert Fate demo and some of my own experiences).

You can also mix dynamic lights with static lights. For example, in the demo explosions have point lights to light up the environment. Static baked lighting with GI looks better than direct lighting even with soft shadows.

In practice in most games, most lights and most objects don’t move. So baking them makes the game run faster & look better. All other lights you simply mark as realtime lights and they will be rendered on top of the static lighting.

Especially in large scenes with long distances, using shadows into the far away distance is unrealistic performance wise. Shadow map sizes would have to very big. Most games simply fade out shadows completely after a short distance. In Unity 3.0 you can fade over to a lightmap, which means the transition between lightmap and fully shadowed / realtime lit is much more subtle.

@Lolli – Deferred Rendering does not reduce the cost of dynamic lights that cast shadows since each one still needs a unique depth map for the shadows.

The benefit of the dynamic lighting in the foreground is that dynamic objects can receive shadows as well as cast them (for instance the soldier entering the building or casting a shadow on the ground). Also, we have a dual lightmap system where indirect lighting (AO and GI) is baked into the near lightmap and indirect/direct lighting is baked into the far one. Therefore you can have realtime shadows mixed with indirect lighting in the foreground which is quite nice.

The blending of PSSM & Baking is an amazing idea. However, what is exactly the interest of having both realtime shadow maps AND baking ?
Especially with the announced “Deferred Shading” that is supposed to handle a large amount of dynamic light ?

“Baking” means intrinsically *static* lighting : you can’t move lightsources anymore, you can’t change the lighting atmosphere (unless you prepare another static baking).

It seems to me more like a solution where you sum up the drawbacks of both solutions : the deferred shading can be more GPU demanding than the forward rendering, and the baking is an extra pass, extra work, and eats more VRam.

Anyway, I guess the baking can be used for ambiant occlusion only, where the direction & positions of the lights can be dynamic :)

I love it. Will the last scene be a tutorial? That would be sweet. Like an upgrade to the FPS Tutorial you already have :)

@Koblavi: Hey, we’re working really hard here to allow you guys to cut down on your game development time so that you can keep your girlfriends/boyfriends! :)

@Lars: Yes. As it is now, through LightmapEditorSettings.maxAtlasWidth|Height

Yeah, but UDK is free. Big bonus there.

“too much processing power” is a bold generalisation in a constantly-evolving industry. Deferred rendering is great, but certainly does not solve more problems than it creates. It really depends on what you want to do.

Finally, I don’t know UDK’s custom shader/material/pp-effect system, but in my experience deferred shading is not hard to write at all.

I love the way Beast is performed in the background here, and the way it utilises both static and dynamic lighting. Awesome.


The free version of Unity 3 will not have dynamic shadows, but it will have a version of the lightmapper that will of course be able to bake shadows for your scenes.

Wow, this looks great!
Any chance the free version of Unity will get dynamic shadows? We don’t ask for much. Don’t need soft shadows or anything, just… something better than blob please? :D

You guys make us luv a commercial product like it’s open source!! It’s awesome work.Unity 3 is about the ‘Sexiest’ game engine there is. Can potentially make a Guy ditch his girl :) … now just stop making us wait and roll it out already!! And I still wonder, with all of these features, will there ever be a unity 4? Hope I’ll have enough money by fall to get the Pro.

Yes! I’ve been waiting for this! If Unity 3 had been released before the summer the game me and some class mates worked on would have been so much cooler!

Oh, and the legs went total wacko a couple of times in that demo =P

Thank you guys for burning the midnight oil, you’re work is unbelievably appreciated. I’m giddy with possibility. Yeah, I said “giddy”.

The dual lightmapping approach combined with deferred rendering is very unique. It means that you can combine bounce lights with realtime shadows / specular highlights / shader fx up close and quickly fade to a fully lightmapped solution with far away objects for performance.

One of the great advantages of this approach is that dynamic objects can receive accurate shadows and blend into a fully lightmapped environement very well. Usually AAA games either do
1. Everything uses realtime shadows and no baked global illumination sometimes combined with AO tricks
2. Global illumination and characters useing fake projector shadows and are either in shadow / out of shadow completely

With Unity 3.0 and dual lightmapping you can have both, realtime shadows on close up dynamic objects, baked global illumiation on static objects with specular highlights and crisp realtime shadows up close and performance.
You can see the effect starting at 7:20 in the video.

Unity 3 also comes with multiple lighting models to pick from. You can go with deferred rendering, forward rendering with spherical harmonics, vertex lit on mobile platforms. And using our new surface shader language it’s easy to write shaders that work with all light models and to write your own lighting functions too!

cmon! Unity3D and UDK have really different targets! hoe can we compare a multiplatform smarty deployer with a Windows only beast?


ps: anyway Unity3D is really rocking!


Eclipse said:
“UDK already supports Beast and has also top notch dynamic lighting.”

The Beast lightmapping solution in UDK is a bit complicated to setup.
You have to click here and there,too much work.

And the dynamic lighting in UDK takes too many processing power.

The UDK also doesn’t have deferred rendering,only forward rendering.
This slows things down.

Epic games has to do something super cool very fast,to keep their UDK game engine alive.
Because I can see now that Unity 3D is going to become the number one freaking game engine in the world.

Totally awesome man. The blending works quite well. The sunrays coming through the windows at the end… is that an image effect or particles?

Comments are closed.