Packing for lightmaps was great in Unity 3. It got a bit worse in Unity 4 (it packed by bounding box instead of tighter packing, but still good). It is horrible in Unity 5 (it fails to pack very simple cases).
Did you notice some islands missing? They are in a second lightmap now. Even though the first one still has all that free space. And they definitely fit inside the first.
I haven’t seen any other Unity feature regress this much. And I’m including baking with Enlighten vs baking with Beast in that. It has gotten THAT bad.
I mean, the logical next step for Unity 2017 is to just not do any packing, and create separate maps for each mesh.
I don’t know, but I’m also not sure if it’s related. Packing is a different process and I don’t think it matters which lightmapper you are using afterwards.
I’m hoping they plan on doing improvements though.
That’s what I fear, I was hoping they’d do a better packing method for the new lightmapper but likely isn’t the case. Have to wait and see. At least iterating trying to find the “bad-but-not-the-worst” packing will be faster with the new lightmapper…
I am hoping it won’t match Enlighten in terms of being pre-alpha quality, slow and fragile mess when baking lighting. I’m hoping it’s more like Beast in terms of output & robustness.
At least it was nice knowing the resulting lightmap sizes very quickly when changing things. Helps quickly adjusting if things are on the verge of splitting into too many lightmaps.
I still can’t get the over that the packing in Unity 3 was so much better.
Also can’t get over the fact that originally they were going to have a mode where you would pick how many light maps and what resolutions you want, and the packer would try to maximize the resolution without creating more lms. But they scrapped it because apparently “people don’t want that”.
It seems to me, that older versions of Unity packed the UVs from bigger to smaller. Which makes sense. You fit the biggest first, so you can then potentially place the smaller ones in weird gaps so you can fill space more efficiently.
Unity 5 and 2017 don’t do that. I have no idea why. I don’t know if there’s any logic, it looks random. But what happens is since it fills the space somewhat hap-hazardly with small and medium UVs and then there isn’t enough continuous free space to fit the bigger ones.
The top one is Unity 4, the bottom one is Unity 2017. (it’s not 100% the same, since I have tweaked the UVs since then a bit, but it’s the same scene).
You will firstly notice that Unity 4 has much more efficient use of the space.
And that’s because of it fits the largest islands first.
I can’t increase the resolution at all in the Unity 2017 version since this island:
Gets packed last. Not sure why. And since it’s packed last and it’s a big square area, it really can’t fit anywhere if I increase the resolution.
Placing the big UVs first and fitting everything else around them makes sense and it works. Placing smaller ones first and then trying to fit the big ones in the remaining fragmented space, does not.
I don’t know why it was changed and I don’t know why they won’t change it back. If there is a logic to this madness, please let me know.
I too would be very interested in hearing more info about the packing. @Jesper-Mortensen might know about it with progressive lightmapper…?
I haven’t used Unity 3, but with 4 and above lightmap workflow of specifying resolution first has always felt backwards to me. I would like to set a limit on how many lightmaps to use and what their maximum resolution should be → lightmapper / packing would figure out the correct resolution to give me that (or at least give something that is close to what is requested).
Now, and this is especially problematic with wasteful packing there is currently, you have to guess a resolution and tweak it down (+ adjusting lightmap scale on objects) until you get close to what you want. Granted, it’s faster to iterate with progressive LM and I’m grateful for that, but still the other way would make a lot more sense to me (mobile development). Thoughts?
You’re not alone, Ive noticed this as well and I dont see better packing using the Progressive Lightmapper. I end up experimenting for a long time with scale-in-lightmap values for tons of meshes and then seeing odd and random overflows into new lightmaps (with the same big empty spaces in existing maps). The packing is so bad/inefficient I’ve resorted to packing my own secondary UV set in 3ds Max.
Just wanted to tell that we’re aware of packing issues and that’s why the roadmap for Progressive Lightmapper is being re-arranged and one of our developers will start to work on packing improvements soon.
Main reason why it was delayed so far is because other tasks took priority. Primary goal for Progressive Lightmapper is to have feature parity with Enlighten and it is getting there (memory work is currently being addressed, also static scene dressing for lightmapped objects and importance sampling for emissive materials will be added).
Thank you all for your understanding and raising your concerns. We hear your input and it is really valuable to us, we’re simply trying to arrange the schedule based on priorities.
Wow, your graphic really makes the problem clear. So any word on the fixes yet? Looks like it’s been exactly a year since they started tackling this issue.
