Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity's lightmap atlas packing UVs with overlap on bake

Discussion in 'Global Illumination' started by Acegikmo, Sep 7, 2016.

  1. Acegikmo

    Acegikmo

    Joined:
    Jun 23, 2011
    Posts:
    1,294
    Hey!
    I'm having some issues with Unity's lightmapper. I have a set of procedurally generated walls/floors/ceilings, which are UVd in code. The UVs are generated for both UV0 and UV1, and I presume those models will use UV1 for lightmaps. The UV1 of each individual mesh looks fine. It's packed into the 0-1 range in UV space, so it should all be good. However, on bake, the lightmap gives a rather odd result. All shells are very spread out, and some, more problematically, overlap.

    I tried mixing them with Unity's cubes, just to see what would happen. The shells from the procedural meshes overlap the cube shells as well.

    Just one example of how it looks in the atlas:
    LM issues.png

    In the picture above, there's a bunch of Unity cube shells, and then, somehow, a shell from one of the procedural walls overlapping them.

    All mesh renderers have the default LM settings, and the project/bake is using standard UV baking too. I'm baking non-directional LMs, if it matters.

    Another image, without the Unity cubes. Overlaps highlighted with the blue circles:
    WallLightmapBug.jpg

    Any help would be very much appreciated :)

    Cheers
     
  2. Acegikmo

    Acegikmo

    Joined:
    Jun 23, 2011
    Posts:
    1,294
    It seems as though the lightmapper is using uv0 for lightmapping, even though I did assign something to uv1.

    I managed to get it somewhat working, though in a very hacky way.

    When I generate the mesh, I now do:

    1. Clear mesh
    2. Generate verts and triangles, assign to mesh
    3. Call Unwrapping.GenerateSecondaryUVSet( mesh );
    4. Re-assign the old verts and triangles, theoretically cancelling the last command

    This makes it work, somehow. I really have no idea how this is even possible, since, when decompiling, it doesn't seem as if the GenerateSecondaryUVSet modifies the mesh itself in any other way, apart from triangles and uv1. The serialized data of the meshes don't appear to change either.

    I'm quite lost as for why this is.

    Edit: Seems to have been a false positive. The UVs are still much better packed, but I'm still getting some overlap. Strangely though, removing the hack keeps them neatly packed, but still has the overlap too.
     
    Last edited: Sep 8, 2016
  3. iamthwee

    iamthwee

    Joined:
    Nov 27, 2015
    Posts:
    2,149
    For the love of god tick the generate lightmap uv check box.