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!
Cool. If I understand correctly it’s only an option if you’re completely generating Lightmap UVs.
Since the unwrapping of lightmap UVs leaves a lot of things to be desired, could we perhaps have a hybrid method that takes user authored islands and just does the packing with the new margin stuff?
I have given up on Generate Lightmap UVs and getting the margins to look correct with hand authored UVs is kind of a pain, so it would be nice if we had tools to help with that too.
@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” ™ 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 have to say then, I’m slightly confused on the purpose of the feature.
“Generate Lightmap UVs” produces very inefficient UVs. It was an okay algorithm 8 years ago, and it’s still largely the same. I can’t imagine anyone using it for anything other than quick and dirty UVs in early development, since it wastes a ton of lightmap space.
So, while it’s “nice” that “Generate lightmap UVs” has proper packing distances, it feels like the feature is wasted, since it’s a polishing feature that is applied to something that people shouldn’t be using for their final UVs anyway.
There are a ton of small lightmapping adjacent features that would be really great to have (storing lighting values in vertices, I believe it has been discussed for a decade almost now) and apparently, there isn’t room in the roadmap for them, so it’s frustrating that when we finally get something, it’s somewhat… misguided. Or at least, that’s what it looks like to me.
Im sure a previous commenter also had this problem, but I think if you change the Min Lightmap Resolution setting in the advanced tab of the Generate Mesh UV’s sub-menu to something higher than your current Lightmap Resolution in the Lighting settings tab, it bugs and stops you using your keyboard to change values in the lighting tab, you can still use your mouse to change the values, it requires a restart of the project.
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).
Hi @rasmusn , your statement brings up my years-old problem/question regarding the Unity “baking” process:
is there any workflow that allows imho quite logical option - to use the UVs generated and imported together with the 3D object itself - in an external DCC application (3DS Max for example), most of which have far superior unwrapping algorithms and provide much better control over it?
There is somewhere here years-long forum thread discussing and begging for such option as the current Unity UV unwrapper is really really bad and ability to use imported well-optimised UVs would most probably clearly outweight all the benefits of the feature you have “advertised” here…
One of the topics discussed there was also - if we try to generate the unwrapped UVs for baking externally - which UV channel should be used as it seemed not quite clearly mentioned in the Unity documentation… is this clear now?
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.
Thanks for this! It’s been one of my number one irritations if I’m honest, with Unity’s lightmaps. I even have had to use dodgy lightmap scales to edge things into shape. So this is a big improvement, possibly more than most people realise.
What remains, I think is to improve lightmap resolution consistency where there are a lot of separate lightmap surfaces. Unity seems to struggle here, with some objects sharing, sometimes waste space sometimes it just has poor results but AFAIK that just is a whole different kettle.
Is it available for Bakery / Other lightmappers? I guess so providing it uses only Unity’s lightmap UVs.
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).
Rasmusn - thank you for the information! it´s 2019. feature very cool… I still in the 2018LTS so not deep familiar with a lots of hidden new features!! really nice to know!! the next game will be 2019.3… this one for quest i will keep on 2018 until we release the update!
cheers!
I already answered [your other recent post that is similar to the one in this thread]( Lightmapping nightmare page-2#post-5695423), 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.
