Lightmapping nightmare

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

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

2) Occupying same space 2048x2048. Unity 5.0.1 results look like rubbish in comparison to Unity 4.6. LOD popping is quite bad.

3) 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]

4) 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:
http://forum.unity3d.com/threads/st...htmap-from-3dsmax-on-uv2.278166/#post-1923095

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.

 

Ok, please have a look at this screenshot:

Those are point lights, not a spot. But it looks very wrong to me
it's like there is close to no attenuation (I am talking about selected point lights)


Another thing,...why I cannot see my baked light map after building to device?
It's very strange. It's just gone and all I see is transparent checkerboard. (I am talking about visualising light map in viewport besides 'shaded' mode)



As for the LODs.
@Kuba said that they pick up secondary lighting from light probes
But what exactly is secondary lighting? Final Gather?

As you can see, on this screenshot I have fence section at LOD1 much darker than LOD0
And seems that is happening due to a specularity/directional approach. As light map itself seem to work OK on both

Any idea for a fix?

Thanks

 

Hey Kuba,
Thanks for clarifying that and being so active in these forums in general
For our project, we desperately need to provide custom lightmaps for our mobile-builds because we employ our own encoding on the HDR data (the built-in "double-LDR" introduces too many artifacs when used with compressed ightmaps..).
In our pipeline we build all scene-data as AssetBundles. The actual player is built in another project that doesn't know anything about these lightmaps. If I understood you correctly, the current API doesn't support this workflow since lightmap-changes are not serialized when building the AssetBundles (this also corresponds to my experiments....). Do you have a solution for that? Is there anything planned in the future to support this workflow? Currently, the only "workaround" would be to provide ALL custom lightmaps of ALL scenes in the Resources-folder of the player-project and exchange them during runtime. However, this is no real option for us as it would drastically increase memory-needs of our Application...

 

One more thing.
Final gather takes into account objects which are set to not cast shadows:


As you can see on the screenshot above.
That is a decal with a Standard shader with rendering mode set to Fade
If I bake light map without "Final Gather" it doesn't have shadow. But final gather adds this fake ambient occlusion.
Ambient Occlusion is set to 0 btw

In my case I cannot use final gather, as all decals will have those black shadows

 

Regarding LODs being darker.
By looking on the directionality maps some objects are simply missing from it:

some of them are missing, and some are still present
all objects are prefabs and there is no obvious reason for them not to be in directional part of the light map

 

Yes. that is the way i did lightmapping in Unity. It worked for me. But then i have never had more then 100 baked meshes, and with some grouping and scripting it was a peace of cake.

 

nope, unfortunately that didn't help

i am not using realtime GI btw
i only need baked light map

 

*Bump*
Any info on this one? Our build-pipeline heavily depends on it...

 

Still lost on how to use my externally created lightmaps even after reading all of this. Most people in the archviz field are artists and not programmers. It may seam ridiculous but some of us are really struggling with this in unity 5. Hopefully we can sort this out.

 

I attach a little PBR-compatible shader that may help in some situations (Thanks to Shaderforge which I highly recommend for customizing/extending the shader):

- Tint + Opacity (RGBA)
- Diffusemap
- Specular
- Glossiness
- Optional Specularmap with Glossiness in Alphachannel (overrides Spec+Gloss properties)
- Normalmap
- Lightmap UV2 (also reduces specular)

 

Legend. Thanks Cascho01.

 

I'm guessing that you're used to working in gamma space lighting (aka this-math-makes-no-sense lighting) vs linear and here you're using linear.
Please try a point light over a plane in both modes. In gamma space it's quite wrong and it falls off waaaay to quickly. In linear space it's correct.

That's certainly not by design. Could you submit a bug report with steps on how to reproduce it and (possibly) a repro?

Secondary lighting is bounced lighting, light from emissive materials and from the environment (skybox/gradient/color).
My point with the lower LODs was that the secondary lighting for them is not computed in lightmap space, but it is computed for the light probes that exists in the scene first and then applied to this geometry.

Anyway, the result that you're getting is not expected, please submit a bug report on that. Thanks!

 

If that's the case, then you can ignore the scale/offset as you already have your UVs atlased.
Anyway, we'll probably add an example script to the docs that can aid your workflow.

You mean in the built-in Standard shader and with the built-in lightmapping?
If so, then the contribution from the light that was baked will be coming from the lightmap and:

• in Non Directional and Directional modes you'll get no specular,
• in Directional Specular mode you'll get specular that behaves properly in shadowed areas -- you get it for indirect lighting only.

Specular also comes from reflections. Each scene has a default reflection cubemap that contains only the skybox. If you don't have a reflection probe covering an area then that default reflection is used.
When Skybox/Procedural is used then we also make sure not to render the sun disc into the cubemap, so that you don't get incorrect specular reflections in the shadows and double specular in lit areas.

 

What do you put into your AssetBundles exactly? Scenes, prefabs or ...?

I don't think I understand your problem then. Is it with lightmaps (the textures), with lightmaps array (so references to those textures) or with the data on the renderer (lightmap index, scale/offset).

If you could submit a bug report where you show what you're trying to achieve in more detail, I'm sure we'll come up with a solution.

 

I would like to ask you all to stop responding in this thread*, as it covers way too many topics at this point.

Please search for an existing thread in the Global Illumination subforum that covers your issue and write there. If there's no such thread, please start a new one for that problem and that problem only.

Aggregating all your issues in one thread makes it harder to help and harder for others to find solutions.

*) Case numbers are ofc welcome here though.

 

Didn't want to open a new topic extra for this and it's not another bug, but a little rant. (Bear with me, it's not ill intenioned. )
But I wanted to agree with frederico and emphasize that Unity to me really doesn't seem artist friendly.
There is often a middle ground missing between dumbed down controls and being a scripter/programmer.
As an artist I want access to as much controls as possible and I want proper documentation for those controls.
Unity clearly strives to make everything as simple, self explanatory and fool proof as possible and there is some merit and target group for that. I just don't know if I'm in that target group and I dare say I'm not alone.
It would be great to have some additional parameters and finetuning options behind a rollout or something like that at least.
If you deal with things like GI and lightmapping, many people will quickly arrive at a point where they understand enough to want more control or want to do things differently without having to dig into scripting or running to a programmer. (Which isn't always possible, as well.)

 

I am targeting iOS platform, so no linear space is available as I understand.
I've been using gamma in Unity 4.6 and I am using exactly same scene and gamma in Unity 5.0
However results look different to my eye.
What I've found helps to smooth out sharp light edges is enabling Final Gather

I'll work on bug reports

 

@Almakos I do have a similar problem with Final Gather producing weird shadows. I do have transparency Lightmap parameters but it still occurs.
@KEngelstoft Could you tell me the case number of the bug report for this? I'd like to follow its progress

 

Did any one notice that the new lighting system works poor on mobile?
I not sure it might my fault but I only get 20 FPS on iPad mini 2 in a scene which has only a few polygon.
But if I switch to the older shaders, it works smooth a lot.
How can I deal with it? I have post a lot of post and none of them was answered.
I don't want to switch the old shader since the new one appears beautiful.

 

@QI: I may be wrong but if the performance is better upon switching to the old shaders it shouldn't have something to do with lightmapping but rather with the more complex calculations inside a pbr shader. Not sure if pbr is intended to work with mobile hardware.

 

Thanks you, but Unity didn't provide us a mobile version, so I think they must include a mobile version in the Standard and they must design something for mobile.

 

@QI: Yeah, it was just an assumption I made based on what I know about pbr and shaders Guess an official statement would be nice, I'm interested in that, too.

 

Can you show me how to disable every thing that have a high cost in pbr system?

 

Hi.

I guess case like Cascho01 is soved by use custom shader or Scripting. which uses exteral Uv and exteral rendered Lightmap.

But, I'd like to use exteral UV for render Lightmap in Unity3D.
also qualified these..

• 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 tried script that fixs scale/offset. but that was for mesh that already has baked lightmap...
I really need option to set index, scale/offset for baking lightmap inside Unity 3D.

 

I drop my brick as well on lightmapping - so slow as hell... please guys from Unity FIX IT AS SOON AS POSSIBLE !!!!THIS IS NOT POSSIBLE TO WORK WITH THIS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

did anybody found a way to set the lightmap index on objects?

 

General guess would be too high of the realtime/indirect resolution, please try lowering based on the size of your scene.
Something around 1 is fine for an apartment.
0.1 for a small outdoor scene
0.01 for a big scene with terrain

Alternatively, would you be willing to share the scene you have problems with?

 

I am experiencing INCREDIBLY slow build times as well, with NO realtime component. A scene that took 20 minutes in the old system is taking 6 hours or more on the new. My baked resolution is 2, indirect is 1. I am really just looking to match our 4.6 results, but getting even close seems to be incredibly hard. I have also lowered the settings to Default-LowResolution.

This is for a fairly large outdoor scene, but the player moves between indoor and outdoor spaces, so an overall low resolution to the baked lighting isn't an option. I have set the large distant objects to only use .05 scale in the lightmap, is there anything else I can be doing to try and get back to the 4.6 functionality and visual quality?

 

Indirect resolution is equivalent to realtime and is way too high.
I'd recommend using something in the range of 0.001-0.1 depending on the size. Please experiment with those values. Instead, after you find a suitable indirect, you can increase baked resolution to around 10 or maybe even more

To better suit your scene you can also have different lightmap parameters for indoor and outdoor elements with different resolutions.