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

Overlapping Generated Lightmap UVs

Discussion in 'Global Illumination' started by MiriamAteo, Mar 20, 2018.

  1. MiriamAteo

    MiriamAteo

    Joined:
    Sep 26, 2017
    Posts:
    17
    Hi all,

    I'm getting a warning on some of my assets that the lightmap UV is overlapping - the problem is, I'm already letting the Unity importer generate them for me. Is this possibly a bug in the importer? Or are there situations where the importer simply isn't able to generate proper lightmap UVs?

    I also get weird coloured splotches on my lightmaps, so it isn't just a spurious error message but really an issue with my UVs. See attached files for pictures of the error message and lightmap results.

    Edit: I think I found the problem. Unticking "Optimize Mesh" and "Weld Vertices" in the import settings makes the UV warning disappear. Still seems like odd behaviour by the importer - this makes me think the UVs are generated before changing the mesh geometry for optimizations, which makes little sense to me.

    Also, I am still getting random colourful patches in my lightmaps (bright red, green, teal). It looks like light bleeding and I tried upping the UV margin / lightmap padding. However, the margins are at 32 pixels, padding is at 12 texels and I'm still getting these patches. There is no coloured light anywhere in the scene, so I don't even understand where it would pick up those patches. Basically, there is no part of the lightmap where it should legitimately be bright red, I don't even have objects with red diffuse that could be scattering red light to nearby objects...

    Edit2: Nope, getting the overlapping UVs warning again even though vertice welding is still disabled. At this point I'm pretty much at a loss, I have no idea what I changed. I was playing around with different Hard Angle settings for the UV generation, but setting it back to the original value doesn't make the warning go away. Please help.
     

    Attached Files:

    Last edited: Mar 20, 2018
  2. MiriamAteo

    MiriamAteo

    Joined:
    Sep 26, 2017
    Posts:
    17
    Anyone?
     
  3. RichardSim

    RichardSim

    Joined:
    Dec 15, 2013
    Posts:
    14
    I see this too in the 2018.1 beta's - was looking around for a fix and found this thread.
     
  4. UnityLighting

    UnityLighting

    Joined:
    Mar 31, 2015
    Posts:
    3,866
    1. you must generate lightmap UV for your model

    2. You can increase Lightmap Scale to have higher resolution for certain models

    Send some screenshots from "Baked Resolution" mode fro m scene view
     
  5. Glowing_Slab

    Glowing_Slab

    Joined:
    Jun 19, 2015
    Posts:
    43
    I'm also seeing this problem.
     
    P_Jong likes this.
  6. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    568
    This may be an erroneous warning.

    But in some cases, the unwrapping is incorrect. (Especially if you are using Automatic unwrapping with a complex model.) You may get problematic triangulation, or some areas have not properly expanded. But even when you have made sure that it is 100% properly unwrapped, there may be other reasons. i.e. the way unity constructs the lightmap.

    Try either increasing your lightmap padding in unity, or the UV padding in the 3d software you use. IF your model is too complex, try breaking it down to pieces. i.e. avoid unwrapping an entire room with the furniture as a single lightmap atlas. There are many reasons this can happen. Try eliminating he most obvious by making sure your Lightmap UV page looks clean and simple. (Modular modeling helps a lot in that direction)
     
    askomorucha likes this.
  7. AlexanderZotov

    AlexanderZotov

    Joined:
    Mar 4, 2016
    Posts:
    7
    I have the same problem with ProBuilder asset. Even creating a simple cube causes this warning.
     
  8. MaxRoetzler

    MaxRoetzler

    Joined:
    Jan 3, 2010
    Posts:
    136
    Same issue in 2018.1.3f1
     
  9. P_Jong

    P_Jong

    Joined:
    Jun 14, 2017
    Posts:
    58
    Same issue in 2018.2.0b10 with creating a new shape (cube) with ProBuilder.
     
  10. kristijonas_unity

    kristijonas_unity

    Unity Technologies

    Joined:
    Feb 8, 2018
    Posts:
    1,080
    Hello! As others in the thread have already noted, Generate Lightmap UVs is not a sure fire way to remedy lightmap problems. For more complex meshes, the best practice would be to unwrap them manually in a 3D modeling package.

    If you want, you could provide us with a link to your project/scene so that we could investigate in detail. Thank you!
     
  11. SamRock

    SamRock

    Joined:
    Sep 5, 2017
    Posts:
    250
    I have having the same issue when using Progressive Lightmapper. I tried increasing or decreasing resolution, texel and generating UV map. Still same
     

    Attached Files:

    P_Jong likes this.
  12. Switch2803

    Switch2803

    Joined:
    Sep 29, 2017
    Posts:
    1
    I had the exact same issue - it was because I had a giant floor and wall mesh set to lightmap static, meaning the generated lightmap UVs for the important meshes were compressed to such a point that they overlapped.

    After unticking lightmap static for these large meshes and then re-baking, the issue was gone. Hope it helps someone!
     
    LaurieAnnis and louischen62 like this.
  13. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Hi MiriamAteo,

    I would recommend you to read this page which was written exactly for situations like yours:
    https://docs.unity3d.com/Manual/ProgressiveLightmapper-UVOverlap.html

    Unity's UV generator is not perfect. For example low pack margin values can cause UV islands to be close together. This may or may not cause an actual UV overlap - this also depends on your lightmap resolution. Annoyingly many variables are involved here (which is why the root cause can be several things).

    To solve the problem you must find out where and why there are overlap. Here's a gif where I show how to inspect a cube:
    uv-overlap.gif

    Some weird unrelated warnings pop up in the gif, but that's just because I am using a dev-version of Unity. The overlap warning did disappear, I promise :p
    Also I should note that changing the lightmap resolution is often not the best way to solve this problem as it increases memory usage. Ideally you want to adjust UVs, for example by increasing pack margin. But in order to make a good decision you first have to understand/see the overlaps.

    Your version of Unity maybe slightly different UI-wise, but you should be able to find the same panes/windows.

    I cannot explain why "Optimize Mesh" and "Weld Vertices" have an impact on the warning. I would leave them at the defaults unless you have a good reason to change them. They should not be needed to avoid UV overlaps.

    Regarding the unexpected coloring, this may be due to lightmap compression. Try turning it off and see if that helps (in Lighting window).
     
    Last edited: Aug 9, 2018
  14. Max_Bol

    Max_Bol

    Joined:
    May 12, 2014
    Posts:
    168
    Currently, I'm using Unity 2018.2.0f2 and I can guaranty that Unity, at least in that version, isn't able to manage its lightmap system properly.

    When I look at the OV Overlap, I'm seeing what's supposedly overlapping... and that's bogus at best.

    First, the biggest issues comes from how Unity manage the Lightmaps UVs islands alignments within the Lighting engine system.

    It does it on a per-mesh basic regardless of whatever Generate Lightmap UVs is active or not.
    If ALL the assets on the same lightmap are similar in size, the issue won't be seen much, but if the assets have quite the variation in sizes, then the UVs generated for the Lightmap will be screwed beyond saving regardless of the Lightmap Parameters set on the renderers in the scene.

    First, let's show an example of who bad the system manage the UVs, currently:

    Let's start with an example. I made this semi-modern medieval building by modeling (including a clean manually optimized UVs unwrapping) pieces that were assembled in Unity. The main reason why I did it as a modular assembly is because I can create multiple buildings with the exact same pieces.
    UvsOverlayIssues_01.png

    Now, with a Lightmap Resolution of 16 Texels per Unit (which is at least 2x more than I would normally allow to such a simple asset that isn't looked up as close )... Let's see the overlapping.

    If I the lightmap to use my own UVs (disabling the Generate Lightmap UVs option) :
    UvsOverlayIssues_02.png

    Ok. It returns us a warning that 110 object have overlapping UV's. We can see that some parts are overlapping in the Scene view. What if I use Generate Lightmap UVs then?
    UvsOverlayIssues_03.png

    Sacre-bleu! Isn't that worse?!? Now the warning tells me there are 143 objects with overlapping UVs.

    Now, let's see what the Lightmap UVs actually look like...

    The best case was with the option Generate Lightmap UVs disabled so let's start with it.
    UvsOverlayIssues_04.png

    Mmm. The light map basically used quite a small bit of the available space. Not only that, but you can see that some stuff is really tiny in the space.

    By the way, this test was done with Lightmap parameters set so that the big parts (walls and roof) are at "Medium Resolution" while the small parts (doors, frames, windows, etc.) are set at High Resolution. Fact is that I try with both at Medium and with the one I just mentioned and the size of the UVs on the Lightmap were identical in sizes.

    Let's take a closer look at the part, in the preview, that sounded like it was really overlapping in both cases : The windows.

    UvsOverlayIssues_05.png

    Okay, the UVs are like what I manually applied in the 3D software, but mirrored in both X and Y.
    (I added a screen shot of the UVs in the 3D software, the mirrored it in both X and Y to display the similarity.)
    The parts that aren't visible in Unity's Overlay Lightmap UVs but are visible in the 3D software are parts of another window model that isn't used in the scene right now.

    But, we can see the problem there. The UVs island on the Lightmap are too close. If I was in controls of those specific features, the 2 solutions would be to regenerate the UVs in a way that doesn't stick them as close as that or to allow the UVs island to take more space in the Lightmap so that there's at least enough space (padding) between each island, right?

    I tried many things by changing the Lightmap Parameters and allowing an higher resolution. Didn't change anything unless I put a resolution that is far too high. Raising the Lightmap Size didn't changed neither.

    On thing I do find quite strange is how the lightmap resolution in the Scene Lightmapping Settings has some extreme change in the way it handle the lightmap uvs. The change between 2 and 8 were noticable for all the sizes. Between 8 and 32, the changes mostly only affected the big assets like the walls and roofs while the small assets seemed to keep it really small in comparison. (There's maybe a 20% difference in size between 8 and 32 for the small asset while the big asset tripled in size.)

    When made it pass 34, suddently, the UVs island of the lightmap extend onto the whole area (filling that big black square spot you can see in the screenshot above.

    So, adding more available space in the UVs is, at most, impossible to predict unless I start raising the resolution through the roof just so that the original padding from the UVs can enough to avoid Unity to think something is overlapping.

    I'll post this now and will follow with another post as I can't post more than 5 image per post.
     
    Last edited: Sep 20, 2018
    trueh and Manuel_Fernandez like this.
  15. Max_Bol

    Max_Bol

    Joined:
    May 12, 2014
    Posts:
    168
    Now, what if I let Unity handle the UVs? Why was is even worse then? Shouldn't it be able to put enough space (padding) between the parts? The answer is: No. The way the generated UVs are made... basically works as great as if you let any 3D software handle the UVs by itself.

    Here what's the generated UVs looks like :
    UvsOverlayIssues_06.png

    Sure, it's "cleaner" than the one I made since the one I made also included 1 window that isn't used yet in the scene, but why did unity stick those UVs island so close? It's basically generating Overlapping UVs by itself, right?

    Now, I though "Well, it doesn't have enough padding. That's all." So I raised the Lightmap Padding in the Scene's Lighting's settings. Well... that didn't work because that padding setting actually only affect the space between the WHOLE object in the Lightmap and not the islands generated by the Generate Lightmap UVs option.

    Well, since that Padding option in the Scene Lightmap option is useless for this problem, let's look at the Generate Lightmap UVs advanced option...
    UvsOverlayIssues_07.png

    Nothing much that looks like padding. Maybe that Pack Margin... If I raise it, what is it doing?
    Well, it's "kinda" like a padding option, but it comes with one really big problem which you can see here :
    UvsOverlayIssues_08.png
    That's if I set the Pack Margin at 64 (maximum).

    As you can see, it did add padding between the UVs island, but... it did it so by reducing the size of the UVs.
    Even so, Unity still see Overlapping UVs ieven in those case. Sure, the warning dropped at 72, but that makes the UVs a bit too compacted.

    The issue clearly comes from how Unity Lightmap system sizes things up.

    Also, I tried to force the small asset onto their own Lightmap, but didn't worked because, in the end, the lightmap size and Lightmap Resolution's texels per unit is what's determining the resolution of each part in a generic way. You can't have 1 part with an higher resolution than another part or, at least, it doesn't allow me to do so regardless of the settings I apply.
     
    Last edited: Sep 20, 2018
    trueh likes this.
  16. rob8861

    rob8861

    Joined:
    Sep 25, 2015
    Posts:
    86
    @Max_Bol this is 100% reproducible on my end, on pretty much every unity version. I honestly have no clue how anyone can fully eliminate 100% of the UV overlapping warnings on complex geometry (not cubes). To add to what the OP has already stated above, I was even able to reproduce this behavior using only Unity's primitive geometry where you have no control over the UVs.
    I am by no mean a computer lighting expert but this system is not very user friendly. 99% of the times, I see no issues such as bleeding etc, yet Unity still complains. In certain cases where the geometry is very simple, increasing resolution solves the overlapping issue. however, when the models are more complicated in nature , tweaking the settings will not ( or in my case never) clear 100% of the warnings.

    This issue does not exist in Enlighten so why is it such an issue in Progressive?
     
  17. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Thank you for that detailed analysis.

    Let me first say that I understand your frustration. The current behavior is confusing and difficult to interpret. We are aware of it and are working to improve the situation. Let me try to address some of your comments.

    The UV overlaps that Unity warn about refer to charts/islands that are too close together in the discrete lightmap, i.e. separate charts that sample from same texels. This means that you can pass in a UV layout without overlaps, and the warning may still fire if the final lightmap has charts that are too close. This may happen for example if lightmap size is too low. Our chosen wording "UV Overlaps" is misunderstood by many (with good reason) and we will probably rename it.

    The reason you see more overlaps when using Unity's built-in UV Generator is presumably that you set the Pack Margin setting relatively low compared to the lightmap size (256^2, 512^2, 1024^2, ...). Increasing the Pack Margin should lower the amount of overlapping texels, but it will not necessarily eliminate it. Pack Margin controls the amount of space between "UV islands" in the UV layout. Another reason may be that you used a low Light Padding value in the Lighting settings window. This controls amount of space between object.

    Even if your UV layout happens to be perfect (generated or hand-authored), it may not work for particular lightmap resolutions/sizes. Charts may end up sampling from same texels because resolution is too low even when there are no overlaps in UV space. All these interdepedencies makes it very hard for the user to address the overlap issues you are facing.

    You may argue "Why doesn't the UV Generator just calculate a proper spacing?" The primary problem is that the proper spacing depends on the chosen lightmap size and this information is scene-specific and therefore not available to the UV Generator (which is part of the mesh importer). Technically we could provide that information but this is not trivial since that would mean that the imported mesh asset depends on a particular scene and thus cannot be used in another scene. Also, it would mean that the mesh asset (and its UV layout) should change whenever you change the lightmap sizes. There are ways to solve this of course, but I am just trying to illustrate it is not a trivial matter.

    I cannot guarantee anything specific but this is what we are talking about so far:
    * In the short term: Improve wording and/or UI of "UV Overlap" to reduce likelihood of misunderstanding.
    * In the long term: Implement alternative packing algorithm that will eliminate texel overlapping altogether.

    Additionally, we already added a link to a docs page (mentioned below) next to the warning in the editor. I think this was part of 2018.3.

    You presumably already did this, but if you may find this manual page that describes the problem interesting:
    https://docs.unity3d.com/Manual/ProgressiveLightmapper-UVOverlap.html
     
    Last edited: Oct 12, 2018
  18. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,631
    I don't know how feasible/easy would be to implement this, and I fully admit that there could be implications and complexities that I'm unaware of, but could the UV overlap/bleeding warning give us a percentage of how much larger the padding should be to not be overlapping/bleeding?

    I hand author my UVs and also mainly use unique meshes per scene (so I could potentially fine tune the padding to be almost perfect for the one scene and lightmap res they are used) and I usually know how much padding I already have, so a percentage would save me a lot of "let's repack this with slightly larger padding and see if Unity stops complaining". I mean, I can take a look at the resulting lightmap and make a fairly educated guess, but that still leaves a lot of trial and error, so a percentage would be nice.

    Just an idea.
     
    JamesArndt likes this.
  19. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Hmm, interesting idea. Thanks. Calculating such a percentage seems a bit daunting. It depends on a bunch of different settings and scene contents. I am not sure but I think that it would be more difficult to calculate such a percentage than it would be to simply make layout that is guaranteed not to overlap to begin with (which is already on our todo list). So I think it would be more wise to spend our time on that instead.
     
  20. RickshawDerpyDerp

    RickshawDerpyDerp

    Joined:
    Nov 6, 2018
    Posts:
    25
    I made all my own UV's specifically to avoid this problem and Unity generated new lightmap UV's for an object anyway, even though I marked it not to. I am using a simplified mesh with no UV's as a mesh collider and wonder if it generated UV's for that and is basing the Lightmap UV's off of the collision mesh?
     
  21. salex1

    salex1

    Joined:
    Jul 9, 2015
    Posts:
    29
    Well, I'm making my own assets and UV maps also, and try to do as clean as possible but unity still has some real problems in some places with Lightmap overlapping. The more complex object is, the more problems I have! In other hand the enlighten doesn't have that problems at all! Problems only occur in progressive lightmaping..I hope unity will find some solutions for this because it's a big problem and as i see it's still same situation in 2019
     
  22. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Colliders should not have any affect on the lightmaps, so I don't that is to blame. Given the information given it is hard to diagnose your issue. Here are some things you can try/consider:
    • Check your Mesh Importer settings whether "Generate Lightmap UVs" is actually checked or not.
    • Is it possible that your UVs are actually used, but they are just scaled/translated into the lightmap by Unity? That is expected behaviour at the moment (for better or for worse).
    Without more information about your project it is difficult for me to be anymore specific. If you can recreate your problem in a simple new project and then use the Unity menu's Help > Report a Bug feature to send it to us, that would be great. This would definitely provide us with the information needed to thoroughly look into your issue.
     
  23. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Enlighten makes sure that charts are placed sufficiently far away in lightmap space, so that texel bleeding (overlap) cannot happen. Unfortunately, the progressive lightmapper does not do this. We are aware and trying to solve this. Given the current state of Unity, we need to fix several smaller issues to fix the overall issue.

    The first improvement will be in the Mesh Importer where we will introduce a new setting called "Minimum Lightmap Resolution". With this setting you can specify the intended lightmap resolution with which an object is intended to be used. The Mesh Importer will then generate UVs that are guaranteed to have no bleeding when using that lightmap resolution (or higher). Of course, this does not address your issue directly but we try to also find time to look into that as well (but one thing at a time). When this new setting becomes available (presumably 2020.1) you may want to reconsider to use auto UV generation.
     
    Last edited: Aug 8, 2019
    bman1907 and Subliminum like this.
  24. salex1

    salex1

    Joined:
    Jul 9, 2015
    Posts:
    29
    Thank's rasmusn for good news! It's nice to hear someone working on that problem. I hope some progress will be made with 2020..because this overlapping situation on import is really bothering me...on some bigger projects, those overlap errors on import can be annoying or maybe unity could get those warnings somehow out of sight
     
    rasmusn likes this.
  25. newguy123

    newguy123

    Joined:
    Aug 22, 2018
    Posts:
    1,248
    From an AEC perspective:
    While you're working on the Mesh importer, can we get support for Autodesk Physical Material Import via FBX please? According to Autodesk this information is already saved during export from 3ds Max so it is in the FBX, it's up to Unity to get the information out of the fbx. Im aware that currently only standard and stingray materials are supported (Directx shader with stingray loader). But the ability to support Physical Material will open up the door to so many things from existing DCC workflows that we can finally get a proper import INTO Unity.
    Shader graph is great and all, but why recreate stuff that can just be importewd straight?
     
    Jelmer123 likes this.
  26. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Thanks for the suggestion! I am definitely no expert in AEC and/or model formats so I am afraid I cannot help you with this particular issue. However, this sounds a bit like what the new Unity Reflect is all about. If you haven't already, I recommend you check it out.

    Also, I recommend that you post your suggestion in the Assets sub forum. The sub forum of this current thread is about GI/lighting, so I think you get better exposure over there.
     
  27. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Just wanted to let you know that the Mesh Importer improvement described earlier, will indeed be part of 2020.1 (as I hoped :)).
     
    JamesArndt and salex1 like this.
  28. newguy123

    newguy123

    Joined:
    Aug 22, 2018
    Posts:
    1,248
    Errr no, Reflect is NOT about that and can't do what I need.

    Thanks I'll take a look at the subforums
     
  29. soleron

    soleron

    Joined:
    Apr 21, 2013
    Posts:
    568
    Those having "overlap" problems never going away, simply ignore them.
    I know it sounds like bad advice but if you are certain you have unwrapped properly simply ignore this warning.

    For those with more complex meshes, make sure you decrease the Hard Angle, (this concept is very similar to the smoothing angle) I typically decrease the auto UV generation "Hard Angle" to 30 if I need to make sure the UVs are broken in proper chunks, and increase your "Pack Margin" to at least 8 pixels. (the number is pixels). Even if you perfectly unwrap in your 3d software this warning will still come, Unity automatically packs that UV in a larger atlas so no matter what you do, you will still get that message. I was told by members of the Unity, team we were troubleshooting this for 10-15 days the response that I got was what I just told you. "just ignore it".

    (As long as you made sure that you have your UVs right of course or that you broke down your mesh UV in Auto, properly.)

    I would prefer that Unity didn't show that message because I know there are so many OCD people who want a clean console even from minor warnings and get frustrated, but such is life with Unity. Every engine and every tool has its quirks. Deal with it. :)
     
    blueivy and DamurStudio like this.
  30. neptoonism

    neptoonism

    Joined:
    Aug 19, 2019
    Posts:
    19
    Thanks rasmusn, I was very confused about the chunky corrupted look of my baked lightmaps (using either cpu or gpu progressive lightmapper) and in my case it wasn't the overlapping uvs of the model rather it was the overlapping uvs from the generated lightmap which were causing bad results. Apparently in my case it was the default model import settings which set the 'pack margin' to a calculated amount which caused it.

    note - the real cause of the bad lightmap was the scale of the model when it was exported from blender - it wasn't overlapping uvs after all

    This is what that looked like.using the 'calculate' setting - blocky, chunky and corrupted baked lightmap textures.
    upload_2020-8-8_11-54-30.png
    upload_2020-8-8_11-53-6.png

    when I unchecked 'calculate' the default margin of 4 fixed the problem immediately
    upload_2020-8-8_11-59-46.png
    upload_2020-8-8_12-0-45.png
     
    Last edited: Aug 25, 2020
    miracletechteam1 and rasmusn like this.
  31. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    That is very interesting, thank you very much for letting us know about this.

    Can I get you to create a bug report containing your mesh? You can do that by creating a minimal project (containing the problematic mesh) and then clicking Help > Report A Bug in Unity's top menu. That would allow us to take a look at what is going on.
     
  32. neptoonism

    neptoonism

    Joined:
    Aug 19, 2019
    Posts:
    19
    @rasmusn Sure - I did that, it's Case 1269657. Definitely works fine using 'manual pack margin' but maybe it's how blender packs uvs (very close together) or bakes textures that might be resulting in the overlapping lightmap uvs - really not sure.
    Thank you!
     
    rasmusn likes this.
  33. neptoonism

    neptoonism

    Joined:
    Aug 19, 2019
    Posts:
    19
    @rasmusn - yeah, and actually I think I know why the model has that patchwork of light and dark spots - it's because some of the normals are facing in the wrong direction (hence dark and light spots). I supposed the real question is if having 'generate lightmap uvs' checked or 'margin method' setting was still using the incorrect normals.
    If I flip the inward facing normals on the model I'm pretty sure the patchy lightmap would've been avoided. ;)
     
    soleron likes this.
  34. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    That's good to know, thanks. I think you can easily test your hypothesis by letting Unity generate the normals. In the ModelImporter you can set Normals = Calculate to try it out. Please let me know if this resolves your issue. You probably need to rebake lighting as well.
     
  35. neptoonism

    neptoonism

    Joined:
    Aug 19, 2019
    Posts:
    19
    @rasmusn - I didn't notice that option - I tried it out and rebaked the lighting - didn't affect the patchy lightmap but when I exported the model from my scene (using the fbx-exporter preview package) and checked it out in blender it really was cleaned up. Maybe the normal direction isn't related after all.
    Using that setting is a great way to get normals facing out, for sure! I appreciate it!
     
  36. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    @bingbing642 We have now had time to look into your bug report. We investigated your scene and found that the Calculate method is actually working as intended. The idea with the Calculate margin method is that the user specifies the minimum lightmap resolution and min object scale with which the associated model is expected to be used. However, in your scene test scene the Min Object Scale was set to 1 in the ModelImporter but the actual object scale used in the scene was 0.0254 (see game object transform).

    This means that the actual object scale was smaller than the value specified for the Min Object Scale setting in the mesh importer and this leads to a violation of the assumptions made by the ModelImporter's UV unwrapper.

    If we set the game object's scale to 1 the unwrap/bake worked as expected. Alternatively, you could set Min Object Scale = 0.0254 in the ModelImporter.

    This being said, we can understand why you and other users have a hard time understanding how to use this feature. Our docs and UX are simply not good enough. Firstly, the 2020.1 docs (https://docs.unity3d.com/2020.1/Documentation/Manual/LightingGiUvs-GeneratingLightmappingUVs.html) does not contain information about this feature. Secondly, the information available in 2020.2 docs are not particularly good, https://docs.unity3d.com/2020.2/Documentation/Manual/LightingGiUvs-GeneratingLightmappingUVs.html. We have created tickets to ensure that the docs are improved in this area.

    @bingbing642 Let me know if this resolves your issue and if your have further questions :).
     
  37. neptoonism

    neptoonism

    Joined:
    Aug 19, 2019
    Posts:
    19
    @rasmusn Ah, you're right! The model came out that way from blender and by changing the fbx export settings I was able to get it right. The strange lightmap is easy to reproduce both when the model is scaled way too small or way too big.
    Actually I wouldn't have come across this if I'd exported from blender at a sensible scale - really great that you pointed me in that direction because I can see that I did the same thing with some other models.
    The explanation makes perfect sense - I really appreciate the attention and the scaling thing is something I'll keep in mind.

    Looks like I didn't need to 'generate lightmap uvs' anyway once the scale was right.
     
    Last edited: Aug 25, 2020
    rasmusn likes this.
  38. unity_QJ7RazXzghZCzA

    unity_QJ7RazXzghZCzA

    Joined:
    Jul 9, 2021
    Posts:
    104