Where/how is lightmap object mapping stored?

Unity Engine
1

Hi,

we’re baking lightmaps with pretty normal settings. We bake some scenes in batches of 2 (those that should have the same “mood”). The final bake looks alright on the source computer but after versioning all affected files into our source control (GIT), some objects look broken on other computers.

As you can see on the image below, the models are mapped to the wrong places on the lightmap texture. We checked all the files in the lightmap folder on both computers and they all have identical hashes.

Where is the blue mapping stored? Did we screw up versioning meta files / scenes?

Thanks :slight_smile:

3464670--274922--upload_2018-4-17_10-17-52.png
3464670--274922--upload_2018-4-17_10-17-52.png419×721 167 KB

Here are the bake settings:

3464670--274924--upload_2018-4-17_10-19-0.png
3464670--274924--upload_2018-4-17_10-19-0.png420×804 38.1 KB

2

Bump. Please we need to know this.

3

I’m having the same problem. The bake on generated lightmap UVs look fine on two of our computers, but is broken on the others. I tried to find the difference and everything seemed to be the same except the baked lightmap instance hash. The hashes on the broken objects were the same on the two working computers and not the others. This leads me to believe that the lightmap UVs were somehow recalculated on the other computers, but, like OP, I can’t seem to locate where the UVs or instance hashes are stored and manually override.

We are using PlasticSCM as our version control.

4

Happening to my team as well, this is a huge annoyance. Any solution?

5

It used to be that Macs and Windows did the Generate lightmap UVs differently, sometimes. Not sure if that’s the case any more.

A more permanent solution is to hard craft your own UV2 channels, so you don’t have to rely on generate lightmap UVs any more.

1 Like
6

Same problem here… between windows machines. Very annoying.
@AcidArrow I hope it is just the generation of the second uv set per object that is inconsistent but the layouting for the scene is working as expected?
We use the same object in several scenes and we can’t have already uniquely mapped geometry for that reason.

7

I was wondering whether or not this issue still occurs when you rebake the lightmaps on other computers? Or does this only occur when you open scene in question without rebaking first? Thanks.

8

This happens when I bake the lighting on one machine and then open the same scene (without rebaking) on another computer.

9

This only occurs when opening the scene that was baked on another machine without rebaking locally

10

Is there any solution for this?
I’m having the same problem in 2018.2 with Prgressive Lightmap.
Our team uses the cache server. Is it related to the problem?

11

My solution was providing my own lightmapping uvs (generated in maya or other)

12

As other in the thread have suggested, authoring custom lightmap UVs in a DCC tool would be the best approach. That being said, lightmaps generated by Unity should carry over across all platforms.

I have tried to reproduce the issue by syncing a small repro project over mercurial repo across Windows and Mac machines. The project was authored in 2018.2.2f1, yet I could not reproduce the issue.

If you still happen to experience the problem, please provide us with more detail so that we can investigate. Or better yet, submit a bug report via Unity’s bug reporting tool, and paste the bug link here - we’ll take a look at it right away. Thanks.

13

Happening to us as well. SOMETIMES, but not always, manually forcing a reimporting of the meshes fixes the problem. This is really becoming a time drainer. Has anyone come up with a solution. We run Unity 2018.4.3 but have seen this in 2019.2.4. Same behavior. Is there a way to turn GI cache completely off?

14

Have you tried disabling static batching?