Lightmapping breaks when sharing lightmaps built with different build settings

These is what I do:

Generate lightmap on a Windows machine (fast CPU, Build settings: PC/Mac) with the Beast lightmapper.

Commit lightmaps and scene to SVN (I have Unity Pro)

Update project from SVN on a Mac (slow CPU, Build settings: iOS).

Load the lightmapped scene and the lightmaps are broken (geometry get weird shadows, like the UV2 coords were wrong or something like that)

The same thing happens if I build the lightmaps on the Mac and load them on the Windows machine.

Is there any way around this issue? Does somebody experience the same thing?

Thanks!
Jorge

 

Uhhhh good to know... luckily this seems not happening on Unity Android

 

I'm trying to strip down a sample to send you with the bug, hold on.

 

(Case 390505) Lightmapping is broken on some objects

Thanks!
Jorge

 

Hi,

We've found the same problem. I think it's an important bug. If you work with several designers (freelance or in house) working in PC and you have to deploy to iOS, then you've got a huge problem. Is there any workaround to remap the uv generation?

Best regards,
Roberto.

 

If you create your own UV2 unwrap then it should be loaded the same on both platforms.

 

Perfect!
Thank you

 

I uploaded a simple object that demonstrates this : Case 404489

Would really love to see this bug gone in the next version.

And I didn't put this in my report, but for some reason it seems the bug happens when polys are rotated 45 degrees. (not sure if it's relevant)

 

UPDATE: Unity 3.4 :

From this line I assumed the bug was fixed and while the lightmap is less all over the place than before, it still is wrong at places, so baking on WIN and using a MAC afterwards is still impossible. It seems the bug report I made is still open, so I'm guessing it's not considered as being completely solved yet.

In any case, I made another scene that demonstrates this and made a new bug report: Case 413529

 

Hi Alexey,

I don't mean to hijack this thread too much but could this be related?
http://forum.unity3d.com/threads/98362-Unity-3.4-Beast-asigning-lightmaps-to-dynamic-objects

Also, have you managed to open a bug case for this ? I'm worried because I submited a bug report to your bug submission email (workstation is offline so I did a manual submision) a week ago but I have no idea if you got it...

Thank you.

 

Thank you Alexey, sorry for the hijack...

 

I also have this problem with textures when using SVN on Windows and Mac.

how can you save the uvs with an editor script?

 

Is anyone still experiencing this in 3.5? I had some very minor issues with this on 3.4.2, but it's even worse in 3.5. I have rebuilt all my lightmaps and reimported all my fbx files.

 

We have experienced the same problem until we figured out that one of our Mac workstations has Unity 3.5.0f1 (RC) installed. "Check for updates" says that it's up to date, but obviously it's not. After updating to Unity 3.5.0f5 the lightmapping problems disappeared.

 

That would have been great. But this is in 3.5.0f5.

 

Hi Joakim, could you please submit a bug report and attach a small project that includes the erroneously lightmapped objects?

 

Is this still an issue in the latest version, we have quite a few scenes and have a mix of win mac machines we're building on.

 

Anyone?

 

Hello ....?

 

We think it's very reliable between the 2 platforms atm, but that doesn't mean you couldn't run into a corner case. Have you tried it yet yourself?

 

We had problems a couple of months ago with the first 3.5 but haven't tried it since

 

Ok, did you do the usual thing of reimporting the meshes and rebaking the levels? If you're seeing massive differences between the two platforms then you probably didn't do this step. If you're seeing small differences on single objects then we'd very much like to see the meshes.

Also, please remember that unwrapping the secondary UVs does not have to be done in Unity in order to work with Beast. You can import the secondary UVs from your 3d app. So if you have one or two offending meshes then the quickest workaround is to create these UVs externally.

But again, we need these offending UVs to track down corner cases so bug reports are much appreciated.

 

From my observations this has _not_ been fixed in 3.5.2

See my reply to this thread

 

From my experience, this has not been fixed for 3.5.3...

rebaking lightmap is not easy sometimes because it can involve significant setup overhead

 

The testcase I mentioned in the previous page should be still good, it still breaks lightmaps in 3.5.6. It seems the bug report is closed for some reason. Maybe I'll make a new report with a new scene.

 

Is there any way to view the generated uvs inside the Unity Editor? It will help a lot to discover case error for this bug.

 

You can display them with something like this :

Code (csharp):

1. void UvDisplay( MeshFilter meshFilter )
2.     {
3.         if( meshFilter != null )
4.         {
5.             Mesh mesh = meshFilter.sharedMesh;
6.             if( mesh != null )
7.             {
8.                 if( mesh.vertices != null )
9.                 {
10.                     EditorGUILayout.LabelField( "uv count " + mesh.uv.Length );
11.                     for( int i = 0 ; i < mesh.uv.Length ; ++i )
12.                     {
13.                         Vector3 v3Uv = mesh.uv[i];
14.                         EditorGUILayout.LabelField( "Uv " + i.ToString( "000" ) + " : " + v3Uv );
15.                     }
16.                 }
17.                 else
18.                 {
19.                     EditorGUILayout.LabelField( "No uv" );
20.                 }
21.             }
22.         }
23.     }
24.  
25.     void Uv1Display( MeshFilter meshFilter )
26.     {
27.         if( meshFilter != null )
28.         {
29.             Mesh mesh = meshFilter.sharedMesh;
30.             if( mesh != null )
31.             {
32.                 if( mesh.vertices != null )
33.                 {
34.                     EditorGUILayout.LabelField( "uv1 count " + mesh.uv1.Length );
35.                     for( int i = 0 ; i < mesh.uv1.Length ; ++i )
36.                     {
37.                         Vector3 v3Uv1 = mesh.uv[i];
38.                         EditorGUILayout.LabelField( "Uv1 " + i.ToString( "000" ) + " : " + v3Uv1 );
39.                     }
40.                 }
41.                 else
42.                 {
43.                     EditorGUILayout.LabelField( "No uv1" );
44.                 }
45.             }
46.         }
47.     }
48.  
49.     void Uv2Display( MeshFilter meshFilter )
50.     {
51.         if( meshFilter != null )
52.         {
53.             Mesh mesh = meshFilter.sharedMesh;
54.             if( mesh != null )
55.             {
56.                 if( mesh.vertices != null )
57.                 {
58.                     EditorGUILayout.LabelField( "uv2 count " + mesh.uv2.Length );
59.                     for( int i = 0 ; i < mesh.uv2.Length ; ++i )
60.                     {
61.                         Vector3 v3Uv2 = mesh.uv2[i];
62.                         EditorGUILayout.LabelField( "Uv2 " + i.ToString( "000" ) + " : " + v3Uv2 );
63.                     }
64.                 }
65.                 else
66.                 {
67.                     EditorGUILayout.LabelField( "No uv2" );
68.                 }
69.             }
70.         }
71.     }

I do since 2 days ago to check some assets in my scene cause this lightmap bug :x. And at this time, no solutions for me :/

 

Well, I kinda see where this could be useful, but it may be much better if we can "visually" see the uv layouts , something like in Maya or Max.
So we can easily compare two and just be able to tell if two auto generated uvs done by Unity Windows and Unity Mac is different. Sorry, I am TA, but still an artist

 

oh, my bad :/

I display uv with shader too. But I don't know if it's what you want ?

 

I am not sure whay you mean displaying uv with shader exactly. Are you saying that you can display uvs similar fashion to what you normally see in the uv editor in Maya?

 

Something like this :
http://docs.unity3d.com/Documentation/Components/SL-VertexProgramInputs.html

But I don't think it's what you want. You probably say draw some line on the mesh to see the vector direction or something like that ?

 

No, that is not what I ment.

I was refering to something like this :

http://www.benbathen.com/images/TutorialImages/ProjectionHandles.jpg

 

This issue is really getting to me at the moment,... we have about 22 scens having to rebake light map due to this uv mismatch between 2 platforms.

Any progress on this one?

 

Sorry for reviving this thread but I'm in the same boat as Castor76... We have many scenes and re-baking them every time we have to commit a change from PC to Mac is a huge waste of time.
It takes roughly 5 min per scene to rebake on the Mac, so with 10 scenes, it's almost one hour wasted... It used not to be a problem on Unity 3.4 - but it's happening all the time on 3.5.

 

When you upgraded to 3.5 did you re-import all the meshes? The UV unwrapping algorithm gets refined with each release and re-importing is the only way to make sure that they're the same on both platforms.

And of course the other way to avoid this problem 100% is to create your secondary UVs in your 3d app.

 

Alexey fixed the issues wholesale in 4.0 by running the same code on Windows and Mac.

From the Unity 4.0 release notes: Lightmapping: Fixed "Generate Lightmap UVs" difference between Windows Mac!

So go ahead, get Unity 4.0, bake the lightmaps on whichever machine you want and see them look nice and pretty on all the others.

 

I am not sure if I am correct but to me, this is BUG. Not a feature request. So having to upgrade just to be able to get bug fixed sounds like totally wrong approch. Why do we have to pay extra for bug to be fixed? We have few 4.0 licenses, but I am almost sure that everyone in Unity community will agree with me.

 

The reason this issue was fixed in 4.0 and not before is that the fix piggy-backs on some tech that allows us to run exactly the same code on Windows and Mac. The tech was developed to support a new feature and porting it back to 3.5 is simply not feasible.

 

I can't confirm this fix. Just baked light maps on a windows machine, transferred them to a Mac, and all the lightmapping UVs broke.

 

I see, so basically a bug which existed 3 years will finally not be fixed unless you spend 1500 x number of platforms. Now while I don't blame anyone, and this issue currently does not affect me, I can see how this is going to harm unity.

1. when interviewed, a developer may not be singing unity's praises: for example, instead of singing unity's praises the comment will be: I was forced to upgrade because they wouldn't fix a 3 year old bug in 3.x. This is a simple factual statement without hype. It is the honest truth for some people.

2. people will be able to throw this back in unity's face, repeatedly. This will also harm your business.

Personally, I'm no going to do those behaviours. But I can see how it can easily occur and I suggest for the future going forwards, with 4.x you do NOT have ANY outstanding bugs lasting longer than 6 months. If a bug lasts longer than 6 months IMHO you're not doing your jobs.

OK?

It's a case of pulling the finger out and doing what needs to be done. As I've said, it doesn't affect me and I'm nonplussed. But going forwards you DO need to get a grip on bugs and nail them. Your competition won't wait 3 years to get one over you Unity is my platform of choice and I want whats best for you.

If a bug doesn't fix, a real programmer throws the code in the bin and starts from scratch. My grandfather said once: "nothing good comes of a bad start".

 

I totally agree with hippocoder with this one.

Unity is basically saying that because the bug is fixed using new tech base on version 4, pay and use version 4 for the bug existed in version 3 for very long time.

Now even Unity , has to admit that something is pretty wrong here. Advertised and Known feature of software was not working properly because of bug (or whatever reason) and then almost officially declearing that this is NOT going to be fixed because we moved onto another version.

But let me tell you, lots of more people are still using version 3 than version 4. I am not working for Unity and I can certainly say this for sure.

If this was a feature request, then I have no problems with Unity not putting their resources. And this is not a small issue, but real, time consuming work pipe line altering , breaking issue for countless studios.

 

I work at a large studio that's been working on a project for the past year. We can't upgrade to v4 simply due to good development practice for maintaining stability. We're currently experiencing the light-map issue on a few objects in our scene and is a cause for a lot of hassle. I have noticed that objects made from maya tend to be a bit more prone to this sort of issue than those made in max - but it is not the rule. There tend to be differences in the lightmap in a wide range of objects made from both packages at vary degrees of severity.

Are there any plans to back-port to 3.5? This is desperately needed. If the work-around is to hand-author the second UV set for those objects, will they still be packed into a condensed lightmap with the rest of the scene?

 

While I do generally agree that Unity should concentrate their resources on making version 4.0 better, this case is special because this is such a critical case. I feel that this bug is as important as dynamic batching not working with normal map. Very important feature of Unity simply not working as it should.
Whatever work around we can use to get pass the issue, this is simply not the best of practice from Unity.

 

I have to agree with Hippo and everyone here. A bug that existed for 3 years haven't been fix on 3.5 and now requires $1500 to be fix on v4. It is irresponsible and inexcusable. Unity you disappoint me.

 

For the record, I also submitted this bug in May 2012.