Official [2020.1] New Feature - Auto Pack Margin

Shaded view. Notice dark artifacts around the objects' edges caused by the UV overlaps.

UV Overlap debug view. Notice the lack of overlaps in the image on the right.

Overview
This feature was developed by Rasmus Rønn Nielsen (@rasmusn).

In the Mesh Importer users have the ability to automatically generate lightmap UVs. Traditionally, we had a setting called Pack Margin. One could use this setting to deal with texel bleeding across lightmap islands. However, for various reasons this setting is extremely difficult to use and is generally disliked. This feature introduces a new way to work with lightmap UV margins. The new method allows the user to set Min Lightmap Resolution and Min Object Scale. These can be thought of as "a contract". As long as the imported model is used in scenes that has a lightmap resolution of at least [Min Lightmap Resolution] and as long as instantiations of the object is scaled to at least [Min Object Scale], then Unity will guarantee no bleeding across islands. This is achieved by conservatively calculating a pack margin that is large enough to avoid leaks.

Unfortunately, larger margins can of course also cause lower texture utilization. There's no free lunch, but at least we now get correctness.

Setup instructions
New pack margin options are available in the Mesh Importer window. Select your mesh, and make sure that Generate Lightmap UVs flag is enabled. Unfold Lightmap UVs settings, and set the Margin Method to Calculate to access the feature:



Feature access & feedback
You can get access to the feature by downloading the latest 2020.1 alpha build via the Unity Hub, or via this link. We are looking forward to hearing your feedback!

 

@AcidArrow that option makes a lot of sense indeed. CC @rasmusn.

 

@AcidArrow @Kuba This new feature is unfortunately tightly coupled to our internal UV unwrapper, so we cannot just "apply it" to user authored UVs. That being said, I agree that such a feature makes total sense.

Given a UV layout without overlaps (in continuous UV space), Unity should ideally be able to transform this into a "resolution-aware" UV layout that respect baking settings (e.g. Lightmap Resolution) such that no texel bleeding can happen during runtime. With such a feature, users could exploit unwrapping algorithms of DCC tools and it would "just work" (tm) when passed to Unity even after changes to Unity baking settings. But, alas, our roadmap does not (currently) set aside much time to improve in this area.

 

I agree that the current situation is bad and that there are plenty of proven techniques that we should learn from and adopt. The reason that we aren't is that we have a lot of other stuff on our plate currently. I hate to sound like a broken record, but it is the truth.

It is my impression that a lot of people are using the built-in UV generator (bad as it may be). For them, it is nice to at least be able to get correct lightmaps (as in no texel bleeding). With this feature, you can get that. Therefore I think it is a bit much to say that the feature is "wasted".

The problem with that approach is that it scales linearly with vertex count (regular lightmaps don't). This means that it will be great for some games, but really bad for others. For that reason, we are hesitant investing too much into per-vertex lighting. I think a modern implementation of light probes has a better chance of being a better replacement/improvement of lightmaps that works across a wide range of game types and assets, but that is a different discussion

 

Thanks for mentioning that @AcidArrow.
@DoomPriestK To what @AcidArrow already said, I can add that the bug has now been fixed and will be part of one of the coming patch updates to 2020.1 (and will of course also be fixed 2020.2).

 

Yes, that is possible. Just let your DCC write the UV layout to the secondary UV channel and Unity should pick it up (assuming you have turned "Auto generate UVs" off in the Model Importer). Do note however, that your object's UV rectangle will be scaled (uniformly) and positioned inside a lightmap. This scaling/positioning is currently not configureable but several people have requested this. So far we have unfortunately not been able to find time for such a feature in our roadmap. Unity performs the scaling automatically to maintain the same "texel per unit distance" resolution across the entire scene (unless you have configured it differently, e.g. via the "Scale in Lightmap" parameter). Note that even though your charts have no overlap in the continous UV space [0,1]^2, data may "bleed" across charts due to bilinear filtering on the GPU.

I could not find it in the docs, so my answer would be no I will report this to our docs team right away.

 

I understand @AcidArrow's sentiment completely. It's not entirely "wasted" effort, but the effort should be expended on dealing with more important issues at hand..i.e. the poor packing algorithms for generating UVs. I've been a user of Unity for over a decade and to see that a decent auto UV algorithm hasn't been developed within that time frame is disheartening. So I understand what he meant. Who cares about pack margins when the UVs themselves are terribly wasteful. We're talking about facilitating millions of developers to produce games and products that will ship out into the world with poor memory management...or rather poorer than it needs to be out of the box. Why not focus on empowering developers to manage memory more efficiently? Versus continuing down the path of ignoring the problem of wasteful texture memory utilization?

PS - As an aside, did Unity ever get in that functionality for passing through user-authored lightmap UVs without repacking them, shifting or moving them around on atlases? Basically pass them directly through not altered in any way...how it was done in Beast.

 

Maybe you already know this, but for what it is worth you can achieve this by manually setting the Baked Tag. Objects with different Baked Tag will go to different lightmaps. You can use this to ensure that objects that are close to each other go to the same lightmap (or set of lightmaps if you have too many objects to fit into one).

 

Thanks for your sincere comment @JamesArndt.

I already answered your other recent post that is similar to the one in this thread, but I will reply here as well for completeness.

I hate to sound like a broken record, but a lot of UV work got de-prioritized against other high-priority fixes and improvements. The fact that this has been a known problem for so long is definitely not something we are proud of or have forgotten about. We are currently looking into ways we can repurpose our resources in order to find manpower to address this. I know this is not the answer you had hoped for, but I can tell you we are trying our best with the resources and other obligations that we have.

 

@awenc-lsvr Thanks for your feedback! That work-around is pretty clever I must say .

I cannot promise when or if the following will be delivered, but these are some things are actively looking at which I suppose you'll like:

• Revised architecture and API of the light baker. The old global Lightmapping.Bake() API is coupled to the Lighting window. We'd like to ada a new lower-level bake API with no global side-effects where the user is given much more control (at the cost of less convenience). For example, they'll be able to fully control the input to this bake (as opposed to Unity automatically extracting everything that is in the scene) and also where the outputs go (e.g. the API won't be coupled to MeshRenderer at all).
• Atlassing will be extracted from baking such that it can be passed in as an input to the bake. Alongside the new API mentioned above, this means that users who use the new lower level API can pass in _any_ atlas/UV-set they want via C#. This should unlock the "Lock Atlas usage" that you mention.
• We are considering to replace our current (old) atlassing solution with something similar to what Frostbite presented in 2018 (see attached image). This is fully automatic, has high utilization, and guarantees no bilinear sampling leaks across charts. Effectively, this would remove the need for the "Calculated Pack Margin", "Minimum Lightmap Resolution", "Padding", "Pack Margin" settings because everything will just work (tm).

Again, I cannot promise if/when we will deliver these .

 

I agree, this would be useful. I have submitted a usability request for this feature.

 

Yes, exactly.

Yes, agreed. The method I refer to do indeed take UV unwraps as input, and these can be hand-authored or automatically generated by Unity or another program. The packing algorithm will then identify each chart in the UV unwraps, and pack these efficiently and safely in the list of lightmaps (using only translation + scaling).

So this allows the user to control seams but it doesn't allow the user to control the entire lightmap chart layout.

That said, the architecture refactoring mentioned above involves decoupling lightmap packing from light baking, and therefore it would also enable 100% pass-through UVs, i.e. at mode where we don't try to packing anything. However, if the packing algorithm mentioned above work as nicely I think it does, then I'm not sure this pass-through mode is still relevant. I'd love to hear what you think about this.

 

Not that I know of, no. Unfortunately.

Ideally, we should somehow make it an opt-in whether you want to use a new version of the UV auto unwrapper. But this comes with its own set of complexity given the current state of the ModelImporter (how do you expose this choice in the UI, how do you serialize it to disk, how do manage users who switch back and forth between versions, how do you handle unwrap settings that may make sense with one version of the unwrapper but not another one, etc). And given that additional complexity isn't exactly what Unity needs currently, my guess is that the author of this change assessed that requiring a rebake was the better compromise.

I understand why this may not be a satisfactory answer for you but at least I hope it shows that this isn't exactly a trivial problem either.

 

Are you referring to the Auto Margin feature (in the Model Importer) specifically or the general packing algorithm? These are two different algorithms (one generates input for the other, if configured to do so).

Or maybe you are implying that the large area of unused space in the attached lightmap means that there must be a bug in the packing? With the current packing implementation, that is actually not the case. The algorithm tries to reduce the size of the last of your lightmaps, and it does so by halving the lightmap resolution until the objects in it no longer fits. In your case, you would not be able to half the lightmap size one more time and still have the objects fit, and therefore it doesn't. This behaviour yields this funny-looking L shape.

Note that I'm saying that our current packing strategy is great. I'm only saying that it seems be doing what it was originally designed to do (based on the few details you have shared).

Please share more details about your problem or [file a bug](https://forum.unity.com/threads/2020-1-new-feature-auto-pack-margin.827859/), and we'd be happy to take a deeper look. Thanks.