This was actually fixed some time in the 2018 cycle (I think). It wasn’t mentioned in the release notes for some reason. At least for the progressive lightmapper, not sure about enlighten.
I am talking specifically about packing the larger islands first.
There are still things that are worse than old Unity versions. For example, packing is still bounding box based, while older versions of Unity did a much tighter fit, but they took that out to accommodate for bake selected. But now we haven’t had bake selected for years and packing is still bounding box based.
We’re using 2018.2 and the packing algo is still horrible. On a 4K map, there’s 2K of used space and the remaining space consists of two flat colors that don’t appear mapped to any of the 4 meshes in our scene. (All 4 meshes using Unity’s automatic unwrap setting)
@kemalakay Any updates on the progressive packer.?
Any update on packing improvements for the Automatic Lightmap UVs? I keep checking release notes on each successive release of Unity since 2017 and I don’t see any notes on it, so not sure what’s been worked on or improved? I still have the issue of Unity not respecting my custom-authored lightmap UVs from 3ds Max. Unity still performs it’s own rotation to my UV shells, moving them onto different atlases, etc. I’ve set proper packing tags for geometry I want on the same atlas, but it doesn’t respect these because of very poor packing of atlases…so it shifts UV shells onto atlases with massive amounts of empty texture space.
Thanks for all the feedback guys! As clear from the above, the packing algorithm used in the progressive lightmapper has a lot of issues. It needs work and over the last year this work has been postponed due to other problems that for various reasons have been deemed more important.
Unity 2019.1 will have a minor new packing feature and that is “Limit Lightmap Count”, the ability to set a max number of lightmaps to be used for a certain group of objects. This feature is currently in the polishing phase, and once it is done, I will focus on addressing the issues mentioned in this thread.
I cannot guarantee anything, but on my radar right now is:
Improve texture utilization (i.e. avoiding space waste).
Avoid texel bleeding/overlap.
An option to pass-through UVs unaltered (as requested by @JamesArndt1 ).
Thank you so much for the consideration of this. The Bakery Lightmapper plugin does something similar with its “Lightmap Groups” functionality. You can assign a Lightmap Group to a set of geometry that may or may not be combined meshes. Once you’ve assigned this script you can drop-down select to use “Original UVs” and it will bake and preserve my 3d package authored UVs. I would highly recommend looking at this plugin as it produces lightmap bakes that are cleaner than anything I’ve seen come out of Unity in years.
I say they (Unity) should just buy Bakery. Over night the problems are all solved. I guess I’m going to have to buy Bakery next week. My experience with lighting in Unity lately has been frustrating-- I put a few models I’ve made in and bake lighting and whole UV islands are getting the wrong colors with hard seams. It has nothing to do with bad mapping on my part, since the artifact remains even if Unity does the UVs. Looking at the islands, they have plenty of space around them. I noticed the UV packing. I thought-- Jeez, if they’re going to waste the space, move the islands farther apart or something to help avoid artifacts. Plus, I cant get global illumination to change no matter what buttons I push or sliders I drag. The HDRI Sky script seems to be missing from 2018.3 HDRP… Or do I have to download Unity’s HDRI sky pack for half a gig to get the script? The spotlight in the demo construction scene seems to have the light map pixels drawn backwards or else some weird choppy gradient artifact is chunking up the shading-- Oh wait. I see it on the ground from the directional light too. so… Yeah. I’m gunna buy Bakery for 55 bucks and hope it works for me. I’m just an artist that wants to try making stuff for the Unity store, and I want my promo pics to look good. But dang. I feel like I have to be a Technical Artist who can code and knows engines and video cards in depth just to set up a nice looking test scene
I would highly recommend this plugin. I’ve used to great success to lightmap large racetracks on a project of mine. It’s for mobile so I don’t need a lot of the fancy realtime GI stuff. For Beast-style lightmapping that looks even better than Beast this is the plugin that does it!
Unity clearly creates a uv layout for each fbx on import and just moves it around inside the final lightmap.
I’ve added another barrel to the scene, and since you “clearly can’t fit” another “barrel layout” inside this lightmap, it generated a separate one for just that one barrel.
Ha ha yeah that is a bit ridiculous, but it’s a symptom of a larger problem. The system they have in place for auto generating UVs for both real-time lighting and for baked lighting is like a platform held up by a bunch of rickety poles. Each of these tiny, interdependent systems that affect one another in ways you wouldn’t expect. It’s simply not intuitive to understand or work with these inter-dependencies. So it becomes a time sink, money wasted spending all of this unecessary time trying to reverse engineer these settings. The UVs and lightmaps do not bake well out of the box or rather by default. Unity 5 has been out for around 5 or 6 years I do believe and I would have thought they would have dramatically improved the packing algorithms by now.
This is so frustrating. I work with my brother, who’s doing the art for the game. We constantly discuss various aspects of the development and decide whether he should do something(level design, lightmaps, etc) using Unity tools or 3rd party tools. Every time he says he will do it faster in 3rd party app, and every time I convince him that he should use Unity, because “Hey, in all the videos Unity features look so well made, and EVERYONE uses them!”. We start using the Unity tool and it turns out that basic functionality is half-baked, missing or absolutely not usable for production. How can ANYONE use these tools for production?
Like this example right here… Yeah, you can bake a lightmap and the scene would look cool in a Unite presentation. But then you check the actual lightmap files, and realize that there are 5 half-empty textures, eating your entire space budget for a scene.
Create your own UV2 for lightmaps by hand and then pack each one with something like RizomUV or a similar good packing tool. Then massage: scale in lightmap and overal texel resolution until you have decent coverage. You might need to repack some of your UVs if they end up much bigger (so they waste space), or much smaller (so you get overlaps) than you thought. Then massage again.
Keep repeating this loop until you get decent coverage. Around *0.7 of the theoretical maximum is pretty good.
It is a ton of manual work, but this is how my lightmaps look these days:
And this exposes yet another shortcoming. If you’ve authored lightmap UVs in your 3D package, there is zero massaging that you should have to do to those UVs in Unity. They should pass through unaltered. Hopefully they do implement this, as I’ve been told they likely will.
That is freaking unacceptable.
Let me guess, greedy Unity shareholders forcing you guys to work on completely nonsensical “features” because they heard some buzzword on Wall Street about the newest cool thing in tech instead of working and improving existing things that are actually important?
Unfortunately, I cannot see the image you posted. Can you please try re-posting?
We have one minor update on this. Spatially coherent packing landed in 2023.3.0a4 (thanks to @Pema-Malling ). It works somewhat similar to what I showed [here]( https://discussions.unity.com/t/654098 page-15#post-3777937).
I won’t comment on your guess, except to say that we know the packing is bad and that we (still) want to improve it. There has just been (even) higher priorities for us, e.g. ensuring GPU baking still works on MacOS even after OpenCL is removed (Apple deprecated OpenCL some years ago).
Thanks mgear! This is a classic example and there’s a reason for this shape.
The packing algorithm will reduce the size of the lightmap if it can. However, these reductions happen by halving each dimension so each potential reduction step will give you 1/4 of the original number of pixel. This means that in order for a reduction to happen, all charts needs to be able to fit into a single quadrant (i.e. 1/4 of the pixels). In the example shown, this is quite clearly not possible, even if you rearrange them. Therefore Unity doesn’t shrink the atlas in this case.
That said, the utilitization is still awful. We need something better and this is on our roadmap but actually finding time to work on this has proven difficult (see my comment just above).
