I don’t know where to start but since the new version of Unity the whole lightmapping is a real pain. In the previous version i could use my own lightmaps and now i’m stuck with the lightmaps generated by Unity. If they would be as good as the lightmaps generated by Unreal engine i would say okay. But Unity doesnt match the quality Unreal engine has. Neither the quality from Vray or the soon to be announced baking from Ottoy. So why would you remove the option to use your own lightmaps.
And then you have the option to generate lightmap uv’s on import. That is nice, if you are to lazy to create it yourself. But if you opt out unity is stil messing with my uv’s.
And then the time it takes to bake!!! I’m probably doing something wrong. But doing things wrong is not hard either. Because of the lack of good documentation. Why on earth would you release something if it’s not documented. Last year i needed to use the loadrawtexturedata. it took me a whole day to figure out how to use it, since it was not documented at all.
it’s a shame. I was really happy with Unity and since the day it’s available on PC i have a license. But for unity 5 we didn’t buy it yet and im looking more and more at other alternatives.
@Kuba answered it in the next post
That definitely shouldn’t happen. Could you please report a bug with any meshes which are affected by this?
Some general tips:
- Make sure precompute resolution isn’t too high if your scene is big. Try something around 0.1 for example
- Disable final gather and AO
- Disable baking for big planes, which aren’t too important or split them into smaller objects
- Use lower res parameters for not important objects
Are you referring to outdated manual shipped offline? Updated docs are available online since launch day
I would second the phrase that Unity 5 light mapping is nightmare
To me it’s been a total disaster to say the least…
-
I have baked light map. All lights in scene are set to “baked”, however when I toggle built-in lighting on and off with an editor button, scene gets darker/brighter. And when I run the game scene looks darker than baked result
If I manually switch off lights via inspector nothing changes, so they are baked, but still affected by something which is out of my control -
Occupying same space 2048x2048. Unity 5.0.1 results look like rubbish in comparison to Unity 4.6. LOD popping is quite bad.
-
I do not see light maps working on iOS at all… Do they even work on iPhone? [as turns out light maps will only work on GLES 3.0 or Metal and will no longer work on GLES 2.0]
-
Lightprobes way too bright [known issue]
You still have the option to provide external lightmaps.
The API is still the same as before (LightmapSettings.lightmaps, Renderer.lightmapIndex, Renderer.lightmapScaleOffset). The only change is that those properties are only serialized in the scene when building a player, so you need to make sure that you set them every time the scene is loaded in the Editor. This was required so that the precompute/bake doesn’t dirty the scene when it’s done. Now all the generated data lives outside of the scene. (I was hoping someone would appreciate that, anyone?)
The second UVs of a mesh (either coming from the model file directly or being generated by Unity’s unwrapper) will currently* be used as is for baked lightmaps. If you see something else, please report a bug with a scene that uses the problematic model and post the case number here.
*) We’re planning to use per instance UVs for baked lightmaps’ UVs, so that we can adjust the padding between the charts based on the resolution of the instance.
The intention typically is for the system to be simple enough that it can be understood without documentation.
Unfortunately baked GI was already not quite simple and adding realtime GI to the mix just made things more complex (even after having multiple simplification passes).
Please make sure that you’ve read all the tooltips available in the Lighting window.
We are assembling all the questions that we get here, on Answers, Twitter and the beta list and we’re making sure that the docs will cover all the problematic areas. It’s work in progress, but parts of it will roll out this month.
When the lighting toggle is ON the rendering uses all the realtime lights, realtime GI and baked GI.
When it’s OFF, the realtime lights are not used for rendering and a light attached to the camera is used instead. However, realtime GI and baked GI is still on and the reflection probes are used as well.
The light attached to the camera is there to allow you to make out the shape of objects in case there is no GI. Having both GI and the light is mostly confusing. We’ll start a thread to figure out what do people still use it this mode for and we’ll fix accordingly.
Can we get a repro?
LOD is currently only supported for baked lightmaps. Please note that lower LOD levels get the indirect lighting from light probes, so make sure you have those around.
That is not accurate. Non-directional lightmaps work on all the platforms. Directional (default) and Directional Specular currently don’t work on GLES2.0, but most likely we’ll make them work.
Hey Kuba,
thank you for your answers, however I still have some things to clarify.
please look at the questions below
When I Toggle lighting ON i the viewport my scene gets darker…much darker. I have no realtime lights in the scene.
Please look at the screenshots (upper one is Editor view with Lights toggled OFF, lower one is game view)
I do not need realtime GI at the moment. I want to bake lightmap and see the same result in game with what I see in the editor.
How do i do that?
Unfortunately there is no repro. I will look closer what’s going on. But it appears to me that UV unwrapping/packing algorithms might have changed in Unity 5
You mean when baking lightmap, LODs will be lit by light probes? (I am not using realtime lights)
That’s something I hear for the first time, so want to be sure I got you right
Thanks for making it clear
And thank you for all the explanations
The “built-in lighting” toggle affects just the scene view and that’s by design.
When you have the “built-in lighting” turned off a directional light pointing in the same direction as your scene view camera is used and all the realtime lights are turned off. Since you don’t have any realtime lights then when “built-in lighting” is turned on you see just the lightmaps. When it’s turned off you see the lightmaps and that light attached to the camera and of course that gives a brighter result than just the lightmaps. The darker result is the correct one, however.
The unwrapping and packing is actually exactly the same between 4.6 and 5.0.
Yes, the indirect lighting will come from light probes. Direct lighting will be calculated for each LOD level separately and accurately.
For some reason while resolution stayed the same 4.65 I’ve got two [2048x2048] light maps instead of one. Probably padding in scene changed during the transfer.
The whole thing starts to make more sense to me, but still transition is a bit painful to say the least
Would be great if there was a video explaining exactly how to work with baked only approach.
As it is the best for mobile devices but not really covered that well
Thanks again for answering all the questions
For some reason transparent materials have some issues being light mapped
Upper red stripe decal seems ok
but lower one lost shadows from pipes
They both use same material and have exactly same setting. Light map static, cast shadows Off, receive shadows On
Also there are quite few specularity artefacts after bake. Image over has some strange shadows from ladder
and you can see some weirdness on the image below
External lightmaps (usually on UV1) are not supported by the standard shader 
Yeah that’s too bad… I tried to modify the Standard shader to read the lightmap from UV1 myself, but it has so many includes I’ve got discouraged. I guess I’ll only do it if I start needing it reaallly bad… 
Almakos, both of your images look fairly strange, could you submit a project with that scene in a bug report?
Cascho01, we already talked about this. This functionality does not belong in the UI of the shader itself. There’s appropriate places for the appropriate properties, see:
The workflow is already there: you have the API to set the data in Unity and you can fetch the lightmaps, lightmap indices and lightmap scale/offset from your external lightmapper. If you have trouble with that, please submit a bug report and we’ll take a look.
Kuba, I already followed the instructions from your link but failed.
Could you tell me what exactly you mean by “fetching lightmaps, indices, and scale/offset from external lightmapper”?
I render my maps with Max+VRay.
this external lightmapping thing should be wayyyyyy more artist friendly. normally artists are the one working on lightmaps (specially when doing it externally) not programmers.
As for the unlit red stripes, issue been due to stretched light map UVs (I believe in Unity 4.6 they were much more properly lit despite UV stretching)
As for the weird specularity thing I will see if I can reproduce it in test environment as too troublesome to share the whole map. it’s quite big
On the other hand it appears to me that spotlights work a bit different if to compare to 4.6
In particular spotlight cookie is way more sharp…any way to make spotlight softer?
What is Spot Cookie in Other section for the light mapping?
Honestly I don’t remember anything like that in Unity 4.6
Sorry for my late response. I was busy with a lot of things. Thanks for you’re answers.
Well i had a specific workflow. And that was baking in a different dcc app. populate the lightmaps array and assigning the models to the appropriate index. Now i have to build that functionality myself. But i’m glad that the editor is extensible.
As for the uv settings i will do a bug report.
thanks again.
When you calculate your lightmaps in an external lightmapper you’ll get:
-
an array of lightmaps (preferably in some HDR file storage format like EXR)
-
for each renderer:
-
lightmap index
-
lightmap scale/offset
and those are the pieces of information that are needed by the rendering pipeline. I can’t imagine manually transferring this data from an external lightmapper. One would most likely write a script that can extract this data from that lightmapper and then plug it into Unity.
This situation can be simplified if we assume that:
- the entire level fits in one lightmap – as then all the renderers can just use index 0;
- the UVs for baked lightmaps (second UV channel) were already atlased in your modelling package (so that if they all use the same lightmap they will not overlap) – as then all the renderers can just use the default scale/offset of (1,1,0,0); this also assumes that each renderer uses a unique mesh.
I know that some of you have workflows that work with those assumptions, but this is not a general case.
This leads us back to workflow automation – on Unity side everything that is needed is exposed. The other side, the external lightmapper, is not known (well, there’s many of them), so a bridge for each external lightmapper needs to be created by the interested parties.
You sure? The spotlight cookie hasn’t changed for at least 4 years (that’s as far as our Mercurial history goes).
It’s exactly the same as you could find in the render settings window in 4.x. It allows you to override the default spotlight cookie.
See “Spot Cookie” in http://docs.unity3d.com/Manual/GlobalIllumination.html.
We do ArchVis-Projects and manually bake only large surfaces like floor, walls, ceilings with 3dsmax+VRay.
For an average project we get around 20 lightmaps (each 2048x2048px) for 20 objects with 20 materials.
Recieving lightmap index+scale/offset is completely new to me, so there´s no automated data transferring - we indeed do it by hand. But I assume that this workflow is pretty common. So - the current implementation of these lightmaps in Unity with the standard shader is a workaround to me and not very convenient at all.
However - maybe we have to change our workflow.
Fortunately we have shaderforge where it´s very simple to build a custom shader that works like expected:
For example I am a bit surprised that the Lightmaps assigned to a standard shader do not reduce specular (imagine a ground shadowed by a house where specular on shadowed area is the same as directly hit by the sun…)
Anyway, thanks very much for the explanation. I still hope that external lightmaps will find an easier way into the standard shader.