[bug] Lightmap color continuity issue

Hi HynoticShark,

Can you provide more information on what’s going on? Can you provide screen shots as well? Is it only caused by the directional light?

Thank you!


If you’re able to make a small scene that can replicate the issue you can upload the project file here. That would allow me to look at the problem much quicker. Just provide the link here. Thanks!

Sure thing Tim, will do that but i highly doubt the file is going to be smaller than 512kb. Do you know a site that is not blocked by your firewall where I could upload it?

dropbox is a good free sight to do so.

Before you try that, Is the offending object that is having light cast through it a plane? I’ve been playing around with the lighting and if you have a plane with a only one side displaying the material, if there is a light behind that mesh it will not recognize it since there is no material for it reflect off of. You can adjust the settings in two places for this. In the mesh details panel you can select “Cast Shadow as Two Sided” or in the material editor properties you can check to have the material be “two sided.”

This may solve your issue. if it does please post back here for confirmation. If you’re still having the problem I’ll gladly see if there is something I can see in your project.

Thank you!


Thanks Tim. No, the offending object is a box. What is happening is the indirect lighting (whether it be from a directional light, point light or spotlight) gets abruptly cut off and lighting does not look continuous. Visually, this looks exactly like the first image in this thread, where the bounce light from the sun is hitting the floor and gets abruptly cut off. The first 2 row of tile on the right seem fine (look orangish due to the bounce) but the ones in the middle are dark.

also having another lightmass issue where the indirect lighting looks blocky. The lightmap resolution of each mesh is set to 512 which I think should be more than sufficient. In the image I have just used the cube shape that comes with the starter content and placed a spot light, changed the lightmap res of the cube to 512 and built lighting. I can understand that the indirect illumination isn’t going to have smooth gradients but I would expect that at the pixel level and not at the mesh level. Each “block” you see in the image is actually a copy of the cube mesh as shown by the selection

edit: forgot to mention that the light is a static light. But the issue remains the same with a stationary light.

I have included only the map above. To open the map properly, just create a blank project with starter content and you should be able to just open the map as it is not using any custom assets. The lightmap resolution for the mesh is overridden in the map file itself.

Hi HypnoticShark,

After loading up the map and looking at the objects UVs it made more sense. I had to export the shape cube to confirm that the Lightmaps were not set up to be tileable/seamless. Essentially what is happening is that the edge is not on a grid point in the UV editor window of a 3D software. This will leave the shadow baked seam that is appearing.

If you take a look at the attached image you can find the ‘Wall_400x300’ that is included with the starter content. This has been setup with correct tileable lightmaps in the 2nd uv channel. I used your same scene as a reference and placed these above the floor you had to demonstrate.

[This information provided on WorldofLevelDesign.com will help you with your own assets.][2]

If you have any other questions feel free to ask!

Thank you!


Ah i see. I guess that would solve that problem but what if the mesh was more complicated? it would involve a lot more work to make everything sit on a grid point so it does not lie in between pixels. I am guessing there is no edge dialation present in the lightmaps and empty areas in the lightmap are just black. Could this be added as a feature than working around the issue by making sure verts sit on grid lines? It would save everyone a lot of work. This is what an edge dilated texture would look like http://pmarjanski.weebly.com/uploads/1/4/2/4/14242102/5191797_orig.jpg?0. Some more info on the same http://wiki.polycount.com/EdgePadding There is a photoshop action at the bottom of the polycount page that performs the padding in photoshop using the alpha channel as a mask

Also there appear to be seams at the back of your image, would it it be possible to provide the map file so that I can take a look at it locally? Thanks!


I used the wall 400x300 mesh and I am still having this issue. There are no seams where the mesh is affected by direct lighting which is great, but the indirect part is still blocky

Realistically for a complicated mesh it shouldn’t be that much more complicated. The edges are where you want make sure you are on a grid point more than anywhere else. The reason being that if it’s in between a grid point it’s rendered black if it’s on a grid point white. If you want to have a good seamless lightmap for modular walls this is a good way to go about it.

Alternatively you could do what others (myself included) have done and use something that would sit on that seam as a separate mesh to hide the fact that it’s got the seam. The scifi hallway does this by having pipes sitting over seams on one wall that I noticed.


I understand, but it is still a lot more work when it can be solved by just padding the lightmap, I wouldn’t mind manually doing this if I were given access to the lightmap assets. It is a much faster fix than going through every tileable game asset and modifying uvs to make sure they sit on the grid points and then reimporting everything. That would solve the seam issue but in the image I provided, it doesn’t look like seams are the only issue, the whole scene is lit by a directional light and a skylight and if the uvs are set up right for the wall 400x300 mesh this issue should not be occurring. Each mesh looks like it has its own indirect color which appears to be a different problem

Hi HypnoticShark,

The issue is within Lightmass at the moment. It’s something that is known. The ultimate resolution for now would be a workaround to solve the issue. That would be to use other meshes to conceal seams or to only have modular assets seams be at wall corners.

I’m always interested in developing using Modularity with walls and proper lightmaps, so you as I get more information or discover things that will help I will post updates here for tips and advice. :slight_smile:

Thanks for your patience!



I had a similar issue in a environment I am creating (see https://answers.unrealengine.com/questions/55062/lighting-issues.html)

I may have found a fix. (I’m using 4.3)

I came across this video - YouTube and after following the steps this is what I got


It’s a little buggy in places (see images)

Red colour from other side of the wall bleeding through

Red colour being too bright (should be the same as the floor colour)

Also some areas are still too dark, but I should be able to offset this with point lights and white textures are too bright.

I can either keep posting updates here or start a new thread?

better keep here so Epic can get all the related info in one place. Hopefully they’ll change their mind and try to fix this earlyer.

Ok I’ll keep updating here, hopefully a Epic dev will see this and figure something out, all I can do is keep tweaking settings.

As I also get colour from the floor bouncing onto the ceiling.

So while it fixes the lightmap seems, I get other issues cropping up.

This is not a fix for the problem because they are handled differently. LPV’s use dynamic lighting, thus you are not seeing the baked lighting edge seams in the previous posts.

Keep in mind that LPV is still an experimental feature that is being developed. It is known to have issues that will be addressed when the feature moves to a ship-ready feature.

Thank you!


So… I’m not sure if I understood this correctly.

The cause of this lightmap color continuity issue is that I don’t have the edges of the meshes aligned to the grid in the UV? I suppose that there’s no other way to solve this… I think that this may be quite difficult with more complex meshes.

I got this problem with a few wall variations in my tileset, and I just wanted to check if I could solve this without fixing the UV of every wall.

Thanks for your help!

@anonymous_user_fd378872 Marcos

Wow, this is an old post!

UV tricks that are posted around about snapping to the grid or doing the grid size based on 1/LightmapResolution - 2 won’t likely show you any improvements either. It can help in some instances, but it’s not going to get rid of the shading differences 100%.

This particular issue is caused by indirect lighting with precomputed lighting. If the faces are not connected via the UV, lightmass will not know how to match the shading on the edges of each mesh since they are handled on different cpu threads when they are being processed. This problem doesn’t have a solution yet and I know it’s something that we’d like to work on fixing, but there isn’t any planned timeframe for it, unfortunately. The best option right now is to use a single floor mesh for a room/area or ones that can hide the shading artifact by using other geometry to cover the seams.

While adjusting the UVs can help to some degree, it’s not full-proof and can sometimes prove to be wasted time only to see it didn’t resolve the issue. Also, by using fewer modular planar pieces (walls, ceilings, floors) you reduce drawcalls. I’m not against modular design, but depending on the geometry and if it’s just a flat polygon with a normal map you’ll run into many more issues than.