Unity 4.1 Broke lightmaps

When I imported my project (with 8 lightmapped (using Unity Beast) levels), the lightmaps become garbled.
Or actually, the lightmap UVs are wrong; the lightmap images themselves aren’t changed of course.

This is a huge, huge setback for our project, since we have very carefully lightmapped these scenes.
What can we do?

Do you let Unity generate the lightmap UVs of your imported meshes? I am not 100% sure, but as far as I know the results might not always be the same if you reimport the meshes. That means that these auto generated UVs might have changed when reimporting the assets in 4.1. Re-generating the lightmaps should solve the issue in that case.

That isn’t “solving the issue” though. That is “redoing all the work”. You are right that this is the Unity editor error that causes this problem.
Obviousy it is not intended that when you open your project on another computer (if you are more than 1 in the same team for example), the lightmaps will break on that computer.

Well, you didn’t change your arrangement and settings. So wouldn’t the lightning look the same if you regenerate the lightmaps with the same settings? Maybe I’m wrong and not too familiar with Beast, but just an assumption.

Also if you really need thing to be absolutely the same across computers and versions I personally would never rely on automatically generated stuff which you are not 100% sure of whether it’ll always deliver the same results. You can also equip you models with a second UV channel directly in your 3D app. That’ll make sure that those are consistent, also you won’t need that much time on import. Just on a side note.

That you have to repeat lightmapping with every version may be nasty but the way it is. That`s always the result of a changing. Better that way than having a broken lightmapping in general.

Lightmapping gots mixed up between 4.0 and 4.1 again. They fixed something there. So my guess is that one of your pc´s has Unity 4.0 and the other 4.1 installed. Lightmapping will most likely change for 4.2 too, means you have to do lightmapping again then. Because the lightmap packing is broken since 4.0. I get a bunch of totally black ligthmaps and a very ineffective lightmapping. Bug report is sent. Waiting for a fix.

It’s not that simple. The application I am working is a product configurator (not a game), where several objects change in the environment in runtime, but still have to be lightmapped. That means that I have to switch these objects in and out from their target places and bake them separate. It’s not just clicking on the “bake” button.

in 4.1 we added quite lots of fixes regarding lightmap uv generations to be consistent between osx/win (on all our tests, uvs are now binary same). So yes, you kinda can expect that after upgrading to 4.1 uvs were re-generated (read: changed) so you need to rebake lightmaps

I understand.

It seems however that the problem remains that some models take a very, very long time to Generate lightmap UVs. This is an old issue that a Unity developer has acknowledged here on the forums (back in version 3.4). Some models take seconds, others take up to an hour.

Any ETA on this issue?

well, some models are slow to unwrap, yes. Honestly for now we dont have plans to “fix” it. As it will demand non-trivial amount of work.

Ok how about a progress bar, or at least not let Unity be completely unresponsive (not even able to maximize it properly) during the process?

Just stressing this again: If it’s feasible for you you might want to create a secondary UV channel directly when it comes to unwrapping your 3D model in your 3D application. That UV2 channel is baked into the mesh, it won’t change no matter which version of Unity you use, and you don’t need to go through that hour-long process of generating the lightmapping UVs in Unity every time you import an asset.

So what If I don’t have access to those models, and they are supplied by a customer, and have no license for that type of software? I work in Unity, not in Unity + 3D Studio MAX

Hmm, that’s bad in that case, I understand. I personally would make that a requirement for their work: Providing a secondary non-overlapping UV set in [0,1][0,1] space - that doesn’t help you now of course.

I’m not entirely sure if that exists, but - depending on the format of the meshes you use (fbx I guess) - maybe there’s some kind of tool around which let’s you copy the uv1 to uv2, provided that the uv1 conforms with the needs mentioned above. Or maybe you can import them into Blender (which is free) and fix them there. Just to make sure you don’t run into that same trouble with the next update again.

I can imagine that this might also work directly in Unity through scripting, but that’ll be some more work.

Thanks for the advice. From now on I will require the second UV set if am in a similar situation.

Why not open source this part on github, let the unity community have a good go at it.

Why not just open that part of unity regardless? I mean the entire mesh/import pipeline of unity should be fully open source so that the community can quickly add more support from different 3D packages and so on.

It’s clear this uv nightmare has persisted for over 3 years, so perhaps the community can do something.