Hi,
Reviving the lightmapping thread a bit…
the “Generate Lightmap UVs” checkbox is very handy, sure it makes ugly UV’s on “soft/organic-like” meshes, but still. It’s a One click feature that let’s you bake any objects pretty efficiently. not overlapp, no unfolding hassle…
and I still author my own UV2s when necessary…
So auto pack margin feature, yeah that’s cool. but the feature that changed a lot the final quality for me on Automatic UV’s is the Stitch Seams option couple years ago**.**
Now even with poor UV2, the final result is very decent (in terms of quality, now memory waste on lightmap is another story)
I baked this helico interior a few months ago (see image) with GPU and Automatic UV’s, and it’s fast and clean… while a few years ago it wouldn’t have been that easy.
Now about a pass through option
There used to be a Lock Atlas feature with Beast back with Unity 4.
and it was possible to force bake the lightmap within 0 and 1. no offset, no tilling.
I’m trying to reproduce that on a project right now… and I still get some tilling no matter what. also padding is 2 as a minimum value, tried editing that padding value manualy in Lighitng Setting file, doesn’t seem to take.
My goal is to bake some lightmap in Unity for specific animated objects and use those lightmap in the shadergraph to lerp between 2 states or more. to have Animated Lightmap. and right now I’m a bit stuck…
@rasmusn
I’ve been using Unity for almost a decade, and I’m now really happy with the Auto Generate Lightmap UVs and the actual, pretty robust, GPU lightmapper !
I’ve tried a workaround to solve my actual problem :
I have several objects I want to bake in one single Lightmap, onto my prepared Layout, to be used in a shadergraph later.
So I combined those objects to have one single Mesh for the bake, to bake lightmap on the layout without any repack by Unity.
But I was still ending with some small offset and tilling like mentionned in previous post. The workaround :
I added some cubes to the combined mesh, really small/invisible, just to have UVs present at the four corners of the layout.
So Unity detects my layout as a full 0 to 1 UVs and it doesn’t apply any offset or tilling on that. (see attachment (this is a test, UVs are “auto-layout” in Maya))
It’s kind of a trick more than a real process, but maybe it can help other people.
@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 ™.
Again, I cannot promise if/when we will deliver these :).
If I understand correctly, this will generate UVs for the whole scene at once, so packing will be more efficient since you’re getting rid of the requirement of having a mesh UVs be their own little box and then having those boxes packed together.
That has the potential to work well, but can you please make sure if this feature ever sees the light of day, that there is a mode where we can supply the UV islands ourselves, and then your algorithm can move scale etc them as it sees fit?
Even if the new UV generation algorithm is great, being able to control where to have or not have seams is a must have and the simplest way for this would be for the algorithm to accept user authored UVs as input and then repacking them.
At the very least it would make it easier for people on the forums to explain why their lightmaps look weird, but it would also be useful for lightmappers to identify potential errors (I generally never use double sided GI unless I have a very specific reason). It could be a debug view in the scene view.
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.
Hi, I’m updating a project (from Unity 2019 to 2020) which had several levels with light baked and autogenerated UVs, when I open the project with the new version it recalculates all auto UV’s and now my lights are all broken, Have you anticipated this? is there a fix that doesn’t involve baking all of my levels again?
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.
[quote=“rasmusn, post:28, topic: 776483, username:rasmusn”] 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).
__[/quote]
__
Any news about this feature? Unity should be able to just use the imported UVs and repack the individual UV islands with an adjustable padding. This would make lightmaps much more efficient and save a lot of time.
Start a new thread and post more information, the packing is generally still pretty bad, but this feature generally works, from that image I cannot tell what the problem is.
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 not 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 , and we’d be happy to take a deeper look. Thanks.
