Unity 4 - Lightmap atlasing broken?

Since upgrading to Unity 4 automatic lightmap atlasing has stopped packing UVs correctly for me. I've asked this over on answers but I'm having no luck, so trying here.

I create all my lightmap UVs outside of Unity and there is often empty space in the [0,1]x[0,1] UV square. Previously Unity would use up this space but in Unity 4 it leaves this space empty. Is anybody else seeing this?

Here's a before and after...

 

Please check your UVs outside of Unity, using your modelling software.
Lightmap UV should put on channel 2.

Once bring in Unity,
uncheck "Generate Lightmap UVs"
uncheck "Swap UVs"

Turn on Lightmap Static for the Object, and Bake using Beast.
If the lightmap does not lighted your scene properly (leaking and black patch everywhere),
then it should be Unity Beast Lightmap bug,

else the UV2 for the Object is done it that way.

 

So...

• Lightmap UVs are on channel 2
• "Generate Lightmap UVs" is off
• "Swap UVs" is off
• Lightmap Static is on

I think the problem here is not with Beast though, it's with the lightmap UV atlasing process, which I think is all done in Unity before Beast gets it.

Here's the Unity 4 lightmap as above but I've highlighted a couple of the [0,1]x[0,1] UV squares. You can see that there is empty space in some of the squares which isn't getting used up. In 3.5 this would get used up...

 

To make bake selected possible (and efficient) we needed to move away from texel packing to bounding box packing. The reason is that it's easy to remember where each bounding box came from, but remembering that per lightmap texel would be too much.

So the effect you should be seeing is that concave areas of UV sets are no longer filled up with smaller UV sets, but when looking at (tight) bounding boxes everything should be nice and tightly packed. In practice our unwrapper rarely produces concave UV sets, so on levels we tested it on (like Angry Bots) there was no visible difference.

BUT! Your image shows that the bounding boxes of the UV sets aren't tightly packed. So either there are some stray vertices in your UV unwrap that make the red boxes stretch all the way to [0,1]x[0,1] or it's a bug in our atlasing code. Could you check if it's the former and if not, submit a bug report with a small scene with a couple of those meshes and post the bug number here? Thanks!

 

The UVs are all confined to where they should be (not spread to the bounds of the UV square) so I've submitted a bug (#504094). This is a serious one for us as it triples our lightmap count and will likely not run on device because of memory limits. Thanks.

 

Thanks! We'll take a look.

 

Any news about that huge bug ?
I've got the same problem, and in my case it can go to 1 object per LM, and the object takes 1/16 of the place, for an
"Object's size in lightmap has reached the max atlas size" ...
I'm at 85 LightMaps for a scene that takes 6 in unity 3.5...

And without mentioning that the base ratio calculated for the scene is horribly wrong between objects. Looking for the ratio previsualisation, and the diffrence between the shecker size for each object are huge, even when I use the automatic UV for all the objects.
And when they are pieces of the same roads with a difference 10,1551723 : 1 for one piece, 17,38971 : 1 for another, then 35,35871:1, how possibly correct that manually everywhere ????
It's only when I maximize the scale in LM that I can have the same ratio everywhere. And it obviously not maximize the size in the LM, as you can see above, not mentioning the empty space, for a non-concave UV of a plannar mesh (a piece of road) with a centered pivot...

 

I would also like to know what is up with that bug, we're having the same problem on our projects. Since we're making texture atlas, the UVs or certain object leave huge gaps of empty space. Lightmaps on a previous project on 3.5 takes twice the size minimum in 4.0 !

@Aynis Scale in Lightmap 50? Its kinda big.

 

Here is the results. Meshes are set to Create LightMap UVs and are mapped to map1 in Maya with no out of bound UVs. You can see the black gap between the rectangular plane mesh uvs and it's doing the same thing with they other meshes on the right and top.

 

Yeah, I know, but otherwise it's impossible to have a correct ratio all over the differents meshes. Even if all the pieces have a uniform scale at 1, a correct sets of UV (1 and 2), and the same materials...
When two continuous pieces of the same road have totally differents ratio if the LM scale is 1, and that for almost all the pieces, it's awfull when lightmapped. I've tried different ratio, but only the 50 make all looking fine and similar Oo And when I look at the maps created, it is not really at that scale as you can see in the picture, and really not using the maximum size of the map...
There really is a problem with the ratio and the atlasing in unity...

 

I'm getting a similar problem on my end. Every single lightmap generated for me is 1024 x 1024, no matter how small the scene is.

I made an empty scene with one cube, baked lights, and ended up with a 1024 x 1024 atlas. In 3.5 this would have been 128 x 128 or smaller. We're unable to update bugs in our iOS game until this issue is fixed because it will increase memory usage in scenes that were already pushing memory limits. We've also had to drastically lower texel resolution in some scenes just to get them on single atlases. This seems incredibly broken.

 

@robert - Any news on the UV bounding box packing problem yet Robert? It's getting more serious the deeper we get into production. Is there any way of writing a custom editor script to get around the problem for now? Thanks.

@Aynis - Though related, I think the ratio problem is a separate issue. I noticed slight inaccuracies with the ratio back in Unity 3. It's possibly just a result of approximating UV shell scale from UV surface areas. I've mostly been able to live with it.

@MightyRabbit - This also sounds like a separate issue. I've not experienced this myself though.

 

I've just discovered that not only all the meshes with a second UVset are all in separate LM like my precedent picture, but also the atlas has just take the second UVset as it is.
No UVshell was moved, no reorganisation in order to low the maps of the scene like an atlasing should do. It's like there has been no atlasing at all for those meshes Oo I've combined the maps in photoshop and without moving anything I've just reconstruct the UV I've made in maya, the simple up plannar with unfold (it's for the roads, no need for a complicate method)

@Jde : about the ratio problem, in my case it's really huge. And it exists allready in the previous versions. With a road cut in several pieces, and an night atmosphere, the ratio difference become really visible with every light source near the separations, not to mention the quasi-impossibility to correct it manually. And with a ratio problem, I don't think that the atlasing could be efficent. After all, the atlasing is based on the UVshell's size, those depends on the ratio. In my case, even with squared UV (no noticable blank space in the UV bounding Box) there are a lot of empty space in the other maps (not the ground part), pieces without manually created second UVset and a low ratio (between 1 - 5).

 

I'm pretty sure the atlasing process is not intended to separate individual UV shells from within a single mesh. So that's correct behaviour you're seeing. It should however be packing those shell groups better.

I can see how the ratio thing is hard to ignore in your case. And the ratio problem will certainly impact on the atlasing efficiency. I guess it's just that the bounding box packing is the more serious problem for me right now. In my scenes the ratio problem wont be that noticeable. Worth bugging though (if you havent already).

 

I guess my english is very bad and my explanation was wrong ^^"

The road is separated in severals meshes. And every mesh has is own LM !!! The atlasing is inexistent for all thoses meshes : the UVs are in the same place than in maya.
The atlasing has to pack every UV shell the more efficently, same mesh or not. It's like the Layout UV in maya : it packs the UV for all the meshes selected, using only the shells as reference, and the meshes are somewhere irrelevant (single or multi selection, it doesn't care, it only pack the selectionned UV with the parameters we set).
In my scene, the atlasing separate the UV of every meshes with second UV in is own LM, without touching the shell, and only a 50ratio can make all the elements have the right ratio even if they use a very small amount of texture. It's like it was saying :
Oh, a second UV set ! I won't use it to calculate and organise the atlas, it's simplier to use it as-is. And in case they are overlaping between the diffrent meshes, I will separate all the pieces in is own LM, so it's clean. And the ratio ? I can't calculate an accurate one, let's say that 50 is the exact size of the second UV in the 1024*1024, it would be fine.
And tada, that's exactly what I have ><
For me : big ratio errors + inexistant atlasing for every meshes that have second UVset = 86 1024*1024 LM
Unuseable for anything else than screenshots...
And the atlasing for the rest of the scene (Unity generated LM UVs) is broken too, with lot of blanck space (more than half the texture at least for one of them, 1/3 for 2 more ... ) without any reason. And like for the road, if I check the ratio, it's wrong. And I can't correct all the ratios in hand (it's a big town with lots of roads, places, buildings, and of course urban props everywhere...)

 

Its a big problem as well for us here. Look at what I get right now.



It could easily be 2 lightmaps, now its 4 with huge gaps!

 

Hi all.

I am having the same issue and for us this is a massive problem. However, considering how much of an issue this is there doesn't feel like there is enough noise around it from the community. I have also contacted other companies that say they are not having these problems.

This makes me wonder if it software, export method specific.

I'm using a Mac running Maya 2013 and exporting using FBX. Are we all using the same software/import method?

 

I'm using Maya2012, FBX export, and windows7 64bit.

 

From what I have seen, it seems to happens for a specific reason but I havent been able to pinpoint the problem. I have this issue on one project but not on the other.

The difference seems to be on the scale of the environment and the shapes of the meshes to lightmap. I could partly fix the problem by cutting somes pieces so their UV are layed in squares rather than rectangles

Im using Maya 2012 with the latest FBX exporter. I was using a previous version but updating did'nt fix the problem... however, since it seems to be project related, I dont think the exporter is to blame.

 

Thanks for the quick response.

I have thought about face mapping everything in a similar method to Ptex which will do the same sort of thing Julinoleum is suggesting. Still not ideal.
I will have a play with scene scale and import scale. Thanks for the tip.

Sorry Julinoleum, but are you Maya users aswell?

Ok cool. The studio I contacted are Max users and have not had this issue. We are all Maya users, so It might be worth looking at how Maya scene scale effects things.

I'll do this and post my results on here. Thanks for the help all.

 

Yup!

 

Maya 2013 with FBX export here too. Using Mac right now but had the same problem on my Windows 7 PC.

 

Hi all. Thought I best let you know how my testing of different scales and things has gone and I can report that I have had no luck in getting it to work.

However, I have been in contact with the support team and have just had this reply:
'Hello Ewan
The problem has been identified and fixed, but unfortunately at this time I can not say when and which version of Unity will be released.'

Not the best response but with any luck it will be in the next update or 2.

 

At least they did something about the problem ^^

We just have to wait and see now.

 

That's good to know. Thanks Ewan.

In theory it's probably possible to write an editor script to do the atlasing (and use the 'lock atlas' option when baking) but I'd rather wait for a proper fix. Hopefully this wont take too long to get into an update.

 

Hi *, sorry it took a while. The bug is now fixed, so atlasing will happen based on tight bounding rectangles. The fix will be available in the next 4.2 build.

 

So, till 4.2 what should we do? There's any workaround? Maybe the the manual atlas editor script?

 

Has this been fixed?

http://answers.unity3d.com/questions/476443/lightmap-atlasing-problem.html

 

@hvilela: 4.2 should be out quite soon. In the meantime, atlasing is not broken, it's just wasteful if your UVs take up a small portion of their [0,1]x[0,1] square. But if you really need different atlasing, you have full control from scripting too.

@Stardog: For now atlasing won't try to shrink the size of the last (or the only) lightmap, like it used to originally. We should probably add that. In the meantime note that the lightmap is actually very tightly packed, so if you increase the resolution, there should be no leftover space.

 

Any news about 4.2? It has been 7 months since this bug was reported.
About the script: Any chance that you, Unity guys, provide us an editor script to manualy do the atlasing Unity 3.x style?

 

4.2 will ship Really Soon Now™.

Sorry, we won't provide a script like that. We're working on a better solution, which takes a different angle on atlasing, so we don't want to be going back to the old ways now.

Besides that, in my book, workflow simplicity and iteration speed have a higher priority than 10% memory savings

 

Finally!
"Lightmap atlasing now always tightly packs object UVs based on their bounding rectangles."

Let's try it.

Source: http://unity3d.com/unity/whats-new/unity-4.2

 

Ugh, 4.2 solved nothing. Our tiny scenes still output 1024 x 1024 atlases for absolutely no reason.

We used to be able to get 128 x 128 atlases in Unity 3.5, in Unity 4 we've only ever been able to produce 1024 x 1024 lightmaps. This is incredibly frustrating when we're targeting memory challenged devices.

 

If you want a 128x128 lightmap, you have to reduce the texture size at the end of the process. Make you you get your uv packed on the whole 1024x1024

 

No, that doesn't work because it reduces quality. With Unity 4's lightmapping system we'll see the actual light map only takes up a small piece of the new 1024 x 1024 lightmap, the rest is all unused blank space. If we reduce it to 128 x 128, the tiny section of the lightmap that is actually being used will only get smaller.

The best solution is to increase texel resolution to fill the full 1024 x 1024 and then reduce that down. I'm OK with doing this, but it's a completely unnecessary step when Unity 3's lightmapper seemed to be doing everything better.

Also, scenes that were already fitting on a 1024 x 1024 lightmap now seem to use multiple lightmaps. In order to get those back down to single 1024 lightmaps, I have to lose a lot of fidelity.

 

I have yet to try 4.2 but Im working with increased texel size like you mentionned in your second paragraph + some manuel control on prefrab lightmap size as well depending how far and big they are on screen. Apart from the bad packing, I didnt have much problem. I thought what caused multiple 1024x1024 was that bad packing... so yeah, I'll see what we get when we jump on 4.2 in about 2 weeks.

 

4.2 fixed what it said it did - tightly packing based on UV bounding rectangles

There were no changes to make the lightmaps smaller if only a portion is filled. But if there's a specific resolution you're aiming at, you can change the atlas size from script to something lower than 1024x1024.

 

Any news on this? The atlasing is really sub-par leaving huge empty areas in the maps instead of utilizing the entire space. It has serious impact when trying to get down build size as much as possible.

 

What do you mean? The issue which had started this thread has been fixed in 4.2.

 

I guess he is talking about the bounding box packing instead of the previous method (texel packing?) which was much more efficient in packing things together. I'm not that happy about the change myself.

I can understand why the change in the packing algorithms happened, but I still don't find bake selected very useful, so the tradeoff isn't justified.

Especially since "Generate UVs" doesn't really try that much to generate a "Box" like UV maps. Before the change, Generate LM UVs + the Old packing, generated decently packed Lightmaps. Now it's pretty bad.

I ended up changing my workflow and I make all the LM UVs myself now, which has even better results overall, which is fine. I just miss being able to not care about making LightMaps UVs and have results that don't make me mourn about all the lost texels

 

Right. So I felt like the response to Bake Selected was overwhelmingly positive when we introduced it. I'm guessing mostly due to how long it takes to bake the entire scene, much less because with Bake Selected some new, atypical workflows are possible. And Bake Selected requires bounding rect packing, no good way around it.

But with Enlighten, Bake Selected seems much less justified due to how fast Enlighten itself and our entire pipeline around it is. So I think we can drop Bake Selected and revisit texel-tight packing.

 

I understand the reasons behind the change and I understand that other of people find Bake Selected useful. I was just offering my POV.

That would be great.

 

Hey Robert, it has been a year and a half.

Uhhh... how's it going?..

Your past self was considering texel tight packing, is your current self still considering it?