Here we are a year later, and lightmapping is still living in the shadow of Unity 4

When are you guys going to get this thing fixed? I'm seriously at my wits end with how to continue using Unity anymore.

- Atlas packing is extremely wasteful. Take a look at the 2k texture I've attached!!! How is this acceptable? I routinely get lightmap atlases that look like this (or worse). Hell, even if I pack my own UVs in my 3d app Unity still finds a way to waste some space (take a look at the second screenshot).
- Lightmap UV atlas is repacked after every bake. There is NO way to lock the atlas in 5- which means there is no way to use different lightmaps on the same static geometry.
- Static geometry with scale in lightmap set to 0 still causes the UV charts to get shifted during a bake, so even non-shadow-casting, non-shadow-receiving lumigons blow up your lightmaps. Why? The scale is ZERO.
- Can't even use Unity 4.6 to bake lightmaps because the EXR's are incompatible with 5.
- LightmapData is a black box, can't change anything at runtime
- Loading a different LightmapData to the scene requires a scene reload before you see any effect??
- Still takes twice as long to bake anything in Unity5 than it did in Unity 4.6 with Beast (and that's with compression turned off and no realtime GI).

A year later I would expect that it would be much better than it is today. Pretty disappointed and will likely switch engines for my next project.

 

Also, still getting random pixelated garbage in my bakes. There one minute, after a 30 minute rebake it's gone! Nothing in the scene has changed!

 

The number of replies by Unity staff in this thread are exactly the number of sh*ts they give about these problems. Good to know.

 

Here's another awesome one! Two 4096x4096 maps baked. Take a look at the second one and join me in the world's largest collective facepalm. remember, these are BOTH 4k maps (downrez'd for this post, obviously).

 

Fun fact- did you know that having a directional light that is flagged as "realtime only" will contribute to baked lightmaps?

Now you do!

 

Wait what?

I don't think that's true.

 

Try it for yourself, and look closely- you'll notice that all of your shadows will brighten up. I had to write a script to disable all realtime lights before a lightmap bake and then re-enable them when it's finished. ridiculous!

 

That's because of the precompute though, no? You should have bounce set to 0 on the light if you want it to produce no gi at all.

 

I'm not using precomputed realtime GI, just baked.

 

Here's a bake I just did. simple plane with a cube, two directional lights. one is set to "baked", the other "realtime"


Two shadows in the lightmap. Both lights disabled for this screenshot to prove it's just a lightmap:

 

Same scene with the "realtime" directional light disabled during the bake. One shadow = one light.

 

More fun facts- did you know that the lightmapper totally ignores culling masks? Now you do!

Unity has known about it for almost a year, but apparently it's too much work to fix so it's not getting fixed any time soon.

 

Do you have precompute disabled? I think that causes the lights to fall back to "baked"

 

Yes, precompute is turned off. And to be honest, a light that a designer has specified as "Realtime" that bakes into a lightmap is broken, regardless of how it's explained.

Imagine an elevator with an up and down button. You press up, but it goes down instead. After some google searching, you discover that up takes you up if you press it twice in a row quickly, but that's the only time it works as advertised. When my designers come to me and I explain to them why lights work the way they do, I feel like this analogy sums up the stupidity of it, so I write a script to force the button to be pressed twice when the user presses once so the elevator goes up as they expect. Do you see my problem?

 

The realtime refers to the gi aspect. Try turning precompute on and put bounce to 0.

 

except when it doesnt. directly from the unity docs on the Light component, there is this:



If you follow the link to the Global Illumination docs, it just takes you to the Lighting window, where they use the term "realtime" interchangeably with what the rest of the industry calls a "realtime light".



Regardless, we're spending a lot of time discussing this issue when it could be summed up as "its like that because that's how they programmed it". my point is that the way it's designed is wrong and there are pages and pages of threads like this on other forums (like Polycount and Unity Answers). The same justification could be made for any inherently backward implementation- such as how the UV packing works.

For example- we can specify a target texel density and maximum atlas size, but we have no control over what we end up with. Why can't we set a target atlas size and have EVERYTHING packed into that (IE: texel density is adjusted to fit neatly and efficiently into a given atlas. Or- When the lightmapper has to split the lightmaps into multiple textures, WHY does it make the second one the same size as the first when that is rarely the most efficient thing to do??? In one of my previous examples, the first lightmap was packed inefficiently, sure- but the second one could have fit in a 512x512 texture- yet it was atlased into 99.9% wasted space on a 4k map. It's ridiculous.

But that's the way they coded it, so i guess we should just go along with it?

 

The docs often lie and enlighten is terrible.

I was trying to help you find a working solution.

 

OH, well- I definitely appreciate it, though my current solution is working well enough. I just have a batch baking editor window that automatically looks through the scene for lights that are marked 'realtime' and disables them for baking- then re-enables them when finished. It's just silly that it's necessary to do that is all.

 

Have to agree here. I don't see why we can't even specify lightmap resolution (in pixels) on a per-object basis, then optionally have a checkbox to allow it to be atlased. And, as you say, just have a global setting with "max 3 maps, max size 2048", then just use the scales set per-object to fit them as best they can automatically.

Currently, we hit bake without knowing what it will spit out.

Realtime lights baking seems to be a bug, or maybe just a fallback as mentioned - http://forum.unity3d.com/threads/understanding-lighting.381166/#post-2483604

 

I had requested something like that when Unity 3.x was around.

Also they had it implemented at some point, but people that were in the closed beta didn't like it. (Becauuuseeeee..........)

 

Do you know if this only happens for directional lights? Does it happen for spot lights and point lights?

 

It happens with point too.

 

I basically make all the lightmaps externally and force the UV's to work by code and UV hacks. I'm so tired of riding the short bus with Unity Lightmapping.

 

The path-tracing lightmapper hopefully helps with some of these Enlighten issues, but we shall see.. I'm cautiously optimistic. Maybe in 5.5 or 5.6? (see https://twitter.com/aras_p/status/700289748821217280)

It's clear that Enlighten is really pre-alpha stuff that should have never been brought in production; Beast was robust and very useful for mobile, I enjoyed working with it. Enlighten, I don't want to touch at all.