Serious Lightmapping Issue with Seams

Hi Guys,

so i'm making a game where the level is built modularly, i have cubes that tile together to form a room. I was lightmapping the scene when i noticed that seams were popping up all over the place, so i decided to run some very basic tests, and what im starting to discover is that either the lightmapper is broken, or i'm not taking advantage of the right settings.

I broke a scene down to something very basic. The following is a screen shot of 4 planes side-by-side, lightmapped.



Notice that there are no seams, everything looks good.

For the next experiment, i added 3 more plane walls, forming a cube (with no top or bottom), on the RIGHTMOST plane. (you will not see the back planes because they are facing out.



I then proceeded to lightmap the scene again (Resolution 10 btw for all experiments, which is a very high resolution, i would not be able to lightmap at this size for the final project). Notice that 2 seams appear. One between Planes 1 and 2, and a much lighter seam between Planes 3 and 4.



After some research and more testing, i discovered that this is happening because the texture atlas that controls the lightmap is poorly designed/placed.



the top left square represents the far left plane. (Plane 1). The dark square next to it represents the plane on the far right that received no light. They are not only next to each other, but they blend the colors together, even though this definitely should not happen, because in the world they are nowhere near each other. This is what is causing the seam, and in fact there is a seam on the darker plane as well. If i paint over the 1 pixel border between the two squares, the seam disappears.



So the questions are, how can i create a padding between each of the squares so that this doesn't happen? is this fixable? Why is this happening?

Thanks for your help.

 

Check out this section of the manual for custom Beast settings that should help. In particular the TextureBakeSettings:

http://unity3d.com/support/documentation/Manual/LightmappingCustomSettings.html

 

yes I've read through that already, and everything else i could find on the issue before i made this post. When you create a custom beast setting, the bilinear filter and conservativeRasterization flags are already true, so there's nothing else to change there. However, if you set conservativeRasterization to false, it does get better than when it is true. But the seam i am showing above still exists.

 

Same problem here. The only "hacky" solution is create some padding in the lightmap UV creatively placing unnecessary geometry in your modular pieces.

Here's my floor piece: the 2 vertical quads are only used to create the padding in the UV...



I'm really hoping for a better way to handle the lighmap packing in unity

 

I need to bump this thread up. We are getting closer to our ship date and this still has not been resolved. Is there any chance that this issue will be resolved?

 

If you supply your own uvs can't you scale them down a bit so they have some padding? If you are generating uvs can't you adjust the padding/border size?

 

Actually, scratch that. It seems to me there is too much edge dilation going on. Reduce that by a couple of pixels.

 

Alexey,

You're thinking of the wrong kind of padding. In this example i'm using plane's supplied by Unity. You cannot alter the meshes on those planes. However, adjusted the padding on my cubes that i use in my actual game got the problem to be "better" but not "fixed". On the light map, they still sit next to each, and they still blend, exactly as described above. The problem is that the light mapper, not the objects, is improperly placing objects next to each other in the atlas, and then blending the lines between them, seemingly for no reason, causing seems.

 

I'm having this issue as well. I've tried using a few different settings for edgeDilation (in my scene's BeastSettings.xml) -- tried '3', the default, then '1', '0' and '8' but there was no impact on the seams. I also tried creating a plane mesh in Maya instead of using Unity's built-in plane, then in the "generate lightmap UVs" advanced tab I set the "pack margin" to 64 (the maximum), but that also had no effect. I could really use a tip as to what settings I should be experimenting with; this is all a bit new to me but I have to get rid of these seams. Thanks in advance for any advice!

Here's what my scene looks like (without lightmapping there are no seams between the planes):



And my BeastSettings.xml file, if it helps:

Code (csharp):

1.  
2. <?xml version="1.0" encoding="ISO-8859-1"?>
3. <ILConfig>
4.   <AASettings>
5.     <samplingMode>Adaptive</samplingMode>
6.     <clamp>false</clamp>
7.     <contrast>0.1</contrast>
8.     <diagnose>false</diagnose>
9.     <minSampleRate>0</minSampleRate>
10.     <maxSampleRate>2</maxSampleRate>
11.     <filter>Gauss</filter>
12.     <filterSize>
13.       <x>2.2</x>
14.       <y>2.2</y>
15.     </filterSize>
16.   </AASettings>
17.   <RenderSettings>
18.     <bias>0</bias>
19.     <maxShadowRays>10000</maxShadowRays>
20.     <maxRayDepth>6</maxRayDepth>
21.   </RenderSettings>
22.   <EnvironmentSettings>
23.     <giEnvironment>None</giEnvironment>
24.     <skyLightColor>
25.       <r>0.86</r>
26.       <g>0.93</g>
27.       <b>1</b>
28.       <a>1</a>
29.     </skyLightColor>
30.     <giEnvironmentIntensity>0</giEnvironmentIntensity>
31.   </EnvironmentSettings>
32.   <FrameSettings>
33.     <inputGamma>1</inputGamma>
34.   </FrameSettings>
35.   <GISettings>
36.     <enableGI>false</enableGI>
37.     <fgPreview>false</fgPreview>
38.     <fgRays>1000</fgRays>
39.     <fgContrastThreshold>0.05</fgContrastThreshold>
40.     <fgGradientThreshold>0</fgGradientThreshold>
41.     <fgCheckVisibility>true</fgCheckVisibility>
42.     <fgInterpolationPoints>15</fgInterpolationPoints>
43.     <fgDepth>1</fgDepth>
44.     <primaryIntegrator>FinalGather</primaryIntegrator>
45.     <primaryIntensity>1</primaryIntensity>
46.     <primarySaturation>1</primarySaturation>
47.     <secondaryIntegrator>None</secondaryIntegrator>
48.     <secondaryIntensity>1</secondaryIntensity>
49.     <secondarySaturation>1</secondarySaturation>
50.     <fgAOInfluence>0</fgAOInfluence>
51.     <fgAOMaxDistance>0.223798</fgAOMaxDistance>
52.     <fgAOContrast>1</fgAOContrast>
53.     <fgAOScale>2.0525</fgAOScale>
54.   </GISettings>
55.   <TextureBakeSettings>
56.     <bgColor>
57.       <r>1</r>
58.       <g>1</g>
59.       <b>1</b>
60.       <a>1</a>
61.     </bgColor>
62.     <bilinearFilter>true</bilinearFilter>
63.     <conservativeRasterization>true</conservativeRasterization>
64.     <edgeDilation>3</edgeDilation>
65.   </TextureBakeSettings>
66. </ILConfig>
67.  

 

First off, creating a ground plane with many default Unity planes at 200 triangles a pop is not the most efficient way to go about this. Create larger planes to achieve the same result. Now on to the issue...

This could be a mip map problem. Are the seams visible up close or only at this distance? If they're visible up close try increasing the edge dilation in the lightmap settings. Another thing to try is to adjust the bgColor in the Beast settings to a middle grey. Also, are you positive that the planes are precisely lined up next to each other? There might be small gaps.

That being said, lightmaps are a low resolution approximation of a lighting solution. Most, if not all, AAA games have lightmapping artifacts that are "covered up" by texture details. Lightmap artifacts that are noticeable on untextured geometry become indiscernible when the level is fully textured instead of simply a flat purple plane.

 

Yeah I also think it's from the mipmaps. Increase uv padding and edge dilation. (or as a test only turn mipmaps off for the lightmap to see if the seams go away).

 

Thanks for your insight. In this case, there won't be a ground texture but just that flat purple-ish plane. Is "increasing uv padding" a different process from setting the "pack margin" value in the 'FBXImporter->Generate Lightmap UVs->Advanced' setting? I've already increased that to 64 (the maximum). I've also tried increasing the value of "edgeDilation" in the settings XML from 3 to 8 -- am I just not going high enough?

 

racter, did you try turning mip maps off for the lightmap to see if it fixes that? You shouldn't do that in general, but it will help us narrow down the problem a bit.

 

Hm, how would I disable mip maps for the lightmap? I don't see a setting for that. thanks!

 

Go to :

Lightmapping -> Maps -> Click on the map (or if you have multiple you have to do that for each one).

When you click on the map the actual lightmap file will be highlighted on the project view.

Click on the lightmap on the project view.

Then on inspector do : Texture Type -> Advanced -> Uncheck Generate Mip Maps -> Apply.

It's not really advisable to do this though even if it fixes your problem. We are only doing it to see if the seams you get are mip map related or not so we can rule that out.

 

Hm, no change there. But I didn't know about this inspector before so I'll try experimenting with some more of these settings -- thanks!

 

Also, try changing the bilinear filtering to point. Everything will look like crap then, but the seams might disappear.

 

Hey thanks for pointing out that lightmap texture inspector. I changed the "max size" to 4096 in the texture importer now I'm able to get the whole scene's shadows at a good resolution without splitting the ground plane up into pieces. I assume there are some consequences about load time or memory footprint, but I'll just have to do some tests on other hardware see how it goes.

 

I need to pipe in here because I'm having the same problem and it seems that the suggested solutions so far have missed the point a bit. The problem of seams in the example images at the beginning of this thread is caused by Unity's UV island atlasing process and not the UV's themselves or anything that Beast has done.

The problem is that Unity packs the UV islands together with no padding between them. This is obviously efficient use of the lightmap space but when bright and dimly lit UV islands are packed next to each other (as in the original post) lightmap bilinear filtering alone will cause the seams because the dark and light pixels will blend together (especially at low resolutions).

I have figured out a slightly dodgy workaround which is this (requires meshes to have manually created UV2):

Step 1: Bake the whole scene as normal.
Step 2: Open up the models in your 3D package and uniformly scale UV2 down a smidge and re-export.
Step 3: Bake the whole scene again but with 'Lock Atlas' turned on.

This will give the effect of atlas padding because Unity will assume that the UV islands are bigger than they actually are.

 

Hi Alexey, yeah I have tried playing with the custom beast settings but nothing in there seems to completely eradicate the seams. With bilinearFilter and conservativeRasterization on, and edgeDilation set high, I still get a few seams which are pixels filtering in from a neighbouring UV island. From what I can tell it's caused by a combination of the UV islands being so close together (looks like only one pixel gap if any at all) and the fact that the edges of the UV islands never quite cover a whole pixel (which is what conservativeRasterization is supposed to account for).

Apologies if I have missed something obvious, but the workaround method I mention above worked for me.

 

Hi, This is actually a bug to do with the final texture packing of lightmaps that come back from beast.

I've got edge dilation of 0 and texture padding of 16 on the import FBX settings, and while there is a gap between all the UV islands in the UV block for each mesh in the imported FBX (due to the import), there are actually at least a few instances of textures overlapping each other in the final baked texure!... not just 'no gap between them', but literally overlapping

This needs looking at, ideally would be good if we could specify the pack margin in the LightMapEditorSettings, but at the least, it definitely looks like it's causing them to overlap when packing the textures. So, if you are unlucky enough to have a bright part of your scene packed next to a dark area, you will get dark pixels bleeding into the bright part, and bright pixels bleeding into the dark part. Thats even with bilinear OFF.. if you had bilinear ON (which you would), you would get much more seams/apparent leaking because all of the textures that are not overlapping have no margin at all between them.

For the overlapping problem, it seems like it might be calculating the packing on a 1024x1024, then scaling down those pack coordinates to the size of the final texture (in my case 1024x512)... so 2 pixels in the Y are mapping to 1 pixel in the image, causing the overlap. I can't see any overlaps in the X, thats why I think that's the issue.

The trouble is, because the images that come back from beast are merged together by unity, there is no way of making our own UV maps and atlas UV/scales from the beast images. Until that's fixed, there will always be a high probability of seams.

It's such a shame to have all these settings to reduce light leakage in the main UI / XML file, and then to have such a simple thing as this completely obliterating that effort!

Does anyone know if it is actually possible to get at the individual pre-packed textures? If that was a possibility it would be pretty straightforward to use Unity texture packing code with a margin and pack them properly...

Also, edge dilation is literally smearing pixels over the surrounding UV patches, its not expanding the area of each island and dilating the edges out to those new bounds, its just dilating them in place. You can check this by baking something with edge dilation of 0, then bake the same thing with edge dilation of say 16, and compare the position of the islands.. they are in the same place

Oh well ! The only workaround available (and its not really practical for anything other than a test scene), is to combine all your static meshes down to 1 and have an FBX with one massive mesh and a giant tpage, so that when you import, the UV islands are separated and then when you bake, the final pack will just be packing 1 texture.. only then can you be sure of not getting any seams Also you would need to have all the other XML settings correct and have edge dilation of 0...

Another alternative, assuming there were no actual overlaps, is to write a script that goes through the static objects in the scene, then by looking at the Lightmap Index, Tiling X, Y and Offset X,Y for each object.. use those to grab out the pixels from the lightmap texture to create a temp texture for each static object, and then repack all of those textures with a new margin, and recreate the Lightmap Index, Tiling X, Y and Offset X,Y for each static mesh again. That would fix the problem of stuff being packed too tightly that the OP described, but unfortunately there would still be this bug of the areas overlapping

I will file this as a bug and attach a tpage of clearly overlapping UV blocks, it should be a quick fix (hopefully!), maybe Unity could add a pack margin parameter aswell while they are at it ( please! )

 

Looked into this a bit more, and it seems that beast is doing the actual packing into 1 texture, but unity is passing the UV bias (offset into the texture) and UV scale (size of each island) to beast in an xml file, ie the packing regions.. but I haven't been able to find the xml file.

from the beast documentation:

So, the values being passed to beast from unity are wrong, causing the overlap. In theory it would be possible to do something like this:

- write a new program, called thebeast.exe.. this will be called from unity with the filename of the .xml file containing the info for baking the textures.

- have this program grab out the data from the xml, repack correctly and with a margin around each island and create a new xml file with the correct values for baking

- have this program then call the real 'thebeast.exe' with the newly created xml file.


( the parameters for each static object would then also have to be adjusted to fit this newly created set of textures )

so, quite a bit of work, but at least do-able...

But, probably a lot quicker for UT to just work out the values correctly and add a pack margin, should only be a couple of lines of code
With a pack margin, the edge dilation amount would also then make sense, you would set it to the same value as the pack margin and be able to fix mipmap problems at the same time. At the moment, the edge dilation is just bleeding out islands over each other, so you should definitely not be setting it to anything other than 0 ! It's defaulting to 3 atm, which, without having a margin of 3 to bleed into, is just going to corrupt your lightmaps.

For a small amount of work on UT's part to fix this, it would make a HUGE difference to the usability of Beast with Unity. We would finally have a situation where we could create lightmaps with no seams or leaking problems. At the moment, the best you can hope for is that by sheer luck, the leaks + seams are similar enough to not notice.

 

Excellent, would be so good to get this fixed!

btw, I've been through all the XML settings and tried changing pretty much every variable to get correct lightmaps, heres a working XML (apart from the packing problem, this setup seems to work ) ...

In FBXImporter settings, set Unity to 'Generate Lightmap UVs to ON, in the advanced part, put:
Pack Margin 32 (in my scene I have it at 16 because putting it too high seems to lock up on import depending on the scene)
Angle error: 1
Area error: 1

(then reimport your scene)

In the lightmapping tab, set to generate the XML, file, load that up and replace the whole file with this:

in the above, you'll want to put fgRays higher until any blotchiness is gone.

That XML has diffuseBoost set to 5 so that light bounces more around the room. If your lightmaps come out overly bright with this setup, try reducing it back down to 1. Also I have AO influence there set to off - this is only because with having so many bounces, the areas that AO would have darkened come out dark anyway as less light reaches them, theres no reason you can't put that back in as per your previous settings.

inputGamma is set to 0.45 as per the beast docs - this is for using standard LDR textures (that will have a gamma of 2.2. If you are using HDR textures, you will want to set this to 1.0... I think unity defaults this to 2.2, but it actually needs to be 1/2.2, ie 0.45). Not anything to do with leaking, it just means the lighting calcs will be more accurate.

Also, a new setting there is fgUseCache : Irradiance, this from the beast manual - speeds up the final gather part of the bake by caching rays.

Hope this helps someone out, messing with these settings can be very time consuming!!

A large part of reducing the leaks is in the UV calculation, and where objects are split... eg, if you had 2 walls intersecting each other, you have to make sure each of those 4 pieces have separate UV areas, otherwise you will always get leaks as whatever pixel value beast puts at the intersection pixels will be wrong for one of those walls.... setting the FBX importer to generate UV's will split the object according to the 'Hard Angle' setting and so will fix these type of problems. I have it set to 60 instead of the default 88, but in theory 88 is ok.

 

Thanks for the detailed analysis Chris. I wasn't aware of the overlapping problem! A fix from Unity which adds a padding option is exactly what I'm after. My dodgy workaround essentially replicates what a padding margin would give you.

Something that's quite useful with the workaround is that I can be selective with the padding. I only need to add padding to the worst offending meshes (I'm using hundreds of meshes which have their own UV islands but only about 10% of those have visible seams). A padding option would be great if it worked in the same way the 'Lightmap Scale' option currently works (on a per mesh basis).

 

Regardless of whether the padding parameter is exposed or not there should never be overlapping UV patches. Please submit a bug report and send me the case number, much appreciated!

Nope, we are using Beast's built-in atlasing, which directly takes the scaleInLigmap * resolution to determine the relationship between the world space size and the amount of texels covered by the instance.

We will add the padding option in 3.5. Unity always wants to give you a lot of flexibility and power, while keeping the amount of options low, so that they're quick to find and easy to understand. So whether the padding will be controllable in similar way to Scale in Lightmap in the first drop is still a bit up in the air... perhaps it will come with the Advanced tab.

Edge dilation is another issue. Currently it is very simple and pixels bleeding from one edge can overwrite the pixels bleeding from the other edge, hence effectively cancelling edge dilation on some instances. We'll work on a proper solution with the Beast guys (since Beast has more data to do it properly i.e. when it does the conservative rasterization). So stay tuned!

 

Hi, Thats great news Yes, I will submit the bug with the overlapping areas ASAP, trouble is that since I typed that original message, I've now got a new rescaled scene that isn't showing the problem... but it will come up again soon I'm sure, as it's not something that's rare, and I've got a few other scenes I can bake aswell... as soon as it shows up again I will submit the bug!

Having the pack margin will be a massive improvement, to be able to fix light leaks, and have proper mipmapping without leaking, regardless of the overlapping problem....even if it's only controllable from the XML file

 

Sorry to dig up this old topic, but the edge bleed issues are still kicking around.

Importing my own UVs rather than using Unity's (Import Settings) generated UVs solves the issue of light bleed every time (I use FlatIron in Max). Is there a problem with the UV generation?